Ccv assertion in dm6467t video decoder

Hi Bhushan,

Can you please mention the complete release version of the MPEG2 decoder here as well, which you have downloaded.

I have also downloaded the stream, we will verify and  let you know about the same.

Regards,

Mahantesh

Hi Mahantesh,

Following are the required details of MPEG2 Decoder.

1)Version 1.10.00

2)Build ID 1.10.00.07

Thanks & Regards,

Bhushan.

Bhushan,

Identifying the root cause is still in progress, we will update this in the next one and half week time frame.

Regards,

Mahantesh

Hi  Mahantesh,

would it not be possible to get it done earlier...since we need to complete the product by April end....and this is a major

blocking issue for us.

Thanks & Regards,

Bhushan.

Bhushan,

Can you please verify the following stream as well on the latest library version "01_10_00_10", which you might have downloaded already.

3113[1].receiver_ccv.m2v - for assert failure at app level

Regards,

Mahantesh

Mahantesh,

We are still facing the same problem with the latest library version "01_10_00_10",  can you just look it again its deadlock for us.

we need to complete the product by mid May and we are struck with this critical issue .

Regards,

Bhushan.

Bhushan,

Thanks for the information...

We will verify once again on the latrest library (1.10.00.10) and let you knwo about the same.

Regards,

Mahantesh

Mahantesh,

I have verified the corrutped input file on standalone TI's decode application .The widh and  height is good but the x  and y dimensions are wrong when the

assertion comes.

i have provided you the log which prints the x and y cordinates(srcDim.x, srcDim.y,) along with the height and width of the decoded frame when the output of the

decoder is given to BufferGfx_getDimensions(hOutBuf, &srcDim) , when the input is correct and when decoder output is provided to this function then the values of

x and y are zero, but as the inputs gets corrutpted the values are non-zero leading to assertion.

so decoder output is only resonsible to provide wrong co-ordinates values.

What is your observation on this issue??

Regards,

Bhushan.

0741.receiver_ccv.txt

>>    

Bhushan,

The MPEG2 decoder gives the following through outArgs:

Outargs-> displayBufs[0].buf

outargs->displayBufs[0].frameWidth

outargs->displayBufs[0].frameHeight 

outargs->displayBufs[0].framePitch 

There is no X,Y dimensions coming from the codec. Actually offset is also not required since we are directly giving the pixel from where to start displaying. The BufferGfx_getDimensions should be a function in the CCV driver. We have already looped in the right person from the driver’s team to help for this issue.

Regards,

Mahantesh

Mahantesh,

You are absolutely right it's not coming form codec, just that the function which calculates that value takes ouput of decoder .

Regards,

Bhushan.

Bhushan,

You have mentioned that,

When decoded output for the non erroneous input is provided to the fn BufferGfx_getDimensions(), then the values of X and Y are zero and there is no assertion problem.

However, when the decoded output for the erroneous input is provided to the fn "BufferGfx_getDimensions()", then the values of X and Y are non zero and because of this there is an assertion problem.

Based on this can you please check the following,

- What circumstance is making the X and Y non zero in the fn "BufferGfx_getDimensions()", when decoded output with artifacts is fed to this.

- Does really the non zero values of X and Y are responsible for the assertion failure or something else creating the problem.

Regards,

Mahantesh

Mahantesh,

Regarding the circumstance , i have not debugged into the function much as it was TI function ..i will check and  let you now.

and regarding X an Y responsible , the assertion statement is as follows:

Ccv_accel_execute: Assertion `!((BufferGfx_getColorSpace(hSrcBuf) == ColorSpace_YUV420PSEMI) && (srcDim.y > 0))'

so it checks for the dimenstion Y for non zero and for my logs i am printing the values of colour space and the dimensions and we see the colou rspace remains same .

Following is the part of the log.

ormal Case
Video Decode  : Ccv Assertion ColourSpace  - 0, x = 0, y = 0, width = 720, height = 576 linelength = 736

**************************************
Debug_msg: Before Vdec_process
Debug_msg: Decoded video buffer
Debug_msg: Decoder returned value = 4
Debug_msg: Buffer_getNumBytesUsed(hInBuf) = 15479
**************************************

Normal Case
Video Decode  : Ccv Assertion ColourSpace  - 0, x = 0, y = 0, width = 720, height = 576 linelength = 736

**************************************
Debug_msg: Before Vdec_process
Debug_msg: Decoded video buffer
Debug_msg: Decoder returned value = 4
Debug_msg: Buffer_getNumBytesUsed(hInBuf) = 7
**************************************

Error: Video Decode  : Ccv Assertion ColourSpace  - 0, x = 64, y = 1524146, width = 720, height = 576 linelength = 736

**************************************
Debug_msg: Before Vdec_process
decode_ccv: linux/dm6467/Ccv_accel.c:212: Ccv_accel_execute: Assertion `!((BufferGfx_getColorSpace(hSrcBuf) == ColorSpace_YUV420PSEMI) && (srcDim.y > 0))' failed.

For assertion you are testing for only Y dimension  as seen highlighted.

Regards,

Bhushan.

Hello Bhushan,

If the video decoder returns an error, the CCV module should not be invoked. Why is it getting called with an error frame? That should be the issue. However a more fundamental issue seems to be why is the BufferGfx derived structure is being modified/corrupted at all. And who is doing it?

What is the error value that the Viddec2 _process call is thrwoing? is it 4 or -4? 

So, can you  add debug messages after the process call? We need to see if codec is corrupting the BufferGfx structure. Please share the log with me.

Sample debug code:

      /* Decode the video buffer */

        ret = Vdec2_process(hVd2, hInBuf, hDstBuf);

BufferGfx_getDimensions(hDstBuf, &dimTemp);

printf("\n hDstBuf Dimensions: BufferGfx.x = %d, BufferGfx.y = %d\n"

,dimTemp.x, dimTemp.Y

Also in display.c, in the display thread, please take the similar dump after below line at aprox line 501

/* Get the dimensions of the source buffer */

        BufferGfx_getDimensions(hSrcBuf, &srcDim);

Hi Feroz,

Thanks for your inputs.

Kindly note that we are running the standard application from TI. It is not developed by us. Also we ran the application on EVM and not on our custom board.

It will help if someone from TI can share the results (with log) on running the application on EVM at your end.

To answer your query regarding return value, we have confirmed the return value and it is 4 and not -4.

Regards,

Bhushan.

Hi Bhushan,

Few comments on CCV issue,

In the repeated sequence headers all the data elements (except those defining quantization matrices) should have the same values as in the first sequence header. However as the height is changing (to 832) in one of the sequence header (might be due to loss of data). During this situation and based on the error code returned from the decoder, application has to either correct these values or reset the decoder. Because decoder should not change these values. 

Regards,

Mahantesh

Hi Mahantesh,

If this is regarding the new drop that TI has provided, please note that it is not only about height. We have found instances where even x and y values are garbage. Please take this into consideration.

Regarding the height value corruption, could you be more elaborate here?

>> During this situation and based on the error code returned from the decoder, application has to either correct these values or reset the decoder. Because decoder should not change these values.

1. In this case, as I understand, dvsdk is the application which should do the correction, is that right?

2. If not, then please let us know what the expected error is - that the application should handle. Since we do not see any error returned from the decoder when it gives the wrong output values. We are using the codec engine wrappers from the demo application provided by TI.

3. At most we are able to capture the fact that x, y, width and height values go wrong in some cases. Are you expecting the application to check for that after every decode and correct them if they are not as expected? (i.e. x=0; y=0; width=DISPLAY_WIDTH;height=DISPLAY_HEIGHT)

Please let us know.

Regards,

-Sheetal.

Hi Sheetal,

I will come back in detail regarding error code for wrong width and height values and adjusting these values by app based on error code, before this can you please clarify the following,

- Does x and y values go wrong only when decoder provides wrong width and height vlaues?

Regards,

Mahantesh

Hi Mahantesh,

x and y values go wrong even when width and height values are ok.

Regards,

-Sheetal.