On 24-01-2019 05:25 PM, Carl Eugen Hoyos wrote:
ffmpeg | branch: master | Carl Eugen Hoyos <ceffm...@gmail.com> | Thu Jan 24
12:52:50 2019 +0100| [406f8d9c9a10267299d6eefd0672bd4f4c9342b4] | committer: Carl
Eugen Hoyos
lavf/movenc: Mention video_track_timescale as option to fix the timescale.
Smarter improvements for this error message were suggested in the past
but this is certainly an improvement.
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=406f8d9c9a10267299d6eefd0672bd4f4c9342b4
---
libavformat/movenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index adaff4c5e9..65be2968a1 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2741,8 +2741,8 @@ static int mov_write_mdhd_tag(AVIOContext *pb,
MOVMuxContext *mov,
if (version != 0 && track->mode == MODE_MOV) {
av_log(NULL, AV_LOG_ERROR,
"FATAL error, file duration too long for timebase, this file will
not be\n"
- "playable with quicktime. Choose a different timebase or a
different\n"
- "container format\n");
+ "playable with QuickTime. Choose a different timebase with "
+ "-video_track_timescale or a different container format\n");
}
return 32;
A few comments:
1) Am I correct in thinking that after printing the error msg, the muxer
carries on? If so, the ffmpeg log will get populated with other
messages, and since this will likely be a very large file, the user may
never see the message for enough time (or at all) to register it.
Shouldn't we abort at this point?
2) The error message doesn't provide context for the message. QT only
supports 32 bits for duration, and track duration is too large to be
recorded. We should print the timescale, the duration, and explain the
limitation. And that the 'different timebase' (sic; --> timescale)
should be smaller. Or better, a viable timescale ceiling can be printed.
3) If the offending track is audio, then nothing can be done, the
message should reflect that (and the muxer should quit).
4) Unrelated to this commit, the returned size is 32 but the box size
may be 44. An oversight in a3a80ddc, I suppose.
Gyan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
