Hi Chris,
Yes. The extended parameter (of type IDMJPGE_TIGEM_CustomQuantTables) is a pointer. What will happen in this case where the parameter is a pointer?
1. Will the code engine on ARM side pass on this pointer to DSP side, but the codec on DSP side will not be able to understand as the pointer is not shared memory.
OR
2. Codec engine will send a NULL pointer as it understands that the pointer does not point to a shared memory.
Can the following be a possible solution?
Allocate a buffer of size IDMJPGE_TIGEM_CustomQuantTables using cmem and copy the quant tables to the same. Pass on this buffer as pointer of type IDMJPGE_TIGEM_CustomQuantTablesto to CE, which will be able to do address conversion (as it is in shared memory) and pass it codec.
Regards
Sayanna
Hi all,
I tried some stuff regarding to the last post :
ptr = CMEM_alloc(128, NULL); if (ptr == NULL) GST_ERROR("Failed to allocate ptr\n"); p = CMEM_getPhys(ptr); GST_ERROR("Allocated buffer of size %d at virtual address %#x , phys address = 0x%lx .\n", 128, (unsigned int) ptr, p);
int DQT_table[128] = {
16, 11, 10, 16, 24, 40, 51, 61, 12, 12, 14, 19, 26, 58, 60, 55, 14, 13, 16, 24, 40, 57, 69, 56, 14, 17, 22, 29, 51, 87, 80, 62, 18, 22, 37, 56, 68, 109, 103, 77, 24, 35, 55, 64, 81, 104, 113, 92, 49, 64, 78, 87, 103, 121, 120, 101, 72, 92, 95, 98, 112, 100, 103, 99,
17, 18, 24, 47, 99, 99, 99, 99, 18, 21, 26, 66, 99, 99, 99, 99, 24, 26, 56, 99, 99, 99, 99, 99, 47, 66, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99}; // Default quantization table
save_ptr = ptr;for (i = 0 ; i < 128; i++){ *save_ptr++ = DQT_table[i];}
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, (IDMJPGE_TIGEM_CustomQuantTables *) CMEM_getPhys(ptr),
or
(IDMJPGE_TIGEM_CustomQuantTables *) ptr,
}
The goal was to set the matrix in the shared memory with CMEM and pass the phys adress or virt address as a (IDMJPGE_TIGEM_CustomQuantTables *) pointer.
The result is not good... (only 02 in the header)
3 questions :
Regards,
Mika
Mike, merely from a Codec Engine framework POV, what you're doing should work. CE doesn't know what's in the extended params and sends them unchanged to the server. B/c you're sending a phys addr of a physically contiguous memory block the address should get passed to the codec, and the codec can access that memory at the same address (b/c there's no MMU).
One thing I don't know is the cache settings of that buffer, nor whether that matters. From the ARM-side, the memory is non-cached (that's default CMEM behavior and your CMEM_alloc() call uses those default params). From the server side, the cacheability is unknown, and likely determined by the BIOS MAR configuration for the memory CMEM is managing. You'll have to check that yourself - it may not be your issue, but is worth understanding.
I don't know how the codec behaves, nor whether there's a perf lift if that memory is cached (I'd assume perf would improve if it's cached, but you may have to then manage the cache, e.g. if the values in the table change or that memory is reused for something else).
Chris
Hi TI Engineer,
Does someone can give an answer to theses questions :
Hi Mika,
Regarding your questions
#1
Ideally both documentation and idmjpge.h should be in sync for extended structures. Can you please be more specific? Which point/data is conflicting here.
#2
Yes. qValue can be changed even with custom quant table i.e. different qValues produce different images with same custom quant table.
#3
I could not think of any other way of enabling customer quant table work.. The earlier experiment should have worked. We need to debug why it is not working.
Hi, We did an experiment with DVTB in DVSDK v3_10_00_19 to change the custom Q table of JPEG encoder. We are able to change the custom Q table with below changes. Customer Q table to insert: unsigned short DQT_table[128] = { 16, 11, 10, 16, 24, 40, 51, 61, 12, 12, 14, 19, 26, 58, 60, 55, 14, 13, 16, 24, 40, 57, 69, 56, 14, 17, 22, 29, 51, 87, 80, 62, 18, 22, 37, 56, 68, 109, 103, 77, 24, 35, 55, 64, 81, 104, 113, 92, 49, 64, 78, 87, 103, 121, 120, 101, 72, 92, 95, 98, 112, 100, 103, 99, 17, 18, 24, 47, 99, 99, 99, 99, 18, 21, 26, 66, 99, 99, 99, 99, 24, 26, 56, 99, 99, 99, 99, 99, 47, 66, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99 }; // Default quantization table Allocating memory : Quanttabptr = Memory_contigAlloc(128 * sizeof(XDAS_UInt16), Memory_DEFAULTALIGNMENT); User defined table is populated to the allocated memory. for (i = 0 ; i < 128; i++) { Quanttabptr[i] = DQT_table[i]; } Call getphysical conversion funtion::::::::::: Quanttabptr_phy = (XDAS_UInt16 *) Memory_getBufferPhysicalAddress((XDAS_UInt32 *)Quanttabptr, 128*(sizeof(XDAS_UInt32)), NULL); Call setparams control call:::::::::: T->g.jpegenc1.ienc1DynParams.quantTable = (IDMJPGE_TIGEM_CustomQuantTables *)Quanttabptr_phy ; T->g.jpegenc1.ienc1Cmd = XDM_SETPARAMS; if (DVEVM_ST_FAIL == dvtb_jpegEnc1Control(&T->g.jpegenc1)) { SYS_ERROR("Unable to set the Dynamic params\n"); } The only difference i see from your code to my code is the APIs used for contiguous memory allocation. We have used Memory_contigAlloc() and Memory_getBufferPhysicalAddress(). Can you please try with these APIs? Regards Sayanna
Hi Sayanna,
I tried your code :
UInt8 *Quanttabptr = NULL;int i =0;XDAS_UInt16 * Quanttabptr_phy = NULL ;Quanttabptr= Memory_contigAlloc(128 * sizeof(XDAS_UInt16), Memory_DEFAULTALIGNMENT);unsigned short DQT_table[128] = { 16, 11, 10, 16, 24, 40, 51, 61, 12, 12, 14, 19, 26, 58, 60, 55, 14, 13, 16, 24, 40, 57, 69, 56, 14, 17, 22, 29, 51, 87, 80, 62, 18, 22, 37, 56, 68, 109, 103, 77, 24, 35, 55, 64, 81, 104, 113, 92, 49, 64, 78, 87, 103, 121, 120, 101, 72, 92, 95, 98, 112, 100, 103, 99, 17, 18, 24, 47, 99, 99, 99, 99, 18, 21, 26, 66, 99, 99, 99, 99, 24, 26, 56, 99, 99, 99, 99, 99, 47, 66, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99 }; for (i = 0 ; i < 128; i++) { Quanttabptr[i] = DQT_table[i]; } Quanttabptr_phy = (XDAS_UInt16 *) Memory_getBufferPhysicalAddress((XDAS_UInt32 *)Quanttabptr, 128*(sizeof(XDAS_UInt32)), NULL); 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 (IDMJPGE_TIGEM_CustomQuantTables *)Quanttabptr_phy, 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, }; videnc1->dynParams = (IMGENC1_DynamicParams*)&JPEG_DynParams;
control and process call for imgenc1.
I tried this and with "0," for quantTable (to use default table) to check if the same header appears (with same qValue). And it's still not the same!
When you say "We are able to change the custom Q table" did you check if the headers/Quantization Table are the same with and without this custom table ? (It may be the same because in the documentation it's the table use by default when IDMJPGE_TIGEM_CustomQuantTables is set to 0)
The QTable cans be found in a jpg file after FF DB marker.
there is another table to check if it works for you (if you can check it):
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,
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,
Mika.
We tried with the table you have mentioned and it works fine at our end. We could see the table in stream analyzer (JPEG snoop). Please see the attached output image we got.
Did you try this with the test application provided with DVTB or you have any other application?
Attaching a o/p image from Sayanna, he is having trouble uploading it
We succeed to make it work ! Thanks you. I think our prob was from a cast of pointer. I share the code working :
XDAS_UInt16 * Quanttabptr = NULL; int i =0; XDAS_UInt16 * Quanttabptr_phy = NULL ; Quanttabptr= Memory_contigAlloc(128 * sizeof(XDAS_UInt16), Memory_DEFAULTALIGNMENT); if (Quanttabptr == NULL) GST_ERROR("Failed to allocate ptr\n");
unsigned short DQT_table[128] = { /*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,
};
or (i = 0 ; i < 128; i++){ Quanttabptr[i] = DQT_table[i];}Quanttabptr_phy = (XDAS_UInt16 *) Memory_getBufferPhysicalAddress((XDAS_UInt32 *)Quanttabptr, 128*(sizeof(XDAS_UInt32)), NULL); 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 (IDMJPGE_TIGEM_CustomQuantTables *)Quanttabptr_phy, 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, };
Ienc1_control(videnc1->hIe, (IMGENC1_DynamicParams*)&JPEG_DynParams2);
Ienc1_process(videnc1->hIe, videnc1->hInBuf, videnc1->hEncOutBuf);
(Based on Gsttividenc1 plugins + add of (dmai) Ienc1_control like this post : http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/138400.aspx)
(Sayanna, I can't click on "This reply answer ..." , it makes an error. )