Guenter Bartsch wrote:
>do you have a timeframe in that you think the dvd/spu stuff can
>be sorted out realistically?
My todo list has (in any order): -
1) Floating point speed setting. Maybe using a get/set speed_near()
function. So if the current media stream only supports normal speed and
fast, but xine metronom might be able to compensate by skipping some
frames to go faster, so some more thought needs to go into how best
implement the api.
2) Floating point frame duration. (59.96 Hz is vary difficult with integers)
3) Test playing an encrypted DVD to see if the CSS config settings work.
( I need help on this, I don't have a DVD drive with me at the moment.)
4) Multiple Subtitles displayed at the same time. DVD spus and CC
(Decide on some sort of xine-lib api so the GUI can set the second
5) audio_alsa_out.c mixer thread... <- What is that for? Try to remove it?
6) Implement some more audio/video sync options.
a) using the current gap feedback in audio, or using resampling to
adjust for differences between the metronom clock and the sound hardware
b) detecting more accurate PTS values.
7) Passing extra info through decoders untouched.
E.g. Information that is send to the GUI from the input/demuxers, but
needs to be in sync with the currently displayed video frame.
As for a time when the "Multiple spu decoders" will be sorted, I would
say that it will not effect the xine-lib api -> GUI, so could be fixed
later. I would like suggestions from people on this list how best to
It would be nice to find a method to match buf_type to spu_decoder
without having to search the entire list of spu_decoders each time a
fifo buf comes. Maybe some dynamic method for registering buffer types
would help here. The decoder could register a buffer type and a
description of the stream type it handles, and then the demuxers could
request the buf_type dynamically at run time to tag the fifo buf with.
E.g. Decoder registers that is can handle DVD SPU subtitle packs, when
the demuxer inits, it knows what type of streams is can demuxer, and
requests all the buf_types that it will use.
Then we could have a simple lookup table to match buf_type to decoder,
instead of the static method currently, with the developers having to
edit buffer.h each time a new decoder is added.
Then at least this could start to get close to the possibility of a
developer writing a plugin without having to re-compile xine-lib just to
add buffer types. E.g. Developer installs xine-lib in binary form, but
the developer can still develop and test new plugins without ever
needing to touch the xine-lib source.