[x264-devel] avoiding copying x264_picture_t

[Dennis Munsie]

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't gain anything.  Another strike against me is that
my pictures are coming in as YV12, not NV12.

it sounds as though I wouldn't be able to get this working easily, so I'll
have to live with the overhead of copying.

Thanks!
dennis

On Mon, Aug 30, 2010 at 4:34 PM, Jason Garrett-Glaser <darkshikari at gmail.com
> wrote:

> On Mon, Aug 30, 2010 at 1:17 PM, Dennis Munsie <dmunsie at gmail.com> wrote:
> > Hi --
> > I have a question about the x264_picture_t that gets passed into
> > x264_encoder_encode() -- would it be possible for the encoder to not copy
> > the YUV buffer and work off the pointer to the YUV buffer directly?  I
> > already have a mechanism in my code that would insure that the YUV data
> that
> > I provide in the x264_picture_t could stay around until the library
> > indicates that it no longer needs that picture.  I'm just not using it at
> > the moment because x264 copies the frame data.  Even if this required
> > additional restrictions on the picture that is passed in (such
> > as alignment), I could work those into my program.
> > I don't know if this would yield a noticeable improvement in encoding
> speed
> > or not -- it may have been that this has been looked into in the past and
> > there wasn't a clear win.  If that is the case, my apologies in advance.
> > Thanks!
> > dennis
>
> I have a draft patch for this from a while back.  There would be two
> restrictions:
>
> 1.  It would have to be a memory buffer of x264's choosing.
> 2.  It would have to be stored as NV12.
>
> Dark Shikari
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>



-- 
dennis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20100830/f23c56e0/attachment.htm>