[x264-devel] access to reconstructed pixels

Jason Garrett-Glaser darkshikari at gmail.com
Mon Nov 8 21:22:55 CET 2010


On Mon, Nov 8, 2010 at 11:16 AM, Dennis Munsie <dmunsie at gmail.com> wrote:
> 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.

Why exactly do you want to force the deblocker to run?

Dark Shikari


More information about the x264-devel mailing list