[FFmpeg-devel] [FFmpeg-cvslog] lavf/movenc: Mention video_track_timescale as option to fix the timescale.

[Gyan]

On 24-01-2019 05:25 PM, Carl Eugen Hoyos wrote:
> ffmpeg | branch: master | Carl Eugen Hoyos <ceffmpeg at 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