Unnamed repository; edit this file 'description' to name the repository.
 help / color / mirror / Atom feed
From: Stanimir Varbanov <stanimir.varbanov@linaro.org>
To: Hans Verkuil <hverkuil-cisco@xs4all.nl>, linux-media@vger.kernel.org
Cc: Nicolas Dufresne <nicolas@ndufresne.ca>,
	Tomasz Figa <tfiga@chromium.org>,
	Michael Tretter <m.tretter@pengutronix.de>
Subject: Re: [PATCHv3 1/5] media: docs-rst: Document memory-to-memory video encoder interface
Date: Fri, 29 May 2020 13:17:01 +0300
Message-ID: <7e86a915-1ff0-0d2a-e82c-8bf204b1cc82@linaro.org> (raw)
In-Reply-To: <15e979fa-f782-a8af-5bf3-d39e6c245b36@linaro.org>



On 5/29/20 12:57 PM, Stanimir Varbanov wrote:
> 
> 
> On 5/26/20 1:09 PM, Hans Verkuil wrote:
>> From: Tomasz Figa <tfiga@chromium.org>
>>
>> Due to complexity of the video encoding process, the V4L2 drivers of
>> stateful encoder hardware require specific sequences of V4L2 API calls
>> to be followed. These include capability enumeration, initialization,
>> encoding, encode parameters change, drain and reset.
>>
>> Specifics of the above have been discussed during Media Workshops at
>> LinuxCon Europe 2012 in Barcelona and then later Embedded Linux
>> Conference Europe 2014 in Düsseldorf. The de facto Codec API that
>> originated at those events was later implemented by the drivers we already
>> have merged in mainline, such as s5p-mfc or coda.
>>
>> The only thing missing was the real specification included as a part of
>> Linux Media documentation. Fix it now and document the encoder part of
>> the Codec API.
>>
>> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
>> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
>> ---
>>  .../userspace-api/media/v4l/dev-encoder.rst   | 728 ++++++++++++++++++
>>  .../userspace-api/media/v4l/dev-mem2mem.rst   |   1 +
>>  .../userspace-api/media/v4l/pixfmt-v4l2.rst   |   5 +
>>  .../userspace-api/media/v4l/v4l2.rst          |   2 +
>>  .../media/v4l/vidioc-encoder-cmd.rst          |  51 +-
>>  5 files changed, 767 insertions(+), 20 deletions(-)
>>  create mode 100644 Documentation/userspace-api/media/v4l/dev-encoder.rst
>>
> 
> <cut>
> 
>> +
>> +Reset
>> +=====
>> +
>> +The client may want to request the encoder to reinitialize the encoding, so
>> +that the following stream data becomes independent from the stream data
>> +generated before. Depending on the coded format, that may imply that:
>> +
>> +* encoded frames produced after the restart must not reference any frames
>> +  produced before the stop, e.g. no long term references for H.264/HEVC,
>> +
>> +* any headers that must be included in a standalone stream must be produced
>> +  again, e.g. SPS and PPS for H.264/HEVC.
>> +
>> +This can be achieved by performing the reset sequence.
>> +
>> +1. Perform the `Drain` sequence to ensure all the in-flight encoding finishes
>> +   and respective buffers are dequeued.
>> +
>> +2. Stop streaming on the ``CAPTURE`` queue via :c:func:`VIDIOC_STREAMOFF`. This
>> +   will return all currently queued ``CAPTURE`` buffers to the client, without
>> +   valid frame data.
>> +
>> +3. Start streaming on the ``CAPTURE`` queue via :c:func:`VIDIOC_STREAMON` and
>> +   continue with regular encoding sequence. The encoded frames produced into
>> +   ``CAPTURE`` buffers from now on will contain a standalone stream that can be
>> +   decoded without the need for frames encoded before the reset sequence,
>> +   starting at the first ``OUTPUT`` buffer queued after issuing the
>> +   `V4L2_ENC_CMD_STOP` of the `Drain` sequence.
>> +
>> +This sequence may be also used to change encoding parameters for encoders
>> +without the ability to change the parameters on the fly.
> 
> How the v4l2 client knows which parameters could be changed on the fly
> and which cannot? Controls should return -EBUSY?

Sorry, I re-read "Encoding Parameter Changes" paragraph.

> 
> Also could that Reset be used to change the pixel format and probably
> colorspace?
> 

-- 
regards,
Stan

  reply	other threads:[~2020-05-29 10:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26 10:09 [PATCHv3 0/5] Stateful Encoding: final bits Hans Verkuil
2020-05-26 10:09 ` [PATCHv3 1/5] media: docs-rst: Document memory-to-memory video encoder interface Hans Verkuil
2020-05-29  9:57   ` Stanimir Varbanov
2020-05-29 10:17     ` Stanimir Varbanov [this message]
2020-05-29 12:21     ` Tomasz Figa
2020-06-05  7:19   ` Stanimir Varbanov
2020-06-05 21:24     ` Nicolas Dufresne
2020-06-06  7:58       ` Stanimir Varbanov
2020-06-07  0:27         ` Nicolas Dufresne
2020-06-10 12:28       ` Tomasz Figa
2020-06-10 13:08         ` Nicolas Dufresne
2020-06-10 13:55           ` Tomasz Figa
2020-06-10 13:58         ` Tomasz Figa
2020-06-23 10:36   ` Hans Verkuil
2020-06-23 11:47     ` Tomasz Figa
2020-06-23 10:47   ` Mauro Carvalho Chehab
2020-05-26 10:09 ` [PATCHv3 2/5] vidioc-g-parm.rst: update the VIDIOC_G/S_PARM documentation Hans Verkuil
2020-05-28  7:54   ` Michael Tretter
2020-05-26 10:09 ` [PATCHv3 3/5] dev-decoder.rst: small fixes Hans Verkuil
2020-05-26 10:09 ` [PATCHv3 4/5] videodev2.h: add V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL flag Hans Verkuil
2020-05-26 10:09 ` [PATCHv3 5/5] dev-encoder.rst: add reference to V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL Hans Verkuil
2020-05-28  7:58 ` [PATCHv3 0/5] Stateful Encoding: final bits Michael Tretter
2020-06-02  9:01 ` Tomasz Figa

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=7e86a915-1ff0-0d2a-e82c-8bf204b1cc82@linaro.org \
    --to=stanimir.varbanov@linaro.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=m.tretter@pengutronix.de \
    --cc=nicolas@ndufresne.ca \
    --cc=tfiga@chromium.org \
    /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

Unnamed repository; edit this file 'description' to name the repository.

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://archive.lwn.net:8080/linux-media/0 linux-media/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-media linux-media/ http://archive.lwn.net:8080/linux-media \
		linux-media@vger.kernel.org lwn-linux-media@archive.lwn.net
	public-inbox-index linux-media

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://archive.lwn.net/lwn.kernel.linux-media


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git