I want to use custom quantification table for the jpegenc codec.
I'm using DVSDK 3.10 with gstreamer_ti :
gst-launch -v ticapturesrc num-buffers=1 video-standard=1080i ! TIVidResize ! 'video/x-raw-yuv, width=720, height=288' !
TIC6xColorspace engineName=codecServer ! queue ! TIImgenc1 engineName=codec Server codecName=jpegenc iColorSpace=YUV420P oColorSpace=YUV420P ! filesink ....
When i use my custom quantification table, i have always the same wrong header in my jpeg file generated:
FF DB 00 84
00 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02
02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02
01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02
FF DA
and the image it's near 64kB and with another jpeg codec with the table below i'm near 11kB.
My code :
IDMJPGE_TIGEM_Params JPEG_Params = { { sizeof(IDMJPGE_TIGEM_Params), /* Size of params structure */ 288, 720, 0, XDM_BYTE, XDM_YUV_420P, }, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, };
IDMJPGE_TIGEM_CustomQuantTables DQT_table = { { /*Luma*/ 14,9,8,14,21,35,45,54, 10,10,12,16,23,51,53,49, 12,11,14,21,35,50,61,50, 12,15,19,25,45,77,71,55, 16,19,33,50,60,97,92,68, 21,31,49,57,72,93,101,82, 43,57,69,77,92,108,107,90, 64,82,84,87,100,89,92,88 },
{ /*chroma*/ 15,16,21,42,88,88,88,88, 16,18,23,59,88,88,88,88, 21,23,50,88,88,88,88,88, 42,59,88,88,88,88,88,88, 88,88,88,88,88,88,88,88, 88,88,88,88,88,88,88,88, 88,88,88,88,88,88,88,88, 88,88,88,88,88,88,88,88 }
};
IDMJPGE_TIGEM_DynamicParams JPEG_DynParams = { { sizeof(IDMJPGE_TIGEM_DynamicParams), XDM_DEFAULT, XDM_YUV_420P, 288, 720, 720, XDM_ENCODE_AU, 35, }, 288, 0, &DQT_table, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, };
imgenc1->hIe = Ienc1_create(imgenc1->hEngine, (Char*)imgenc1->codecName, (IMGENC1_Params*)&JPEG_Params, (IMGENC1_DynamicParams*)&JPEG_DynParams);
Does someone already try to use custom quant table with succes ?
NOTE : There is a difference between the user guide PDF and the idmjpge.h in the struct definition (see DRI / customQuantTable).
Any help will be appreciate !
I tried to use the quantification table on appendix A of the user guide PDF, and i have the same result...
Even i put no value on IDMJPGE_TIGEM_CustomQuantTables DQT_table = { };
I have the same thing...
Hi,
The customer quantization table should be set through SETPARAMS command of IMGENC1_control() call.
Int32 IMGENC1_control(IMGENC1_Handle handle, IMGENC1_Cmd id, IMGENC1_DynamicParams *params, IMGENC1_Status *status);
Can you please share the arguments passed to this call?
Regards
Sayanna
Your dynamic params looks fine to me. I doubt that SETPARAMS call might be failing w/o setting the parameters to encode and the codec is using default parameters. Can you please try to change the quality factor (may be from 35 to 80) and see whether there is any change in output? If there is a change in output, we can confirm that base params setting is fine. Then we need to see whether extended params are set properly or not.
Could someone from TI confirm that this features work with a DM6467T ?
I'm still thinking it's an encoder problem, so i need to have a confirmation to continue or not with this encoder.
Thanks in advance,
Mika
up
Hi Mika,
What was the issue? Any parameter to codec required to be changed?
I still have the same problem. The encoder works fine if i use the qValue method to change the quality or compression level.
Now i use the jpegenc in the TIVidenc1 pluggin (without thread process and to just keep one pluggin to make h264 & MJPEG encode) , with YUV422P input for the jpegenc.
But i still can't use custom quantification tables with this encoder. If i do that, and look at my header file i have bad values after the FF DB marker :
FF DB 00 84 00 02 02 02 02 02 FF FF FF 02 02 02 02 FF FF 02 02 02 FF FF 02 04 04 05 FF FF 03 02 FF FF FF 02 02 FF FF04 04 04 FF FF 06 05 FF FF FF FF 04 03 FF FF FF 06 06 FF FF FF FF 03 05 06 FF FF FF FF FF 01 FF FF FF FF FF 02 02 02 FFFF FF FF 03 03 FF FF FF 02 03 FF FF FF FF 04 03 FF FF 02 02 02 FF FF 03 02 FF FF FF 05 06 FF FF 04 04 02 02 FF FF 05 04 05 FF FF 05 05 05 04 FF FF FF 06 05 05 06 06 FF DA
And the best surprise it's when i change the value of the qValue parameter the encoding quality/compress change according to it... I'm a little bit despair with this functionality.
IDMJPGE_TIGEM_Params JPEG_Params = { { sizeof(IDMJPGE_TIGEM_Params), /* Size of params structure */ videnc1->height, videnc1->width, 0, XDM_BYTE, XDM_YUV_422P, }, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, }; IDMJPGE_TIGEM_CustomQuantTables DQT_table = { { /*Luma*/ 14,9,8,14,21,35,45,54, 10,10,12,16,23,51,53,49, 12,11,14,21,35,50,61,50, 12,15,19,25,45,77,71,55, 16,19,33,50,60,97,92,68, 21,31,49,57,72,93,101,82, 43,57,69,77,92,108,107,90, 64,82,84,87,100,89,92,88 }, { /*chroma*/ 15,16,21,42,88,88,88,88, 16,18,23,59,88,88,88,88, 21,23,50,88,88,88,88,88, 42,59,88,88,88,88,88,88, 88,88,88,88,88,88,88,88, 88,88,88,88,88,88,88,88, 88,88,88,88,88,88,88,88, 88,88,88,88,88,88,88,88 }, }; IDMJPGE_TIGEM_DynamicParams JPEG_DynParams = { { sizeof(IDMJPGE_TIGEM_DynamicParams), XDM_DEFAULT, XDM_YUV_422P, videnc1->height, videnc1->width, videnc1->width, XDM_ENCODE_AU, videnc1->qValue, }, videnc1->height, 0, #ifdef iVLCD NULL, #endif &DQT_table, // 0, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, XDM_DEFAULT, };
Thanks Sayanna to following the thread !
Just my 2 cents from a framework POV...
On multicore systems like OMAP3 and DM6467[T], Codec Engine is running the codecs in 'remote' mode. That is, it's managing a codec on a different processor, and doing address translation and cache management for "buffers it knows about" in the various XDM structs. This address translation and cache mgmt needed when crossing processor boundaries takes place in "stubs" and "skeletons", which is typical RPC-jargon for marshalling/unmarshalling arguments that cross boundaries.
I don't know details on this JPEG encoder, but the stubs/skeletons used by default in Codec Engine only know about the 'base XDM structs'. That is, the stubs/skels know about buffer pointers in the base class (e.g. IIMGENC1 types), but not in codec-specific extended classes (e.g. IDMJPGE types). There are some details on extending XDM here:
http://processors.wiki.ti.com/index.php/Extending_data_structures_in_xDM
From the code snippets in this thread, these custom Q tables look like they're passed in extended structs, so the default stubs/skels don't know these are pointers and won't pass them correctly. Specifically, they'll be passed to the DSP unchanged. Obviously, that's wrong - the virt addrs need converted to DSP-side addrs, the buffer containing the Q table cache will need its cache managed, etc. Also, unless the codec makes a copy of these Q tables (which, for simplicity, it probably should), ownership of that buffer will need to be established - who owns that buffer after control() returns... and if it's the codec, when is that buffer reclaimed by the app?
Codec Engine supports use cases like this, but it's the codec's responsibility to provide "custom stubs/skels" if it places anything other than scalar values in the extended structs. Does anyone know if this codec is providing these stubs/skels?
Note for codec vendors, there _are_ IN/OUT buffer pointers in the base XDM classes in the *_Status structs (e.g. IIMGENC1_Status.data field), and those existing buffer pointers are likely preferable for accepting things like custom Q tables. See this XDM FAQ for some details.
Chris
hi Chris,
Thank you to give these info.
I'm not sure to have completely understood what you wrote, so is there something i can do to give you more info or only the codec provider cans give more info ?
up !
I'm hoping the codec folks can chip in (I guess so are you!).
Briefly, are any of those extended params "pointers"? If so, Codec Engine is _not_ passing them correctly to codecs if the codecs are running on different processors.
It looks like DQT_Table points at an ARM-side struct, and a pointer to it is passed in 'extended' params. If I'm reading that right, again, Codec Engine doesn't know that's a pointer (b/c it's in a codec-specific 'extended' param). We'd need the codec team to provide details on how to use that DQT_Table with Codec Engine when the codec is 'remote'.