xine-lib/src/demuxers, branch 1.1.8

mpeg_ts multiple audio streams fix + spu lang fix

2007-08-17T18:42:18+00:00

With current code, ts demuxer stores audio tracks in the order it finds it in
PMT, but doesn't correctly set the buffer type so stream's audio_track_map
may (and often) have a different order and so a user can get german audio
when selecting "ita" ! Bad. This patch fixes that.
It also fixes get_optional_data to return correct spu lang instead of none.

Patch: mpeg_ts + ffmpeg

2007-07-08T14:25:07+00:00

Attached is a little patch that allows using ffmpegvideo w/o direct rendering
to play mpeg2 ts.
It works for both mpeg2 and h264.

Fix demuxing of wavpack files, and avoid crashing with the tags at the end of the file.

2007-07-02T12:55:24+00:00

Rename the BE/LE/ME macros with a _X_ prefix, so they don't clash with Solaris definitions.

2007-06-16T13:11:56+00:00

Fix compiler warning (pointer arithmetic).

2007-06-13T21:30:46+00:00

Add $(LTLIBICONV) wherever objdump -R shows a dependency on iconv functions.

2007-06-09T17:14:42+00:00

Some plugins may have been missed due to them not being built here.

Add $(LTLIBINTL) wherever objdump -R shows a dependency on gettext functions.

2007-06-09T16:59:03+00:00

Some plugins may have been missed due to them not being built here.

Add two missing alloca.h includes and clean up one other.

2007-06-08T13:55:35+00:00

[patch] Fix video pid misdetection

2007-06-03T16:47:19+00:00

Hi, the next bug that has been annoying me is as follows.

I have some streams recorded from BBC4 on UK DVB-T. BBC4 only actually
starts transmitting at about 7pm; prior to that there is a static
picture saying it is not playing just now. With these streams and
xine, I would get audio, but no picture.

Looking at the PMT table during the static picture, all the streams
have type 0x0b. However there IS a video stream in there, but there
are also several streams of binary data.

Xine's current video PID auto-detection code was locking on to one of
these streams of binary data because it contained the magic sequence
00 00 01 e0 at one of the PUS. *HOWEVER* it is NOT a PES stream; this
sequence is just an accident. The other problem is that xine can only
handle one video stream; so once it was misdetected once, it was stuck
at that PID.

The attached patch changes the corrupted_pes flag into a counter. If a
video stream has more than CORRUPT_PES_THRESHOLD corrupt PES packets
in a row, then it is deselected as the video stream, and
auto-detection is kicked off again. Auto-detection will now also
ignore any streams seen previously which have a nonzero corrupted_pes
count. This works very well; I can now see the video fine.

One possible issue might be that if you get a lot of corrupt PES in a
stream which really IS the video stream, it will be deselected.
However, this is not actually a problem: once the corruption goes
away, the corrupted_pes counter will be reset to 0, and the stream
will once again be autodetected as the video stream (and playback will
continue from there).

Prioritise the musepack demuxer over mpgaudio, as sometimes the latter can misfire and report a good file as unplayable.

2007-06-01T07:05:56+00:00