[Bug 733864] v4l2videodec: Implement EOS handling through V4L2_DEC_CMD_STOP

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=733864

Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #310576|none                        |reviewed
             status|                            |

--- Comment #21 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
Review of attachment 310576:
 --> (https://bugzilla.gnome.org/review?bug=733864&attachment=310576)

::: sys/v4l2/gstv4l2videodec.c
@@ +344,3 @@
+    GST_OBJECT_LOCK (decoder->srcpad->task);
+    GST_TASK_WAIT (decoder->srcpad->task);
+    GST_OBJECT_UNLOCK (decoder->srcpad->task);

gst_pad_task_stop() here instead. Actually, just remove the _unlock() call down
there.

@@ +349,3 @@
+    /* otherwise keep queuing empty buffers until the processing thread has
+     * stopped, _pool_process() will return FLUSHING when that happened */
+    while (ret == GST_FLOW_OK) {

I actually found that MFC behaviour have changed over time. In the past we
would have to push an empty buffer for each buffer to come out, but now it
actually run the cmd stop routine. So only one empty buffer would do. Anyway,
that lead to strange behaviour, specially with the _unlock() all that flush
everything, we sometimes loose buffers now. Maybe we should just drop it in the
end ...

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.