What i have to do is quite easy:
i just need to encode a simple bmp image 1 bytePerPixel in greyscale exploiting HW acceleration.
The image is already loaded in an array(unsigned char *) of w*h elements, where w and h are respectively the width and the size of the image.
As a first step i created a sample application to encode a single image based on files saved in samples/common of the Media sdk. This application is very simple and works properly as expected, but the problem is that it does not completely exploit hw acceleration, a warning message appears right after the encoder init() function.
After that i integrate in my application the vaapi allocator, always from the samples/common files, the warning message about the partial HW acceletion is no longer shown, the encoding time is improved, i got any other errors/warnings but the output image(saved to a file) doesn't make sense, it is just like a noise, it is made of white and black squares.
I'd like to ask you what i'm doing wrong in my code, and if you could recreate this simple application to encode a greyscale image contained in a buffer.
thanks for the support
Thanks for posting in Intel Communities.
Could you please share the below details:
- Media SDK Version
- OS you are using
- Sample reproducer code and the exact steps you followed
- Screenshots of the error
- What samples you are using from samples/common file
thanks for reply me back.
The target device is based on Elkharth-Lake (Atom x6000E) and uses the intel Yocto image with pre-installed Media SDK and libVA (core-image-sato-sdk-intel-corei7-64).
I set MFX_CHROMAFORMAT_MONOCHROME as encoder chroma format and MFX_FOURCC_NV12 as FrameInfo.FourCC parameters.
When i use vaapi/sysmem allocator then the warning related the partial hw accelleration (after the encoder->init()) disappers, I don't get any error/warnings at all, but the output jpeg file is just like a noise (black and white squares).
If i don't use any allocators i get the partial acceleration warning but the output jpeg file is correct.
for the allocator part i use following files that i found in samples/common:
I also tried the same code on my PC:
Mesa HD Graphic 520
Ubuntu 20.04 LST
Intel Media SDK 22.1.0
In both cases, using allocator and not using it, the result is the same: the program chrash during the following instruction;
i just modify a bit the "simple_3_encode" example you provided in github, and i set the Y(luma) plane of the encoder surface with the input image buffer image buffer.
Of course i can share the mfxEncoder parameters:
params->mfx.CodecId = MFX_CODEC_JPEG;
params->mfx.FrameInfo.FrameRateExtN = 60;
params->mfx.FrameInfo.FrameRateExtD = 1;
params->IOPattern = MFX_IOPATTERN_IN_SYSTEM_MEMORY;
params->mfx.FrameInfo.FourCC = MFX_FOURCC_NV12;
params->mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_MONOCHROME;
params->mfx.FrameInfo.PicStruct = MFX_PICSTRUCT_PROGRESSIVE;
params->mfx.FrameInfo.Width = MSDK_ALIGN16(imgWidth);
params->mfx.FrameInfo.Height = MSDK_ALIGN16(imgHeight)
params->mfx.FrameInfo.CropX = 0;
params->mfx.FrameInfo.CropY = 0;
params->mfx.FrameInfo.CropW = imgWidth;
params->mfx.FrameInfo.CropH = imgHeight;
// JPEG encoder settings overlap with other encoders settings in mfxInfoMFX structure
params->mfx.Interleaved = 1;
params->mfx.Quality = quality;
params->mfx.RestartInterval = 0;
I found an handy workarond to get correct output images and exploiting HW acceleration, but i think it is not optimized and the econding time could further reduce.
I set YUV420 as chromaFormat instead MONOCHROME as explained before, but this time in order to avoid green images i also set the value of UV plane to 128 even if it should not be needed since the image is a grayscale one.
memcpy(encoderSurfaces[i].Data.Y, imgBuffer, width * height)
memset(encoderSurfaces[i].Data.UV, 128, width * height / 2); // YUV420 workaround
With the UV plane set to 128 the images are grayscale ones, but this seems very strange to me, i'm working with 1byte grayscale images, the havent any other chroma information, just the brightness. Having set YUV420 of course takes into account also the UV plan and not only the Y one and doing this i believe the solution is not optimized.
I thought that using chroma format MONOCHROME whould have been better in terms of encoding time since it shouldn't take into account U, V planes, but when i use it i get images made of black and white squares.
Which would it be the best way(the faster one) to proceed in order to encode an image of 1 byte per pixel in greyscale without any other chroma info?
which are the correct encoder parameters?
Thanks in advance,
Do you have any news regarding the jpeg encoding of a monochrome image?
In my programe i'm encoding greyscale images of 1280X960 pixels, but i try to encode pictures of different size i get once again an output image that is like a noise. Are there some size limitations? Could you haelp me?
This appears to be an issue with libVA. You can submit the issue here:
But I will do the same.