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

[Pradeep Ramachandran]

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?


>
>
> --
>
> Fun and success!
> Mario *LigH* Rohkrämer
> mailto:contact at ligh.de
>
>
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20171115/293af22f/attachment.html>