Posts: 11
Joined: Jun 2008
Reputation:
0
I have been testing all Handbrake (0.92) settings myself, and the ONLY option that stopped the stuttering (at decent other settings) is -nf
Even when I disabled deblocking in Handbrake UI, it was STILL doing inloop deblocking.
The only way to get around it is to specify the extra parameter in x264 opts as
-nf
Posts: 127
Joined: May 2008
Reputation:
1
kparuchuri, I also use the --nf setting... it seems to be that if you don't use trellis in MeGUI it adds the --nf setting for you, and I don't use Trellis because it causes major stuttering. i never directly associated this setting with no stuttering, but it makes sense now!
Also, why don't you turn CABAC on? You get a 15% increase in quality at the same bitrate... just make sure you stay under my suggested bitrates and you'll be fine!
geosmack, I tried using my settings again with the new SVN snapshot of Handbrake and I don't seem to be having any issues. Encodes come out great! so i'm not sure why you would opt for lower quality in this hi-def world, but that's your own preference. you could probably even go for a mix between my settings and the defaults, trading off a setting or two for a faster encode time. the options that are slowing down your encodes are CABAC=1, subq/subme=7, me=umh -- changing these setting will give you faster encodes at the cost of overall quality. But again, not using CABAC immediately drops the quality 15% less!
I guess I am just trying to squeeze out every drop of quality because I run XBMC on a 42 inch and a 50 inch HDTV, so lower quality looks 10x worse at those sizes.
Posts: 127
Joined: May 2008
Reputation:
1
I'm sorry I was wrong, if you check off the "Deblocking" option in MeGUI it adds "--nf" to the commandline. Obviously this is a good thing, because Deblocking makes the Xbox stutter like a crazy bitch.
Posts: 127
Joined: May 2008
Reputation:
1
Ok, so after a little research on skipping frames, I found a fix!
It involves modifying the "mplayer.conf" file (located in: system\players\mplayer\)
Adding the line: "lavdopts=skiploopfilter=all" removes all deblocking from any file encoded with deblocking turned on (deblock=1:X:X -- X represents any value). This will produce visual artifacts upon playback, but solves the problem of not dropping frames in complex scenes!!! In most cases, this will make the video visually worse. However, files that were encoded with the "--nf" setting (or deblock=0:0:0) are unaffected and play back normal with zero quality drop.
An even better setting is adding the line: "lavdopts=skiploopfilter=bidir" -- With files encoded with Deblocking, this produces a lot less artifacting and better quality, but you can still run into a little skipping here and there. What this is doing is skipping the Deblocking filter on the B-Frames only.
And finally, one other setting is: "lavdopts=skiploopfilter=nonref". I couldn't find much info about it other than it helping with playback. I didn't test it because I read that "bidir" is the best, but I'm guessing that this setting removes deblocking on the Reference Frames (or non referenced frames?) I don't know... but give it a test!
All I did was open the mplayer.conf file into Notepad, added the line at the very bottom (under lavdopts=lowres=1,1400), saved, and uploaded to my box (replacing the old file).
Again, this seems to be only affecting Deblocked videos, but in one instance I dropped less frames on a video that wasn't Deblocked! So if you are willing to tradeoff quality for smooth playback, play with these settings! And please report back your results... maybe we can even get these to become changeable through the GUI!!!
Posts: 11
Joined: Jun 2008
Reputation:
0
JPSiemer, I would use cabac option, but there is a remote possibility that I might use these same encoded videos(without reencoding) on my 'future' ipod/iphone, and I heard that its better to turn cabac off for those devices.
That's why I am not using cabac.
And BTW, IMO this is the BEST thread with REAL solutions for making H264 playback smooth in XBMC. Keep it up! You guys rock.
Posts: 127
Joined: May 2008
Reputation:
1
kparuchuri,
If you haven't bought an iPhone yet, just wait a little longer. Steve Jobs is about to introduce the new iPhone model and rumors are going around that it will be faster and might even support higher resolution video. So it quite possibly might be able to handle CABAC with ease on the newer model! Don't take my word for it tho, just wait and see -- it's only about a week away...
Posts: 127
Joined: May 2008
Reputation:
1
kparuchuri,
By the way, I decided to go with vbv-bufsize=1500 for all my encodes now. Before, I was using 768 (don't ask why), and it was working out fine, until I realized that MeGUI was giving me WARNING messages in the logfile everytime. It was telling me that my buffersize was too low. So what it was doing was increasing the buffersize on the 2nd pass everytime. I don't know if this could potentially cause any problems, but I decided that 1500 was a safer number to use and I don't get these errors anymore. Plus, people on other forums thought I was crazy when I told them I was using a buffsize of 768!
Posts: 11
Joined: Jun 2008
Reputation:
0
Siemer,
Can you tell me what this vbv-bufsize affects?
I encode with a bitrate of 1400 or so, how will vbv-bufsize improve things?
Posts: 11
Joined: Jun 2008
Reputation:
0
Also, I recently removed the vbv-bufsize and vbv-maxrate settings from my encoding settings, because on one movie, I saw that the video was out of sync with audio.
So then I reverted back from handbrake latest SVN to handbrake 0.92 and removed these vbv settings, and it fixed the problem.
I am still not sure whether the older HB version fixed it, or removing these vbv options fixed it.
Posts: 127
Joined: May 2008
Reputation:
1
I've had out of sync audio before, as well. When that happened I usually just encoded the video with another application and it worked out fine. It probably is more likely a bug in the application than the settings, since the settings have worked out on every other video why wouldn't they work in this case?
As for what vbv-buffsize affects... I haven't the slightest clue -- I got that setting from reading a couple different threads of people experimenting with H.264 encoding for XBMC. In fact, half of the settings I am using is from extensive research of what other people have done. If some of the settings are outdated or are pointless, then please let me know and I will look into it.
However, I think I remember doing some tests with and without this setting, and I think setting it the maxrate to 5000 solved major skipping problems at high resolutions (when I say high resolutions, I mean the maximum safe resolution that XBMC can handle H.264 files -- 720x400, 720x384, 704x400, etc..)
Anyways, you could always do a test encode with 0.92 with the vbv settings and compare it to your encode you did without the settings. That would answer your question...
ubq=5:analyse=all:direct=auto:cabac=0:nf