2010-08-07, 20:10
I would like to ask why VLC is decoding a 1080p uncompresed .mkv without problems and XBMC has framedrops and jitters making the mkv unwatchable. What does VLC have that XBMC does not?
roads Wrote:OK here you are. Tried to play a 1080p uncompressed mkv. 16 fps. Same on Imac 24" 4GB 2009 April/may as on Epson TW5500
LINK to logfile
Modellname: iMac
Modell-Identifizierung: iMac9,1
Prozessortyp: Intel Core 2 Duo
Prozessorgeschwindigkeit: 2,93 GHz
Anzahl der Prozessoren: 1
Gesamtzahl der Kerne: 2
L2-Cache: 6 MB
Speicher: 4 GB
Busgeschwindigkeit: 1,07 GHz
Boot-ROM-Version: IM91.008D.B08
SMC-Version (System): 1.37f3
NVIDIA GeForce GT 130:
Chipsatz-Modell: NVIDIA GeForce GT 130
Typ: GPU
Bus: PCIe
PCIe-Lane-Breite: x16
VRAM (gesamt): 512 MB
Hersteller: NVIDIA (0x10de)
Geräte-ID: 0x062e
Versions-ID: 0x00a1
ROM-Version: 3370
Monitore:
Farb-LCD:
Auflösung: 1920 x 1200
Pixeltiefe: 32-Bit Farbe (ARGB8888)
Synchronisierung: Aus
Eingeschaltet: Ja
Integriert: Ja
EPSON PJ:
Auflösung: 1920 x 1080 @ 60 Hz
Pixeltiefe: 32-Bit Farbe (ARGB8888)
Hauptmonitor: Ja
Synchronisierung: Aus
Eingeschaltet: Ja
Rotation: Unterstützt
Fernseher: Ja
What else do you need?
davilla Wrote:If you are having issues with VDA decoder under OSX, best post xbmc.log (with debug turned on) and more details. First I've heard of any issues with VDA besides the issue with the MacMini and 10.6.4 update when connected to a real HDTV.
We are rolling towards Dharma release and these issues need to get resolved ASAP.
fingon Wrote:Ok, here's my log (edited little, removed 100+k of library scanning from beginning).
Hardware:
- 2009 Mac Mini, 2.53GHz + 4GB RAM
- FullHD 1920x1080 projector
- 24p mode selected
http://www.iki.fi/fingon/xbmc.log
Let me know if you need some more information, I'd love to see this resolved
P.S. The anomaly (~1/3+ dropped frames effect despite low CPU usage) seems to happen only with 1080p material, not with 720p. So in theory could be due to small cache, how big is XBMC's disk cache anyway? The videos are on 7200RPM FW800 drive, so throughput shouldn't be a problem, although latency at times could be.
davilla Wrote:22:49:00 playback starts at
22:49:40 play is quit.
How about letting it play for longer that 40 seconds. There's lot's going on during playback startup and I like to see past this point. 5-10 mins please.
XBMC's demuxer queues are time based not sized based, there's 8 seconds worth in the queues.
fingon Wrote:Ok, I'm took a longer log now. I watched the movie when logging it, the stream bitrate doesn't have anything to do with dropped frames - for example, at 5Mb/s places with people chatting drop frames, but on the other hand some 15Mb/s scene didn't drop frames.. Seems fairly arbitrary, really, where it decides to drop them. When it 'stalls' the sync% goes down from 40% to -50%? and error% is all over the map (mostly 50-400%). Also the W: fps is dropping to ~14-18, in the drop cases, while the S: refresh is still 24.
http://www.iki.fi/fingon/xbmc2.log
~*3k dropped frames or so (which means 140-ish seconds out of ~700 I had it playing..)
To amend my previous comment I'm actually seeing some drops on 720p material too if I use hw acceleration at times, but not so much it'd bother me..
davilla Wrote:Turn off the sync to display option, let's start simple.
xbmc.log looks picture perfect, no thrashing, no queue drains.
Quote:I think I found the culprit. Wait for vblank is causing it, but only in hardware mode, not in sw... Video's not really watchable with the updates somewhere in middle of screen, but I have had now only ~130 drops in 5 minutes, and those were all when switching scenes (for some reason blank screens had frame drops). The parts with stuff on screen were perfectly fine.
So any idea what could be this vblank interaction?