Re: [FFmpeg-devel] [PATCH] libavformat/movenc : Change MOV_TIMESCALE from 1000 to 600

[Mark Burton]

On 18 Mar 2018, at 07:52, Mark Burton  wrote:
> On 14 Mar 2018, at 23:20, Michael Niedermayer  > wrote:
>> for other cases 600 is less accurate
>> for example input that uses timestamps in ms precission
>> like flv
>> but also 3/1001 will be less precisse
> 
> In the case of a Quicktime encoder, a 3/1001 frame rate encode would 
> still have a Movie Header timescale of 600, but a video track timescale of 
> 2997. Since ffmpeg allows us to specify the video_track_timescale, this 
> output could still be achieved.
> 
> As for flv and formats that use ms precision, I’ll freely admit thats not 
> something I work with so am not in a position to comment. However, would 
> these formats not also have the benefit of the current flag to set 
> video_track_timescale?

Or go with 1200, which is more accurate for ms precision formats and also works 
for all major frame rates.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/movenc : Change MOV_TIMESCALE from 1000 to 600

[Mark Burton]

On 14 Mar 2018, at 23:20, Michael Niedermayer  wrote:
> for other cases 600 is less accurate
> for example input that uses timestamps in ms precission
> like flv
> but also 3/1001 will be less precisse

In the case of a Quicktime encoder, a 3/1001 frame rate encode would still 
have a Movie Header timescale of 600, but a video track timescale of 2997. 
Since ffmpeg allows us to specify the video_track_timescale, this output could 
still be achieved.

As for flv and formats that use ms precision, I’ll freely admit thats not 
something I work with so am not in a position to comment. However, would these 
formats not also have the benefit of the current flag to set 
video_track_timescale?

Thanks
Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/movenc : Change MOV_TIMESCALE from 1000 to 600

[Mark Burton]

On 14 Mar 2018, at 23:20, Michael Niedermayer  wrote:
> is there something that i am missing or can this simply
> be computed from the input timebases instead of being
> a fixed value ?
> so its accurate for the input when that is possible
> and only some fixed value when that is not possible

I think that would be a much better solution. Unfortunately, I don’t have the 
skill to write that kind of patch.
If anyone has any ideas for this patch, would be great to see this tested and 
potentially applied.

Thanks Michael.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/movenc : Change MOV_TIMESCALE from 1000 to 600

[Michael Niedermayer]

On Sat, Mar 10, 2018 at 02:38:17PM +, Mark Burton wrote:
> On 9 Mar 2018, at 01:26, Carl Eugen Hoyos  wrote:
> > This breaks fate, our regression testing suite (my mistake).
> > To download the test-suite:
> > $ make SAMPLES=fate-suite fate-rsync
> > $ make SAMPLES=fate-suite GEN=1 fate
> > This changes the values for fate, then commit again with:
> > $ git commit tests libavformat
> 
> 
> Thanks Carl, I hope the below is now correct.
> 
> From 0c73563d06c05245ecf8bcaf64bc1c2809f375e4 Mon Sep 17 00:00:00 2001
> From: mwjburton 
> Date: Sat, 10 Mar 2018 14:33:02 +
> Subject: [PATCH] libavformat/movenc : Change MOV_TIMESCALE from 1000 to 600
> 
> Changing the MOV_TIMESCALE value from 1000 to 600 results in
> files that seek accurately in professional Quicktime software. This is
> due to the fact 600 is cleanly divisible by more frame rates than 1000, for
> example 24fps and 30fps. The Quicktime specification default is set to 600
> for this reason. When set to 1000 seeking can be inaccurate for these fame
> rates.

for other cases 600 is less accurate
for example input that uses timestamps in ms precission
like flv
but also 3/1001 will be less precisse

is there something that iam missing or can this simply
be computed from the input timebases instead of being
a fixed value ?
so its accurate for the inpiut when that is possible
and only some fixed value when that is not possible

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/movenc : Change MOV_TIMESCALE from 1000 to 600

[Mark Burton]

On 9 Mar 2018, at 01:26, Carl Eugen Hoyos  wrote:
> This breaks fate, our regression testing suite (my mistake).
> To download the test-suite:
> $ make SAMPLES=fate-suite fate-rsync
> $ make SAMPLES=fate-suite GEN=1 fate
> This changes the values for fate, then commit again with:
> $ git commit tests libavformat


Thanks Carl, I hope the below is now correct.

From 0c73563d06c05245ecf8bcaf64bc1c2809f375e4 Mon Sep 17 00:00:00 2001
From: mwjburton 
Date: Sat, 10 Mar 2018 14:33:02 +
Subject: [PATCH] libavformat/movenc : Change MOV_TIMESCALE from 1000 to 600

Changing the MOV_TIMESCALE value from 1000 to 600 results in
files that seek accurately in professional Quicktime software. This is
due to the fact 600 is cleanly divisible by more frame rates than 1000, for
example 24fps and 30fps. The Quicktime specification default is set to 600
for this reason. When set to 1000 seeking can be inaccurate for these fame
rates.
---
 libavformat/movenc.h   |  2 +-
 tests/ref/acodec/alac  |  2 +-
 tests/ref/acodec/pcm-s16be |  2 +-
 tests/ref/acodec/pcm-s24be |  2 +-
 tests/ref/acodec/pcm-s32be |  2 +-
 tests/ref/acodec/pcm-s8|  2 +-
 tests/ref/fate/adtstoasc_ticket3715|  4 +--
 tests/ref/fate/binsub-movtextenc   |  2 +-
 tests/ref/fate/copy-psp|  6 ++--
 tests/ref/fate/copy-trac236|  2 +-
 tests/ref/fate/copy-trac3074   |  2 +-
 tests/ref/fate/gaplessenc-itunes-to-ipod-aac   |  8 ++---
 tests/ref/fate/gaplessenc-pcm-to-mov-aac   |  2 +-
 tests/ref/fate/movenc  | 48 +-
 tests/ref/lavf-fate/mov_qtrle_mace6|  2 +-
 tests/ref/lavf/ismv|  6 ++--
 tests/ref/lavf/mov | 14 
 tests/ref/vsynth/vsynth1-avui  |  2 +-
 tests/ref/vsynth/vsynth1-dnxhd-1080i   |  2 +-
 tests/ref/vsynth/vsynth1-dnxhd-1080i-10bit |  2 +-
 tests/ref/vsynth/vsynth1-dnxhd-1080i-colr  |  2 +-
 tests/ref/vsynth/vsynth1-dnxhd-hr-hq-mov   |  2 +-
 tests/ref/vsynth/vsynth1-dnxhd-hr-lb-mov   |  2 +-
 tests/ref/vsynth/vsynth1-dnxhd-hr-sq-mov   |  2 +-
 tests/ref/vsynth/vsynth1-mov-bgr24 |  2 +-
 tests/ref/vsynth/vsynth1-mov-bpp15 |  2 +-
 tests/ref/vsynth/vsynth1-mov-bpp16 |  2 +-
 tests/ref/vsynth/vsynth1-mpeg4 |  2 +-
 tests/ref/vsynth/vsynth1-prores|  2 +-
 tests/ref/vsynth/vsynth1-prores_ks |  2 +-
 tests/ref/vsynth/vsynth1-qtrle |  2 +-
 tests/ref/vsynth/vsynth1-qtrlegray |  2 +-
 tests/ref/vsynth/vsynth1-svq1  |  2 +-
 tests/ref/vsynth/vsynth1-vc2-420p  |  2 +-
 tests/ref/vsynth/vsynth1-vc2-420p10|  2 +-
 tests/ref/vsynth/vsynth1-vc2-420p12|  2 +-
 tests/ref/vsynth/vsynth1-vc2-422p  |  2 +-
 tests/ref/vsynth/vsynth1-vc2-422p10|  2 +-
 tests/ref/vsynth/vsynth1-vc2-422p12|  2 +-
 tests/ref/vsynth/vsynth1-vc2-444p  |  2 +-
 tests/ref/vsynth/vsynth1-vc2-444p10|  2 +-
 tests/ref/vsynth/vsynth1-vc2-444p12|  2 +-
 tests/ref/vsynth/vsynth2-avui  |  2 +-
 tests/ref/vsynth/vsynth2-dnxhd-1080i   |  2 +-
 tests/ref/vsynth/vsynth2-dnxhd-1080i-10bit |  2 +-
 tests/ref/vsynth/vsynth2-dnxhd-1080i-colr  |  2 +-
 tests/ref/vsynth/vsynth2-dnxhd-hr-hq-mov   |  2 +-
 tests/ref/vsynth/vsynth2-dnxhd-hr-lb-mov   |  2 +-
 tests/ref/vsynth/vsynth2-dnxhd-hr-sq-mov   |  2 +-
 tests/ref/vsynth/vsynth2-mov-bgr24 |  2 +-
 tests/ref/vsynth/vsynth2-mov-bpp15 |  2 +-
 tests/ref/vsynth/vsynth2-mov-bpp16 |  2 +-
 tests/ref/vsynth/vsynth2-mpeg4 |  2 +-
 tests/ref/vsynth/vsynth2-prores|  2 +-
 tests/ref/vsynth/vsynth2-prores_ks |  2 +-
 tests/ref/vsynth/vsynth2-qtrle |  2 +-
 tests/ref/vsynth/vsynth2-qtrlegray |  2 +-
 tests/ref/vsynth/vsynth2-svq1  |  2 +-
 tests/ref/vsynth/vsynth2-vc2-420p  |  2 +-
 tests/ref/vsynth/vsynth2-vc2-420p10|  2 +-
 tests/ref/vsynth/vsynth2-vc2-420p12|  2 +-
 tests/ref/vsynth/vsynth2-vc2-422p  |  2 +-
 tests/ref/vsynth/vsynth2-vc2-422p10|  2 +-
 tests/ref/vsynth/vsynth2-vc2-422p12|  2 +-
 tests/ref/vsynth/vsynth2-vc2-444p  |  2 +-
 tests/ref/vsynth/vsynth2-vc2-444p10|  2 +-
 tests/ref/vsynth/vsynth2-vc2-444p12|  2 +-
 tests/ref/vsynth/vsynth3-dnxhd-1080i-10bit |  2 +-
 tests/ref/vsynth/vsynth3-dnxhd-1080i-colr  |  2 +-
 tests/ref/vsynth/vsynth3-dnxhd-hr-hq-mov   |  2 +-
 tests/ref/vsynth/vsynth3-dnxhd-hr-lb-mov   |  2 +-
 

Re: [FFmpeg-devel] [PATCH] libavformat/movenc : Change MOV_TIMESCALE from 1000 to 600

[Carl Eugen Hoyos]

2018-03-09 0:26 GMT+01:00, Mark Burton :
> From 9c3cb06bb869e33daaf0c0dacfb4fa66d18a5722 Mon Sep 17 00:00:00 2001
> From: mwjburton 
> Date: Thu, 8 Mar 2018 22:58:31 +
> Subject: [PATCH] libavformat/movenc : Change MOV_TIMESCALE from 1000 to 600
>
> Changing the MOV_TIMESCALE value from 1000 to 600 results in
> files that seek accurately in professional Quicktime software. This is
> due to the fact 600 is cleanly divisible by more frame rates than 1000, for
> example 24fps and 30fps. The Quicktime specification default is set to 600
> for this reason. When set to 1000 seeking can be inaccurate for these fame
> rates.
>
> ---
>  libavformat/movenc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/movenc.h b/libavformat/movenc.h
> index ca2a9c9722..b7fc2c029d 100644
> --- a/libavformat/movenc.h
> +++ b/libavformat/movenc.h
> @@ -29,7 +29,7 @@
>
>  #define MOV_FRAG_INFO_ALLOC_INCREMENT 64
>  #define MOV_INDEX_CLUSTER_SIZE 1024
> -#define MOV_TIMESCALE 1000
> +#define MOV_TIMESCALE 600

This breaks fate, our regression testing suite (my mistake).
To download the test-suite:
$ make SAMPLES=fate-suite fate-rsync
$ make SAMPLES=fate-suite GEN=1 fate
This changes the values for fate, then commit again with:
$ git commit tests libavformat

Sorry, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel