[Bug 733864] v4l2videodec: Implement EOS handling through V4L2_DEC_CMD_STOP

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=733864
  GStreamer | gst-plugins-good | git

Nicolas Dufresne (stormer) <nicolas.dufresne> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #293102|none                        |needs-work
             status|                            |

--- Comment #10 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> 2014-12-20 00:51:31 UTC ---
Review of attachment 293102:
 --> (https://bugzilla.gnome.org/review?bug=733864&attachment=293102)

This isn't right. First we don't want to replace, backward compatibility is as
important in userspace library that it is in kernel. Then the patch will make
you loose few buffers at the end of the playback. There is a good reason why
there is all this synchronization between threads. The problem is rather
simple:

a) Send CMD_STOP
a') If CMD_STOP returned ENOTTY, fallback to the empty payload buffer loop
b) wait for the processing thread to have left
c) return

::: sys/v4l2/gstv4l2videodec.c
@@ +299,3 @@
   GST_DEBUG_OBJECT (self, "Finishing decoding");

+#if 0

Eh ?

@@ +718,3 @@
+    case GST_EVENT_EOS:
+      GST_DEBUG_OBJECT (self, "got EOS event, send V4L2_DEC_CMD_STOP");
+      gst_v4l2_decoder_cmd(self->v4l2output, V4L2_DEC_CMD_STOP, 0);

Ok, you didn't not understood what the virtual method _finish() is doing.
Finish method is called by the base class when EOS event is received. The
implementation should drain sycnhronously the decoder and then return. At the
end of the drain the processing thread should be stopped.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.