RGB to NV12 performance in encoding h.264 in sample_encode

[RyanS]

I'm using SDK 3.0 beta 4. My PC is a Core i5-2500k. I've modified sample_encode to read from an avi containing raw RGB data and encode it to h.264. It's working and the output is correct. The good news is that the encode speed is great, the bad news is that the overall processing is not much faster than other encoding software, maybe because the processing is dominated by RGB toYUV420 conversion, primarily ippiRGBToYUV420_8u_P3R (profiler says 24% of time) and then ippiSwapChannels_8u_C3R (19%).

I'm quite surprised that just converting to YUV420 seems to be taking nearly as long as other encoders take to do the entire encode (from the same source file).So I'm wondering, does this make any sense, or must I be doing something wrong? Ifit seems like my code is likely to be working as expected, is there anything I can do to speed up the conversion?

Ryan

[Eric_S_Intel]

Hi Ryan,

Can you use VPP to accelerate the color conversion? The DirectShow h264 encoder filter demonstrates how to setup VPP to accept RGB32 anddo the conversion inthe hardware. Check out mfx_video_enc_filer.cpp in the samples.

-Eric

[RyanS]

My primary purpose is simply to get an idea of the performance of my transcode scenario (AVI with raw rgb data to h.264) using QuickSync hardware. I took a look at the example you mentioned (1000 lines or so)andit looks like it would take me awhile to grok that and pull out the code I want. I don't wantto invest the timeon that right now. Is there aquicker way to determine the speed?Can I (easily) build aDirectShow or MediaFoundation filter chain using the sample filters to do this processing?

[Eric_S_Intel]

The DirectShow filters are not optimized for performance, but they certainly can be used to examine your transcode scenario. The inclusion of VPP color conversion in the sample should help you get an idea. Use graphedit to build something like: SouceFilter(Your RGB data) -> H.254 Encoder Sample Filter (with VPP Color Conversion) -> MP4 Muxer -> FileWriter. All MSDK samples and no code.

Hope this helps

-Eric

[RyanS]

I ended up using the same sample I was working with originally, sample_encode. It alreadysupportedVPP (I didn't realize that originally) so I just had to create my own file reader in lieu of CSmplYUVReaderand tell VPP about the color format (RGB3).

I don't think thecomment above about using DirectShow filters was accurate, I didn't find VPP code in there, maybe thatsuggestion confuses DirectShow and Media Foundation.I thinkthe MF sample has VPP code, but MF doesn't work for me, evidentlydue to a MF GUID registration problem (not Intel's problem) that makes it impossible to connect filters that use RGB GUIDs, but that's another story.

Note that my profiler numbers in my original post were very distorted (possibly byusing adebug build) but regardless the color conversion was stillthe bottleneck. The transcode is muchfaster nowwith VPP.

Ryan

[Nina_K_Intel]

Hi Ryan,

Good to hear about your progress. One comment, just in case it may appear useful for you, there is VPP code in DirectShow samples of Media SDK. Though it's not a separate plugin as in Media Foundation. VPP code is a part of CEncVideoFilter, VPP functions preceed the ENCODE functions. You may check out the filemfx_video_enc_filter.cpp.

Regards,

Nina

[RyanS]

Okay, I see the VPP code in mfx_video_enc_filter as you said. However the sample seems to not be using VPP for RGB4 to NV12 conversion. Itlooks like it uses plugin_cscwhich uses the CPU to do the conversion. My goal is to use VPP for the RGB3 to NV12 conversion, but if I copy the RGB4 code path it will not use VPP. I'm not sure why the sample doesn't use VPP for the conversion. I see the comment about top-down vs bottom-up memory order. Ismfx_video_enc_filter correct to use the CPU for the conversion or couldit be made to use VPP for the conversion?

Ryan