summaryrefslogtreecommitdiff
path: root/README
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
commit1d5c7d9f5766b92de1e0c43b38af3086b3560cef (patch)
tree29d7009a5b04d944be2dbf497bf422f6db64ca01 /README
parentbcf37512cdb7e72162917ceb5dfa7bbc4d486485 (diff)
downloadxine-lib-1d5c7d9f5766b92de1e0c43b38af3086b3560cef.tar.gz
xine-lib-1d5c7d9f5766b92de1e0c43b38af3086b3560cef.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.
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions