>>> Can you explain the actual intended use-case for this?
>>>
>>> The current way to handle resolution changes (or any other stream change of
>>> similar magnitude, like a pixel format change) is to flush the existing
>>> encoder and then make a new one with the new parameters. Even ignoring t
On 13/03/2019 01:01, Oliver Collyer wrote:
>> On 12 Mar 2019, at 23:40, Mark Thompson wrote:
>>
>>> On 08/03/2019 07:44, Oliver Collyer wrote:
>>> From c704e3535f866d9f89535b9df59db9ca9811bcf9 Mon Sep 17 00:00:00 2001
>>> From: Oliver Collyer
>>> Date: Fri, 8 Mar 2019 07:42:41 +
>>> Subject:
> On 12 Mar 2019, at 23:40, Mark Thompson wrote:
>
>> On 08/03/2019 07:44, Oliver Collyer wrote:
>> From c704e3535f866d9f89535b9df59db9ca9811bcf9 Mon Sep 17 00:00:00 2001
>> From: Oliver Collyer
>> Date: Fri, 8 Mar 2019 07:42:41 +
>> Subject: [PATCH 1/1] avcodec/nvenc: Reconfigure resoluti
On 08/03/2019 07:44, Oliver Collyer wrote:
> From c704e3535f866d9f89535b9df59db9ca9811bcf9 Mon Sep 17 00:00:00 2001
> From: Oliver Collyer
> Date: Fri, 8 Mar 2019 07:42:41 +
> Subject: [PATCH 1/1] avcodec/nvenc: Reconfigure resolution on-the-fly
>
> ---
> libavcodec/nvenc.c | 31 +++
>>> To use this feature you would need to:
>>>
>>> 1. Specify max_width and max_height before opening the encoder
>>
>> Can't they be set to a maximum number to be as flexible as possible?
>>
>
> It would allocate the output surfaces to this size if we took that approach
> and I don’t think
