Thanks Vtain, for your promt reply.. Please find my comments below with tag "suHas" > > > suhas wrote: >> >> Hi Brain, >> >> It seems that, you are successful in using ODS0 in 1024x768x16bpp. >> >> I am working on DaVinci dm6446 EVM. I am posting this problem here as >> there was no reply to my post in other thread. Its a similar problem, >> so please help. >> >> I am facing a problem of display flickering when cpu gets busy with >> some other processing (may be for Ethernet data transfer or while >> displaying video). >> >> It seems that the problem is with CPU bandwidth. >> >> I am using OSDWIN0 in RGB565 mode. I have selected standard resolution >> of NTSC. I understand this means a 720p x 480p resolution. >> >> As per the bandwidth requirement formula, required bandwidth is: >> >> [(720 * 480) * 2 + 0 ] * 30 = ~20Mbps. Thus this satisfies the >> condition for <25Mbps >> >> Still, display flickers whenever there is any heavy processing done >> over CPU. Kindly help me out of this. >> >> > I saw this problem when trying to use > 74.25Mhz external clock with > dm6446. If you have the Video1 window enabled, try disabling that. It > really depends what the 'flicker' is. Of the few effects I have run > into, one was what appeared to be a few single lines which would wrap, > and the other was large vertical portions of the picture which would get > wrapped. The latter happening when we tested using a out-of-spec clock > at a higher frequency.
suHas: I have only OSDWIN0 enabled. All other windows are disabled. With flicker I do mean that, whenever there is some heavy processing over ethernet the screen "shakes". Also if I try to view any video, it seems that few frames are dropeed and the entire screen flickers. Complete picture becomes shaky. This effect exceeds when I view the video in full screen mode. I am using Analog display and am currently working on DaVinci DM6446EVM. >> >> I am using non-interlaced mode. Would this cause any problem? I dont >> think so, as I have also checked with interlaced mode. >> >> Results were the same. But using non-interlaced mode, made the picture >> more clear. >> >> Is there any other way by which I can implement this ping-pong logic >> for OSDWIN0? >> >> > I am not using any analog displays so I never became very familiar with > what the ping-pong code actually did. I am fairly certain that it has no > use for the OSD window. I believe it toggled the source of the video > window between vid0_addr and the subpicture addr. I have no idea why > that fixed anything, or whether it was simply to offset one of the > 'fields' a line. >> >> Can you please help me out to get this issue resolved. >> >> BTW what is panning in the framebuffer driver? Could this be used to >> solve my issue? >> >> > I believe panning was initially implemented solely for having a larger > virtual resolution than your display. Lots of times, however, it seems > to be used in framebuffer drivers for buffering. >> >> Awaiting your reply >> >> Regards, >> >> Suhas Jain >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On >> Behalf Of Carl Renaud >> Sent: Wednesday, October 15, 2008 9:16 AM >> To: Brian Rhodes >> Cc: [email protected] >> Subject: Re: DM6446 1024x768 graphics with video overlay >> >> Thanks for your response Brian! >> >> You say you are able to use OSD0 in 1024x768x16bpp. >> >> 1) Can you also use OSD1 at the same time as an attribute windows to >> >> let VID0 show through? E.g. have a D1 30fps video playing over a >> >> 1024x768 graphic background? >> >> 2) When you say "...If you need to do some form of animation on the >> >> OSD window, you'll have to do some work to understand the limitations, >> >> especially if you are using OSD1 as an attribute window for per-pixel >> >> alpha blending... ", what kind of limitation are we talking about? I >> >> know about the rendering speed limitation of the 297MHz ARM, but other >> >> than that? >> >> 3) I guess I don't understand the equation in section 4.3.1 of >> >> sprue37c.pdf (Video Window Constraints). According to the equation, >> >> using OSD0 in 1024x768 at 30 fps seems to exceed the specified limit >> >> of 25 Mbytes/second. >> >> [(1024 * 768) * 2bpp + (720 * 480) * 0.5bpp] * 30 = [1572864 + 172800] >> >> * 30 = ~52 Mbytes/sec >> >> What am I missing? >> >> Thanks again! >> >> On Tue, Oct 14, 2008 at 4:57 PM, Brian Rhodes <[EMAIL PROTECTED]> wrote: >> >> > >> >> > >> >> > Carl Renaud wrote: >> >> >> >> >> >> Hi, >> >> >> I am seeking advice on the DM6446... >> >> >> Our product requirements >> >> >> ================== >> >> >> Display a 1024x768 graphic background with a video overlay. Using >> the DM6446, there is no problem doing this is in D1 resolution, using >> VID0 for video, OSD0 for graphics and OSD1 for transparency. For >> resolutions higher than D1, there seems to be a few limitations... >> >> >> Methods >> >> >> ====== >> >> >> 1) The first method would be to use VID0 for video, OSD0 for >> graphics(RGB565) and OSD1 for transparency. >> >> >> I read in the VPBE document (section 4.3.1 of sprue37) that the >> combined bandwith of the OSDs cannot be more than 25MB/sec. This is >> exactly a D1 resolution OSD at 30 fps. So... this method would not >> work... Correct? >> >> >> >> >> > >> >> > I am not having trouble drawing 1024x768x16bpp graphics to OSD0. To >> prevent tearing, use the memory you would have for Video 1 window and >> implement panning in the framebuffer driver. Your 'product >> requirement' has a full screen graphic background, and for that OSD0 >> will suffice. If you need to do some form of animation on the OSD >> window, you'll have to do some work to understand the limitations, >> especially if you are using OSD1 as an attribute window for per-pixel >> alpha blending. >> >> >> >> >> >> 2) The second method would be to use VID0 for graphics(RGB888) and >> VID1 for video (as a picture in picture). >> >> >> In the VPBE document (again section 4.3.1 of sprue37), it is stated >> that when doing HD, VID0 should be used and VID1 disabled. Also, >> reading through the mailing list, it seems that there is a silicon >> problem on the DM6446 that prevents using VID0 and VID1 at the same >> time. So... this method would not work... Correct? >> >> > >> >> > You are correct. You cannot use Video 1 when the resolution of Video >> 0 is > 720x576. The bug in the silicon causes a flicker when both >> Video 1 and Video 0 are used at lower resolutions. >> >> > >> >> >> 3) The third method would be to use VID0 for graphics(RGB888), OSD0 >> for video(RGB565) and OSD1 for transparency. >> >> >> My understanding is that this should be possible if we limit the >> video to be a D1 frame within the 1024x768 graphics of VID0. This >> would respect the OSD bandwidth limitation. However, since OSD0 only >> takes RGB565 (and bitmap), I would need to convert the YUV 4:2:2 video >> to RGB565 on the ARM(or DSP). Correct? >> >> >> >> >> > >> >> > This would not be possible. You would not be able to do this >> colorspace conversion quick enough. Codec implementations which do >> conversions between 4:2:2 and 4:2:0 are simply reassembling the stream >> of data, throwing some away in one direction, and duplicating some in >> the other. the conversion from yuv -> rgb is considerably more work. >> >> >> >> >> >> Is my understanding correct? Is there any other option on the >> DM6446 to meet our requirements? >> >> >> Thank you! >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> >> _______________________________________________ >> >> >> Davinci-linux-open-source mailing list >> >> >> [email protected] >> >> >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >> >> >> >> >> _______________________________________________ >> >> Davinci-linux-open-source mailing list >> >> [email protected] >> >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >> > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
