[gstreamer-bugs] [Bug 337026] oggmux doesn't set EOS properly

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=337026
 GStreamer | gst-plugins-base | Ver: HEAD CVS





------- Comment #6 from James "Doc" Livingston  2006-06-23 08:52 UTC -------
Created an attachment (id=67880)
 --> (http://bugzilla.gnome.org/attachment.cgi?id=67880&action=view)
possible patch

I've taken a look at this, and come up with this patch. I don't have a full
understanding of oggmux, so it might be the wrong approach, but I think it
makes sense. The patch is against cvs, but I'm having issues with oggdemux
using core and -base from cvs so I've only tested against 0.10.8.


Basically it changes oggmux from holding a single buffer for each pad, to
holding two, and doesn't release the data to be muxed until there is two
buffers (or EOS was received on the pad).

When the first buffer is received for a pad it is put in next_buffer, and if
that pad is the best, it will continue waiting for for data. When collect pads
next calls the callback, pad->next_buffer will be moved across to pad->buffer
and next_buffer filled. If the pad is now the best it can pull the data as
current versions do.

When EOS is reached pad->next_buffer is still moved across to pad->buffer, but
next_buffer isn't filled (as there is no more data). This means that the code
can check pad->next_buffer to see whether there ismore data, and set the
packet's EOS flag appropriately.


I haven't done any real testing, so this needs to be checked to ensure that it
fixes the problem correctly and doesn't break any other situations, such as
chained vorbis streams, theora, etc.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.