[gst-devel] Ogg and GStreamer

[in7y118 at public.uni-hamburg.de]

Zitat von Ronald Bultje <rbultje at ronald.bitfreak.net>:

> Hey Benjamin,
> 
> On Thu, 2003-07-31 at 12:55, in7y118 at public.uni-hamburg.de wrote:
> [..]
> > - get this value when encoding in oggmux?
> > - use gst_pad_query for encoding
> 
> No, won't work. Keep in mind that "our" definition of frame in a format
> might be different from Ogg's definition of "frame". So either way,
> oggmux will have to deliver all this itself. No matter how gruesome
> that'll be. We can adapt GStreamer to suit their needs, we can't change
> GStreamer to work as prescribed by them. That's insane.
> 
Ogg and GStreamer use exactly the same definition of "frame". "frame" is a 
format defined by the stream in Ogg and GStreamer.
And Oggmux itself can _never_ deliver it itself, because it does not know about 
any format stored inside it. It must be delivered in some way by the stream.

> > - store this value when decoding in oggdemux?
> > - discard the value when decoding
> 
> Discarding is never a good idea, but since it doesn't seem to provide
> much more info than, say, mpeg, I guess we don't have much of a choice.
> 
> > That's why I was asking for addition of a field inside the buffer struct
> for 
> > the frames/length combination.
> 
> Sounds reasonable, and might be needed for encoding. However, for
> decoding, it won't actually solve the issue, it'll only make it worse,
> since you actually need to fill in *more* fields that you might not know
> (and thus have to retieve using evil hacks or extra elements). So in
> turn of making muxing simpler, you're also making demuxing harder.
> Please don't forget that. :).
> 
I'm not making demuxing harder anywhere. Filling of those fields is optional 
everywhere. Just like timestamp or duration.