[FFmpeg-devel] [FFmpeg-soc] GSoC 2008 qualification task TS Muxer
Thorsten Jordan
tjordan
Wed Mar 19 12:57:34 CET 2008
Baptiste Coudurier schrieb:
> Hi,
>
> Thorsten Jordan wrote:
>> M?ns Rullg?rd schrieb:
>>> Baptiste Coudurier wrote:
>>>> Hi,
>>>>
>>>> I don't think extracting duplicated code from mpegenc.c and mpegtsenc.c
>>>> is that hard. H264 muxing might be slightly harder.
>>> Assuming the H264 data is correctly encoded for TS muxing (i.e. has
>>> AUD NAL units and the like), it shouldn't be any harder to mux than
>>> anything else. All that's needed is a descriptor in the PMT. The
>>> PES packetisation is no different from MPEG2.
>> Just as reminder: you only have to handle the extra pitfalls of PAFF
>> encoded h264: the stream timebase is e.g. 1/25 even if there are 50
>> fields with PAFF, and there are 50 access units to mux. Either the
>> bottom fields get same pts/dts as the top fields or +1/2 frame duration
>> - in that case it is harder to write the muxer.
>> As far as I know, the two fields of a PAFF-coded frame don't need to be
>> consecutive in the stream, and can be mixed with other frames - so its
>> hard to compute PTS/DTS for a bottom field. Using the values from
>> av_interleaved_write_frame() or AVPacket the bottom field will get the
>> same PTS/DTS as the topfield.
> And here you scared everyone ;)
the most troublesome part is to partition the stream into access units
and to generate pts/dts for them, and that is done outside the muxer for
ffmpeg, so the muxer itself isn't that hard to write, indeed. It would
need a more advanced h264-parser than current one though.
To solve the PAFF problem one could choose an appropriate AVStream time
base like 1/50 or even 1/90kHz, and provide per-field pts/dts.
Just some ideas, nothing to be scared off ;)
--
Regards, Thorsten
More information about the ffmpeg-devel
mailing list