GNOME Bugzilla – Bug 764726
dashdemux: fix default suggestedPresentationDelay
Last modified: 2017-03-02 18:12:42 UTC
When applying default value of suggestedPresentationDelay, the value should be subtracted from current time, not added to it. When streams setup is performed and live point is calculated, we have to go to the wall clock (current time) minus suggestedPresentationDelay, if we try to start with current time plus suggestedPresentationDelay, we would be asking for future stream, which has not yet been recorded.
Created attachment 325533 [details] [review] fix
Review of attachment 325533 [details] [review]: ::: ext/dash/gstdashdemux.c @@ -743,3 @@ } else if (dashdemux->default_presentation_delay) { gint64 dfp = - gst_mpd_client_parse_default_presentation_delay (dashdemux->client, Good catch but I also believe the value should be passed as microseconds so it should be multiplied by 1000 as well.
Created attachment 326072 [details] [review] Patch Yes, definitely. Patch with the time conversion from ms to us.
commit 8eb87ce5dc69f44ffe539eb617c27bd389d39ec0 Author: Wojciech Przybyl <wojciech@visla.co.uk> Date: Fri Apr 1 17:42:32 2016 +0100 dashdemux: fix default suggestedPresentationDelay When MPD@suggestedPresentationDelay is not present in the MPD, dashdemux can provide default suggestedPresentationDelay. However when applying default value of suggestedPresentationDelay, the value should be subtracted from current time, not added to it. When streams setup is performed and live point is calculated, we have to go to the wall clock (current time) minus suggestedPresentationDelay, if we tried to start with current time plus suggestedPresentationDelay, we would be asking for future stream, which has not yet been recorded. Also the value needs to be converted from ms to us. https://bugzilla.gnome.org/show_bug.cgi?id=764726