[x265] [PATCH] Add CLI option to enable or disable picture copy to internal frame buffer

[Mario Rohkrämer]

Am 15.11.2017, 17:15 Uhr, schrieb Pradeep Ramachandran  
<pradeep at multicorewareinc.com>:

> On Wed, Nov 15, 2017 at 6:52 PM, Mario *LigH* Rohkrämer <contact at ligh.de>
> wrote:
>
>> Am 14.11.2017, 11:11 Uhr, schrieb <kavitha at multicorewareinc.com>:
>>
>> +.. option:: --copy-pic, --no-copy-pic
>>> +
>>> +       Allow encoder to copy input x265 pictures to internal frame
>>> buffers. When disabled,
>>> +       x265 will not make an internal copy of the input picture and  
>>> will
>>> work with the
>>> +       application's buffers. While this allows for deeper  
>>> integration,
>>> it is the responsbility
>>> +       of the application to (a) ensure that the allocated picture has
>>> extra space for padding
>>> +       that will be done by the library, and (b) the buffers aren't
>>> recycled until the library
>>> +       has completed encoding this frame (which can be figured out by
>>> tracking NALs output by x265)
>>> +
>>> +       Default: enabled
>>>
>>
>> I wonder how this is supposed to work with a CLI executable in a  
>> separate
>> process.
>>
>> When an application integrates x265 as a DLL or linked-in library, I can
>> imagine that there are memory pointers to application buffers with frame
>> contents which can be used by the encoder.
>>
>> But when calling x265 as a separate process, how does it get the frame
>> contents provided? Possibly as a pipe via STDIN or physical file. Means  
>> to
>> me, via file handles, allocated by the OS.
>>
>> Which means of controlling any RAM frame buffers are then available to a
>> calling application?
>>
>> In other words: Does it even make sense to expose these options to the  
>> CLI?
>>
>> I'm curious about a usage example.
>
>
> I understand the confusion this might cause. Let me try to clarify.
>
> If you invoke the x265 application, you won't be able to access the
> invoking application's memory buffers as you are in separate processes  
> and
> therefore this option isn't useful. This option is applicable only when  
> you
> do an integration of the x265 library with another application. In that
> case, the option is useful because we advocate that you use the
> x265_param_parse() API call to populate the right fields of the param
> structure instead of directly writing the struct yourself; doing it  
> through
> the API ensures that all checks are done by the library. For every param,
> the string that you pass to populate the param is the cli-option string  
> and
> therefore, exposing this as a CLI option enables folks who do deep
> integration to use this option in a clean fashion
>
> Does this make sense?

OK, so exposing it as CLI option may not help a pure x265 encoder binary  
as it is, but possibly any new application which may derive from this  
structure, especially when configuring itself with an internal CLI  
parameter string.

Vaguely understood, I hope.

-- 

Fun and success!
Mario *LigH* Rohkrämer
mailto:contact at ligh.de