[FFmpeg-devel] [PATCH] avformat/movenc: Support for variable timescale in mov containers

[Michael Niedermayer]

On Wed, Nov 06, 2019 at 11:41:15AM +0000, Kevin Wheatley wrote:
> On Tue, Nov 5, 2019 at 4:52 PM Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> > Assuming this doesnt violate any specifications and assuming that
> > it works with all players.
> > Then it would make sense to select this value automatically based
> > on the stream timestamps or timebases.
> > maybe there could be still a -mov_timescale but with an option for
> > "auto" to autoselect a small one which allows accurate representation
> > of most streams
> 
> Michael,
> 
> thanks for the feedback, I did consider this, but I am not that
> familiar with the code base of FFmpeg to know what the 'right' data
> fields to use are and at what point during the initialisation process
> of the movenc code it is valid to use them.
> 
> There certainly seams to be a number of points at which the code tries
> to compute a lowest common multiple in the general FFmpeg code and a
> number of fields representing timebases, frame rates etc.
> 

> If somebody can help point me at what I should use, then I'm happy to
> add something to automatically determine something.

AVStream.time_base or track->timescale or the fields it is set from 
the code setting it should be a starting point for this.

The lowest common multiple will not work alone.
Because its unbounded and can exceed any limit even 64bit integers
easily

what is simple and might work is to simply write a simple brute force
implementation, just try all values from 500 to 2000 
thats within a factor of 2 of the current default
its only 1500 cases to try with no optimizations so speed should be
a non issue. But this can surely be optimized ...
The case to select could then be the one that can represent most
streams accurately.


> 
> In terms of the specification, the Apple documentation certainly
> recommends the use of 600 on p221 of
> https://developer.apple.com/standards/qtff-2001.pdf for most integer
> frame rates, but as the following section in that document says this
> does not work for 23.976 or 29.97.
> 
> For newer frame rates like 48 and any other number of 'new' content
> types, those number fail so whilst  I'd suggest using the Apple number
> for the well used rates, I guess a computation would be needed for
> other things.
> 
> Finally what about the default behaviour, would it be the old use a
> fixed setting or would we change the default to be automatic with the
> option of explicitly passing in 1000 to mimic the previous behaviour
> if required (plus any updates to fate to account for the change).

i would leave the default for now. So we change one thing at a time
once this had a bit of testing the default should be changed to auto
probably

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20191106/267f6461/attachment.sig>