| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixed bug id=17.
|
|
skips the first part of the frame.
Fixed wmv playback with ffmpeg.
|
|
Such broken wrong-extension wrong-MIME-type lists exist in the wild...
|
|
--HG--
extra : transplant_source : %00%11%94ZZG%2A%A0%2A%3B%DA%CDx%AC%02%A8%E8%C3%DF%A5
|
|
|
|
This way, bigger audio chunks won't make the demuxer fail.
Fixes bug #6.
|
|
(transplanted from c139cfe735874922208d936c8e49bbfa532ed2ec)
--HG--
extra : transplant_source : %C19%CF%E75%87I%22%20%8D%93l%8EI%BB%FAS.%D2%EC
|
|
Some instances of "key colour" remain; ffmpeg is unmodified.
This change has caused two strings with two translations to collide (the
strings have become identical since some instances already used "colour").
I have therefore arbitrarily dropped the first of the differing translations,
the one for the string at src/video_out/video_out_directfb.c:1365.
|
|
|
|
|
|
|
|
(transplanted from 6d9f36be48839984c3888f3d803319942c4d76e6)
--HG--
extra : transplant_source : E%81r%E5-%5B%C2%21%15h%E3_%CB%23%25%9B%01l%03Y
|
|
(transplanted from c994a2508893efc4c85f5b49600b7dceec5c890e)
--HG--
extra : transplant_source : %C9%94%A2P%88%93%EF%C4%C8_%5BI%60%0B%7D%CE%EC%5C%89%0E
|
|
|
|
Negative values would be accepted, resulting in junk in XINE_META_INFO_GENRE
or a segfault.
|
|
|
|
|
|
This way you can get a safer build for binary redistribution.
|
|
|
|
DEMUX_FINISHED from send_header
|
|
|
|
Fixed interpretation of "videodatarate" variable.
Export audio bitrate information when variable "audiodatarate" is found.
|
|
That should prevent xine from discarding the first keyframe on non-seekable stream.
|
|
section_length is sometimes 0; this leads to the CRC32 calculation being
performed with a data length of -1 bytes, a.k.a. 4294967295 bytes.
(Reported by Johannes Zellner.)
--HG--
extra : transplant_source : %B6m%D0%0C%84%DA%40%C3%0B%06%11%B1%11%9El%A8%1F%95%27%E5
|
|
Some servers don't set this information, thus the demuxer fails.
|
|
|
|
--HG--
extra : transplant_source : %E0%D0%C5%8B%BEU%DD%24%5D7%1F%ADV%AD%EB%23%CBU%80%EB
|
|
For contributed code, leave whatever the version we last synced for is using
to make simpler future syncs.
|
|
The last fix to PTS wrap detection could not handle streams with A/V
offsets larger than 3 seconds. The improved version can deal with
them now.
--HG--
extra : transplant_source : %89%1F%7E%12%D5r%A8%CE%95N%BAG%96%02%60%0C%10%9Aar
|
|
|
|
(transplanted from 2b2f2adc8a1e0a05d89354ff259f7b2a331aa071)
--HG--
extra : transplant_source : %2B/%2A%DC%8A%1E%0A%05%D8%93T%FF%25%9F%7B%2A3%1A%A0q
|
|
Successive MPEG1/2 B frames (each with a slice #9) could incorrectly
lead to the assumption of a H.264 stream, as sequence or group start
codes were not seen for these frames. So the detection logic
interpreted the slice #9 start codes as H.264 access unit delimiters
and therefore incorrectly switched to H.264 buffer type instead of
MPEG1/2. Extending the detection logic to consider MPEG1/2 picture
start codes as well (which do not appear in H.264 streams), prevents
false positives.
|
|
|
|
|
|
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.
|
|
Attached is a little patch that allows using ffmpegvideo w/o direct rendering
to play mpeg2 ts.
It works for both mpeg2 and h264.
|
|
of the file.
|
|
Solaris definitions.
|
|
|
|
Some plugins may have been missed due to them not being built here.
|
|
Some plugins may have been missed due to them not being built here.
|
|
|
|
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).
|