[FFmpeg-devel] GoC 2008 and H264 SVC decoder

[Michael Niedermayer]

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 

av_read_frame_internal() which is called to read the next frame
av_read_frame_internal() will then call the demuxer (av_read_packet) to
get the next packet from the demuxer.
That packet will then be feed through 
av_parser_parse() and compute_pkt_fields()
after that timestamps for h.264 in mpeg-ps/ts will often be random trash.

If you look at av_parser_parse() you will see it does some timestamp
reordering so the existing timestamps get associated with the correct
frames (which are output from av_parser_parse().

compute_pkt_fields() then tries to calculate missing timestamps exactly
This goes wrong in various ways for h.264 due to the h264 parser not
setting things like has has_b_frames correctly.
Also compute_pkt_fields() plain does not have enough information to
calculate exact h264 timestamps.

One way to solve this is to implement what is written in H.222 about H264
timestamps in the h264 parser, so that av_parser_parse() returns only
frames/fields with timestamps.

There of course might be other solutions as well ...

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.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080325/0d424944/attachment.pgp>