Thibaut Mattern wrote:
>> a few words about the functions:
>> Returns the number of buffers/frames in audio/video fifos of the
>> specified stream respectively output drivers.
>> The function should initially wait for all fifos to get empty, but a s
>> the output driver fifos can be fed by different streams, it is likely
>> that the function would block infinitely. That's why it just returns the
>> number of buffers contained in those fifos. It's now up the caller to
>> consider the case of the output fifos never getting empty and to react
>> I use this function to synchronize VDR to xine, e. g. when VDR is
>> replaying a recording and has reached the end of the recording file, it
>> must wait until xine has presented all the remaining data in the fifos.
>> Afterwards, VDR my switch back to live TV mode.
>> Returns whether there are any outstanding OSD painting events of the
>> specified stream's overlay manager. Once again it's up to the caller to
>> not wait indefinitely for processing of all osd events.
>> I use this function to synchronize VDR to xine, e. g. when VDR prompts
>> the user for a decision: before VDR my react on any input events it must
>> first make sure that the user has seen the prompt to guarantee that the
>> next input event is a result of the user having read the prompt.
>> Calls the demuxer's seek() method.
>> I use this function to have demux_mpeg_pes send a discontinuity event
>> when receiving the next PTS.
>> stream->frontend_lock is used internally to synchronize calls into
>> xine-lib of multiple frontend threads.
>> As input_vdr behaves a little bit like a frontend, it must also gain the
>> frontend_lock before it calls certain xine-lib functions on behalf of
>> VDR. Otherwise it is likely that deadlocks happen.
> IMHO, these patches exhibit a design flaw in the engine, input plugins
> should not have to know how the rest of the engine work.
> I really think we need the ability to insert a TAG from the input
> plugin into the data flow and be called back when the TAG reach the
> output loops.
> I like the TAG+Controler idea described here :
> This would allow us to fix a lot of problems, including the ability to
> wait for a frame to be displayed from the input plugin.
The idea is interesting, but it will be a lot work to modify all plugins
in xine-lib accordingly. Especially the input <=> demux interface will
need an extension, to pass the TAG to the demuxer. Then it could be
transported in special control buffers and finally in special video
frames / audio buffers. OSD stuff might be a struggle too.
But I don't see, how TAGGING could replace _x_demux_seek() /
_x_lock_frontend() / _x_unlock_frontend();
Dipl.-Inform. (FH) Reinhard Nissl