Am 14.11.2017, 11:11 Uhr, schrieb <kavi...@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:cont...@ligh.de
_______________________________________________
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel
