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

[Mario *LigH* Rohkrämer]

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.

-- 

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