Le mercredi 16 décembre 2015 à 15:49 +0100, Philipp Zabel a écrit : > > # [ 1382.828875] coda 2040000.vpu: CODA PIC_RUN timeout > > # [ 1383.938704] coda 2040000.vpu: CODA PIC_RUN timeout > > > > The video is stopped but I can see last frame on the screen although in > > qt application it should receive end-of-stream message and stop the > > video (resulting with black screen). > > Looks like the coda driver is constantly fed empty buffers, which don't > increase the bitstream payload level, and the PIC_RUN times out with a > bitstream buffer underflow. What GStreamer version is this? I believe this is side effect of how the MFC driver worked in it's early stage. We had to keep pushing empty buffer to drain the driver. So GStreamer still poll/queue/poll/queue/... until all capture buffers are received. I notice recently that this behaviour can induce high CPU load with some other drivers that don't do any active wait when a empty buffer is queued. I would therefor suggest to change this code to only push one empty buffer for your use case. An submitted patch to support CMD_STOP can be found here, though is pending a re-submition by it's author. https://bugzilla.gnome.org/show_bug.cgi?id=733864 For proper EOS detection with CODA driver (using EPIPE return value), you indeed need GStreamer 1.6+. cheers, Nicolas
Attachment:
signature.asc
Description: This is a digitally signed message part
