| Age | Commit message (Collapse) | Author |
|---|
|
needed (during decode).
|
|
|
|
|
|
|
|
Thanks to Jeff Mitchell for reporting and testing the fix.
This change reverses the meaning of _x_use_proxy() function to be the one
expected by human logic (1 -> use proxy, 0 -> don't use proxy), this way
a failure in hostname resolution would result in the proxy being used
rather than discarded.
Basically now you can use xine behind a proxy when you can't get out to
the DNS servers (or where the DNS servers don't resolve Internet hosts
that you are not allowed to connect to).
|
|
|
|
The attached patch applies after my logging patches (I can regenerate if
needed).
demux_ts attempted to read packets from the input 200 times before
giving up. When playing a local file, this is harmless, as it will hit
EOF 200 times; however, input_dvb waits 5 seconds for packets on each
call to read, resulting in a 1000 second delay if tuning fails.
Remove the counting of input packets, and add a comment to read() in
input_plugin.h, to indicate that we expect inputs to try and return some
data when read() is called. This fixes the delay, and makes it clear to
future maintainers that they shouldn't expect to loop like this.
--
Simon Farnsworth
|
|
The three attached patches (against 1.1.6) each increase the amount of
debug logging in their respective components. We've found the extra
logging useful when trying to track down faults.
I've split this into three patches to make it easier to apply only some
of our changes.
--
Comments welcome,
Simon Farnsworth
|
|
|
|
Patch from Dmitri Fedortchenko <dimo <at> angelhill.net>, required
for upstream Totem bug:
http://bugzilla.gnome.org/show_bug.cgi?id=418316
|
|
|
|
xine-lib 1.1.6 ends up looking for real codecs eg. in /usr/locallib/win32,
/usr/locallib/codecs etc, there's a missing slash. The attached patch
should fix it.
More info: https://bugzilla.redhat.com/237743
|
|
Untranslated messages use LOG_MODULE in the string literal, whereas translated
messages use %s.
|
|
|
|
Remove unused x_odd parameter from blend_???_exact functions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
once.
This way, it avoids to calculate the multiplication in the for loops and in the
memset() call.
|
|
by not exporting them.
|
|
|
|
|
|
|
|
|
|
function; add some doxygen comments with a @todo to remind that this function should be implmeneted once and forever in xine-utils.
|
|
--HG--
rename : src/libdts/xine_dts_decoder.c => src/libxineadec/xine_dts_decoder.c
|
|
libdca 0.0.5 was released about a week ago, and this commit replaces the old
code from libdts 0.0.2 (that was renamed libdca).
There's basically no functional change even if the build system is simplified
as configure takes care of switching between the two implementations on its
own.
|
|
This fixes reported alignment issues on ARM.
(We could require correct alignment on some architectures, but this is easier.)
|
|
|
|
To build against this, we need to make sure that the system dts.h header is
used instead of the internal copy of it, as the internal copy will declare
the functions with the old names, while libdca's system header will create
macro aliases between the old names and the new ones.
Better fix will be implemented in 1.2 series.
--HG--
rename : src/libdts/dts.h => src/libdts/internal-dts.h
|
|
- validate palette alpha values in overlay manager
(one check / overlay / palette index) instead of
checking every alpha value twice for every
blended pixel in every frame
- remove unneeded calculations
- approximiate expensive integer divisions with
multiplication and shift
|
|
|
|
This may have side-effects wrt other streams; CDDA is fine, though.
|
|
|
|
|
|
at configure time.
|
|
|
|
redrawing.
While splitting my original big patch set, I've lost three lines.
This change will make xine-lib compile again.
|
|
When BUF_FLAG_FRAME_END is sent before the first frame, decoding
fails as there is no data and a "bad" frame of size 0x0 will be
allocated, which is really bad as such as frame is simply invalid.
|
|
The original number of OSD objects was 5 which served xine-lib's
needs. VDR may on it's own allocate up to 16 OSD objects and thus
there may be no more OSD objects left for xine-lib's needs.
The change addresses this by increasing the current number by 5.
|
|
|
|
These functions are likely to be removed later when more correct
solutions have been found.
|
|
|
|
|
|
supply decoded frames.
There can still be scheduling delays which may let the number of
frames ready for displaying to drop below frame drop limit just
for a short period of time.
Therefore the changes remember that the decoder should have been
asked to drop some frames but do not actually have the decoder to
drop some frames. When the situation has improved at the next time
when the check is performed, the remembered frame drop is canceled
or otherwise (when the number of frames is still below frame drop
limit) executed.
|
|
allocated frames.
The current code uses a hard coded frame drop limit of 3 and
doesn't adhere to it's documentation when testing whether frames
shall be dropped. As a result frame drop limit is actually 4,
which means that the decoder is asked to drop some frames when
the number of frames waiting for displaying is less then 4.
Consider a video out device like xxmc which only supplies 8
frames. For MPEG2 decoding, two frames will be used by the
decoder (for the current frame and the forward reference frame)
and two further frames will be used in the video out loop (the
current and the previous frame) so that at any given time (under
perfect conditions) there will be 4 frames waiting to be displayed.
But when there are delays in scheduling, it might happen that
there are only 3 frames ready for displaying and thus will result
in asking the decoder to drop frames.
The changes therefore determine the maximum frame drop limit in
dependence of the number of allocated frames and make the
detection work like documented. In the above scenario, the maximum
number actually used for frame drop limit will then be 2 which
allows to compensate some scheduling delays without causing the
decoder to drop frames.
|
|
available.
Usually it's a good idea to avoid reallocating frames especially
when a deinterlacer needs a different format than the decoder, as
this would then happen all the time.
But when there is only a limited number of frames available, then
even a single frame which is not scheduled at frame allocation may
let the number of frames ready for displaying drop below frame
drop limit and thus resulting in unnecessary frame drops.
|
