[FFmpeg-devel] [PATCH] movenc: calculate track_duration without packet duration
Alfred E. Heggestad
alfred.heggestad at gmail.com
Wed Jun 19 16:51:42 EEST 2019
On 19/06/2019 15:36, Derek Buitenhuis wrote:
> On 19/06/2019 06:43, Gyan wrote:
>>> setting track_duration is inconsistent; some times it includes
>>> duration and some times not.
>> It may be best to check the commits for these assignments to see if the
>> inconsistency is deliberate.
>> The track duration is written into the media header box for the track. I
>> also see it being used elsewhere to adjust dts. Do those roles remain
>> Does FATE pass?
> Wouldn't the correct fix be to fix the places where duration is *not*
> Writing the track duration without taking into account the actual
> packet duration of the last packet is just wrong. That's not the
> track's duration, and is in fact very problematic for low frame
> rate files, such a slide shows; QuickTime will cut off at the
> end of the media and track duration, dropping possibly a whole
> slide, for example.
thanks for your comments. I agree that track_duration should
include duration, I will take a look at this tomorrow.
but why do you require that dts > prev_dts + prev_dur when dur
is unknown ? I think this check is too strict. a better check
dts > prev_dts
a very simple example of how to demonstrate this:
$ ffmpeg -y -loglevel info \
-listen 1 -i rtmp://127.0.0.1:1935/live \
-f dash out.mpd
and then use ffmpeg to send FLV/RTMP stream to 127.0.0.1
after some seconds ffmpeg prints this warning:
[mp4 @ 0x7faffe065600] Application provided duration: -2 / timestamp:
1761244 is out of range for mov/mp4 format
More information about the ffmpeg-devel