On Thu, 2005-09-08 at 23:46 +0100, 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.
This all makes sense. I did more testing last night with the partially patched version. Playback of live TV is the correct speed but quite jerky: not sure it's actually missing any frames but the speed seemed a tad uneven (A-V sync was also off which may have helped it to look worse than it actually was!). Bizarrely, playing back recordings (from vdr) played them at what looked like double speed. I think these are problems with softdevice, though, from looking throught the softdevice list archives. Your 720x576NoScale patch to via_vt1622.h makes so much difference, though! I did not apply it to start with and the OSD was really fuzzy. After applying that, it was so much sharper. > 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. That all sounds like I was thinking apart from the whole frame being sent to the encoder twice: is this by DirectFB or internal to the encoder chip? > 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). I'm just having a quick look through the source code for softdevice and FIELD_PARITY does probe directfb to see if it is supported (should your patches make a unichrome chip report FIELD_PARITY as an option? It doesn't look like it to me). If FIELD_PARITY is supported by the output device, it is set as an option for the video layer, tested to see if it can be set without errors, and then used if successful. Do your patches to viafb and DirectFB introduce FIELD_PARITY behaviour but not advertise it as such? How easy would it be to add proper FIELD_PARITY support to the unichrome driver in DirectFB? Is the functionality there but it doesn't report it or check for whether it should be used or not? I'm just looking through the matrox driver in DirectFB to see what that does! Cheers, Laz _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
