[gstreamer-bugs] [Bug 320984] [oggdemux] cannot handle multiple chains

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=320984

  GStreamer | gst-plugins-base | Ver: HEAD CVS




------- Comment #30 from Allan  2007-05-14 03:48 UTC -------
Created an attachment (id=88141)
 --> (http://bugzilla.gnome.org/attachment.cgi?id=88141&action=view)
patch

Here's a patch that sort of fixes the problem for me. It only modifies
oggdemux.c. There is still a problem, so maybe someone can pick up where I left
off. Here is what I think was wrong:

First, I am using the virginradio-three-consecutive-chains.ogg file from
comment #1 for testing. It's made of three chains with the following start/stop
timestamps and position in the total file:

start     stop      offset
3:52.80   4:01.39   0:00.00
0:00.00   0:05.52   0:08.59
0:00.00   0:10.53   0:14.11

The total file has length 0:24.64

There were three fixes. First, a newsegment event wasn't being sent in one case
when a chain was started. Second, I removed the code from the patch given
above, though I didn't look into that in detail. Third, the values set in
another newsegment event (when seeking) were wrong: The very first newsegment
event sent happens in the seek code, I think because oggdemux seeks back to the
beginning after having searched the file. The problem is that the timestamps
set are as follows:
3:52.80   4:17.45   0:24.64
ie, it was sending the times for the entire file, not just the first chain. The
sink element was waiting until the 24 seconds were up before running the data
from the second chain. I simply changed the stop time to be based on the
current chain's time. 

My change is incomplete - all the other values there have extra checks and a
more complicated calculation, but I am not sure enough about everything going
on in that code to fix it. I'll look at it when I get more time. Actually, all
those seek calculations seem a bit iffy to me... maybe it's time to revisit bug
344013?

The problem that remains is that there is a split-second gap in output in
between the chains. The timestamps from the newsegments all align perfectly
though, so I suspect that there is some computation which is taking too much
time and holding up the start of the next chain. 

Someone with more knowledge about gstreamer should check all this.. I am a bit
uncertain about a lot of it.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=320984.