[Bug 748316] hlsdemux: The end offset (range_end) of a segment is not calculated properly in the m3u8 parser

[GStreamer (GNOME Bugzilla)]

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

Thiago Sousa Santos <thiagossantos at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #302437|none                        |reviewed
             status|                            |

--- Comment #20 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
Review of attachment 302437:
 --> (https://bugzilla.gnome.org/review?bug=748316&attachment=302437)

Some comments in the code, what do you think? Is stop=0 something we should
worry about?

::: ext/soup/gstsouphttpsrc.c
@@ +1891,3 @@
+
+  if (segment->stop != GST_CLOCK_TIME_NONE) {
+    stop = segment->stop - 1;   /* make stop non-inclusive */

You are actually making it inclusive here.

@@ +1897,3 @@
+    GST_DEBUG_OBJECT (src, "do_seek(%" G_GUINT64_FORMAT "-%" G_GINT64_FORMAT
+        ")", segment->start, (gint64) stop);
+  }

What happens here if stop == 0?

Is this a valid use case? I guess theoretically it is possible to receive a
seek with start=0 and stop=0, not sure if it is useful but having the
segment.stop non-inclusive and stop inclusive doesn't allow us to represent
this case.

Perhaps we want to keep segment_stop as non-inclusive and just subtract one
when adding to the request headers?

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