GNOME Bugzilla – Bug 733369
dashdemux fails to detect end of period
Last modified: 2015-01-16 20:27:38 UTC
Created attachment 281133 [details] [review] Patch to fix segment start times and period end detection. dashdemux fails to detect the end of period when the current period doesn't start at 0s. This seems to be because the period start offset is not added to the calculated segment start in gst_mpdparser_get_chunk_by_index(), but is later compared to the end of period offset into the stream. The attached patch fixes this issue and also a related issue of not progressing in live streams with multiple periods (should only wait for an MPD update if we have finished the last period). I am now seeing another issue which is that the video stops at the end of the period, it looks like the downloaders for the new period aren't running, but I still need to track that down. Anyone have an idea why the video downloads are ceasing?
Do you have example mpds that show those bugs? That would help testing and debugging.
Ping, can you provide an example mpd that causes these issues? Doesn't need to be online, just the mpd file should help understanding the scenario.
I'm just in the process of getting a colleague to set up a dynamic MPD for a pseudo-live test stream (it'll actually be big buck bunny on loop). This should provide a test case for this and other bugs I'm working on. It should hopefully be ready to use in the next day or two.
Sorry this has taken so long, but we have a "live" stream available at http://rdmedia.bbc.co.uk/dash/testmpds/multiperiod/bbb.php This should repeat the first 3 minutes of Big Buck Bunny over and over as though it's a live stream made up from multiple periods. Playback should begin in the second period (got another patch for that), the MPD should reload every minute and will always contain the previous 3 minute period, the current 3 minute period and the next 3 minute period. Unlike a live stream the server will happily serve segments that should not be ready yet, if the service really was live, and that are beyond the end of the period, so be careful to check segment numbers that are being requested (segment numbers should be between 1 and 47). This is because the server is setup to serve the whole of Big Buck Bunny via other MPDs.
We've made some improvements to the MPD, so now instead of repeating the first 3 minutes, it will repeat the 9+ minutes animation, split into 3 equal 3m8.16s periods. So you should see smooth transition in the media from one period to the next and it will jump back to the start again once it's reached the end. Each period has 49 segments in it (1-49, 50-98, and 99-147).
Is this issue still present after latest refactoring? What I see now is that when it gets to the last period it finishes it but it is not able to continue. I suspect it is because of the sudden change in the mpd that doesn't give dashdemux a way to continue sanely.
Created attachment 294436 [details] [review] Fix detection for end of period The problem still exists in the latest git head. This new patch (against current head) detects the period end when period start time != 0. The old patch caused problems with qtdemux by making the segment start time equal to the media time rather than the current period time. The new patch is also simpler.
Thanks for the patch, merged. ommit 6dca8f5ccee70f4fc5df7871efe4d16952731be0 Author: David Waring <david.waring@rd.bbc.co.uk> Date: Tue Jan 13 14:22:02 2015 +0000 dashdemux: Fix detection for the end of segment. The segment start time is calculated as the offset into the current segment. The old condition to detect the end of period (i.e. segment start time > period start + period duration) failed when the period start was not 0 since the segment start time does not take the period start time into account. Fix this detection by only comparing the segment start to the period duration. https://bugzilla.gnome.org/show_bug.cgi?id=733369