diff options
author | Reinhard Nißl <rnissl@gmx.de> | 2011-01-22 14:54:31 +0100 |
---|---|---|
committer | Reinhard Nißl <rnissl@gmx.de> | 2011-01-22 14:54:31 +0100 |
commit | 43fbcb6029f9a0f63ee8b61f63e54d74fc79de2a (patch) | |
tree | c4bf6e43457c3721b045bab870a481b63d92d5d1 /win32 | |
parent | c8e0257887a361a0b2b7a759309bcdb822d479b2 (diff) | |
download | xine-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