Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <6ae8b9daa0cf406ab604e802bbb6d46736266bd5.camel@ndufresne.ca>
Subject: Re: [PATCH v3 2/2] media: docs-rst: Document memory-to-memory video
 encoder interface
From:   Nicolas Dufresne <nicolas@ndufresne.ca>
To:     Tomasz Figa <tfiga@chromium.org>
Cc:     Hans Verkuil <hverkuil@xs4all.nl>,
        Linux Media Mailing List <linux-media@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        Pawel Osciak <posciak@chromium.org>,
        Alexandre Courbot <acourbot@chromium.org>,
        Kamil Debski <kamil@wypas.org>,
        Andrzej Hajda <a.hajda@samsung.com>,
        Kyungmin Park <kyungmin.park@samsung.com>,
        Jeongtae Park <jtp.park@samsung.com>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        Tiffany Lin =?UTF-8?Q?=28=E6=9E=97=E6=85=A7=E7=8F=8A=29?= 
        <tiffany.lin@mediatek.com>,
        Andrew-CT Chen =?UTF-8?Q?=28=E9=99=B3=E6=99=BA=E8=BF=AA=29?= 
        <andrew-ct.chen@mediatek.com>,
        Stanimir Varbanov <stanimir.varbanov@linaro.org>,
        Todor Tomov <todor.tomov@linaro.org>,
        Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        dave.stevenson@raspberrypi.org,
        Ezequiel Garcia <ezequiel@collabora.com>,
        Maxime Jourdan <maxi.jourdan@wanadoo.fr>
Date:   Mon, 15 Apr 2019 08:30:03 -0400
In-Reply-To: <CAAFQd5BmDvou6qdaw6uSAWTyLBXeTH8RvnBi7dCGCRdedvHPMg@mail.gmail.com>
References: <20190124100419.26492-1-tfiga@chromium.org>
         <20190124100419.26492-3-tfiga@chromium.org>
         <4bbe4ce4-615a-b981-0855-cd78c7a002d9@xs4all.nl>
         <471720b7-e304-271b-256d-a3dd394773c9@xs4all.nl>
         <CAAFQd5Au_=08pVom1z3C1nHKdKak8Y4d5odR6fiNB4urDhfjKQ@mail.gmail.com>
         <787ddc1f-388d-82be-2702-0d7d256f636c@xs4all.nl>
         <CAAFQd5DozydYBpEceFTbJSutP+gwjxybpd1q6N1Vi+YragQT+w@mail.gmail.com>
         <6cb0caf1-61a6-0719-1ade-1dcf8ed8a020@xs4all.nl>
         <CAAFQd5DdDv+Nu0Dry1XRpYAnz0DrSE5kEf7GxY64tg6aJebzMQ@mail.gmail.com>
         <1ec36515-b6ec-b355-47fb-2fe5ad4b3241@xs4all.nl>
         <03751bb884a443ec1cea7b5c023c9d520ffcc3a0.camel@ndufresne.ca>
         <CAAFQd5BmDvou6qdaw6uSAWTyLBXeTH8RvnBi7dCGCRdedvHPMg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.0 (3.32.0-1.fc30) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Le lundi 15 avril 2019 à 17:56 +0900, Tomasz Figa a écrit :
> > Sounds like we need something similar to the SOURCE_CHANGE event
> > mechanism if we want to allow dynamic bitrate control which would
> > require re-allocation of the capture buffer queue. (Or any other
> > runtime control on our encoders, which is really expected to be
> > supported these days).
> 
> Sounds like it. Or we could just assume that one needs to stop both
> queues to do a resolution change, since most codes would anyway reset
> the stream (e.g. send PPS/SPS, etc. for H.264) to change the
> resolution. Not sure if that assumption always holds, though.

I think for resolution/profile/level changes you have a good point, as
you said, we need to start a new stream (new header, new IDR). Maybe
then we should simply require the driver to allocate enough buffer to
support the highest bitrate for the selected resoltion/profile/level?
Though, this could create situation where we waste a lot of memory. On
the other side, if you need to reallocate your buffers on bitrate
change, it might create a visible freeze.

Nicolas