diff options
author | Reinhard Nißl <rnissl@gmx.de> | 2007-04-15 22:11:18 +0200 |
---|---|---|
committer | Reinhard Nißl <rnissl@gmx.de> | 2007-04-15 22:11:18 +0200 |
commit | d3a9d427440dcdf796b4540c0e75efd58f8ce45c (patch) | |
tree | 0f79251cbc47ce401bcf5663497148f7d616f0c1 /po | |
parent | 9e1474cd633e3222d597c1e9c4a35e1b916f1f8a (diff) | |
download | xine-lib-d3a9d427440dcdf796b4540c0e75efd58f8ce45c.tar.gz xine-lib-d3a9d427440dcdf796b4540c0e75efd58f8ce45c.tar.bz2 |
Choose maximum for frame drop limit depending on the number of
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
Diffstat (limited to 'po')
0 files changed, 0 insertions, 0 deletions