[x264-devel] access to reconstructed pixels

[Dennis Munsie]

Well, I'm using libx264, not the command line version. I could use a pipe, but it seems a bit inefficient. 

Also, it looks like the recon file needs to be a real file and not a special file because the recon frames are written in presentation order, not decode order. And to do that, the code uses seek to skip around in the file as necessary. So pipes won't work for this. 

I was able to get the recon pixels via pic_out using the latest version from git and a small bit of code to add an option to always enable the deblocker. The pixels don't quite come out the same way they come in - there are only two planes, luma and an interleaved chroma - but otherwise everything seems good.

Other than decreased performance, is there any reason not to run the deblocker all the time? Will this have any unattended side effects? Is there anything else that might need to be done to get the recon pixels accurately?

Thanks!
dennis

On Nov 8, 2010, at 7:03 PM, Jason Garrett-Glaser <darkshikari at gmail.com> wrote:

> On Mon, Nov 8, 2010 at 1:18 PM, Dennis Munsie <dmunsie at gmail.com> wrote:
>> I want to see the same pixels that I would see if I fed the NALs into a 264 decoder.  When I looked at the code, it looks like the deblocker is only run when the encoder decides it's necessary *OR* if the recon pixels are being dumped to a YUV file (search in encoder.c for psz_dump_yuv -- there are two cases where it's used to set b_deblock).  Since I'm wanting those exact pixels that would be dumped to a file, I also want to make sure that the deblocker is run as well.
>> 
>> Or is this the wrong way to go about this?
> 
> Couldn't you give x264 a pipe as the yuv dump file?
> 
> Dark Shikari
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel