[FFmpeg-devel] [PATCH] Increase MOV_TIMESCALE for higher precision

[Andrey Rikunov]

Gyan, thanks for clarification! It is all exactly as you described. I
thought to set MOV_TIMESCALE to either 60kHz or 90kHz as both are
divisible by most common fps values. And x10 increase is for further
precision in conversion to seconds. Say it's needed to
write segmentDuration=289.4892 sec in elst to start presentation time from.
Using timescale of 1000 we lose 0,0002 sec which turns into pts drift by 6
points for video track timescale of 30kHz.

IMHO there is no need to pull MOV_TIMESCALE up to cli arg because there is
no need to control it. The only requirement is best precision. What do you
think?

On Wed, Mar 24, 2021 at 2:42 PM Gyan Doshi <ffmpeg at gyani.pro> wrote:

>
>
> On 2021-03-24 15:45, Jan Ekström wrote:
> > On Wed, Mar 24, 2021 at 7:30 AM Gyan Doshi <ffmpeg at gyani.pro> wrote:
> >>
> >>
> >> On 2021-03-24 03:38, Andrey Rikunov wrote:
> >>> ---
> >>>    libavformat/movenc.h | 2 +-
> >>>    1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavformat/movenc.h b/libavformat/movenc.h
> >>> index cdbc407..8a152c0 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 60000
> >> Instead of hardcoding it, add an option to allow the user to set it.
> > if MOV still needs its timescale override of 1:1000 for some
>
> To be clear, the MOV_TIMESCALE refers to the timescale written in the
> mvhd atom in all products of movenc.c. It is distinct from the
> stream/track timescales. The mvhd value is the basis for the duration
> field in edit list entries but not media time which is denominated in
> terms of track timescale ( what video_track_timescale targets but only
> for video streams). Users in the past have asked for a change (usually
> to 600) because some Apple products (FCP ?) only work well with 600 for
> mvhd timescale. There is no strict inter-relation or constraint across
> mvhd and the trak timescales, so auto_adjust_timescale shouldn't force
> it in any hardcoded manner.
>
> Regards,
> Gyan
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".