Re: [FFmpeg-devel] [PATCH] avformat/movenc: Support for variable timescale in mov containers
On Wed, Nov 06, 2019 at 11:41:15AM +, Kevin Wheatley wrote: > On Tue, Nov 5, 2019 at 4:52 PM Michael Niedermayer > 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".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: Support for variable timescale in mov containers
On Tue, Nov 5, 2019 at 4:52 PM Michael Niedermayer 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. 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). Thanks Kevin ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: Support for variable timescale in mov containers
On Mon, Nov 04, 2019 at 06:42:10PM +, Kevin Wheatley wrote: > This pair of patches work together to facilitate user specified timescales for > the Movie Header Atom 'mvhd', which allows constant sample table durations for > all frame rates. > > Currently there is a fixed timescale of 1000, which is not an even multiple of > all the typical video frame/field rates. This means when performing certain > duration based operations it is possible to be inaccurate. > > The default behaviour is left at the current default defined by MOV_TIMESCALE, > but can be over ridden by using the -mov_timescale option. > > Typical values of 600 would work for 24, 25 and 30 FPS, for 23.976 and other > fractional rates could use 2997 same as Avid (or 24000 though caution > should be used when encoding long durations). > > > Example usage that has better behaviour than the current: > > # Encode 50 frames at 24FPS and concatenate 5 copies > ffmpeg -f lavfi -i smptebars=duration=2.08:size=1920x1080:rate=24 \ > -codec dnxhd -pix_fmt yuv422p -b:v 115M smptebars_dnx_1000.mov > cat < concat_1000.txt > file smptebars_dnx_1000.mov > file smptebars_dnx_1000.mov > file smptebars_dnx_1000.mov > file smptebars_dnx_1000.mov > file smptebars_dnx_1000.mov > EOF > ffmpeg -f concat -i concat_1000.txt -c copy smpte_concat_1000.mov > ffprobe smpte_concat_1000.mov > > The output of ffprobe will show a frame rate of 23.99 due to the effect of the > sample durations in the stts entries. > > With the new option of -mov_timescale set to 600: > > ffmpeg -f lavfi -i smptebars=duration=2.08:size=1920x1080:rate=24 \ > -codec dnxhd -pix_fmt yuv422p -b:v 115M -mov_timescale 600 > smptebars_dnx_600.mov > cat < concat_600.txt > file smptebars_dnx_600.mov > file smptebars_dnx_600.mov > file smptebars_dnx_600.mov > file smptebars_dnx_600.mov > file smptebars_dnx_600.mov > EOF > ffmpeg -f concat -i concat_600.txt -c copy -mov_timescale 600 > smpte_concat_600.mov > ffprobe smpte_concat_600.mov > > The durations all line up, the stts table is smaller and no rounding > issues occur. 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 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. 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".
[FFmpeg-devel] [PATCH] avformat/movenc: Support for variable timescale in mov containers
This pair of patches work together to facilitate user specified timescales for the Movie Header Atom 'mvhd', which allows constant sample table durations for all frame rates. Currently there is a fixed timescale of 1000, which is not an even multiple of all the typical video frame/field rates. This means when performing certain duration based operations it is possible to be inaccurate. The default behaviour is left at the current default defined by MOV_TIMESCALE, but can be over ridden by using the -mov_timescale option. Typical values of 600 would work for 24, 25 and 30 FPS, for 23.976 and other fractional rates could use 2997 same as Avid (or 24000 though caution should be used when encoding long durations). Example usage that has better behaviour than the current: # Encode 50 frames at 24FPS and concatenate 5 copies ffmpeg -f lavfi -i smptebars=duration=2.08:size=1920x1080:rate=24 \ -codec dnxhd -pix_fmt yuv422p -b:v 115M smptebars_dnx_1000.mov cat < concat_1000.txt file smptebars_dnx_1000.mov file smptebars_dnx_1000.mov file smptebars_dnx_1000.mov file smptebars_dnx_1000.mov file smptebars_dnx_1000.mov EOF ffmpeg -f concat -i concat_1000.txt -c copy smpte_concat_1000.mov ffprobe smpte_concat_1000.mov The output of ffprobe will show a frame rate of 23.99 due to the effect of the sample durations in the stts entries. With the new option of -mov_timescale set to 600: ffmpeg -f lavfi -i smptebars=duration=2.08:size=1920x1080:rate=24 \ -codec dnxhd -pix_fmt yuv422p -b:v 115M -mov_timescale 600 smptebars_dnx_600.mov cat < concat_600.txt file smptebars_dnx_600.mov file smptebars_dnx_600.mov file smptebars_dnx_600.mov file smptebars_dnx_600.mov file smptebars_dnx_600.mov EOF ffmpeg -f concat -i concat_600.txt -c copy -mov_timescale 600 smpte_concat_600.mov ffprobe smpte_concat_600.mov The durations all line up, the stts table is smaller and no rounding issues occur. Kevin Wheatley (2): avformat/movenc: Add command line option to set base mov file timescale avformat/movenc: Use base container timescale, instead of hard coded default libavformat/movenc.c | 23 --- libavformat/movenc.h | 1 + 2 files changed, 13 insertions(+), 11 deletions(-) -- 1.8.5.6 0002-avformat-movenc-Use-base-container-timescale-instead.patch Description: Binary data 0001-avformat-movenc-Add-command-line-option-to-set-base-.patch Description: Binary data ___ 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".
