If I understand correctly, "+1" means that there was no dropped frames, whether the flip occured during field 0 or 1. Field 1 meaning that decoding was a bit late, but not enough to show stutter on screen...
Correct. This is a Via C3 Nehemiah 1GHz, with the following CPU usage on typical
live TV : * software decoding: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2820 vdr 15 0 264m 54m 5696 S 58.0 24.7 0:42.09 vdr * hardware decoding: 3118 vdr 15 0 278m 50m 5580 S 37.7 23.2 0:17.70 vdr
Bear in mind that if you're dropping frames in either case, the fact that there appears to be some headroom available could be misleading. I can tell you that on my 1.2GHz board, software decoding of broadcast 720x576/50i MPEG-2 video in Xine, it runs at around 80% CPU usage.
I presume that output you quoted was for the software decode case? How > does it look when you use the hardware decoder? This was the hardware decoder. The following set is with software decoding : This case has no +2, except at the beginning. After that, the output is smooth.
Which is kind of odd because hardware decoding should be faster! I still recommend you try df_xine (and try it with hardware decoding too) to see how that performs. It may be that on average there's enough CPU time available but that there are some peaks in demand (perhaps independent of the video decoding) that make it unreliable. I've never used vdr/softdevice so I don't know its architecture but if there are other threads running and the decoder threads aren't prioritised, that could cause problems. I also don't know how much buffering is used. Xine, for example, typically runs with 15 buffered frames. Other than that, I've no further suggestions; I don't think it's a DirectFB thing anymore. If you get to the point where you only have '+1's in the debug and it still doesn't work, come back to us. Mark
_______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
