Re: [xine-devel] How do I wait for all fifos to drain? -- extending API

[Reinhard N. <rn...@gm...>]

Hi,

James Courtier-Dutton wrote:

>> I'd need a function similar to _x_demux_flush_engine(), but instead of 
>> discarding all buffers, it should wait untill all bufferd data got 
>> processed.
> 
> What is the application that needs this.

Once again, I'd need this for VDR. VDR typically operates on full featured DVB 
cards, which have small audio/video buffers compared to xine.

When VDR replays a recording, it sends the recorded PES packets for audio and 
video streams to the device. When VDR reaches the end of a recording, it 
issues a command to discard any bufferd data and then it goes on to sending 
PES packets from the current TV channel.

With little buffers, this discards only a fraction of a second, which is not 
replayed at the end of a recording. But with xine as software device, xine's 
large buffers (500) will cause a loss of 16 seconds at the end of a radio 
recording, when I issue a _x_demux_flush_engine() to honor VDR's discard 
buffers request.

Therefore, I'd like to extend VDR to tell me, when it reaches the end of a 
recording. Then I would call _x_demux_drain_engine(), which would block until 
the last buffer was taken out of any fifo. If VDR then calls 
_x_demux_flush_engine() there will be no buffers left to drop. In that way, 
nothing gets lost when replaying.

Well, I've already tried to use fewer buffer (e. g. the minimum seems to be 
4), but this leads to a lot 'fixing soundcard drift' messages. I assume, as 
all buffers are filled with video packets, the audio packets are scheduled to 
late for processing, which then causes the messages. What I don't understand 
in that case is, why audio buffers are allocated on the video_fifo. Maybe it 
would be better to have a separate audio buffer pool for that purpose.

The messages go away completely, if I use 100 buffers. But that's not a 
solution, as it shortens the amount of lost data from 16 seconds to about 3 
seconds, which is still to much. That's why I'd like to have a drain function.

 > 1) Do you want some event to be called when the end of one stream appears?

That wouldn't work, as all data from VDR is sent to xine in a single endless 
stream. But it would be ok to have some synchronisation object for waiting on 
the fifos getting empty.

 > 2) You should be able to just start sending packs from the new stream,
 > without having to wait for the old one to finish.

That's true. But if I would not call _x_demux_flush_engine() at that time, (e. 
g. the user asked to stop replaying and continue with live TV), then the 
following PES data would arrive at the user 16 seconds later (to stay with the 
example). In other words, the time until the user sees a reaction to its 
command be awfully long.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rn...@gm...