DM365 JPEG Encode (Low Compressed mode)

Hi Takeshi,

Can you attach the source YUV that is causing this issue?

Does the problem always occur (when it occurs) on the last line like in this example?

Regards,

Akshay

Hi Akshay-san,

Sorry, since it takes a long time (modify firmware) to get a YUV data(input data for dm365) from current PCB, I'd like you to send a whole

parameters we set. In our experience, this problem seems to be happened nothing depended upon input data. The problem seems always occur

on the last line like in that example.

IMGENC1_Params
  size             : sizeof(IMGENC1_Params)
  maxWidth         : 1280
  maxHeight        : 1024
  maxScans         : XDM_DEFAULT
  dataEndianness   : XDM_BYTE
  forceChromaFormat: XDM_YUV_422P

IJPEGENC_DynamicParams
  imgencDynamicParams.size             : sizeof(IJPEGENC_DynamicParams)
  imgencDynamicParams.numAU            : XDM_DEFAULT
  imgencDynamicParams.inputChromaFormat: XDM_YUV_422ILE
  imgencDynamicParams.inputWidth       : 1280
  imgencDynamicParams.inputHeight      : 1024
  imgencDynamicParams.captureWidth     : 1280
  imgencDynamicParams.generateHeader   : XDM_ENCODE_AU
  imgencDynamicParams.qValue           : 97
  rstInterval                          : 84
  disableEOI                           : XDM_DEFAULT
  rotation                             : XDM_DEFAULT
  customQ                              : NULL

* As we said earlier, the problem happened as well as with qValue=96, 95, 94.

Regards,

Takeshi

Takeshi-san,

What is the size of the output buffer you are setting? Have you tried increasing that?

Regards,

Akshay

Akshay-san,

Thanks for your reply.

The JPEG output buffer you're talking about is probably Ienc1_getOutBufSize.
However, the actual necessary output buffer size will be 2621440 bytes for JPEG encoder.
The input YUV422 size is 1280x1024x2 (=2621440) so the buffer size may enough, we thought.

We tried to increase the size of buffer to 3932160 bytes, but unfortunately we could not see
the any changes.

Would you please advise us any others?

Regards,

Takeshi

Takeshi-san,

I was able to reproduce the issue you are facing. We are trying various options to try and fix it. Thank you for your patience.

Regards,

Akshay

Akshay-san,

How is the situation of the debugging? Any progress?

Takeshi

Akshay-san,

Still debugging?

Takeshi

Takeshi-san,

Apologies for the delay in response.

Can you update with me the cmem pools that you're declaring / using? 

In our setup, the problem does not occur with a particular cmem arrangement, but we're trying to ascertain a root cause or explanation for it.

Regards,

Akshay

Akshay-san,

Thanks for your respond.

Do you mean that you'd like our (my customer's) system to update Linux Utils(which include CMEM) like as below to see whether the problem is gone?
We've never updated CMEM only before so please let us know.

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/index.html

However, the customer uses DVSDK 2.xxx. Isn't there any problem when we updated only utils from them?
CMEM overview in Wiki says there is no depdency with Codec, so maybe it is OK if the supported kernel version are met.

Regards,

Takeshi

Takeshi-san,

As of now, there is no need to update.

I am running in standalone mode (DVTB), where the cmem pools are declared prior to execution. There we've seen different output depending on arrangement of cmem pools, though ideally it shouldn't matter to the codec. 

So I'm trying to ascertain what kind of arrangement are you using.

-Akshay

Dear Akshay-san,

Do you have any update information to solve the JPEG encoding problem in low compression rate for DM365?

Regards,
Takeshi