| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Hopefully, I've applied all of the $(LTLIBINTL) changes correctly...
|
|
Intent is to allow front ends to rename their old, badly-named, config items.
|
|
|
|
|
|
read() function, and declare a new buf variable in the function as needed.
|
|
--HG--
extra : transplant_source : %DFs%84N%8AG%00%5B%EFv%FF%E6%CD%93%23%D8%E6%A1%C2%18
|
|
|
|
|
|
close the driver on a return value <0
|
|
|
|
close the driver on a return value <0
|
|
|
|
|
|
-- Revisit NLS stuff. Not much changed, remove the REVISIT tag
-- Change XDG_BASEDIR_CFLAGS to XDG_BASEDIR_CPPFLAGS, because it only includes
a -I, which is a CPPFLAGS option, not CFLAGS
-- Move XDG stuff up to library checks
-- Cleanup and move zlib checks
-- Move X11 checks up to checks for system services
-- Break audio out plugin stuff into m4/audio_out.m4
-- Break video out plugin stuff into m4/video_out.m4
-- Move libdir name stuff into m4/libFLAC.m4 since that's the only thing that
uses it.
|
|
|
|
|
|
|
|
|
|
-- Removed m4/optimizations.m4, and along with it, AC_OPTIMIZATIONS.
-- Stripped down, cleaned up, and merged the former together with other compiler
characteristic checks.
-- Do not set any optimization flags into CFLAGS. Update all Makefile.am's with
proper AM_CFLAGS, AM_CPPFLAGS, AM_LDFLAGS, etc. to set up optimization flags,
usually from DEFAULT_OCFLAGS.
-- Start cleaning up CFLAGS/CPPFLAGS stuff in Makefile.am's all over the place.
-- Correct a number of places where CFLAGS itself was being mangled in
Makefile to on-the-fly adjust optimizations to work around compiler bugs.
This stuff is now done correctly.
-- The run of automake from autogen.sh is now clean of warnings.
-- Cleaned out some (now) dead macros from m4/_xine.m4
-- Mac OS X intel builds out-of-the-box now -- dropped optimization on
post/deinterlace/plugins/kdetv-greedyh to O1_CFLAGS.
-- OBJCFLAGS is now getting set correctly everywhere that it needs to be
-- Various other miscellaneous cleanups all over
|
|
|
|
when we want to run until the timeout has occurred, partially fixes
Totem's browser plugin playing back browser streams with the xine-lib
backend
See http://bugzilla.gnome.org/show_bug.cgi?id=375866 for details
|
|
|
|
|
|
|
|
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.
|
|
|
|
This fixes reported alignment issues on ARM.
(We could require correct alignment on some architectures, but this is easier.)
|
|
- 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
|
|
|
|
|
|
redrawing.
While splitting my original big patch set, I've lost three lines.
This change will make xine-lib compile again.
|
|
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.
|
|
(transplanted from 4988e864d1a9db84756668ea33a9f6860ded879e)
--HG--
extra : transplant_source : I%88%E8d%D1%A9%DB%84ufh%EA3%A9%F6%86%0D%ED%87%9E
|
|
|
|
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.
(transplanted from b016e80a8206a56ba3996021bacff88b8ba44621)
--HG--
extra : transplant_source : %B0%16%E8%0A%82%06%A5k%A3%99%60%21%BA%CF%F8%8B%8B%A4F%21
|
|
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.
(transplanted from 2936fd493eafe3f176f2e791340167513b4e8048)
--HG--
extra : transplant_source : %296%FDI%3E%AF%E3%F1v%F2%E7%914%01gQ%3BN%80H
|
|
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.
(transplanted from 235058555243755d3aebff03d898f1a5b94ff95e)
--HG--
extra : transplant_source : %23PXURCu%5D%3A%EB%FF%03%D8%98%F1%A5%B9O%F9%5E
|
|
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.
|
|
drops.
When a video out device provides only a little number of video
frames, the video decoder should be scheduled immediately to
provide a decoded frame as soon as possible. Otherwise, the
number of available frames for displaying may go below frame
drop limit and thus resulting in unnecessary frame drops.
(transplanted from 33960e92decd90e6010d904476f9d45b1173153a)
--HG--
extra : transplant_source : 3%96%0E%92%DE%CD%90%E6%01%0D%90Dv%F9%D4%5B%11s%15%3A
|
|
drops.
When a video out device provides only a little number of video
frames, the video decoder should be scheduled immediately to
provide a decoded frame as soon as possible. Otherwise, the
number of available frames for displaying may go below frame
drop limit and thus resulting in unnecessary frame drops.
|
|
redrawing.
The video out loop sleeps up to 20 ms (and the paused loop 20 ms)
which means that pending OSD events are delayed too from beeing
processed. When an OSD is used for example to scroll through a
list of VDR recordings, this delay may slow down scrolling
unnecessarily.
Especially when the OSD manager is able to render the OSD content
indepently from drawing a frame to screen, this change will allow
the fastest OSD update possible.
|
