_x_get_current_frame_data() called get_last_frame() and locked the returned
frame afterwards. At the same time, video_out_loop() unlocked last_frame to
assign a different img afterwards. So in case the image got unlocked before
it gets locked again, the image resides already on the free image queue. So
when the image gets unlocked, it will be put a second time to the queue and
hence cause a loop in the list the queue is based on. Getting an image from
the queue will then run endlessly.
To fix this issue, a new mutex is introduced which protects write access to
last_frame and read accesses via get_last_frame() from other threads. Next,
the semantic of get_last_frame() had to be changed to return a locked image
already. Finally, functions calling get_last_frame() had to be adapted to
its new behavior (there was only a single function in xine-lib which had to
be adapted: _x_get_current_frame_data()).
src/xine-engine/video_out.c | 22 +++++++++++++++++++++-
src/xine-engine/xine.c | 2 --
2 files changed, 21 insertions(+), 3 deletions(-)
From: Andreas Auras <yak54@in...> - 2011-03-27 09:43:33
well this patch from Reinhard will interfere with my outstanding already
emailed patch "[PATCH] Continuous video frame grabbing feature".
For now it's best not to apply my patch. I will email a adopted version
after Reinhard's patch has been merged to xine-lib.
Get latest updates about Open Source Projects, Conferences and News.