improve notes about libfaad and libmpeg2

CVS patchset: 7802
CVS date: 2005/11/15 12:32:46

1 files changed, 25 insertions, 17 deletions

diff --git a/CREDITS b/CREDITS
index 94b84b36b..4ce8e5534 100644
--- a/CREDITS
+++ b/CREDITS
@@ -19,7 +19,7 @@ liba52				0.7.4
 libcdio				0.71 [o]
 libdts				0.0.2
 libdvdnav			0.1.10			Michael Roitzsch
-libfaad				2.0-cvs-2004-09-15	Miguel Freitas
+libfaad				cvs-2005-01-30 [GPL]    Miguel Freitas
 libmad				0.15.1b			Miguel Freitas
 libmpeg2			0.2.1 [*]
 libmusepack			svn 13/01/05		James Stembridge
@@ -31,30 +31,38 @@ vidix				cvs 6/03/05		James Stembridge
 
 -----------------------------------------------------------------------
 
+[GPL] this is the latest GPL compatible version of FAAD2. later cvs
+  snapshots have added an advertisement clause so we cannot update until
+  the situation gets fixed.
+
 
 [*] common question: lastest version of libmpeg2 is 0.3.1, why don't
 you update?
 
-the answer is not so simple. 
+  the answer is not so simple. 
+
+  quoting libmpeg2.sf.net: "The old API [0.2.x] was not flexible enough for
+  most users, as a result various projects (xine, mplayer etc...) ended up
+  rewriting their own versions of decode.c."
 
-quoting libmpeg2.sf.net: "The old API [0.2.x] was not flexible enough for
-most users, as a result various projects (xine, mplayer etc...) ended up
-rewriting their own versions of decode.c."
+  this is indeed true: in order to support a lot of dvd features, menus with
+  still frames, closed caption decoding and better buffer management for
+  xine it was needed to patch our libmpeg2 copy. of course we should always
+  try not to "fork" external projects, but in the libmpeg2/xine case it is
+  easy to see (from CVS logs) how long did it took to reach the stability
+  point we have now.
 
-this is indeed true: in order to support a lot of dvd features, menus with
-still frames, closed caption decoding and better buffer management for
-xine it was needed to patch our libmpeg2 copy. of course we should always
-try not to "fork" external projects, but in the libmpeg2/xine case it is
-easy to see (from CVS logs) how long did it took to reach the stability
-point we have now.
+  so, while targeting a stable libxine release, there is no hurry in
+  updating libmpeg2 and this is not the trivial task as it might sound.
 
-so, while targeting a stable libxine release, there is no hurry in
-updating libmpeg2 and this is not the trivial task as it might sound.
+  note that we have also backported some fixes/improvements from libmpeg2
+  cvs (eg. motion vector clipping for broken streams). if you need any
+  specific change or fix feel free to send us a patch or discuss the issue
+  at xine-devel.
 
-note that we have also backported some fixes/improvements from libmpeg2
-cvs (eg. motion vector clipping for broken streams). if you need any
-specific change or fix feel free to send us a patch or discuss the issue
-at xine-devel.
+  update plan for libmpeg2: we should leave our patched libmpeg2 for 
+  hardware accelerated decoding (xvmc) only and use "libmpeg2new" (containing 
+  updated libmpeg2) for software decoding.
 
 
 [o] These libraries are not well maintained and subsetted from the