lkml.org 
[lkml]   [2019]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCHv4 1/2] media: docs-rst: Document memory-to-memory video decoder interface
    From
    Date
    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?

    >
    > It's more like a clarification anyway, so if you think it would be
    > better to just merge the current revision, I could send a follow up
    > patch.
    >
    > Regardless of that and FWIW:
    >
    > Reviewed-by: Tomasz Figa <tfiga@chromium.org>

    Thanks!

    Hans

    >
    > Best regards,
    > Tomasz
    >

    \
     
     \ /
      Last update: 2019-07-10 10:10    [W:4.234 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site