DM365 720P video

cy said:

Is it possible to play 720P video on OSD0?

I have never seen it done but you should be able to do this, note that you may run into bandwidth limitations if you have multiple OSD/VID windows configured at such high resolutions.

cy said:

what's the difference between VID0 and OSD0, bus bandwidth or any limitation?

The basic differendces are described in section 4.4 and table 30 of SPRUFG9a, in general the OSD windows are meant to display OSD graphics and can manage RGB formats, whereas the VID windows are meant for video display and can only handle YCbCr/YUV colorspace formats. Overall if you have too many windows that are too large in a 720p display you can start running into bandwidth limitations.

Hi Thompson

Thanks for your response.

If I turnoff the V4L2 function, is it still possible to play 720P video on /dev/fb/1 ?

anything should I care specially?

We support two industry standardized video display drivers (V4L2 and FBDev), I mention industry standards to note that the APIs application use to interface to these drivers are Linux Standards and not defined by TI.  That said, V4L2 is suited for video but not very well suited for graphics OSDs; therefore by default our system supports video display via V4L2 (/dev/video#) and OSD via FBDev (/dev/fb/#); this is the reason you likely see the following specified as part of bootargs by our Getting Started Guide (GSG)

    video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K

Suggesting vid0 and vid1 are not under the control of FBDev, but osd0 is.  The device node you suggested above (/dev/fb/1) corresponds to vid0 and you can certianly control it with via FBdev node /dev/fb/1 if you wish; however, before doing so you must tell FBDev driver to allocate a memory buffer for this window during driver initialization by passing the proper bootarg arguments during boot time.  For example,

   video=davincifb:vid0=720x576x16,2500K:vid1=720x576x16,2500K:osd0=720x576x16,2025K

Let us know if this helps clear things up.

hi Juan

I had two questions.

When I set the bootargs to be

   video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K

only last /dev/fb0 and /dev/fb1,  It means the vid0 and vid1 was lost control by FBDEV.

But I saw /dev/video0 didn't create, can it still use through V4L2?

When I set the bootargs to be

   video=davincifb:vid0=720x576x16,2500K:vid1=720x576x16,2500K:osd0=720x576x16,2025K

does it mean vid0 and vid1 cant be controlled by both FBDEV and V4L2?

HI Bernie

What I really concern is the 720P play limitation?

Is it must be showed in VID1?  

We have two candidate though

1:   only use OSD0, and let the application to contorl surface, OSD0 resolution 1280x720  (what bootargs do you suggest for 720P and only OSD0?)

2.   UI dipplay in OSD0 and video play in VIDO, OSD0 resolution 1280x720  (what bootargs do you suggest for 720P with OSD0 and )

cy,

I tried explaining how bootargs worked in http://e2e.ti.com/forums/p/10626/41345.aspx#41345  (excerpt below but would recommend you read entire post at preceeding link)

"Maybe I can help make a little since, though I have done little testing to verify all combinations.  My understanding is that video windows (VID0 and VID1) can be controlled by V4L2 or FBDev driver for video display, but OSD windows (OSD0 and OSD1) are controlled by FBdev driver for graphics display (V4L2 is video specific and not geared towards graphics).  With V4L2, video buffers are allocated at run time by application, but with FBdev video and osd buffers are allocated during boot time, determined by the information you pass via bootargs.

That said, by default GSG suggests 'video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K", which means FBDev does not control vid0 or vid1 (defaults to V4L2 control), but does control osd0 and the maximum size that any application would require of osd0 at run-time is 720x576 16-bit pxels.  FYI, 720x576x2 bytes per pixel  x 5 buffers = 4050K, but I am not sure whay they need 5 buffers.  normally double or tripple buffering should be enough so you probrably can make this last part smaller.  Also it is important to note than since nothing was specified for osd1 (OFF or size), then osd1 will initialize per driver default size."

In addition, /dev/video0 (not to be confused with vid0) is normally associated with capture video port (as opposed to display); it is odd that it did not get created, but should not prevent display from functioning.  And yes, so long as you tell fbdev to allocate buffers corresponding to vid0 and vid1 during boot time (via bootarg), you can swtich back and forth between fbdev and V4L2 control of vid0 and vid1 via fbset command (see post link above).

cy said:

1:   only use OSD0, and let the application to contorl surface, OSD0 resolution 1280x720  (what bootargs do you suggest for 720P and only OSD0?)

2.   UI dipplay in OSD0 and video play in VIDO, OSD0 resolution 1280x720  (what bootargs do you suggest for 720P with OSD0 and )

1)  "video=davincifb:vid0=OFF:vid1=OFF:osd0=1280x720x16,3600K"; this would assume double buffering of OSD0 which I think should be sufficient. 

2)  if vid0 is controlled by V4L2 (default), then same bootargs as in 1) should work, so you are all set.

If you suspect bandwidth may be an issue, than you may want to consider updating OSD0 windows at a lower refresh rate (e.g. only enabling it every nth frame); graphics normally does not need to be updated as often as video.

Hi Juan,

please repost the link on explaining how bootargs worked or maybe put a whole new post on the forum's top, like those ones with the guidelines how the forum should be operated that always stays on top, as those bootargs have always been a bit "greek" to me, or maybe I should say "isZulu" or something.  The link " http://e2e.ti.com/forums/p/10626/41345.aspx#41345" in the previous post here doesn't work anymore and take sme to the "top" of the forum anyway.

Thanks, Jinh T.