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]

Date:   Thu, 16 May 2019 10:37:15 +0200
From:   Michael Tretter <m.tretter@...gutronix.de>
To:     Tomasz Figa <tfiga@...omium.org>
Cc:     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

On Tue, 14 May 2019 17:12:04 +0900, Tomasz Figa wrote:
> 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.

I understand. As the application continues to queue and dequeue buffers
on the CAPTURE queue until it received the last CAPTURE buffer and cannot
dequeue further CAPTURE buffers, "All CAPTURE buffers dequeued" is
correct. Thanks for the clarification.

Michael

> 
> Best regards,
> Tomasz
>