[FFmpeg-devel] [RFC][PATCH] ticks_per_frame / timebase

[Michael Niedermayer]

On Sat, Feb 28, 2009 at 11:17:08AM +0100, Ivan Schreter wrote:
> Michael Niedermayer wrote:
>> On Fri, Feb 27, 2009 at 07:53:58PM +0100, Ivan Schreter wrote:
>>   
>>> Michael Niedermayer wrote:
>>>     
>>>> On Fri, Feb 27, 2009 at 06:47:42PM +0100, Ivan Schreter wrote:       
>>> Independent of that, frame rate is computed wrong for field picture 
>>> stream,     
>>
>> yes
>> what is the problem with parser.repeat_pict == 0 to detect that
>> (possibly with ticks_per_frame == 2) ?
>>
>>   
> Nothing in general, works as well. It just looks like a hack to me... 

> But 
> anyway, patch attached.

looks acceptable


>
>
>>> As for the MOV, my MOV is missing timing info! I just noticed now     
>>
>> alot of h264 are sadly missing it ...
>>
>>   
> I think I'll add some logic to generate timestamps in case timing info is 
> missing on the lines of adding 1+repeat_pict to dts for each frame and 
> letting output delay undefined. This will work for mov and at least for 
> progressive H.264 in mpegts, 


> since mpegts has to code both pts and dts for 
> frames where dts != pts.

there is no such requirement in mpeg-ts, nor in actual streams,
the requirement is then WHEN a timestamp is coded and dts!=pts then
both must be coded, that is its not allowed to store just one
timestamp if they differ, it is allowed to store none when they
differ.


>
> Anything speaking against it?

it wont work
the difference in dts is not the repeat_pict of the current packet.
example:

stored:(type,repeat) I4 P3 .... B2 .. P1 ... B0
presented:              I4 .... B2 .. P3 ... B0

in that respect iam not sure if your patch is truly correct either but as
its just in the framerate guessing code (which is as the name says just
guessing) and it seems to work out in all normal
examples i considered of frame and field mixes i guess it should work for
the normal cases


>
> However, interlaced field-picture stream without timing info in mpegts will 
> be still broken, as the second field of a delayed frame DOESN'T code 
> pts/dts, even though they are different. I didn't find an explanation in 
> standard yet and currently don't have any patch to address it.

read H.222.0, the conditional coding of timestamps allows timestamps to be
ommited in several cases SEIs are just one. The other cases also provide
ways to generate the missing timestamps.


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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- 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/20090228/90f1fc44/attachment.pgp>