[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