Re: [xine-devel] the road to 1.0 and beyond

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

Some points to consider when designing for 1.0 and beyond: -
1) We will never make it future proof, but there is nothing to stop us 
trying!
2) xmms has some nice ideas. one I like is the crossover plugin. This 
plugin lets you have a playlist of some music files, it lets the end of 
the first music file mix with the start of the next music file, so in 
this way there is no silence between tracks. I think this feature would 
be quite hard to do with the current xine-lib.
3) Some work really needs to be done so that xine starts playing 
quicker. demuxer selection should be speeded up, and the delay before 
first frame display should be removed. (I know why the delay is there, 
but we should think of a way round that problem)
4) Somehow extract the dvdnav from the input_dvd plugin, and make it a 
separate plugin type. We could then have dvd and vcd playback via the 
same input plugin, but just use dvdnav or vcdnav control layer plugins 
depending on the media present. dvdnav should be in the control layer, 
and not in the media stream layer as it currently is in xine.
The control layer would also be useful for other plugins. E.g. DVB and 
electronic program guide.
5) Internet streaming should be improved. The input_pvr plugin has some 
nice "pause live tv" features, whereby it caches the stream to the hard 
disk in the input_pvr plugin. I think this might be useful for internet 
streaming plugins, so that one could pause live internet streams.
6) Audio decoders should not have to open the audio device. Audio 
decoders should just decode the audio data and just pass it on to the 
next plugin in the stream. It should be streams that are connected to 
output devices, and not the decoder and post processing plugins.
I.e. audio passes through decoder and post plugins, and only when it 
reaches the end of the chain should it look to see which output device 
this stream should link to.
At the moment, the audio decoder opens the audio device, but if a post 
plugin is there, it diverts the call to itself. I think this diversion 
is messy.
7) Has anyone looked into whether the current ffmpeg avcodec api can 
handle SPDIF passthru modes.
SPDIF passthru requires the decoder to format the SPDIF frame depending 
on the codec type. E.g. A52 SPDIF frame looks different from a DTS SPDIF 
frame, which is why the creation of the SPDIF frame is best done in the 
codec, and not the audio out loop.
8) Has anyone looked into whether the current ffmpeg avcodec api can 
handle mpeg1/2 decoding and special features required when playing a 
DVD. E.g. Stills, stream changes mid frame.
9) Configuation api needs a complete rethink. At some point we will 
reach the point where almost every codec has it's own specific tweeking 
parameters. At that point the config file will just be too big. So, at 
the very least, we should probably have a separate file, or branch of 
the config tree for each plugin. In some ways similar to the windows 
registry, or any tree based database.
Each config entry should store: keyname, value. (Where value is of the 
format: type, length, data), with optional storage of: description, 
default values, expert level.

10) Standardising the input, demuxer, decoder, post processing, video 
out, audio out plugins into a state where other projects could use them.
Similar to the current ffmpeg effort for video/audio decoders
I think that the most likely thing that will prevent this will be the 
buffer management methods used by different projects is so different.
An example of this standardisation, should be so that one can take 
ffmpeg and use it in xine-lib, but also take ffmpeg and use it as a 
direct show.dll, with the only thing needing to change would be a small 
shim file.

11) Designing/auditing the xine-ui to xine-lib api so that the amount of 
data being passed between them is minimal. Maybe a future xine-ui to 
xine-lib api could be over a slow tcp/ip link. E.g. The xine-ui being on 
a palm pilot to display the position slider and title of the media 
stream, allowing one to touch the palm pilot screen to move the position 
slider, and the video out device would be a TV. So have the palm pilot 
as the control display, instead of OSD. So, in effect everything that 
would normally appear on the OSD, would in fact display on the remote 
controller device.
Another E.g. Lots of TVs displaying advertising etc. at strategic points 
all round a shopping mall, but the controlling of the play list is done 
remotely, without wanting anything to show on the OSD, but instead 
remotely over a TCP/IP link.

12) Improve buffer management.
E.g. When playing a DVD, use demuxer/decoder fifo buffer block sizes of 
2048 bytes (A DVD sector size)
When playing an mpeg-transport stream( e.g. from video lan server over 
udp), use demuxer/decoder buffer block sizes of 188 bytes (A TS unit size.)
At this time, it would seem that the best place to decide on the block 
size would be the demuxer plugin.