DM6467T - JPEGENC 2.00.01.00 - Custom QUANTIFICATION Table

mike soso

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 !

over 14 years ago

mike soso over 14 years ago

Intellectual 930 points

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...

Sayanna Chandula over 14 years ago in reply to mike soso

TI__Intellectual 1290 points

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

mike soso over 14 years ago in reply to Sayanna Chandula

Intellectual 930 points

Thank you for your support. When i call Ienc1_create() (like above) in Ienc1.c (dmai) the IMGENC1_control is called with the dynparams i wrote above. I don't have error returned by the control. Another things to try ? Is my dynparams correct ?

Sayanna Chandula over 14 years ago in reply to mike soso

TI__Intellectual 1290 points

Hi,

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.

Regards

Sayanna

mike soso over 14 years ago in reply to Sayanna Chandula

Intellectual 930 points

Thank you for following my thread. If i set Qtable to NULL and use some Qvalue Between 35 to 80 the encoding process works fine. I have quality and compress change. So like you said, i can confirm that the base params and dynparams works fine. To give another info , When i use Qtable with Qvalue under 35 the encoding process fail. But with other Qvalue i still have only 02 in my header and low compress to my jpeg file. I know that Qvalue is not used When we use custom Quant table. Another advice ? Could someone comfirn that custom quant table work fine on DM6467T ? Thanks Mika

mike soso over 14 years ago in reply to mike soso

Intellectual 930 points

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

mike soso over 14 years ago in reply to mike soso

Intellectual 930 points

Sayanna Chandula over 14 years ago in reply to mike soso

TI__Intellectual 1290 points

Hi Mika,

What was the issue? Any parameter to codec required to be changed?

Regards

Sayanna

mike soso over 14 years ago in reply to Sayanna Chandula

Intellectual 930 points

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 FF
04 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 FF
FF 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 !

Mika

mike soso over 14 years ago in reply to mike soso

Intellectual 930 points

Chris Ring over 14 years ago in reply to mike soso

TI__Genius 17205 points

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

mike soso over 14 years ago in reply to Chris Ring

Intellectual 930 points

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 ?

Mika

mike soso over 14 years ago in reply to mike soso

Intellectual 930 points

up !

Chris Ring over 14 years ago in reply to mike soso

TI__Genius 17205 points

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'.

Chris

Sayanna Chandula over 14 years ago in reply to Chris Ring

TI__Intellectual 1290 points

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.

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

mike soso over 14 years ago in reply to Sayanna Chandula

Intellectual 930 points

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),

(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 :

Who is right ? The documentation or the idmjpge.h for the extended structure ?
Does the qValue is applied when we use custom table ? (i have different value [but not good when i use the custom table with default one] in header when changing the qValue with custom table)
Is there another thing to try to get these custom table work ?

Regards,

Mika

Chris Ring over 14 years ago in reply to mike soso

TI__Genius 17205 points

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

mike soso over 14 years ago in reply to Chris Ring

Intellectual 930 points

Hi TI Engineer,

Does someone can give an answer to theses questions :

3 questions :

Who is right ? The documentation or the idmjpge.h for the extended structure ?
Does the qValue is applied when we use custom table ? (i have different value [but not good when i use the custom table with default one] in header when changing the qValue with custom table)
Is there another thing to try to get these custom table work ?

Regards,

Mika

Sayanna Chandula over 14 years ago in reply to mike soso

TI__Intellectual 1290 points

Hi Mika,

Regarding your questions

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.

Yes. qValue can be changed even with custom quant table i.e. different qValues produce different images with same custom quant table.

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.

Regards

Sayanna

Sayanna Chandula over 14 years ago in reply to Sayanna Chandula

TI__Intellectual 1290 points

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

mike soso over 14 years ago in reply to Sayanna Chandula

Intellectual 930 points

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.

Sayanna Chandula over 14 years ago in reply to mike soso

TI__Intellectual 1290 points

Hi 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?

Yashwant Dutt over 14 years ago in reply to Sayanna Chandula

TI__Genius 17215 points

Attaching a o/p image from Sayanna, he is having trouble uploading it

mike soso over 14 years ago in reply to Yashwant Dutt

Intellectual 930 points

Hi Sayanna,

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. )

Mika

Processors

Processors forum

DM6467T - JPEGENC 2.00.01.00 - Custom QUANTIFICATION Table