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

[David R Robison]

Previously it worked because if in h264_ps.c if it overran the VUI 
information it just returned, now it throws an error an rejects the 
packet. However, when I made the change to the STARTCODE_TEST it would 
read the entire SPS correctly. I'll try to get a MKV sample that has the 
data being sent from the RTSP reader into ffmpeg (it is being sent 
throught the ffdshow filters into the ffmpeg decoder). David

David R Robison
Open Roads Consulting, Inc.
103 Watson Road, Chesapeake, VA 23320
phone: (757) 546-3401
e-mail: drrobison at openroadsconsulting.com
web: http://openroadsconsulting.com
blog: http://therobe.blogspot.com
book: http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526

On 11/7/2012 8:18 AM, Michael Niedermayer wrote:
> 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 ?
>
> [...]
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



This email communication (including any attachments) may contain confidential and/or privileged material intended solely for the individual or entity to which it is addressed.
If you are not the intended recipient, please delete this email immediately.