| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Seen in an AVI in the wild; apparently generated by mencoder.
|
|
|
|
>
> /* Special codes used when specifying changer slots. */
> #define CDSL_NONE (INT_MAX-1)
> #define CDSL_CURRENT INT_MAX
|
|
|
|
|
|
|
|
|
|
--HG--
extra : transplant_source : %1D%7F%1D%00%EC%9C%8E%BD%9D%99i%A2%F0d%7D%DC%03%E3B%03
|
|
Found this little problem (was causing some "uninitialised variable
accesses" under valgrind) while implementing Podcast reading in RB using
Totem's playlist parser.
--HG--
extra : transplant_source : J%D9/%16%E2i%B2%84%FA%8A%85%888N%A5%B4%16s%BD%16
|
|
When demux_mpeg_pes uses FFmpeg for H.264 streams, it doesn't set
video_step as it doesn't know it. But FFmpeg provides it deriveable
from time_base. So let's use the derived value as long as it isn't
set explicitly.
Furthermore, demux_mpeg_pes set's BUF_FLAG_FRAME_END whenever it
encounters a H.264 access unit delimiter, which appears between
fields or frames, but it doesn't know, whether it deals with fields
or frames. avcodec_decode_video() on the other hand sets got_picture
even when the decoded data specifies just a field. But it also sets
the flag interlaced_frame. So let's use this flag to halve video_step
in order to show the decoded images just for a field duration.
--HG--
extra : transplant_source : %40Q%E3fO%3C%E7%A0%02%BA%9D%1D%BD%81%F0f-%EAs%87
|
|
|
|
Do MRL unescaping.
For FIFOs, require vdr:///path/to/fifo (i.e. three or more leading slashes).
For host[:port], truncate the MRL at the first "#" (prior to unescaping).
|
|
|
|
|
|
(wait the main stream to fully initialize)
prevents division by zero in draw_subtitle().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(transplanted from 2b2f2adc8a1e0a05d89354ff259f7b2a331aa071)
--HG--
extra : transplant_source : %2B/%2A%DC%8A%1E%0A%05%D8%93T%FF%25%9F%7B%2A3%1A%A0q
|
|
I managed to miss one from my earlier patch, though I could've sworn I
checked this.
Add (prefix)/lib64/real into the real codec path list. It is encountered
in the 64bit PLF Mandriva real-codecs package.
|
|
These cheats where hiding a frame allocation bug in FFmpeg decoder
which was previously fixed.
|
|
|
|
|
|
xine-config is no longer a build-time generated file.
--HG--
rename : misc/xine-config.in => misc/xine-config
|
|
|
|
|
|
|
|
|
|
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.
|
|
These cheats where hiding a frame allocation bug in FFmpeg decoder
which was previously fixed.
|
|
External FFmpeg has recently gained multithreaded H.264 decoding
and to make use of this feature, it is necessary to inform FFmpeg
about the maximum number of threads it may use for decoding.
|
|
When a stream doesn't start with an IDR frame, there will be several
seconds of bad frames and not setting PTS on those frames causes an
unnecessary delay in syncing audio and video.
|
|
When a stream doesn't start with an IDR frame, then frame size isn't
known, but all frames up to an IDR frame are reported as bad frames.
In such a case, a frame of size 1x1 will be allocated as xine-lib
cannot handle 0x0 frames properly, i. e. many output drivers simply
crash.
|
|
|
|
|
|
|
|
|
|
|
|
The attached patch to xine-lib adds two more real codec search paths.
/usr/lib/real is encountered in PLF packages for Mandriva, and
/usr/lib/RealPlayer10GOLD/codecs is encountered in RealPlayer package of
Mandriva.
|
|
|
|
|
|
|
|
That isn't in any release, and anyway we have a suitable replacement in
xml_parser_build_tree_with_options().
|
|
<a>b<[CDATA[c]]></a> gives a.data = "bc".
<a>b<d/>c</a> gives a.data = "b" & .child = "d" then "[CDATA]" with .data = "c"
if XML_PARSER_MULTI_TEXT is set, else a.data = "bc" and there's no "[CDATA]".
|
|
|
