[gst-devel] totem and osssink? (long)

[Benjamin Otte]

Quoting Martin Soto <soto at informatik.uni-kl.de>:

> > It only
> > requires that demuxers send out the same event (refcounted, of course)
> > to all their sink pads. I think all demuxers already do this.
> 
> Hmm, no, it's just the opposite, I guess. When implementing dvddemux, I
> noticed that mpegdemux actually creates a new discont event for every
> pad. I wondered if that was sort of a bug in mpegdemux and checked
> around only to find that other demuxers do the same (admittedly I didn't
> check all of them). I thought it was necessary for some obscure reason
> and proceeded to implement dvddemux the same way. Is there actually a
> reason for doing that? Would it be ok to start changing demuxers to just
> refcount and forward disconts?
> 
You can't just forward disconts, because you have to change the values stored 
in them (the time might not change - though it can, if you use timestamp 
rewriting elements, but most likely the default format will change. Or the 
byte offset or whatever). So you need at least a way to copy them and send on 
the copies.

There's another problem. Imagine some format (let's just call it "ogg"), that 
stores data in chunks (imagine the imaginary format calling them "pages"). 
Those pages are interleaved and ordered, but not guaranteed to have a minimum 
size. All you know about a page is the "granule position" of the end of that 
page. The granule position is different for every format (imagine some format 
called "vorbis" that uses granule_pos = frame_count and some format 
named "theora" that uses granule_pos = (nr_of_last_key_frame << 
some_shift_value) + nr_of_frames_since_last_key_frame). Now in that imaginary 
case the only thing you can seek to is to the page with a grnaule position 
that is bigger than the position seeked to. And the only info you can send in 
a discont is a granule position. You know exactly nothing about the time. And 
you have to send a sicont for every outgoing stream. The timestamps on those 
disconts will never be equal...

> 3. Add a new gst_clock_get_event_time_serial (feel free to suggest a
> nicer name) that receives a serial number and returns the corresponding
> event time. To implement this function, the clock must have an internal
> table, associating serial numbers with event times. When a new serial
> number is seen, the current clock time is stored, and will be returned
> whenever the same serial number is seen again. Values will be discarded
> from the table after a reasonable time (say, 20 seconds). Interestingly
> enough, this makes the "snap to grid" trick unnecessary.
> 
Imagine using more than one clock in your pipeline (for whatever reason). It 
doesn't work in that case. Especially not because elements generating disconts 
most of the time have no reference to clocks (think filesrc).
Though I'm not quite sure I understood this correctly yet.

> Any objections against me implementing this?
> 
If you implement something that works in the general case, I'm all for it. 
However as I said I'm not sure your idea works.
But I'm very interested to review patches :)
Though I still think an explicit syncing framework might be better. (Don't be 
afraid of the term "framework" and that term implying "big", I use this for 
disjoint additional parts of GStreamer, like "parsing framework" or "debugging 
framework".)

Benjamin