From: Miguel F. <mi...@ce...> - 2002-12-22 12:31:12
|
Hi Michael, On Sun, 2002-12-22 at 09:34, Michael Roitzsch wrote: > Examples for two streams on one output? Ok, here we go: > * picture in picture for guenter's DVB card i thought that it would require a post plugin... wouldn't video_out stay receiving a single source of "composed" frames? stream1 -> post p-i-p plugin -> video_out stream2 -> also, in this case, which stream would be passed to vo_frame_draw(img,stream)? > * transition effects like crossfades (might be useful for slideshows) > * alphablending between two streams with a third as the alpha channel > * complex composition setups (rotoscoping) again, i hope you are not planing to add any functionality like that to the video_out.c.... :) my point is that any of these setups shouldn't have multiple streams sending data at the same time to the _output layers_. of couse, any intermediate post plugin can receive and blend the frames. > > i'd like to take the simpliest approach possible here and remove > > these ugly hacks. for XINE_DEADLOCK_ON_QUIT that would probably mean > > to flush only the stream which is actually sending frames to us or > > something like that. Michael, as multi-stream/post-plugin father, > > what do you think? > > That is a possibility, but I don't think it's a good one. In the > examples above, we clearly want all streams flushed, when the decoders > are behind. Ok. > Besides, this solution does not really solve the problem. Even with the > old way xine handled this, we can run into difficulties when calling > flush() on a decoder that is right now disposing itself. > Maybe it would be better to move the video_out->open() and > video_out->close() calls out of the decoders into the main decoder > loop? This way we can ensure, that the decoder is completely > unregistered in the output, before it becomes invalid, and we can > ensure, that it does not hold any locks when calling close(). hmmm, i would rather move the flush() to the decoder loop. That, in fact, simplifies things a lot: libmpeg2 wouldn't have to care about pthread locking anymore. What about that: - video_out would call a buffer allocation function that can fail (doesn't block), therefore avoiding deadlocks. - it fills the buffer with a special BUF_CONTROL_FLUSH. - it would enqueue it to decoder fifo using some special function to get ahead of what is already on fifo. i think this has another potential benefict: dvd input plugin may know about cases where the decoder supposed to be flushed (eg. still menu). therefore it might even send the BUF_CONTROL_FLUSH itself. does this idea has any flaws? > Besides that, are there any other problems with multistream-capable > outputs you know of? I ask because I would really like to keep this > feature. as i told you, i agree with that at a conceptual point of view: output layers should have the same interface as post plugins for the sake of consistency. however i couldn't make sense of some of the implementation details. for example: ao_open iterates over all streams, setting mode, bits and rate several times. the last ao_open takes precedence? why? > > besides, there are still other hacks at the engine that, imho, should > > be fixed. that adjust of scr clock for example (which i introduced > > quite some time ago) doesn't fit in multiple streams architecture > > anymore. may someone explain why it can't be removed? > > This is currently (mis)used to have the output discard any old data. I > tried removing them once, but it failed. I don't know exactly why, so > we should just try removing them again. I think your decoder > discontinuity() call was the missing piece back then. ok, let's try again soon... ;) thanks for the comments! Miguel |