<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 15, 2017 at 6:52 PM, Mario *LigH* Rohkrämer <span dir="ltr"><<a href="mailto:contact@ligh.de" target="_blank">contact@ligh.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Am 14.11.2017, 11:11 Uhr, schrieb <<a href="mailto:kavitha@multicorewareinc.com" target="_blank">kavitha@multicorewareinc.com</a>><wbr>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+.. option:: --copy-pic, --no-copy-pic<br>
+<br>
+ Allow encoder to copy input x265 pictures to internal frame buffers. When disabled,<br>
+ x265 will not make an internal copy of the input picture and will work with the<br>
+ application's buffers. While this allows for deeper integration, it is the responsbility<br>
+ of the application to (a) ensure that the allocated picture has extra space for padding<br>
+ that will be done by the library, and (b) the buffers aren't recycled until the library<br>
+ has completed encoding this frame (which can be figured out by tracking NALs output by x265)<br>
+<br>
+ Default: enabled<br>
</blockquote>
<br></span>
I wonder how this is supposed to work with a CLI executable in a separate process.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Which means of controlling any RAM frame buffers are then available to a calling application?<br>
<br>
In other words: Does it even make sense to expose these options to the CLI?<br>
<br>
I'm curious about a usage example.</blockquote><div><br></div><div>I understand the confusion this might cause. Let me try to clarify.</div><div><br></div><div>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</div><div><br></div><div>Does this make sense?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Fun and success!<br>
Mario *LigH* Rohkrämer<br>
mailto:<a href="mailto:contact@ligh.de" target="_blank">contact@ligh.de</a></font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
______________________________<wbr>_________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/l<wbr>istinfo/x265-devel</a><br>
</div></div></blockquote></div><br></div></div>