On 2021-03-24 15:45, Jan Ekström wrote:
On Wed, Mar 24, 2021 at 7:30 AM Gyan Doshi <ffm...@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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
