Comment # 39
on bug 76564
from jeroen
(In reply to comment #37) > Created attachment 96604 [details] [review] [review] > Possible fix v3 > > Please try this one, it's a complete rewrite of finding the right PLL > numbers. No problem Peter I was already compiling it manually for the previous tests. I just tested the patch using OpenElec 4. 50fps: 14850, pll dividers - fb: 29.7 ref: 4, post 5 23.976fps: 7417, pll dividers - fb: 741.7 ref: 100, post 10 59.94fps: 14835, pll dividers - fb: 296.7 ref: 25, post 8 50fps is spot on and no frames are dropped. The dividers are optimal. 23.976fps is better, but I still count on average a skipped frame every 28sec. Since the skipped frames are not at a regular interval I took the average. Sometimes a frame is skipped after 10sec, but it sometimes also takes 40 seconds. When a frame is skipped I see the fps in XBMC drop to around 22.98fps. What I do not understand is why it is still so often as the error in the clock would suggest a drop every ~9min. 59.94fps is also much better. Here XBMC reports a missed frame maybe every minute or so. This patch is definately an improvement, but it still not as good as fgrlx which could play for many minutes without every dropping/skipping/missing frames. Perhaps since Peter is apparently also following this thread could give some insight in the synchronisation in XBMC? I have the idea the sync behaves differently in OE4 compared to OE3. For example in OE3, the player (P) in the codec info overlay never had the field skipped, only dropped? Is the VBlank moment in XBMC derived from the pixel clock from the radeon or the pixel clock the TV is expecting? Could it be that as the phase between the two pixel clocks is becoming to big, that this is solved/handled differently between fgrlx and OSS radeon?
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
