summaryrefslogtreecommitdiff
path: root/po
diff options
context:
space:
mode:
authorReinhard Nißl <rnissl@gmx.de>2007-04-15 22:11:18 +0200
committerReinhard Nißl <rnissl@gmx.de>2007-04-15 22:11:18 +0200
commitd3a9d427440dcdf796b4540c0e75efd58f8ce45c (patch)
tree0f79251cbc47ce401bcf5663497148f7d616f0c1 /po
parent9e1474cd633e3222d597c1e9c4a35e1b916f1f8a (diff)
downloadxine-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