[FFmpeg-devel] Possible bug in h264.c ff_h264_decode_nal

Michael Niedermayer michaelni at gmx.at
Wed Nov 7 14:18:20 CET 2012


On Wed, Nov 07, 2012 at 07:13:16AM -0500, David R Robison wrote:
> I am trying to play video from a Pelco camera and it is not decoding right. It appears that the entire SPS is not being parsed. In the h264.c file the ff_h264_decode_nal function the following is defined.
> 
> #define STARTCODE_TEST \
>           if (i + 2 < length && src[i + 1] == 0 && src[i + 2] <= 3) {     \
>               if (src[i + 2] != 3) {                                      \
>                   /* startcode, so we must be past the end */             \
>                   length = i;                                             \
> } \
> break; \
>           }
> 
> However, it seems to me from the documentation that the start code will either end with a 1 or a 3. If I change the function to
> 
> #define STARTCODE_TEST \
>           if (i + 2 < length && src[i + 1] == 0 && (src[i + 2] == 1 ||
> src[i + 2] == 3)) {     \
>               if (src[i + 2] != 3) {                                      \
>                   /* startcode, so we must be past the end */             \
>                   length = i;                                             \
> }                                                           \
> break;                                                      \
>           }
> 
> Then my video plays fine. Any thoughts on this? Here is the patch file:
> 
> Index: ffmpeg/libavcodec/h264.c
> ===================================================================
> --- ffmpeg/libavcodec/h264.c    (revision 4489)
> +++ ffmpeg/libavcodec/h264.c    (working copy)
> @@ -178,7 +178,7 @@
>        length--;
> 
>    #define STARTCODE_TEST                                                  \
> -        if (i + 2 < length && src[i + 1] == 0 && src[i + 2] <= 3) {     \
> +        if (i + 2 < length && src[i + 1] == 0 && (src[i + 2] == 1 ||
> src[i + 2] == 3)) {     \
>                if (src[i + 2] != 3) {                                      \
>                    /* startcode, so we must be past the end */             \
>                    length = i;                                             \
> 
> 
> One more piece of information. In speaking with the company that makes our RTSP library, they stated that they remove the emulation prevention bytes from the data it copies into the media type. When they leave them in it seems to play. However, it make me wonder if this patch is still valid for ffmpeg.

WIthout having any test sample to look at. If the emulation prevention
is missing how should the startcode search work except by sheer luck ?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121107/e68ed33d/attachment.asc>


More information about the ffmpeg-devel mailing list