[FFmpeg-devel] [PATCH] Fix mpegtsenc's choking on first H264 start code

[Alexandre Ferrieux]

On 10/09/2010 17:20, Mike Scheutzow wrote:
> Alexandre Ferrieux wrote:
>> Hi,
>>
>> It turns out that when muxing an H264 bitstream, mpegts_write_packet
>> has a
>> very crude check on AnnexB start codes. Specifically, it wants a 4-byte
>> 00000001, disallowing the 3-byte 000001 which is also valid and occurs on
>> the first NALU. As a consequence, ffmpeg is currently unable to mux H264
>> into TS:
>>
>> ffmpeg -f h264 -i a.264 -vcodec copy -f mpegts -y a.ts
>>
>> =>
>>
>> [mpegts @ 0xa11cb80]h264 bitstream malformated, no startcode found,
>> use -vbsf h264_mp4toannexb
>>
>> The attached patch restores correct behavior, by also allowing the 3-byte
>> start code, making the above command line work.
>
>
> I don't believe your patch complies with the requirements of the H.264
> spec. Annex B.1.2 *requires* the 4-byte start code for an SPS NAL and
> for the first NAL in a bitstream.
>

Maybe that's being overly tolerant, but in real life when you receive H264 over RTP and packets are lost, it's good to 
be able to resync (eg next time the SPS/PPS are transmitted, followed by an IDR). Currently ffmpeg cannot do that 
because the error from the muxer is fatal.

 > You could maybe make the muxer more flexible about the input it accepts
 > (Baptiste will decide that), but even then the muxer output must contain
 > the extra 0x00 to generate a compliant bitstream.

OK, be my guest.

-Alex