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.<div>
<br></div><div>dennis<br><br><div class="gmail_quote">On Mon, Nov 8, 2010 at 1:33 PM, Dennis Munsie <span dir="ltr"><<a href="mailto:dmunsie@gmail.com">dmunsie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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:<div>
<br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>params.b_enable_recon = 1;</div><div><br></div><div>...</div><div><br></div><div>x264_picture_t pic_in, pic_out;</div>
<div>// skipping pic_in setup</div><div>pic_out.img.i_csp = X264_CSP_I420;</div><div>pic_out.img.i_plane = 3;</div><div>pic_out.img.plane[0] = yBuffer;</div><div>pic_out.img.plane[1] = uBuffer;</div><div>pic_out.img.plane[2] = vBuffer;</div>
<div>pic_out.img.i_stride[0] = width;</div><div>pic_out.img.i_stride[1] = width >> 1;</div><div>pic_out.img.i_stride[2] = width >> 1;</div><div>x264_encoder_encode(encoder, &nal_ptrs, &nals, &pic_in, &pic_out);</div>
<div><br></div><div>// iff nals were generated, then yBuffer/uBuffer/vBuffer would contain the recon pixels</div><div><br></div></blockquote><div>Would something like this be useful to anyone else? If so, I can put together a patch for submission.</div>
<div><br clear="all">-- <br>dennis<br>
</div>
</blockquote></div><br><br clear="all"><br>-- <br>dennis<br>
</div>