[FFmpeg-devel] GoC 2008 and H264 SVC decoder

[Thorsten Jordan]

Michael Niedermayer schrieb:
> 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:
[...]
>> 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 ...
I agree. I suppose AVI is the only problematic container then? ogm, mkv,
asf, mov etc. are all ok? good to know...

> 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.
thanks for the hint

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

I agree that the spec must be followed. I haven't checked the spec if
such an AUD would be needed - but the spec surely doesn't forbid it.

That is why i proposed adding an AUD between in frame/field in the h264
stream when muxing to TS (or other formats), as it seems common on other
TS muxers.

If its added in another bitstream filter or the muxer itself would make
no difference on the result and the mp4toannexb filter is made for a
different task - that is right.

But using a second bitstream filter would mean another copy of the whole
stream - that is already copied in mp4toannexb. Would be nice to avoid
that. Maybe the muxer can do it better - the question is then if the
muxer should be extended by handling format-specific stuff (the PES
muxer that is).

-- 
Regards, Thorsten