2016-10-11 21:06 GMT+02:00 Josh de Kock <j...@itanimul.li>:
> Fixes ticket #5882.
I don't object but I don't think it is correct.
> While it doesn't automatically set the timescale
> for the user as that would destroy data without prompt, it will tell
> the user how they could set the timescale (as this is mostly likely
> what they want).
>
> Signed-off-by: Josh de Kock <j...@itanimul.li>
> ---
>
>>Would it be useful to print the max duration?
> I'm not entirely sure, open to suggestions though.
>
> libavformat/movenc.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index d7c7158..6bada25 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -5677,11 +5677,16 @@ static int mov_write_header(AVFormatContext *s)
> ret = AVERROR(EINVAL);
> goto error;
> }
> - if (track->mode == MODE_MOV && track->timescale > 100000)
> + if (track->mode == MODE_MOV && track->timescale > 100000) {
> + /* NOTE: forcing setting the suggested timescale manually
> means ffmpeg won't destroy
> + * timestamps without explicit instruction. */
> + unsigned int suggested = (unsigned
> int)av_rescale(st->time_base.den, 1000, st->time_base.num);
If we go this way (I am not completely convinced about it), we definitely need
a heuristic that suggests 24000 for 10000000/417083 fps and 30000 if applicable.
> av_log(s, AV_LOG_WARNING,
> "WARNING codec timebase is very high. If duration is
> too long,\n"
> "file may not be playable by quicktime. Specify a
> shorter timebase\n"
> - "or choose different container.\n");
> + "or choose different container. Using
> -video_track_timescale %d\n"
> + "may fix this issue.\n", suggested);
I believe this should also suggest to "force a sane framerate" as an
alternative.
Suggesting video_track_timescale is very useful, thank you!
Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
