Green RGB32 output from H.264 decoder

[franknatoli]

For one MFC GUI application, am using file reader and splitter to extract video data from MPEG-4 file with H.264 encoded data and presenting that data to H264VideoDecoder. This application generates good, clean RGB32 bitmaps from the H264VideoDecoder.

For another [console] application, am using specialized code to directly extract H.264 data from MPEG-4 MDAT box and presenting that H.264 data to H264VideoDecoder. No reader, no splitter. Since splitter normally extracts all necessary H264VideoDecoder initialization information [width, height, color_format, etc.], it is necessary for this console application to extract that information directly from the MPEG-4 file. This application generates pure green RGB32 bitmaps from the H264VideoDecoder. Have examined the bitmap data and indeed only one byte of each four pixel bytes is non-zero, the green byte.

Am reasonably certain that H264VideoEncoder parameters are identical for both applications.

What might be causing the pure green output?

[Ying_H_Intel]

Hello franknatoli,

Can you provide your console code and test stream, IPP version information so we can look into the problem?

If the code and streamare private, when you attach them, please mark it as Private. or Submit your code to <> with product catagory " Intel IPP Sample code".

About the green RGB32 problem, hust guess, there may be caused bya tiny error.We have a simpledecoder.cpp filein the article <http://software.intel.com/en-us/articles/getting-started-with-intel-ipp-unified-media-classes-sample/>. You can build a small console application based on it and letme know if theYV12 format output looks right?

DataOut.Init(imgWidth,imgHeight,UMC::YV12,8);

DataOut.SetBufferPointer(cYUVData,imgWidth*imgHeight*3/2);

Then consider the format UMC::RGB32?

Best Regards,

Ying

[franknatoli]

Ying: attached is a zip of the VS2005 project that contains the command line test. Also see directory "TestFiles" that contains a test MP4 file and POS file [which contains a record for each video frame in the MP4].

Invoke the program via:

FrameH264Test

For example:

FrameH264Test c:\tmp Channel1_ 140000

The test program will produce a BMP file which represents the video frame at time position 140000 [140 seconds, zero milliseconds] mapped using the POS file. It's all green.

Thanks for your time.

[Ying_H_Intel]

Hi Frank,

When I try to build the project in MSVC2005, I get the error fatal error C1083: Cannot open include file: 'ussr_ioctl.h': No such file or directory. So no chance to debug.

But Could you write the data in inBuf, which is calledin int H264DecoderNextFrame(LPVOID arg, LPBYTE inBuf, DWORD inBufLen, LPBYTE outBuf, DWORD outBufLen) , into a file, then send the file back to me?

Or could you please feed the data file to your first project and see if theh.264 data extracted from MP4 Box is correct?

Best Regards,

Ying

[franknatoli]

Ying: I have uploaded a second zip, this named FrameGrabH264Test2.

TestFiles folder now contains the "bad" green BMP extracted from the MP4 file. It also contains a dot-h264 file which is the H264 data extracted from the MP4 file and run through the H264 decoder by FrameGrabH264Decoder.cpp.

Include folder contains the include files needed to recompile. VS2005 project has been altered to look for the include files in this folder.

The only thing not contained in the project are all the Intel IPP/UMC include files and libraries. I used 6.0.0.062 for this particular build.

When I process the MP4 file using MP4Splitter and process the video stream more conventionally, the H264Decoder has no problem generating RGB32 output bitmaps with proper color.

But when I perform my own extraction of the H264 data from the MP4 file, the H264Decoder generates all green RGB32 output bitmaps. My guess is that some initialization data or action provided or performed by MP4Splitter is omitted by my H264Decoder direct code and this is causing the all green output.

Thanks for your time.

[franknatoli]

The Intel IPP/UMC H.264 decoder appears to have a bug when fed a stream of H.264 data that begins with an interlaced stream I-frame with odd rows.

The decoder requires two "fields" of H.264 data, one "field" being the data for an interlaced [1/60 second] frame, to construct a single output frame bitmap.

If the decoder starts with an I-frame with even rows, followed by P-frames, it correctly decodes data and produces full color output frame bitmaps.

But if the decoder starts with an I-frame with odd rows, followed by P-frames, it incorrectly decodes data and produces all green output frame bitmaps.