linux-kernel - Re: [PATCH v3 2/2] media: docs-rst: Document memory-to-memory video encoder interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190514081204.GA132745@chromium.org>
Date:   Tue, 14 May 2019 17:12:04 +0900
From:   Tomasz Figa <tfiga@...omium.org>
To:     Michael Tretter <m.tretter@...gutronix.de>
Cc:     Tomasz Figa <tfiga@...omium.org>, linux-media@...r.kernel.org,
        linux-kernel@...r.kernel.org, Hans Verkuil <hverkuil@...all.nl>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Pawel Osciak <posciak@...omium.org>,
        Alexandre Courbot <acourbot@...omium.org>,
        Kamil Debski <kamil@...as.org>,
        Andrzej Hajda <a.hajda@...sung.com>,
        Kyungmin Park <kyungmin.park@...sung.com>,
        Jeongtae Park <jtp.park@...sung.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Tiffany Lin (林慧珊) 
        <tiffany.lin@...iatek.com>,
        Andrew-CT Chen (陳智迪) 
        <andrew-ct.chen@...iatek.com>,
        Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        Todor Tomov <todor.tomov@...aro.org>,
        Nicolas Dufresne <nicolas@...fresne.ca>,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        dave.stevenson@...pberrypi.org,
        Ezequiel Garcia <ezequiel@...labora.com>,
        Maxime Jourdan <maxi.jourdan@...adoo.fr>
Subject: Re: [PATCH v3 2/2] media: docs-rst: Document memory-to-memory video
 encoder interface

Hi Michael,

On Tue, Apr 30, 2019 at 07:34:12PM +0200, Michael Tretter wrote:
> On Thu, 24 Jan 2019 19:04:19 +0900, Tomasz Figa wrote:

[snip]

> > +State machine
> > +=============
> > +
> > +.. kernel-render:: DOT
> > +   :alt: DOT digraph of encoder state machine
> > +   :caption: Encoder state machine
> > +
> > +   digraph encoder_state_machine {
> > +       node [shape = doublecircle, label="Encoding"] Encoding;
> > +
> > +       node [shape = circle, label="Initialization"] Initialization;
> > +       node [shape = circle, label="Stopped"] Stopped;
> > +       node [shape = circle, label="Drain"] Drain;
> > +       node [shape = circle, label="Reset"] Reset;
> > +
> > +       node [shape = point]; qi
> > +       qi -> Initialization [ label = "open()" ];
> > +
> > +       Initialization -> Encoding [ label = "Both queues streaming" ];
> > +
> > +       Encoding -> Drain [ label = "V4L2_DEC_CMD_STOP" ];
> > +       Encoding -> Reset [ label = "VIDIOC_STREAMOFF(CAPTURE)" ];
> > +       Encoding -> Stopped [ label = "VIDIOC_STREAMOFF(OUTPUT)" ];
> > +       Encoding -> Encoding;
> > +
> > +       Drain -> Stopped [ label = "All CAPTURE\nbuffers dequeued\nor\nVIDIOC_STREAMOFF(CAPTURE)" ];
> 
> Shouldn't this be
> 
> 	Drain -> Stopped [ label = "All OUTPUT\nbuffers dequeued\nor\nVIDIOC_STREAMOFF(OUTPUT)" ];
> 
> ? While draining, the encoder continues encoding until all source
> buffers, i.e., buffers in the OUTPUT queue, are encoded or STREAMOFF
> happens on the OUTPUT queue. At the same time, the client continues to
> queue and dequeue buffers on the CAPTURE queue and there might be
> buffers queued on the CAPTURE queue even if the driver returned the
> buffer with the FLAG_LAST set and returns -EPIPE on further DQBUF
> requests.
>

The STREAMOFF should be on OUTPUT indeed, because that immediately
removes any OUTPUT buffers from the queue, so there is nothing to be
encoded to wait for anymore.

The "All OUTPUT buffers dequeued" part is correct, though. The last
OUTPUT buffer in the flush sequence is considered encoded after the
application dequeues the corresponding CAPTURE buffer is dequeued and
that buffer is marked with the V4L2_BUF_FLAG_LAST flag.

Best regards,
Tomasz