[gst-devel] ogg and friends

[Ronald Bultje]

Hi,

On Wed, 19 May 2004, Thomas Vander Stichele wrote:
> Others have in this thread said that the following should also work:
> - having identity after oggmux
>   ... oggmux ! identity ! filesink
> - having oggmux ! fakesink, and at some point replace fakesink with
> filesink

Actually, that was for rawvorbisenc ! fakesink and then replace
fakesink with oggmux.

I'd say for the cases where it's theoretically possible to get it to work
(and it is here), we should (try). In other cases, of course, we shouldn't
bother too much.

> Suppose we use caps the way Ronald suggested.  Here's what will happen.
> - vorbisenc will create three packets.  These three packets are put into
> one caps value, as a GList of buffers (the packets really need to be
> separate).

I'd put them in three separate properties: codec_data_bos,
codec_data_setup and codec_data_comment. GList is not serializeable
(yet?). Given that the amount, order and type of header packets is defined
and always the same, this shouldn't cause any harm.

> - vorbisenc could, or could not, send out these buffers as GstBuffers as
> well (there are reasons for doing so and reasons for not doing so; we'll
> see about this later)
[..something about ogg..]
> - The same "problem" exists for vorbisenc and theoraenc, although in
> their case saving them to a file directly makes no sense in the first
> place, so you could work around the issue.  For clarity and consistency,
> it would make sense however to make them behave the same way: put header
> packets in the caps on a GList, and mark them with the
> BUFFER_PART_OF_CAPS flag before pushing them out.

Can you explain the clarity and consistency. It'd only make the behaviour
consistent to what's inside the Ogg container. ;). It wouldn't be any more
or less consistent compared to other parts of GStreamer, apart from
(again) Ogg. Let's not worry about it too much.

I'd say don't do it, because it'll require codec-specific handling for
Vorbis in matroskademux, avidemux, their respective muxers and probably
others (can Quicktime contain Ogg?).

> - suppose we try doing this with a caps field served by oggmux that we
> make tcpserversink aware of (which would be ok, since all streaming
> elements would need such a concept).  oggmux would have a "header" caps
> field that contains a GList of GstBuffers where each GstBuffer is one
> complete ogg page.

I wouldn't go for the caps-approach here, but just mark the buffers as a
header (as you propose later). That also fixes the issue of
order-of-buffers that you would face when not using a GList but
separate properties.

> - We could have a caps function that does all of the needed bits
> automatically: given a buffer,
>   - put it in the caps
>   - ref it
>   - mark the buffer with the flag

I think this (apart from the flagging) is already done in gst_caps_set().
I've used that in the past and it works for me.

> - oggmux ! identity ! fakesink, where fakesink is later replaced with
> filesink, for me personally, is a case of "please don't be silly".  If
> you want to deliberately break the framework by doing stupid stuff, it
> will still be possible.  So will doing filesrc ! fakesink, then later
> replacing fakesink with oggdemux ! vorbisdec ! ... break as well.

Like I said above, let's try solving issues we can solve and not bother
too much with unsolvable issues. oggdemux ! fakesink and then replace
fakesink with vorbisdec can be made to work, so let's make that work. The
above is impossible to get to work so let's just not care too much.

Proposal mostly looks good; when can I try out tcpserversink? :).

Ronald