[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