[xine-devel] Suggestion for new fifo buffer management.

[James Courtier-D. <Ja...@su...>]

Hi,

I have been thinking about how better to handle input plugins that need 
some sort of buffering.
I have also been thinking about how better to handle fifo buffer sizes 
dynamically.
So here are my thoughts: -
Modify the current architecture as follows: -
a) input plugin has it's own thread, so that it can do buffering of 
input data before it enters the demuxer.
input plugin just waits for the demuxer to request data with the 
get_next_block call.
The input plugin decides on the memory block sizes to pass to the 
demuxer and can dynamically change sizes if needed.
There is no fifo attached to the input plugin.

b) demuxer plugin has it's own thread.
It gets a buffer from the input fifo thread, demuxes it and then calls 
the appropriate decoder to decode it without passing it to a fifo.
The decoder then decodes the data into a frame and delivers it to the 
output fifo buffer. The decoder decides on the memory block size of the 
output fifo buffer and can change it dynamically.
There is one output fifo buffer for video(video_fifo), one for 
audio(audio_fifo) and one for SPU(overlay_events).
If one has subtitles that are from a file and not from the media stream, 
a separate stream is used to handle it as the subtitle would require a 
new input plugin, demuxer and decoder.

c) Video out has it's own thread and takes frames from the video_fifo 
and add infomation from the overlay_events and displays the frame.
d) Audio out has it's own thread and takes frames from the audio_fifo 
and plays them.

If the stream is in the STOP state, all fifo buffer mallocs are freed.
Once PLAY is activated, the input plugin allocs the input fifo.
The demuxer starts taking buffer blocks and demuxing them and passing 
them to the decoders.
Once the decoder has enough information about the stream, it mallocs the 
output fifo buffer.
Then the video and audio output threads start displaying the pictures/sound.

This would allow for much better control over memory allocation in the 
fifos than is currently done.
Currently, the fifos are ALLOCed and init time and can never be changed.
I cannot currently see why there has to be a separate audio and video 
decoder thread. I only see a need for a separate audio and video out thread.

Can other developers please comment on wether they think this idea has 
merit.

Cheers
James