Re: problem with coda when running qt-gstreamer and video reaches its end (resending in plain text)

[Nicolas Dufresne <nicolas.dufresne@collabora.com>]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]