All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Pawel Osciak <pawel@osciak.com>
Cc: Nicolas Dufresne <nicolas.dufresne@collabora.com>,
	Fabio Estevam <festevam@gmail.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	linux-media <linux-media@vger.kernel.org>,
	Jean-Michel Hautbois <jean-michel.hautbois@vodalys.com>,
	frederic.sureau@vodalys.com
Subject: Re: coda: not generating EOS event
Date: Thu, 11 Dec 2014 15:47:54 +0100	[thread overview]
Message-ID: <5489AE9A.8030204@xs4all.nl> (raw)
In-Reply-To: <1418308963.2320.14.camel@collabora.com>

Hi Pawel,

On 12/11/14 15:42, Nicolas Dufresne wrote:
> Le jeudi 11 décembre 2014 à 11:00 -0200, Fabio Estevam a écrit :
>> Hi,
>>
>> I am running Gstreamer 1.4.4 with on a imx6q-sabresd board and I am
>> able to decode a video through the coda driver.
>>
>> The pipeline I use is:
>> gst-launch-1.0 filesrc
>> location=/home/H264_test1_Talkinghead_mp4_480x360.mp4 ! qtdemux !
>> h264parse ! v4l2video1dec ! videoconvert ! fbdevsink
> 
> This is a known issue. The handling of EOS and draining is ill defined
> in V4L2 specification. We should be clarifying this soon. Currently
> GStreamer implements what was originally done in Exynos MFC driver. This
> consist of sending empty buffer to the V4L2 Output (the input), until we
> get an empty buffer (bytesused = 0) on the V4L2 Capture (output).
> 
> The CODA driver uses the new method to initiate the drain, which is to
> send V4L2_DEC_CMD_STOP, this was not implemented by any driver when GST
> v4l2 support was added. This is the right thing to do. This is tracked
> at (contribution welcome of course):
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=733864
> 
> Finally, CODA indicate that all buffer has been sent through an event,
> V4L2_EVENT_EOS. This event was designed for another use case, it should
> in fact be sent when the decoder is done with the encoded buffers,
> rather then when the last decoded buffer has been queued. When correctly
> implemented, this event cannot be used to figure-out when the last
> decoded buffer has been dequeued.
> 
> During last workshop, it has been proposed to introduce a flag on the
> last decoded buffer, _LAST. This flag could also be put on an empty

Are you planning to work on this? That was my assumption, but it's probably
a good idea to check in case we are waiting for one another :-)

Regards,

	Hans

> buffer to accommodate driver like MFC that only know it's EOS after the
> last buffer has been delivered. This all need to be SPECed and
> implemented. If you need to get that to run now, the easiest might be to
> hack CODA to mimic MFC behavior. Implement DEC_CMD_STOP in GStreamer
> shall not be very hard though, it simply need someone to do it.
> 
> cheers,
> Nicolas
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


  reply	other threads:[~2014-12-11 14:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-11 13:00 coda: not generating EOS event Fabio Estevam
2014-12-11 14:42 ` Nicolas Dufresne
2014-12-11 14:47   ` Hans Verkuil [this message]
2015-01-22 14:58     ` Philipp Zabel
2015-01-23  5:36       ` Pawel Osciak
2015-10-13  7:43       ` Jean-Michel Hautbois

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5489AE9A.8030204@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=festevam@gmail.com \
    --cc=frederic.sureau@vodalys.com \
    --cc=jean-michel.hautbois@vodalys.com \
    --cc=linux-media@vger.kernel.org \
    --cc=nicolas.dufresne@collabora.com \
    --cc=p.zabel@pengutronix.de \
    --cc=pawel@osciak.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.