Composite Video Output support in OpenMax

OMX VFDC does not support SD-DAC in EZSDK5.02. This support will be available in EZSDK 5.03 and beyond.

In the meantime, you can try using V4L2 display on composite out. You can find a user guide here:

http://processors.wiki.ti.com/index.php/DM816X_AM389X_VPSS_Video_Driver_User_Guide_PSP_04.00.00.12

Archith

Hi Archith,

I'm currently working on adding SD output to the OMX Capture-Encode demo -- could you verify that the SD output (NTSC & PAL) is indeed functional in the VFDC provided in (DM8148) EZSDK 5.03.01.15? 

I wasn't sure if the 5.03 version you mentioned corresponds to the EZSDK version number, or the OMX version in the component-sources directory ($EZSDK/component-sources/omx_05_02_00_30/).

The reason why I ask is that I see the following in "Not supported" text in omx_vfdc.h:

Also, the DM814X OpenMax User Guide ($EZSDK/component-sources/omx_05_02_00_30/src/ti/omx/docs/OpenMax_DM814x_UserGuide.pdf ) lists the following under the VFDC's supported outputs:

Thank you for your time and help!

- Jon

Just for reference, here are the items I think I may need to be changing when modifying this to display on the SD output instead of the HDMI output.  Please let me know if anything looks incorrect or absent.

1. DEI output scalar dimensions and VFDC input dimensions need to be <= 640 x 480
2. The VFDC need to have the following parameter values (for both the display and display control handles):
   nDrvInstId = OMX_VIDEO_DISPLAY_ID_SD0
   eDispVencMode = OMX_DC_MODE_NTSC (or OMX_DC_MODE_PAL)
3. The sMosiacWinFmt[o] x/y offset, width, & height params are adjusted for SD dimensions
   
4. I'm keeping the sMosaicWinFmt[0].dataFormat as VFDC_DF_YUV422I_YVYU, but am not sure if this is correct.
5. I'm unsure if I need to change some OMX_BUFFER_MEMORY_TYPE assignments to one of the *_TILED_* values, given that the below comment mentioned 420T/422T for SD output:

From ilclient_utils.c example. I'm operating under the assumption that the "not supported" comment may be a vestige of a pre-EZSDK5.03.01.15 release.

  /* --------------------------------------------------------------------------*
     Supported display IDs by VFDC and DC are below The names will be renamed in
     future releases as some of the driver names & interfaces will be changed in
     future @ param OMX_VIDEO_DISPLAY_ID_HD0: 422P On-chip HDMI @ param
     OMX_VIDEO_DISPLAY_ID_HD1: 422P HDDAC component output @ param
     OMX_VIDEO_DISPLAY_ID_SD0: 420T/422T SD display (NTSC): Not supported yet.
     ------------------------------------------------------------------------ */

With regard to item 5, I see the User guide states the following.  Is this stating that while the new types have been added, they're not supported yet? Or is the blue text just out of date?

Jon,

SD o/p is not supported in SDK 5315. We will be adding this in next release.

Regards

Vimal

Hi,

Please note, SD display support is available in EZSDK 5.05.01.04.  There is an example 'display', which has SD/HD/LCD display options, also decode_display example too has been enhanced to have option for display on SD output. 

http://www.ti.com/tool/linuxezsdk-davinci

If you see colors missing on SD display, please change display o/p as 

echo 0 > /sys/devices/platform/vpss/display2/enabled
echo "composite" > /sys/devices/platform/vpss/display2/output
echo 1 > /sys/devices/platform/vpss/display2/enabled

Regards

Vimal

Hi Vimal,

I'm still running into an issue with this latest release's SD display support. This is an issue we previously discussed in this thread:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/187782/699251.aspx#699251

The issue is that the SD Display gets corrupted (looks like it tries to use luma data for chroma) when you do not supply it frames fast enough.  As discussed in the above thread, this could be shown in the Display example program when frames were being loaded slowly from a disk/nfs partition.

I am implementing some functionality to "pause" a display while input is still being recorded and streamed. On the HDMI and DVO2 outputs, I can simply stop delivering frames to the displays, and the previous image will remain on screen. (I basically have the component sending frames to the displays immediately recycle buffers in this "pause" condition, instead of making ETB calls to the display.)

However, this does not work on the SD display output; I see the corruption I mentioned if I stop delivering frames to the SD display. (This also happens if the system gets highly loaded and the OpenMax application doesn't get scheduled fast enough!)

My current workaround is to have the SD display passing buffers from an ETBD condition back to an ETB call.  However, this looks quite bad if there's a lot of motion between frames -- the screen will jitter. I think one hack to work around the jitter might be to memcpy the frame off and fill it into the successive ETB's...

Any thoughts on this?

Thanks!

Jon

Hi,

Display component is designed to give back old buffer when new is available, so  last buffer is always available, as you see on HD displays. It appears there is some mismatch for SD display, I would check it internally and let you know. btw we added support for other sizes as well, in last last release size was fixed. just to confirm, you see the issue with decode_display example as well ?

Regards

Vimal

Hi Vimal,

I haven't had time to modify decode_display and provide a patch to reproduce the issue. However the general procedure to reproduce this is to attempt to "freeze" or "pause" the SD display by ceasing ETB calls on it (either directly or by stopping the flow of frames from an upstream component).

For example, I have SC5 supplying frames to the SD Display. When I "freeze" the SD display, SC5 simply recycles frames it's requested to fill. As a result, no new frames are provided to the SD display -- I was hoping this would result in behavior similar to that of the HD displays.

The support for variable sizes has been working great for me! I've tried 4 or 5 different sizes (even numbered-dimensions), and all have been centered in the display as expected.  Thank you for your time an help!

Jon

Hi Jon,

We have found the issue with SD display with underflow condition, however unfortunately there is no workaround in EZSDK 5.05 for overcoming that. We will be able to resolve this in next release.

Regards

Vimal

Hi Vimal,

Thank you for checking into this!

Which components of the EZSDK will require changes for the fix? (e.g., just the firmware?)  I'd just like to get an idea what I'll need to push with our future software updates, and plan accordingly.

As far as a workaround, I do have a bit of an ugly hack which works for small frames sizes. (For larger frame sizes, the memcpy will take too long and the SD display will get corrupted in the manner we've discussed.) I'd greatly appreciate any advice you have on improving this. The basic idea is to copy off a single frame and to keep feeding it back into the SD display.

• Allocate a scratch buffer to store a single SD display frame in CPU memory (i.e., not even contiguous memory buffers shared between cores)
• When a "freeze" or "pause" is requested, memcpy() the next frame's buf->pBuffer contents to that scratch buffer
• One the display's ETBD event occurs, memcpy() the scratch buffer's contents into the "consumed" buf->pBuffer, and sends it back to the display in an ETB

• There's room for optimization here -- after N ETBD's we'll start hitting buffers that already contain our "frozen" frame, so there isn't really a need to continue the memcpy()'s before making another ETB on the display.

• Any idea what this value of N is? I'm kinda just playing with this experimentally. (looks like 3 or 4?)

While this works okay-ish for me (far from perfect, performance isn't great), I think it operates on the following assumptions:

• That enough buffers have been allocated for upstream components such that the SD display hogging (a few of) them isn't an issue?
• That the memcpy's can occur fast enough (it starts to fall apart if the CPU gets busy...)

- Jon

Hi,

This will be change in OMX component. i.e. firmware would need modification. Actual issue is (as it shows), while starving for buffers, it uses same buffer for display and chroma pointer is not updated in duplicate buffer. SD display currently supports only 420, so shows up the issue, while HD are 422, so do not have this issue. May be instead of last frame, you can use single color screen for pause for which luma/chroma have same value ?

Regards

Vimal

Vimal Jain said:

Actual issue is (as it shows), while starving for buffers, it uses same buffer for display and chroma pointer is not updated in duplicate buffer.

So does this imply that the chroma is always coming from a previous frame, and not the frame that the chroma is from? I think I might not be understanding you here.

Vimal Jain said:

May be instead of last frame, you can use single color screen for pause for which luma/chroma have same value ?

That's an interesting idea! Unfortunately, the functionality I have to provide is more of a "freeze frame" sort of pause, rather than being able to transition to a blank/colored "pause screen."  If you or anyone in the community has any other clever tricks that might help, I'm all ears! :)

Thanks again for your time and help Vimal!

- Jon

Hi,

Actually display has same pointers for Y and CbCr in case of freeze, so luma and chroma are overlapped. ( they are referring to same data). Unfortunately, at this point there is no workaround for this issue. I suppose, Other possibility of providing the last buffer in loop during the freeze ( to avoid underrun) is what. you are already having.

Regards

Vimal

Hi,

Theissue with same pointers for Y and CbCr is fixed now and will be available in upcoming EZSDK release (early Jan 2013 - if not earlier, exact release date is TBD)

Regards,

AMISH LAKHANI

Hi Amish,

Is the release you're referring to the 5.05.02.00 release, that I now see up in:

http://software-dl.ti.com/dsps/dsps_public_sw/ezsdk/latest/index_FDS.html

I didn't see this issue mentioned in the release notes, so I just wanted to check.

Thanks,

Jon

hi Jon,

It's available and it's verified in our testing. Just use latest EZSDK i.e. 5.05.02.00 and it must be working.

Regards,

AMISH LAKHANI

Hi Amish,

I just finished upgrading all of our software to use EZSDK 5.05.02.00, and verified that this release fixes the issue we were seeing.  Thank you to all those involved - we really appreciate it!

Just a heads up, with EZSDK 5.05.02.00, I see this warning at boot:

VPSS_FVID2: M3 firmware version 0x1000145 is newer,driver may not work properly.

In linux-2.6.37-psp04.04.00.01/drivers/video/ti81xx/vpss/fvid2.c (line 79), I see that CURRENT_VPS_FIRMWARE_VERSION is defined as 0x01000137. Is this just a harmless warning because this file wasn't updated after the M3 changes? If anyone could verify this, we'd certainly feel a bit better about it as we don't know specifically what was changed on the M3 side of things.

Thank you for your time and help,

Jon

Hi Amish ,

I have tried migrating the HDVPSS firmware  to the new EZSDK 5_05_02 . I have added drivers for custom video decoders in our board into the new hdvpss sources  . My OMX application some times gets stuck at CAPTUREAPP: Detect video in progress for inst 0 .

Also we didn't update U-boot ,kernel,filesystem to the latest EZSDK 5_05_02 . We want to stick with hdvpss sources in EZSDK 5_05_01 .

Can you suggest us the file name and the function name where the changes have been done to solve the green noise in SD display in the older hdvpss_01_00_01_37 sources .

We don't have time and resources to migrate the u-boot ,kernel ,filesystem and firmwares to the latest EZSDK .

Thanks,

N Sivaramkrishna .

Mistral Solutions Pvt Ltd .

Please share with me exact defect number (i.e. IR number) for me to track specific changes in internal system. Or else there is no other option.

Regards,

AMISH LAKHANI

Hi Amish ,

Thanks for the reply . I think Below  is the exact defect no.

SDOCM00089112 - [Display] Flicker observed for video plane through SDVENC ,It got mentioned in HDVPSS release notes 38 .

As jon was discussing in this thread when the buffers are not provided on time to SDVENC display or display is paused we can see the green flickering noise on SD Display . This was the issue you told in this thread that you have fixed .

I just need those changes so that i can include them in the hdvpss_01_00_01_37 sources .

Thanks,

N Sivaramkrishna .