[x265] [PATCH] Add CLI option to enable or disable picture copy to internal frame buffer
Mario Rohkrämer
contact at ligh.de
Wed Nov 15 19:05:25 CET 2017
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
More information about the x265-devel
mailing list