[FFmpeg-devel] [PATCH] movenc: calculate track_duration without packet duration

[Alfred E. Heggestad]

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
>> intact?
>>
>> Does FATE pass?
> 
> Wouldn't the correct fix be to fix the places where duration is *not*
> used?
> 
> 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.
> 

Hi,

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
would be:


    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




/alfred