[FFmpeg-devel] [PATCH] Fix mpegtsenc's choking on first H264 start code
michaelni at gmx.at
Sun Sep 18 23:54:59 CEST 2011
On Fri, Sep 10, 2010 at 05:33:58PM +0200, Alexandre Ferrieux wrote:
> On 10/09/2010 17:20, Mike Scheutzow wrote:
> >Alexandre Ferrieux wrote:
> >>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.
i volunteer to implement that, can someone provide me with a testcase
that needs this?
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
You can kill me, but you cannot change the truth.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel