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.

Extending DM8168 1920x1080 (8bit) capabilities

Hello,

Following a previous conversation on this matter, I have understood that the DM8168 has an hardware limitation for video in (line length of 1920 bytes).

Since I'm using an imaging sensor of 10 bits, which is extremely important for DSP purposes, I need to transfer line of 1920 of 10 bits each pixel.

That makes every line of frmae 25% over the hardware limitation, thus making the DM8168 as not suitable for the mission.

In the previous conversation I have mentioned an idea to overcome this limitation by splitting the data to RGB888 followed by RGB222.

That means that for each couple, the first line is the highest 8 bits of the pixel, and the second line is the least bits of the same pixel.

So in order to transfer a full frame, I will have to send 1080 lines of RGB888 and another 1080 lines of RGB222.

In my case, I use a proprietary FPGA, so I can "play" with the lines as I need to.

Option 1: Interlaced lines: send 1080 couples of (RGB888 + RGB222).

Option 2: Progressive lines: send 1080 lines of RGB888, followed by 1080 lines of RGB222.

Just to mention that the video signals from the FPGA --> 8168 are:

DE, Vs, Hs, Data (24bit) + Optional FID signal (pin) to differentiate lines.

Given that the RGB222 is not used for preview, but just for DSP analysis, can you please suggest and elaborate video data flow for display?

Can you please describe the required changes (maybe code references) needed to be done in order to display the RGB888 only?

Any help will be appreciated :-)

Thanks,

David

 

  • Hi David,

     

    You could use standard FBdev Interface to display RGB888 format on any of the VPSS Venc. Please go through the Vpss Fbdev user guide to know more about the Fbdev. You could even look into Linux Documentation to know more about FBdev.

     

    Regards,

    Brijesh Jadav

  • David,

    If the image sensor output is 10 bit raw then you could simply consider the capture port as a 16 bit wide port.

    The hardware limitation is not 1920 bytes, but 1920 pixels, and is only really an issue if any of the processing modules are being used that need to filter vertically.

    If all modules are bypassed then the capture size can be up to 4K wide.

    I would suggest configuring the VIn port as either 16 bit YUV or 24 bit RGB (my preference would be 16 bit since would require less frame buffer memory). Then you can simply treat the Y and C channels, or R, G and B as 16/24 bit wide ports of which you are only going to use 10 bits.

    If using YUV then configure the capture mode as interleaved so that the Y and C channels are 'packed' together and not split into separate luma and chroma buffers. RGB capture will use a 32 bit container for each pixel by default but can be configured to pack in a 24 bit container I believe.

    Basically, don't pay attention to luma/chroma distinction and treat as a 16 bit port.

    BR,

    Steve

  • Hi Brijesh,

    My only concern was the how to use the image both for display and analysis.

    When it comes to standard Linux usage, I am familiar with FBdev mechanism, but I wanted to close the capture-display loop in the HDVPSS module.

    If the data was only RGB888, then there wasn't any problem from the beginning, but I am not sure about extending the frame to contain 10bits per pixel.

    Finally, I have decided to change my system architecture so the video port (one of them) will receive RGB888 or YUV422.

    Thanks for your time, your help is appreciated.

    David

  • hi,

     

    firmware is loaded using firmware_loader utility, which i believe works on syslink. there are many required to be ported in uboot in order to load firmware in uboot.

     

    Regarads,

    Brijesh Jadav