Fix seek issue 2.0 accepted/2.0/20130422.163146 submit/2.0/20130420.083526
authorZhao Halley <halley.zhao@intel.com>
Sat, 20 Apr 2013 05:12:41 +0000 (13:12 +0800)
committerZhao Halley <halley.zhao@intel.com>
Sat, 20 Apr 2013 08:21:39 +0000 (16:21 +0800)
commit6e84f26f469a05d6c5bd7777f580bf0f84de3350
tree544bf4a8ddca44d612ca2410b688cbdb7127afa6
parent1cdbcfe50220bf3dcd2bf52c707e296bf65ff202
Fix seek issue

https://bugs.tizen.org/jira/browse/TIVI-708

[Reason]
When decoder runs faster than downlink elements (postprocessing and
sink), many video surface are cached in pools (queue element for example).
Then decoding will fail because of no video surface available.

During seek, data flows much fater to position to dedicted frame.
It is easier to run into to above failure.

[Resolution]
1. A condition wait is added to decode func, it waits up until a surface is available.
   It usually happens when a surface is recycled after use (renders to Window/Pixmap).
2. The start of seek event (GST_EVENT_FLUSH_START) will also wake up the above wait,
   even if there is still no surface available.
   The end of seek event (GST_EVENT_FLUSH_STOP) will disable such special case.

to assist the above mechanism
3. The resumed decode func trigger retry on the previous video data.

by the way,
1. The previous solution bases on a timeout wait, it isn't
   reliable during quick seek.
2. Gst event and status change is added in GST_INFO to ease debug.
   If you still meet seek issue, please send us the log wiht
   "export GST_DEBUG=vaapidecode:3"
gst-libs/gst/vaapi/gstvaapidecoder.c [changed mode: 0644->0755]
gst-libs/gst/vaapi/gstvaapidecoder.h [changed mode: 0644->0755]
gst/vaapi/gstvaapidecode.c [changed mode: 0644->0755]
gst/vaapi/gstvaapidecode.h [changed mode: 0644->0755]
tests/test-decode.c [changed mode: 0644->0755]
tests/test-subpicture.c [changed mode: 0644->0755]