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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
