xine-lib/src/post/goom, branch 1-rc5

separate the two semantics of querying a port's status with a NULL stream;

2004-05-29T14:45:25+00:00

before, NULL could mean two things: no stream at all or a stream that does not
want to be addressed; now the latter is represented by the new XINE_ANON_STREAM
resulting changes:
* the status() functions now behave differently for NULL and XINE_ANON_STREAM
  (as the commentary always implied, but this was not the case, so post
  plugin rewiring went wrong, because it relies on the status() function)
* the NULL_STREAM defines in audio_out and video_out are obsolete
* update the function comments in the headers
* update the post plugin rewire functions to use the status() functions to
  check, if the old port was opened and handle the new one accordingly;
  this makes open_count obsolete
* change all post plugins accordingly (mostly using XINE_ANON_STREAM instead
  of NULL)
additional change:
* the status() function of audio port now returns the bits/rate/mode values
  of the input and not the output; this is more likely to be what a post plugin
  wants
* the reimplementation of status() in the upmix plugin is obsolete

CVS patchset: 6603
CVS date: 2004/05/29 14:45:25

track number of times the port has being opened.

2004-05-18T03:16:12+00:00

rewiring a closed port won't cause the new destination to be opened.

CVS patchset: 6564
CVS date: 2004/05/18 03:16:12

help strings added for all remaining config entries (so I hope)

2004-04-26T17:50:06+00:00

please everybody watch out for spelling (and other) errors

CVS patchset: 6442
CVS date: 2004/04/26 17:50:06

swap usage of "up" and "down" to the more common meaning:

2004-04-17T19:54:31+00:00

 "down" is the usual datapath from decoder to output, "up" is the opposite way
-> this means swapping two function names
-> this means increasing the post plugin iface version
external plugin developers: just swap usage of
_x_post_frame_copy_up() and _x_post_frame_copy_down() functions

CVS patchset: 6412
CVS date: 2004/04/17 19:54:31

another int used to store a pointer, which breaks AMD64;

2004-04-05T19:31:35+00:00

thanks once again to Adrian Schroeter from SuSE for spotting this

CVS patchset: 6332
CVS date: 2004/04/05 19:31:35

memleak

2004-03-21T23:26:08+00:00

CVS patchset: 6296
CVS date: 2004/03/21 23:26:08

Various compilation fixes and updates:

2004-02-29T17:26:45+00:00

 - xine compilable without iconv (scream if I something broke)
 - update MSVC port, fixes in avi demux
 - add iff.h into makefiles
 - ffmpeg depends on zlib (build was OK only when freetype was installed)
 - commit a patch for goom

CVS patchset: 6192
CVS date: 2004/02/29 17:26:45

Fixed detection of linux framebuffer support. Included xineutils.h in dsputil_mlib.c and added to diff_to_ffmpeg_cvs.txt. Fixed function prototype in dsputil_mlib.c (should be sent back to ffmpeg-dev at some point). Fixed includes in nosefart. Fixed nested comments and includes in goom.

2004-02-20T19:53:38+00:00

CVS patchset: 6180
CVS date: 2004/02/20 19:53:38

Mandrake patches from

2004-02-19T02:50:24+00:00

  http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/xine-lib/
via Goetz Waschk who reports:
  The amd64 patch (xine-lib-1-rc0a-amd64.patch) sets some conservative
  CFLAGS for amd64,
  the lib64 patch (xine-lib-1-rc0a-lib64.patch) replaces hardcoded
  /lib to support the lib64 library dir on amd64,
  the directfb patch (xine-lib-1-rc2-no-directfb.patch) adds a
  configure option to disable directfb,
  the linuxfb patch (xine-lib-1-rc3a-no-linuxfb.patch) does the same
  for linux framebuffer and
  the 64bit fixes patch (xine-lib-1-rc3-64bit-fixes.patch) doesn't
  apply at the moment against the CVS -- demux_ogg.c was not applied.
  it includes some 64 bit pointer and other fixes for 64bit architectures.
  from Gwenole Beauchesne
I haven't tested other than apply and compile.

CVS patchset: 6174
CVS date: 2004/02/19 02:50:24

function has been renamed

2004-02-12T18:25:07+00:00

CVS patchset: 6140
CVS date: 2004/02/12 18:25:07