Thank you,
I updated GStreamer to version 1.6.1 and applied patches from Nicolas 
(https://bugzilla.gnome.org/show_bug.cgi?id=733864).
This resolved the issue witch "CODA PIC_RUN timeout".

At the moment situation looks a little bit different:
1. Playing flv videos (video codec: Sorenson Spark Video) allows me to 
play multiple videos and EOS message is received.

2. Playing h264 videos with lower resolution runs smoothly (no CODA 
PIC_RUN timeout) but when video reaches it's end - no message is 
reaching the qt application and thus I can only stop it manually.
* Is there a resolution of this problem with missing end-of-stream 
detection?

3. When playing h264 videos in HD resolution (tested with 
big_buck_bunny_1080p_h264.mov) the problem with "CODA PIC_RUN timeout" 
still occurs with small difference - when I press STOP "CODA PIC_RUN 
timeout" messages don't show up anymore while before they were showing 
up repeatedly (every second) until my qt application stopped.
- Another strange behaviour is that after I get "coda 2040000.vpu: 
failed to allocate bitstream ringbuffer" message -> the video starts 
running again (when I press PLAY) and it starts detecting end-of-stream 
(!) - see attached file

> > # [ 3049.161708] coda 2040000.vpu: dma_alloc_coherent of size 3133440 failed
> > # "Failed to allocate required memory."
>
> That shouldn't happen anymore in recent kernels. In the past, repeated
> reqbufs calls would leak buffers because the cleanup was only done on
> close.

Dear Phillip,
Unfortunately I'm using i.MX6 device so kernel provided by Freescale is 
v3.14 and I am using kernel provided by Phytec company which is based on 
mainline but the newest version is 3.19 and I cannot upgrade it.

I have already came upon some patches you provided:
starting with 
https://www.mail-archive.com/linux-media@vger.kernel.org/msg77439.html 
and another pack starting with 
http://www.spinics.net/lists/linux-media/msg91575.html
but I think that some of these are dependent on other components like 
e.g. "[PATCH 07/10] [media] coda: drop custom list of pixel format 
descriptions".

* Is there a possibility for you to give me a list of patches to apply 
(and maybe dependent packages) so I can try to apply them manually?
I hope it's not too much too ask..

Best regards
Piotr Lewicki

On 16.12.2015 22:49, Nicolas Dufresne wrote:
> 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