summaryrefslogtreecommitdiff
path: root/win32
diff options
context:
space:
mode:
authorReinhard Nißl <rnissl@gmx.de>2011-01-22 14:54:31 +0100
committerReinhard Nißl <rnissl@gmx.de>2011-01-22 14:54:31 +0100
commit43fbcb6029f9a0f63ee8b61f63e54d74fc79de2a (patch)
treec4bf6e43457c3721b045bab870a481b63d92d5d1 /win32
parentc8e0257887a361a0b2b7a759309bcdb822d479b2 (diff)
downloadxine-lib-43fbcb6029f9a0f63ee8b61f63e54d74fc79de2a.tar.gz
xine-lib-43fbcb6029f9a0f63ee8b61f63e54d74fc79de2a.tar.bz2
Provide _x_query_buffers() to allow analyzing buffer usage by plugins
This function is similar to _x_query_buffer_usage() but retrieves also the total and available (= free) number of buffers besides the number of buffers ready for processing. For example if one wants to create a buffering algorithm based on the number of frames ready, it's not that easy to determine the maximum number of ready frames possible. In case one configures engine.buffers.video_num_frames:50 it may happen, that only 30 frames can actually be provided by the video out driver. Next a video codec like H.264 may hold several frames in its display picture buffer so that you may end up with only 13 ready frames at maximum. At the same time, the number of available (= free) frames will be 0 (or almost zero in case of vo). So it may be even easier to base the buffer algorithm on the number of free buffers. The reported numbers may also reveal that too few input buffers have been provided to compensate a large a/v offset at input stage. --HG-- extra : rebase_source : 255cb186891fbab5199a99031cf1b1e93ac19923
Diffstat (limited to 'win32')
0 files changed, 0 insertions, 0 deletions