[MAC] Poor video quality (blocking, tearing) in Mac OS X
#1
I wonder if anybody can help me with this:

I use XBMC SVN build 19213M on OS X Leopard, the hardware is an 8-core 2.8 Ghz Mac Pro with 2 GB RAM. I noticed recently that one of my 720p video looked quite blocky so I cross-checked the picture with VLC to assure that the artifacts are not in the source but caused by the decoder. It turned out that this was the case, however, I was able to reproduce the same blocing artifacts with VLC when I set the FFmpeg loopback filter skipping parameter to 'always' (effectively turning off the deblocking filter).

I've read on a number of forum threads about a (hidden) parameter in advancedsettings.xml, namely 'skiploopfilter', I thought this could solve my problem with blocking. It seems that XBMC does nothing new when I set skiploopfilter to 0 or 8 or anything else, neither in OS X, nor in Windows. The debug log says the the advancedsettings.xml was processed but nothing changes then. Is this parameter platform specific? If yes, how can I cope with the blocking problem?

There was also present some kind of tearing (in the same video). Again VLC played without tearing, what is more, my older PC (AMD X2 2.2Ghz) with Windows/XBMC on it played without tearing as well. It was interesting to observe that, on OS X, the (single core) CPU usage was around 65% when I played 720p video in XBMC and around 35% when played the same video in VLC.

It seems as if XBMC would max out my Mac Pro-s processing power which is slightly absurd IMO. If CPU usage grows beyond 100% than usually frame drops occur, in other words, additional cores are not of any use Sad. Tearing is again a sign of insufficient processing power, isn't it?

All this boils down to a single question: what can I do if I'd like to use XBMC's - otherwise great - embedded player and want the highest quality decoder output at my hand, at least the same level of quality that VLC (FFmpeg) can produce? I'm not interested in any additional postprocessing (ie. scaling deinterlacing, noise filtering, detail enhancement) since my AV receiver will care about that. I just want maximum precision decoding with frame-by-frame deblocking and no frame drops at all.

Thanks for the helpSmile
Reply
#2
don't add any skiploopfilter setting to advancedsettings.xml, the default settings is nothing skipped.

19213M is pretty old. try again with something closer to svn head.

check you rendering method and disable any upscaling.

and most important, pastebin your xbmc.log as that will tell us more info.
Reply
#3
Deleted advancedsettings.xml, turned off scaling, tried every renderer, the results are the same.

Here is the log http://pastebin.com/m2aa33ec5 (the video I'm speaking of is referenced in line 570)

Is it possible that the tearing is attributed to incompatible monitor refresh rate and output framerate (60 Hz vs 23.97 Hz)? In Windows, output fps is always 22 Hz (divisor of 60 Hz), in OS X it is always 24 Hz, no matter how 'adjust framerate' option is set.
Reply
#4
adinatha Wrote:Deleted advancedsettings.xml, turned off scaling, tried every renderer, the results are the same.

Here is the log http://pastebin.com/m2aa33ec5 (the video I'm speaking of is referenced in line 570)

Is it possible that the tearing is attributed to incompatible monitor refresh rate and output framerate (60 Hz vs 23.97 Hz)? In Windows, output fps is always 22 Hz (divisor of 60 Hz), in OS X it is always 24 Hz, no matter how 'adjust framerate' option is set.

do you have vsync enabled in the settings?

EDIT: also if you have "adjust refresh" on, turn it off.
Reply
#5
davilla Wrote:do you have vsync enabled in the settings?

EDIT: also if you have "adjust refresh" on, turn it off.
Where can vsync be set? Certainly not in the GUIConfused

adjust refresh was set to off all the time (not that it matters how it is set, in my experienceSmile)
Reply
#6
adinatha Wrote:Where can vsync be set? Certainly not in the GUIConfused

sigh, settings -> appearance -> screen -> vertical blank sync
Reply
#7
oops, sorry. So vertical blank sync was disabled, I enabled it during video palyback so the tearing was gone. So far so good. Thank you for the hintSmile

However, the blocking artifacts are not connected to the vertical balnking, it must only be connected to the degree of post-filtering, or simply macroblock decoding errors. The latter is probably not the case, as I was able to reproduce the same artifacts in VLC by deactivating the loop filter.

And the 65% CPU usage remains, unfotunately. Davilla, do you know why is the video player so power-hungry? It's on par with Quick Time (with Perian) and about twice as demanding as VLC in this respect.
Reply
#8
adinatha Wrote:oops, sorry. So vertical blank sync was disabled, I enabled it during video palyback so the tearing was gone. So far so good. Thank you for the hintSmile

However, the blocking artifacts are not connected to the vertical balnking, it must only be connected to the degree of post-filtering, or simply macroblock decoding errors. The latter is probably not the case, as I was able to reproduce the same artifacts in VLC by deactivating the loop filter.

And the 65% CPU usage remains, unfotunately. Davilla, do you know why is the video player so power-hungry? It's on par with Quick Time (with Perian) and about twice as demanding as VLC in this respect.

Use MediaInfo to qualify your video, pastebin the info.. 720p comes in all flavors. I'd rather not guess about the encoding of your video. Also which version of VLC are you running?

My 2.4GHz MacBook has no problems with any 720p so something is amiss.
Reply
#9
The video is a simple AVC in MKV, nothing special http://pastebin.com/m3571297e

I don't say that the Mac Pro has problems with 720p playback, with XBMC or else; I just say that 65% CPU usage is a bit too much for a 2.8 GHz core to this end. In comparison, the 35 Mbit/s 1080p killa.sampla.x264 plays without a single dropped frame (with CorePlayer @120% CPU). I'm only concerned with high CPU needs because my ultimate target machine is a 2Ghz Mac Mini and not the Mac Pro beast, and high CPU usage=high noise level Sad.

VLC version is 0.9.8.
Reply
#10
adinatha Wrote:The video is a simple AVC in MKV, nothing special http://pastebin.com/m3571297e

I don't say that the Mac Pro has problems with 720p playback, with XBMC or else; I just say that 65% CPU usage is a bit too much for a 2.8 GHz core to this end. In comparison, the 35 Mbit/s 1080p killa.sampla.x264 plays without a single dropped frame (with CorePlayer @120% CPU). I'm only concerned with high CPU needs because my ultimate target machine is a 2Ghz Mac Mini and not the Mac Pro beast, and high CPU usage=high noise level Sad.

VLC version is 0.9.8.

It's special, [email protected], CABAC / 5 Ref Frames, 4050 Kbps and DTS to boot.

Again, I would suggest trying something closer to svn current or 9.04.alpha1. 9.04.alpha1 tagged at http://xbmc.org/changeset/19219

you are running 19213 and http://xbmc.org/changeset/19218 had an important fix to release build. Are you building this yourself or downloaded it from somewhere?
Reply
#11
davilla Wrote:It's special, [email protected], CABAC / 5 Ref Frames, 4050 Kbps and DTS to boot.

Again, I would suggest trying something closer to svn current or 9.04.alpha1. 9.04.alpha1 tagged at http://xbmc.org/changeset/19219

you are running 19213 and http://xbmc.org/changeset/19218 had an important fix to release build. Are you building this yourself or downloaded it from somewhere?

EDIT: another pastebin of just playing the problem video might be helpfull.
Reply
#12
Thank you for your help. I'll try a newer build. This build was downloaded from the forum, but I can compile from source if I try it hard enough, I guess Smile

By the way, if this video was special in decoder requirement terms, what do you think about this one http://pastebin.com/d70a1a7e1? This is not played at all in XBMC, at least not the video stream, the audio stream seems OK. VLC copes with it, and other players as well.

I will post the pastbin with the video playback tomorrow, I am first to try out a new build as you suggested.
Reply
#13
adinatha Wrote:Thank you for your help. I'll try a newer build. This build was downloaded from the forum, but I can compile from source if I try it hard enough, I guess Smile

By the way, if this video was special in decoder requirement terms, what do you think about this one http://pastebin.com/d70a1a7e1? This is not played at all in XBMC, at least not the video stream, the audio stream seems OK. VLC copes with it, and other players as well.

I will post the pastbin with the video playback tomorrow, I am first to try out a new build as you suggested.

VC-1 is fixed in cur svn

this is a 3rd party nightly build site

http://www.sshcs.com/xbmc/
Reply
#14
Thanks a lot again. Have tried out the latest build.

Unfortunately, nothing new with the nightly build 19533. The video is still blocky, and VC-1 is not decoded. My priority would be to solve blocking first as it affects every video while VC-1 affects only a few. Most HD programs and Blu-ray/HD-DVD rips are encoded with x264, I guess. However, I have no difficulties with this VC-1 encoded video in XBMC (I encoded it myself in Windows with Adobe Premiere) http://pastebin.com/d24e615d5 The sound is not played but its OK, WMA Lossless is not supported in XBMC.

Here is the log when playing s-sunshine.mkv and then Minority Report (720p).mkv http://pastebin.com/m24f83b9b
Reply
#15
I still suspect that somehow loopback filtering is disabled in XBMC and this causes blocking. Could you look it up in the source code, please? Do you think that VLC 0.9.8 and XBMC use different versions of FFmpeg?
Reply

Logout Mark Read Team Forum Stats Members Help
[MAC] Poor video quality (blocking, tearing) in Mac OS X0