| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Will break if one reaches 100 :-)
|
|
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.
|
|
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.
|
|
|
|
|
|
--HG--
rename : debian/libxine1.install => debian/libxine2.install
|
|
|
|
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.
|
|
|
|
|
