[x264-devel] access to reconstructed pixels

[Dennis Munsie]

Ok -- in my original look at the code, I didn't notice that the
reconstructed pixels are already being stuffed into pic_out -- but it
doesn't look like the deblocker will always be guaranteed to run unless the
dump YUV option is turned on.  So, my proposal now is for a patch to add the
b_enable_recon flag that would force the deblocker to run, along with some
updates to the x264.h file documenting the output of the recon pixels in the
pic_out struct.

dennis

On Mon, Nov 8, 2010 at 1:33 PM, Dennis Munsie <dmunsie at gmail.com> wrote:

> I would like to be able to have access to the reconstructed pixels that
> x264 generates without having to write them out to a file.  Looking at the
> code, it looks like I can use the fdec field in x264_t (the non opaque
> version) to get access to these, as long as I force the deblocker to run.
>  Since this isn't for production code, I don't mind doing this for now.  But
> would there be any interest in a patch to provide a cleaner method of
> providing reconstructed pixels?  I was thinking of something along the lines
> of using the pic_out struct to provide the pixels for frame being returned.
>  You would have to enable the feature in x264_param_t and provide a buffer
> in the pic_out struct when you call x264_encoder_encode(). Something like
> this:
>
> params.b_enable_recon = 1;
>
> ...
>
> x264_picture_t pic_in, pic_out;
> // skipping pic_in setup
> pic_out.img.i_csp = X264_CSP_I420;
> pic_out.img.i_plane = 3;
> pic_out.img.plane[0] = yBuffer;
> pic_out.img.plane[1] = uBuffer;
> pic_out.img.plane[2] = vBuffer;
> pic_out.img.i_stride[0] = width;
> pic_out.img.i_stride[1] = width >> 1;
> pic_out.img.i_stride[2] = width >> 1;
> x264_encoder_encode(encoder, &nal_ptrs, &nals, &pic_in, &pic_out);
>
> // iff nals were generated, then yBuffer/uBuffer/vBuffer would contain the
> recon pixels
>
> Would something like this be useful to anyone else?  If so, I can put
> together a patch for submission.
>
> --
> dennis
>



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