[Ffmpeg-devel] Re: [PATCH] PKT_FLAG_B

[Baptiste Coudurier]

Hi

Michael Niedermayer wrote:
> [...]
> 
>> I also said I would be really OK for a better alternative and I asked
>> you to propose one...
> 
> looking at the mov/qt specs i cant find any hits for ctts, do you have 
> anything more recent which describes ctts?

ISO media 14496-12 describes in details ctts and stts. Especially the
fact that those can't be negative and that quicktime is creating non
standard files with those negative 'ctts'.

> my feeling though strongly suggests stts == dts, ctts == pts no matter
> what frame type
> so for .mp4 ctts==pts and stts==dts no matter which frame type
> 
> [...]

That is really right. I think I'm just confusing people here. Im not
arguing about 'ctts' and 'stts' values.

Atm current code, as one variable track->hasBframes (maybe wrong name
though), set according to pts/dts difference.

Im just saying that IMHO it is not always correct and writing 'ctts'
atom only when stream really contains B frames might be better.
Im looking for a way to do that.

Situation:
FFmpeg encoder workflow is accurate and almost(b pyramid in x264 does
not work, and xvid encoder produces wrong pts)always produce correct
pts/dts so problem does not occur.

Stream copy workflow is not accurate, and sometimes pts/dts are wrong in
the source or not set (AVI even with -genpts), and got wrongly written
in output file.

Basically what I would like to access the frame type explicitly for GXF
muxer, and for MOV muxer, to write or not 'ctts' atom. Like I said,
having access to AVCodecParser might be a good solution too.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312