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 th
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
On 18 Mar 2018, at 07:52, Mark Burton wrote:
> On 14 Mar 2018, at 23:20, Michael Niedermayer <mailto:mich...@niedermayer.cc>> wrote:
>> for other cases 600 is less accurate
>> for example input that uses timestamps in ms precission
>> like flv
>> but also 3000
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 profes
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 tes
