1080P does not jitter framedrop on VLC!
#1
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?
Reply
#2
Are you using hardware acceleration? With my 2009 mini, the hardware acceleration is very flaky (at least with nightlies, most recently tried with r32544). Sometimes it syncs fine, and beyond initial dropped frames 0 drops for whole Avatar (for example). Most of the time, though, it goes to drop ~20% of frames mode, and while CPU isn't being used, the sync figures go all over the map and movie is unwatchable.

For the time being, I'm just watching in software-only mode, but unfortunately action-heavy sequences seem to be too much for my poor Mini, and I get some dropped frames there. However, that's much better than random behavior in hardware accelerated mode.
Reply
#3
I just tried everything and it jitters in fast motions whatever I do. My Imac has hardware accel yes but I think it’s a buffer thing. Blueray 1080P uncompressed is a lot of data being passed. VLC can handle the mkv with ease and XBMC can not. I am using the latest nightly and it’s no better than the last official version. I can watch the movies with VLC jitter free but I just love XBMC and would like to use it instead.
Reply
#4
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.
Reply
#5
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?
Reply
#6
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?

xbmc.log shows software decoding using ffmpeg, I thought you had a VDA decoder problem ?

NOTICE: CDVDVideoCodecFFmpeg::Open() Using codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10

INFO: ffmpeg[B07B8000]: [h264] concealing 6120 DC, 6120 AC, 6120 MV errors
Reply
#7
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.

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 Wink

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.
Reply
#8
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 Wink

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.

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.
Reply
#9
sure will run it 5 minutes, nothing changes though that’s why I thought that’s enough. Want me to set something else? Will do tomorrow.
Reply
#10
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.

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..
Reply
#11
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..

Turn off the sync to display option, let's start simple.

xbmc.log looks picture perfect, no thrashing, no queue drains.
Reply
#12
davilla Wrote:Turn off the sync to display option, let's start simple.

xbmc.log looks picture perfect, no thrashing, no queue drains.

I pretty much iterated through the options when that build first came out yesterday, all had ~same results. I'm not sure if it has something to do with the 24p mode of the projector, because I'm not sure if I have managed to get non-droppy playback in this mode anymore using hardware acceleration and 1080p.

720p / software 1080p works ok, at least.

Anyway, here's a log with the options 'vanilla' (I turned off the aspect ratio compensation (shouldn't affect this, fullscreen feed), and that a/v sync).

Same ~3k dropped frames.. http://www.iki.fi/fingon/xbmc3.log

Ah ha.. Eureka! ;-)

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?
Reply
#13
Follow-up to self, yeah, I played bunch, no vblank => always flawless-ish (those dropped frames during scene changes rarely), but with vblank one, two scenes in at most.

Now back to watching something for fun, and not Avatar for pixelpeeping ;-)

Let me know if you need some more data on this.
Reply
#14
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?

Very odd, I'm wondering if 10.6.4 has vblank issues with VDA decoder or if something is messing with the DisplayLink tap to sync to vblank.
Reply
#15
Do you still need my log again davilla ?
Reply

Logout Mark Read Team Forum Stats Members Help
1080P does not jitter framedrop on VLC!0