On Wed, Nov 06, 2019 at 11:41:15AM +0000, Kevin Wheatley wrote: > On Tue, Nov 5, 2019 at 4:52 PM Michael Niedermayer > <mich...@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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
