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 639484 - oggdemux: problem with savoir.ogg live stream - stays in buffering mode at 0% on transitions
oggdemux: problem with savoir.ogg live stream - stays in buffering mode at 0%...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-01-14 01:06 UTC by Tim-Philipp Müller
Modified: 2012-11-29 11:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim-Philipp Müller 2011-01-14 01:06:33 UTC
$ gst-launch-0.10 playbin2 uri=http://modulix.org:8000/savoir.ogg

Watch this stream until the curren clip is over (a few minutes at most), then wait for the next clip to come up.

We get stuck at ~0% in buffering mode. Maybe something to do with chained ogg handling? Filing with oggdemux for now.

vlc plays continues playing just fine.
Comment 1 Vincent Penquerc'h 2011-01-14 11:12:35 UTC
The problem is that the chained streams have the same serialnos (0 and 1), so it looks like the granpos jumps backwards within the same stream.
Comment 2 Vincent Penquerc'h 2011-01-14 11:19:59 UTC
If playing using Totem a downloaded version, it stops after displaying the first frame.
Comment 3 Vincent Penquerc'h 2011-01-14 11:46:47 UTC
After more investigation: Icecast forwards the serialnos unscathed, and the streams being broadcast was created by ffmpeg, which creates serialnos by starting from 0 and incrementing for each logical stream, so concatenating streams created by ffmpeg will yield invalid chained streams.

One solution could be to modify Icecast to rewrite serialnos to avoid it creating invalid chained streams (at least wrt serialnos) regardless of the input serialnos.
Comment 4 Vincent Penquerc'h 2011-01-14 17:35:01 UTC
In fact, it seems all chained streams have problems.
A test one with proper serialnos plays the first part, then only parts of the second one, a few frames here and there and largeish pauses in between.
Comment 5 Vincent Penquerc'h 2011-01-21 16:30:43 UTC
For the record, I found that disabling the passthrough mode in gststreamsynchronizer.c makes it all work fine.
Comment 6 Tim-Philipp Müller 2012-11-29 11:50:04 UTC
I believe this (chained oggs, with or without video) works fine in 1.0 in general now, and if the streams are clearly broken, I'm not sure it's worth fixing unless it's a more wide-spread issue (wget on the url EOSes after a few hundred kB, so clearly there are other server side issues..).