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
_______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
