Grr, again the missing reply-to handling on this list. On Freitag, 9. September 2005 00:46, Mark Adams wrote: > > > > With full patch to DirectFB _and_ Mark's field-sync patch to viafb, I > > was getting ca. 25% CPU usage. The improvement must be down to the > > field-sync stuff. Not worked out which bit yet but I think they work > > together, i.e viafb will behave 'normally' unless told otherwise (I > > presume). > > OK. In that case (all patches applied) the vsync will appear to happen 25 > times a second. Without either the DirectFB patch or the viafb patch, the > vsync will happen 50 times a second, i.e. every field. > Therefore, it's not too surprising that the CPU usage should be different > in the two cases but does suggest vdr/softdevice works in a rather different > way to xine (which is what I have experience of). > The fact that you're seeing the video play at half speed and then jump, > strongly suggests the application is creating 50 frames a second, i.e. that > it's doing deinterlacing. You need to supply 25 frames a second. > > To answer your earlier question, the data flow through the entire system is > (or should be) as follows: > - 25 interlaced frames per second input to DirectFB > - DirectFB does no deinterlacing > - Frame buffer therefore updated 25 times a second with an interlaced frame > containing two fields > - CLE266 CRTC generates a 50Hz 720x576 non-interlaced picture which contains > both fields. Being 50Hz, this intermediate signal presents the complete > frame (both fields) twice to the TV encoder before the picture changes to > the next frame > - The TV encoder first reads every odd line of this picture and creates > field 1 of the TV output > - 1/50th second later, on the second repetion of the picture, the TV encoder > reads every even line and creates field 2 of the TV output > Yes, it's a bit complicated but most of that is just how the hardware works > and is of no concern to the application author who need only create > interlaced frames at the correct frame rate. > It's possible that vdr/softdevice checks to see if the FIELD_PARITY option > is supported by the DirectFB layer and if not, performs deinterlacing > itself. If this is the case, the solution is probably to implement the > FIELD_PARITY option correctly in the unichrome DirectFB driver (or patch > vdr/softdevice to workaround the problem). > Mark >
-- Stefan Lucke _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
