summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGuenter Bartsch <guenter@users.sourceforge.net>2003-06-26 20:16:18 +0000
committerGuenter Bartsch <guenter@users.sourceforge.net>2003-06-26 20:16:18 +0000
commit0ed5fc6d9677c2c16e853d932f42ecd7ce6c12c5 (patch)
treecb5bb5f4278ac3c638004766ea07cdfb12f82ce3
parentfdcd473eba226d4fefbd57b65e2f8648065f178d (diff)
downloadxine-lib-0ed5fc6d9677c2c16e853d932f42ecd7ce6c12c5.tar.gz
xine-lib-0ed5fc6d9677c2c16e853d932f42ecd7ce6c12c5.tar.bz2
some ideas about xine's future
CVS patchset: 5098 CVS date: 2003/06/26 20:16:18
-rw-r--r--TODO35
1 files changed, 34 insertions, 1 deletions
diff --git a/TODO b/TODO
index d6cf52e13..06ce1658c 100644
--- a/TODO
+++ b/TODO
@@ -35,7 +35,6 @@ optional
- videolan streaming server support
- helix streaming server support
-- theora alpha api support (andreas)
- detect broken savage drivers in health check, disable Xv in that case
- id3v2 (guenter)
- directfb video output plugin
@@ -63,3 +62,37 @@ Open Tasks
- MAS support (http://www.mediaapplicationserver.net)
- nonlinear video editing and compositing frontend (michael) => enix
- stream format conversion frontend => enix
+
+
+xine's future
+=============
+
+- Separation of lots of audio and video processing functionality into post
+ plugins:
+ - Separate plugins for software scaling, colour space conversion,
+ postprocessing, deinterlacing, cropping, audio resampling, software
+ volume etc. If it's convenient/efficient plugins can do more than one
+ thing at the same time.
+ - Decoders set flags suggesting what needs to be done, e.g. ffmpeg decoder
+ might suggest postprocessing and cropping.
+ - Output drivers advertise what features are supported natively and what
+ limitations there are, e.g. scaling and maximum frame size for Xv.
+ - Front end informs engine what processing the user requests, e.g. audio
+ equaliser
+ - xine engine automatically inserts a chain of plugins for carrying out the
+ necessary processing.
+ Doing this would:
+ - Simplify decoder and output plugins, and therefore make developing new
+ ones much easier
+ - Reduce common code
+ - Increase flexibility of the engine
+
+ The api should also allow the automatic insertion to be overridden/controlled
+ for applications such as video processing.
+
+- see what kind of cooperation can be set up with other media player projects
+ - mike will look into moving xine's decoder api closer to the one
+ ffmpeg uses
+ - check out other media players
+ - output, demuxer plugins
+