[Bug 775127] New: hls_demux.testSeekUpdateStopPosition : The unit test that was always wrong

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Sat Nov 26 08:15:30 UTC 2016


https://bugzilla.gnome.org/show_bug.cgi?id=775127

            Bug ID: 775127
           Summary: hls_demux.testSeekUpdateStopPosition : The unit test
                    that was always wrong
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: bilboed at bilboed.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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 !

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list