GNOME Bugzilla – Bug 775127
hls_demux.testSeekUpdateStopPosition : The unit test that was always wrong
Last modified: 2016-11-26 10:32:50 UTC
This unit test has been failing for a long time... ... but it was also failing almost from the moment it was introduced. Three different behaviours happened over time (going back chronologically): A) Either it outputted too much (4 fragments instead of 3) B) Either it didn't output enough (2 fragments instead of 3) C) Either it did output enough The goal of the unit test is to check the behaviour of just updating the stop position * Playback starts * We then send it a non-flushing seek with a GST_SEEK_TYPE_NONE for the start position and a valid value (3s) for the stop position. i.e. we are telling it to stop when it reaches 3s (instead of playing everything). The expected behaviour is that it should be downloading fragments 1, 2 and 3 (each 1s long). From the very start it was wrong, it was downloading fragment 1, 2 and ...4. But the way the unit test was designed (calculating number of fragments outputted instead of *which* fragments) made it succeed. The way it is failing currently is that it is downloading fragments 1, 2, 2 again and 3. => hlsdemux doesn't seem to take into account the GST_SEEK_TYPE_NONE type => The unit test should be improved/fixed to check the expected downloaded sequence !
Created attachment 340783 [details] [review] hlsdemux: Handle GST_SEEK_TYPE_NONE seek When one is only updating the "stop" position (i.e. non-flushing seek, with GST_SEEK_TYPE_NONE on the "start" (or stop in reverse) position), we only need to store those values instead of moving the current position.
commit 9053a01e723e07607f0f39ac7d7b58322cb0568d Author: Edward Hervey <edward@centricular.com> Date: Sat Nov 26 09:26:36 2016 +0100 hlsdemux: Handle GST_SEEK_TYPE_NONE seek When one is only updating the "stop" position (i.e. non-flushing seek, with GST_SEEK_TYPE_NONE on the "start" (or stop in reverse) position), we only need to store those values instead of moving the current position. https://bugzilla.gnome.org/show_bug.cgi?id=775127