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

[Mathrick <mn...@wp...>]

W liście z czw, 11-03-2004, godz. 11:20, Thomas Vander Stichele pisze: 

> Now, the two possible solutions I could think of were
> - change the design so that the state "PAUSED" means "do everything
> needed to get the first buffer queued, but blocked, on the rendering
> sink" - ie, going to this state would make the scheduler be certain that
> all links to rendering sinks contain a buffer.  Before this might have
> been awkward, now with the negotiation rewrite there actually is a
> concept of a link between pads, so it might be possible to tack this
> concept on it.  Personally, I'd prefer this approach, it seems more
> natural to me.
> 
> The net effect would be that the operation of going from PAUSED to
> PLAYING would be very inexpensive by design (because the framework makes
> sure that everything is ready to go to PLAYING immediately).  Also, in
> practice, the reverse would also be true - going back to PAUSED would be
> very light since the data was already flowing.
> 
> I think that the only reason why this approach wasn't tried in the past
> is because Erik wanted to make absolutely sure no data was flowing in
> the PAUSED state. Anyway, I'd like this approach because it's natural,
> clear, and seems welldefined to me.

I may be wrong, but it looks like that would break badly when using
v4lsrc with TV tuner for example, or more generally any live data feed.
I don't think there's a way to ensure everything being ready for data
flow without it actually flowing, as live data invalidates instantly
when not used. You can either use it, or throw it away, no "keep handy
for later use" possible. IMO, above model is just too nice, optimized
for CD-player-like case, but not taking into account other setups.

Cheers,
Maciej

-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mn...@wp...>
       http://mathrick.blog.pl