that would be less than ideal in my case -- I am currently receiving the pictures to encode over shared memory, so if I had to copy the picture into x264s buffer, I wouldn&#39;t gain anything.  Another strike against me is that my pictures are coming in as YV12, not NV12.<div>
<br></div><div>it sounds as though I wouldn&#39;t be able to get this working easily, so I&#39;ll have to live with the overhead of copying.</div><div><br></div><div>Thanks!</div><div>dennis<br><br><div class="gmail_quote">
On Mon, Aug 30, 2010 at 4:34 PM, Jason Garrett-Glaser <span dir="ltr">&lt;<a href="mailto:darkshikari@gmail.com">darkshikari@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Mon, Aug 30, 2010 at 1:17 PM, Dennis Munsie &lt;<a href="mailto:dmunsie@gmail.com">dmunsie@gmail.com</a>&gt; wrote:<br>
&gt; Hi --<br>
&gt; I have a question about the x264_picture_t that gets passed into<br>
&gt; x264_encoder_encode() -- would it be possible for the encoder to not copy<br>
&gt; the YUV buffer and work off the pointer to the YUV buffer directly?  I<br>
&gt; already have a mechanism in my code that would insure that the YUV data that<br>
&gt; I provide in the x264_picture_t could stay around until the library<br>
&gt; indicates that it no longer needs that picture.  I&#39;m just not using it at<br>
&gt; the moment because x264 copies the frame data.  Even if this required<br>
&gt; additional restrictions on the picture that is passed in (such<br>
&gt; as alignment), I could work those into my program.<br>
&gt; I don&#39;t know if this would yield a noticeable improvement in encoding speed<br>
&gt; or not -- it may have been that this has been looked into in the past and<br>
&gt; there wasn&#39;t a clear win.  If that is the case, my apologies in advance.<br>
&gt; Thanks!<br>
&gt; dennis<br>
<br>
</div></div>I have a draft patch for this from a while back.  There would be two<br>
restrictions:<br>
<br>
1.  It would have to be a memory buffer of x264&#39;s choosing.<br>
2.  It would have to be stored as NV12.<br>
<br>
Dark Shikari<br>
_______________________________________________<br>
x264-devel mailing list<br>
<a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br>
<a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">http://mailman.videolan.org/listinfo/x264-devel</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>dennis<br>
</div>