| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
(transplanted from ce2ba83d5b347bb670e4aaa17a9fbcf21d87a811)
--HG--
extra : transplant_source : %CE%2B%A8%3D%5B4%7B%B6p%E4%AA%A1z%9F%BC%F2%1D%87%A8%11
|
|
(transplanted from 65ffd061414c05cbc368e130d1783a2efdc5b75e)
--HG--
extra : transplant_source : e%FF%D0aAL%05%CB%C3h%E10%D1x%3A.%FD%C5%B7%5E
|
|
These cheats where hiding a frame allocation bug in FFmpeg decoder
which was previously fixed.
(transplanted from c7cc5ff1e184791683ba13bdc54c53b5887e6587)
--HG--
extra : transplant_source : %C7%CC_%F1%E1%84y%16%83%BA%13%BD%C5LS%B5%88%7Ee%87
|
|
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.
|
|
This function shall be used to poll the number of outstanding OSD
events from a certain point in time on until the reported number
is 0. At that point in time, the content on screen is identical to
a certain state of the stream, at which for example, a hardcopy may
be taken.
|
|
uninitalized.
|
|
the Framebuffer output only with fbxine.
|
|
outputs to not encode the video out name on it, to simplify i18n.
|
|
|
|
|
|
|
|
xineplug_decode_ff.la/
|
|
|
|
|
|
elements by the size of the single element.
(transplanted from 512894f517c423fed0cadeca0d46c6d909403106)
--HG--
extra : transplant_source : Q%28%94%F5%17%C4%23%FE%D0%CA%DE%CA%0DF%C6%D9%09%401%06
|
|
(transplanted from 47f7f33b32805da6e8f58513c38e01dc6a595fb8)
--HG--
extra : transplant_source : G%F7%F3%3B2%80%5D%A6%E8%F5%85%13%C3%8E%01%DCjY_%B8
|
|
elements by the size of the single element.
|
|
|
|
|
|
memcpy structures.
When array of constant pointers are used for register enum configurations,
this creates more warnings because of pointer mismatches; I'd consider
casting them, but not yet.
In the memcpy_method array, mark the parts that are constant at build time
as const so to try reducing the overhead.
|
|
|
|
xineutils.h for it, instead use XINE_MALLOC.
|
|
from now on.
|
|
|
|
|
|
|
|
|
|
|
|
Previously, with junk content, the plugin could potentially consume lots of
memory (possibly causing a local DoS).
Also, a few small memory leaks have been eliminated.
|
|
Users might be using DVDCSS_CACHE by theirselves to change the location
of libdvdcss keys cache; if xine resets the environment variable, it might
create an unexpected behaviour to the user.
|
|
|
|
|
|
|
|
instance yet.
|
|
instance yet.
|
|
XDG_CACHE_HOME as a place where to put the data.
|
|
used in a few more cases.
|
|
|
|
than in the root of it.
|
|
With this commit, also fix the previous mistakes in the iteration.
|
|
With this change, when rendering a font through FreeType2 (and not using
FontConfig) the directories looked up are the ones defined in XDG_DATA_DIRS,
right after XDG_DATA_HOME; this way the user can decide to have fonts data
in a different place than its home directory.
This also splits up the lookup for fontconfig and non-fontconfig cases in
two different functions, to avoid gotos and labels.
|
|
|
|
the check manually.
|
|
This handle can then be used by all plugins and other parts of the
xine engine without having to duplicate it.
|
|
Directory Specification.
With this change, xine-lib starts abiding to the XDG Base Directory
Specification, allowing the user to define a different path to save
its cache data (by setting XDG_CACHE_HOME environment variable).
|
|
The introduced functions give "frontend like" plugins a chance to
lock and unlock frontend_lock. This protects such threads for
example from beeing blocked when changing the streams speed.
|
|
The introduced function give "frontend like" plugins a chance to
lock and unlock port rewiring. This protects such threads (when
combined with holding the frontend lock) from beeing blocked when
calling functions like xine_get_current_frame().
|
