[FFmpeg-devel] GoC 2008 and H264 SVC decoder

[Michael Niedermayer]

On Fri, Mar 28, 2008 at 04:44:44PM +0100, Thorsten Jordan wrote:
> 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.

.avi doesnt contain PTS, that is PTS=AV_NOPTS_VALUE _always_.
.mp4 _should_ contain valid PTS. I do not know if all files actually do but
ones which dont are broken AFIAK. We should try to support broken files if
possible but first we must support valid files ...

Also see the genpts code, but note it can not be run by default because it
adds a delay. It is just the last resort if there is insufficient information
to calculate timestamps without analyzing future packets.


[...]

> 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...

Please dont speak about what is "usually" this is totally irrelevant
the only thing which matters is the spec!!! And your patches will be checked
against the spec not what is "usually".

H.222 has several additional constraints to annex.b, these should be
dealt with in a seperate bitstream filter or the PS/TS muxer.
They do NOT belong in a X->annexb bitstream filter.

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- 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/20080328/76c1dd14/attachment.pgp>