This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problems on using DM355 DVEVM

I am now writing some test programs on DVEVM for evaluation purpose, but met 2 problems.

1. If input data format is set to YUV_422P, error occurs when using JPEG encoder. I wonder if jpeg encoder on DVSDK supports YUV422P as input source?

2. There are errors in using JPEG decoder or encoder if the image size is 1600x1200, I ask for DVEVM agency , they told me I have to modify my cmem source code , is that so?

 

Thanks in advance.

  • 1.  The best place to look for information on the features supported by the codec(s) is the codec documentation included in the DVSDK.  For example, SPRS490.pdf (included in DVSDK) is the JEPG encoder data-sheet and list what the codec supports and does not support (YUV 422 interlaced but progressive scan is not suuported).

    2. CMEM defines a shared memory space (and set of memory pools) which ensure contigous memory buffers (not assured by Linux OS) are passed to the MJCP.  You may need to redifine the size of memory pools available to CMEM is you require a particularly large buffer.  This is done via command line (see loadmodules.sh file).  I do not believe there is a need to change the CMEM source code at all.

  • I will try to modify the loadmodule.sh , hope can handle larger images :)

    Yes I have checked codec documents in DVSDK , JPEG Decoder do NOT support YUV422P, only YUV422_ILE :(   my question is that our image raw data comes from a CCD sensor with YUV422P output , if I want to use these sensor as image source, any way to make it work? Thx.

  • 1) When looking at CMEM, please note starting address and size of CMEM; if your buffer cannot fit in this space, you may need to increases CMEM size.  This can be done by giving Linux OS less memory (changed via bootargs) and giving CMEM a lower starting address and bigger size.

    2) I believe the encode demo included with DVSDK uses the resizer to de-interlace video for encoding; a similar approach could be followed for JPEG YUV422P.  I would refer to encode demo.

  • I modified MontaVista boot parameter to reserve more memory for en/decoder. Set a larger buffer in CMEM. successfully decoded and re-encoded a 3200x2400 image.

    Now I am finding ways to handle YUV_422P :)

    Thanks Juan~

  • I am happy to hear you are making progress; the encode demo should help you pass the de-interlacing hurdle, but of course we are here to help if you need further assistance.

  • checking demo codes now, but still a question about it. even if de-interlacing  one YUV_422P frame into two YUV_422I fields, how can I merge two jpeg images encoded from 422I into an integrated frame?....

  • The resizer should be able to help merge interlaced frame into progressive as well. 

  • I went through demo code, seems resizer could merge interlaced frames into a progressive ones. my question is ... how could JPEG encoder proceed progressive data as input source. thanks in advance for answering.

  • What I was suggesting is that you can use the resizer to covert progressive frame into interlaced frame, then you can JPEG encode.  Then, sometime in the future, you can take the encode file and due JPEG decode of the interlaced frame and use resizer again to convert to iriginal progressive frame.

  • I have seen this in JPEG encoder manual, sorry for my question ^_^

    ------------------------------------------------------------

    Does not support progressive scan

    The limitations will not be removed in future releases. These limitations are not defects but intentional or known deficiencies.

    -------------------------------------------------------------