2D Graphics (SWOSD) for the DM8127 IPNC RDK

Allen Black said:

How exactly was this YUV logo file generated?

Can you follow the instructions given in the document "SoftwareOSD_UserGuide_DM812x" in the release package.

Let us know whether you are successful in generating the Logo/Image of your desire.

Regards,

Venu

Allen Black said:

Anyway, I feel like I may be "reinventing the wheel" by spending time writing these functions. Is there a library (for SYS/BIOS on the DSP... not for Linux on the A8) included in the DM8127 RDK that I could or should be using?

Hi Allen, in the current DSP side swosd implementation, actually all graphic content is generated on A8 in YUV format, DSP just receives the YUV buffer address and uses DMA to transfer the YUV data and blend the video frame according to the given osd windows position params, so unfortunately there’s no any existing “drawing” library on DSP.

Thanks Venugopala and Zhuoran for the information. It was helpful and gave me some hints but ultimately I am still trying to figure out a number of things myself.

I believe the main problem and confusion (for me) is that the DM8127 IPNC RDK contains two very different implementations of "SWOSD" (i.e. - Software On Screen Display). To add to my confusion (and make my source code grep-ing much more complicated), sometimes the software components are named "SWOSD", sometimes they are named "SW_OSD", and sometimes things are just named "OSD".

SWOSD IMPLEMENTATION 1:

The following files contain what I believe is the "normal" or "more common" SWOSD implementation. It seems to be the implementation that is documented in the "Software OSD User Guide" that your referred me to, Venu. I assume this API and Link are probably used similarly across any of the DaVinci platforms and are more familiar to many people.

ipnc_rdk/ipnc_mcfw/mcfw/interfaces/link_api/swosdLink.h

ipnc_rdk/ipnc_mcfw/mcfw/src_bios6/links_m3vpss/swosd/swosdLink_tsk.c
                                                    /swosdLink_priv.h

WHICH USE...

ipnc_rdk/ipnc_mcfw/mcfw/src_bios6/links_m3vpss/alg/sw_osd/ti_swosd.c
                                                         /alg_ti_swosd.h
                                                         /swosd_priv.h
                                                         /fonts/(12 files)


SWOSD IMPLEMENTATION 2:

However, the implementation that I have been experimenting with (and asking questions about) is contained in these files:

ipnc_rdk/ipnc_mcfw/mcfw/interfaces/link_api/osdLink.h

ipnc_rdk/ipnc_mcfw/mcfw/src_bios6/links_c6xdsp/swosd/osdLink_tsk.c
                                                    /osdLink_alg.c
                                                    /osdLogo.c
                                                    /osdLink_priv.h

WHICH USE...

ipnc_rdk/ipnc_mcfw/mcfw/src_bios6/alg/swosd/sw_osd.h

ipnc_rdk/ipnc_mcfw/mcfw/src_bios6/alg/swosd/src/sw_osd_ti_alg.c
                                               /sw_osd_ti_ialg.c
                                               /sw_osd_ti_alg_if.c
                                               /sw_osd_ti_dma.c
                                               /sw_osd_ti_ires.c
                                               /sw_osd_ti_priv.h

In the DM8127 IPNC RDK, this implementation is used by the McFW Example Usecase (i.e. - the DSP Usecase) contained in this file:

ipnc_rdk/ipnc_mcfw/mcfw/src_linux/mcfw_api/usecases/multich_tristream_dsp.c

I may be completely wrong about this, but I don't believe this implementation has any relationship to the "normal" implementation (i.e. - "IMPLEMENTATION 1"). Is that a correct assumption???

In any case, I will get back to my questions and tell you what I think I have figured out.

In attempting to convert a JPEG logo to be used by the SWOSD Link (for IMPLEMENTATION 2), I first started following the directions in the "Software OSD User Guide". I used "ImageMagick" to convert from a binary JPEG file to a binary UYVY file. I eventually realized that this was not the format I needed (for IMPLEMENTATION 2) and that the best I could do with ImageMagick was to convert to their "YUV" format which is actually what I would call a YUV420P file (i.e. - UV sub-sampled by 2 both horizontally and vertically; Y, U, and V data all contained in separate planes). What I found I needed for IMPLEMENTATION 2 is a YUV420SP file (i.e. - the same as a YUV420P file except that the U and V data is interleaved in a single plane). So I wrote a utility to make this conversion myself. Finally I used the "bin2c" tool to convert the file to a C array although I had to do hand editing to separate the Y and UV planes into two arrays at the correct point. And the logo does look great now!   :-)

So the directions in the "Software OSD User Guide" do not exactly apply to IMPLEMENTATION 2 of the SWOSD. I was not able to find the "image_convert" utility (mentioned in the User Guide) anywhere within the DM8127 IPNC RDK GA Release 2.0.0. Eventually, I found it from a link on an answer to a post on these forums. I downloaded it and experimented with it (it's a Windows command line utility with no source code or documentation) but I was never able to get it to do anything without displaying errors. So I gave up on it and, as mentioned, wrote my own utility for converting YUV420P to YUV420SP.

Regarding a 2D graphics library for drawing directly into the SWOSD frame (IMPLEMENTATION 2 - YUV420SP frame), I understand now that it is complicated to do when the UV data is sub-sampled with respect to the Y data. That makes it difficult to just draw a single pixel into the frame because the related color data applies to 4 different pixels. So I have implemented a few simple routines for drawing pixels and lines and rectangles (without being able to exactly control the color) but I won't spend any more time on that experiment.

Thanks for your help! ... And let me know if my analysis is correct or partly correct or totally wrong or whatever... And please let me know anything you can add to help my understanding.