After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 744070 - oggdemux: wrong duration for ogv file
oggdemux: wrong duration for ogv file
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-02-05 20:16 UTC by Tim-Philipp Müller
Modified: 2015-04-03 15:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ogv file (111.70 KB, application/octet-stream)
2015-02-05 20:16 UTC, Tim-Philipp Müller
  Details
fix wrong duration on partial streams with skeleton index (4.39 KB, patch)
2015-03-12 16:05 UTC, Vincent Penquerc'h
none Details | Review
fix wrong duration on partial streams with skeleton index (5.20 KB, patch)
2015-03-13 10:04 UTC, Vincent Penquerc'h
committed Details | Review

Description Tim-Philipp Müller 2015-02-05 20:16:13 UTC
Created attachment 296239 [details]
ogv file

$ gst-play-1.0 /tmp/test.ogv 
Now playing /tmp/test.ogv
00:01.7 / 1:02:19.0

But the clip is only a few second.

Wget-ed from an icecast server.
Comment 1 Vincent Penquerc'h 2015-03-12 15:25:14 UTC
It's getting this large length from the skeleton stream metadata :/
This is really unfortunate as I'm not sure how one tell when skeleton should be ignored, and when not...
Comment 2 Vincent Penquerc'h 2015-03-12 16:05:05 UTC
Created attachment 299215 [details] [review]
fix wrong duration on partial streams with skeleton index

Actually we can.
Comment 3 Sebastian Dröge (slomo) 2015-03-12 16:26:38 UTC
Review of attachment 299215 [details] [review]:

::: ext/ogg/gstoggstream.c
@@ +1487,3 @@
+    /* Do not error out, this will happen when catching stream portions
+       as they are streamed from Icecast */
+    GST_WARNING ("Index offets beyond stream length, ignoring index");

Typo :) offets
Comment 4 Tim-Philipp Müller 2015-03-12 16:32:23 UTC
Would it perhaps make more sense to just assume the file is truncated and clip the index to the available size? We can query the upstream size after all, no?
Comment 5 Vincent Penquerc'h 2015-03-12 16:33:58 UTC
Icecast will keep the headers and send them when you connect, so the stream might not start at offset 0 - there will be a hole at start and you don't know how many bytes.
Comment 6 Tim-Philipp Müller 2015-03-12 16:48:12 UTC
That's a good point. But you can know from the packet numbers if this is the case or not, no? (Not sure if it's worth it, just wondering)
Comment 7 Vincent Penquerc'h 2015-03-12 16:50:17 UTC
You can know there is a hole, but not its byte size, and you really need that for the index to be useful since it's a shortcut though the bisection.
Comment 8 Tim-Philipp Müller 2015-03-12 16:57:39 UTC
Yeah, I meant keep the index and truncate it if there is no hole, otherwise discard it.
Comment 9 Vincent Penquerc'h 2015-03-12 17:01:31 UTC
Oh, I see, you could do that indeed.
The index removal-or-truncation would have to be moved to later, as we don't know if there's any hole yet when the index is being built.
Comment 10 Vincent Penquerc'h 2015-03-13 10:04:31 UTC
Created attachment 299296 [details] [review]
fix wrong duration on partial streams with skeleton index

This version clips or discards based on discontinuity at start.
Comment 11 Vincent Penquerc'h 2015-04-03 15:45:09 UTC
commit a44258dbe888e65da3151132978dc60825173759
Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
Date:   Thu Mar 12 16:01:48 2015 +0000

    oggdemux: fix wrong duration on partial streams with a skeleton index
    
    When a stream has a skeleton index, the stream time is taken from that
    index. However, when part of the stream is captured, the index is
    invalid as its offsets are now wrong. To avoid this, we ignore the index
    when the last offset points beyond the end of the stream (when its
    byte length is known).
    
    https://bugzilla.gnome.org/show_bug.cgi?id=744070