[FFmpeg-devel] GoC 2008 and H264 SVC decoder

[Thorsten Jordan]

Michael Niedermayer schrieb:
> On Tue, Mar 25, 2008 at 06:03:22PM +0200, Robert Marston wrote:
>> Michael Niedermayer wrote:
>>> Well strictly we have a AVParser for h.264 it just doesnt fix the timestamps.
>>> And yes it would be usefull, h264 in mpeg-ps/ts needs it, currently it
>>> produces random timestamps from the user apps point of view though
>> I would like to attempt the AVParser for h.264 as one of the 
>> qualification tasks but I am afraid I am unfamiliar with how FFMPEG 
>> parsing works. I fear I may be barking up the wrong tree here so perhaps 
>> someone can point me in the right direction. I believe 
>> libavcodec/h264_parser.c is responsible for finding an H.264 frame and 
>> libavcodec/parser.h is the base for all parsers implemented? If this is 
>> the case I am not sure where exactly or how the time stamps are being 
>> set randomly?
> 
> Well starting from "outside", there is 
[...]
> PS: the timestamps are in AVCodecParserContext which is accessible from
> the parser. If this is insufficient the API for parser_parse() or other
> functions could be changed.

sorry, there is even one more thing i stumbled upon:

Some sources for h264 files with B-frames (AVI and it seems so MP4s as
well) have monotonous PTS values stored (PTS == DTS), so they are not in
presentation order.

If one wants to remux the data (copying the elementary stream, but not
recoding it), this will result in a problem for other output formats (i
am thinking of Transport stream muxer), where it would be important to
have correct PTS values representing presentation order.

Some code in between needs to fix this - question is if that extra load
should be put on the parser as well?


PS:
Another aspect of that is that the h264_mp4toannexb bitstream filter
converts h264 from packet mode to Annex B stream mode by inserting start
codes, implanting the extra data to the stream. However it doesn't also
add access unit delimiters that are usually found in h264 data from
Transport streams. To fix that it would need to check all slice_type
values of all slices of a frame (packet) and compute the
primary_pic_type field for the AUD NAL from it...

-- 
Regards, Thorsten