From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
To: Tomasz Figa <tfiga@chromium.org>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alexandre Courbot <acourbot@chromium.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Stanimir Varbanov <stanimir.varbanov@linaro.org>,
Andrew-CT Chen <andrew-ct.chen@mediatek.com>,
Tiffany Lin <tiffany.lin@mediatek.com>,
Pawel Osciak <posciak@chromium.org>
Subject: Re: [PATCHv4 1/2] media: docs-rst: Document memory-to-memory video decoder interface
Date: Wed, 10 Jul 2019 12:00:58 +0200 [thread overview]
Message-ID: <a6872700-c647-e1a9-02e7-b3a6080cf485@xs4all.nl> (raw)
In-Reply-To: <CAAFQd5A4+o9MZL8_TTdKOYa04O87GEi81PU2Kipa_Seeg98oMA@mail.gmail.com>
On 7/10/19 10:23 AM, Tomasz Figa wrote:
> On Wed, Jul 10, 2019 at 5:09 PM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>>
>> On 7/3/19 6:58 AM, Tomasz Figa wrote:
>>> Hi Hans,
>>>
>>> On Mon, Jun 3, 2019 at 8:28 PM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>>>>
>>>> From: Tomasz Figa <tfiga@chromium.org>
>>>>
>>>> Due to complexity of the video decoding process, the V4L2 drivers of
>>>> stateful decoder hardware require specific sequences of V4L2 API calls
>>>> to be followed. These include capability enumeration, initialization,
>>>> decoding, seek, pause, dynamic resolution change, drain and end of
>>>> stream.
>>>>
>>>> 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 decoder part of
>>>> the Codec API.
>>>>
>>>> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
>>>> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
>>>> ---
>>>> Documentation/media/uapi/v4l/dev-decoder.rst | 1084 +++++++++++++++++
>>>> Documentation/media/uapi/v4l/dev-mem2mem.rst | 8 +-
>>>> Documentation/media/uapi/v4l/pixfmt-v4l2.rst | 5 +
>>>> Documentation/media/uapi/v4l/v4l2.rst | 10 +-
>>>> .../media/uapi/v4l/vidioc-decoder-cmd.rst | 41 +-
>>>> 5 files changed, 1132 insertions(+), 16 deletions(-)
>>>> create mode 100644 Documentation/media/uapi/v4l/dev-decoder.rst
>>>>
>>>
>>> Thanks a lot for helping with remaining changes.
>>>
>>> Just one thing inline our team member found recently.
>>>
>>> [snip]
>>>> +Capture setup
>>>> +=============
>>>> +
>>> [snip]
>>>> +4. **Optional.** Set the ``CAPTURE`` format via :c:func:`VIDIOC_S_FMT` on the
>>>> + ``CAPTURE`` queue. The client may choose a different format than
>>>> + selected/suggested by the decoder in :c:func:`VIDIOC_G_FMT`.
>>>> +
>>>> + * **Required fields:**
>>>> +
>>>> + ``type``
>>>> + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``.
>>>> +
>>>> + ``pixelformat``
>>>> + a raw pixel format.
>>>
>>> The client should be able to set the width and height as well. It's a
>>> quite frequent case, especially in DMA-buf import mode, that the
>>> buffers are actually bigger (e.g. more alignment) than what we could
>>> get from the decoder by default. For sane hardware platforms it's
>>> reasonable to expect that such bigger buffers could be handled as
>>> well, as long as we update the width and height here.
>>
>> I've added this:
>>
>> ``width``, ``height``
>> frame buffer resolution of the decoded stream; typically unchanged from
>> what was returned with :c:func:`VIDIOC_G_FMT`, but it may be different
>> if the hardware supports composition and/or scaling.
>>
>> Is that what you were looking for?
>>
>
> Not sure if composition is a requirement here, but I guess it depends
> on how we define composition. Most of the hardware today at least
> support arbitrary strides (+/- some alignment), but still write the
> pixels at (0,0)x(w,h).
>
> In fact, there would be already some composition happening, even
> without arbitrary strides, because G_FMT would return values aligned
> in some way, but only the visible rectangle would contain meaningful
> pixel data.
Pretty much all codec drivers can handle composition, and with that I
don't mean the macroblock alignment, but that it can compose in, say,
a buffer that's twice the width/height than is strictly required.
And yes, it is a limited form of composition in that the top left corner
typically can't be changed.
Regards,
Hans
next prev parent reply other threads:[~2019-07-10 10:01 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-03 11:28 [PATCHv4 0/2] Document memory-to-memory video codec interfaces Hans Verkuil
2019-06-03 11:28 ` [PATCHv4 1/2] media: docs-rst: Document memory-to-memory video decoder interface Hans Verkuil
2019-06-10 19:54 ` Nicolas Dufresne
2019-06-11 8:29 ` Hans Verkuil
2019-06-12 0:25 ` Nicolas Dufresne
2019-06-12 6:49 ` Hans Verkuil
2019-06-12 7:02 ` Hans Verkuil
2019-07-15 12:12 ` Maxime Jourdan
2019-07-16 12:23 ` Nicolas Dufresne
2019-07-03 4:58 ` Tomasz Figa
2019-07-10 8:09 ` Hans Verkuil
2019-07-10 8:23 ` Tomasz Figa
2019-07-10 10:00 ` Hans Verkuil [this message]
2019-07-17 12:18 ` Nicolas Dufresne
2019-07-19 5:45 ` Tomasz Figa
2019-07-20 3:08 ` Nicolas Dufresne
2019-06-03 11:28 ` [PATCHv4 2/2] media: docs-rst: Document memory-to-memory video encoder interface Hans Verkuil
2019-06-03 14:02 ` [PATCHv4 0/2] Document memory-to-memory video codec interfaces Hans Verkuil
2019-06-04 15:19 ` Nicolas Dufresne
2019-07-03 9:04 ` Tomasz Figa
2019-07-03 17:07 ` Nicolas Dufresne
2019-06-10 15:57 ` Nicolas Dufresne
2019-06-11 8:35 ` Hans Verkuil
2019-06-12 0:33 ` Nicolas Dufresne
2019-06-13 6:48 ` Hans Verkuil
2019-06-14 1:09 ` Nicolas Dufresne
2019-06-15 8:08 ` Hans Verkuil
2019-06-16 0:17 ` Nicolas Dufresne
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=a6872700-c647-e1a9-02e7-b3a6080cf485@xs4all.nl \
--to=hverkuil-cisco@xs4all.nl \
--cc=acourbot@chromium.org \
--cc=andrew-ct.chen@mediatek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=posciak@chromium.org \
--cc=stanimir.varbanov@linaro.org \
--cc=tfiga@chromium.org \
--cc=tiffany.lin@mediatek.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).