What is causing this blockiness?

[Razorholt]

Hello,

I have this QT file (a trailer) that I would like to encode with x264. Here are the settings:

x264.exe --pass 1 --filter -6,-6 --bitrate 1200 --ref 8 --mixed-refs
--bframes 3 --b-pyramid --subme 1 --b-rdo --weightb --trellis 1 --analyse all
--8x8dct --progress --no-psnr

x264.exe --pass 2 --filter -6,-6 --bitrate 1200 --ref 8 --mixed-refs
--bframes 3 --bime --b-pyramid --subme 6 --b-rdo --weightb --trellis 1
--analyse all --8x8dct --progress --no-psnr


Problem: this file is chopy or blocky.

I tried to adjust --ref, --trellis, --bime, etc... but whatever I do it's still not smooth. The only way to correct this problem is by reducing the birate, which is not an option (because the quality suffers) .


Thanks for your help!


- Dan

[ChronoCross]

source and result clips are required to give an accurate answer. Thank you.

[Tommy Carrot]

Well, probably "--filter -6,-6" is the culprit there, try the default settings for deblocking.

[Razorholt]

I found and downloaded the trailer at http://www.apple/trailers

The AVS code is:

LoadVFAPIPlugin("C:\Program Files\AviSynth 2.5\plugins\QTReader.vfp","QTReader")
video = QTReader("Z:\trailers\Thank you for smoking\thankyouforsmoking_h720p.mov")
video = video.FlipVertical.ChangeFPS(23.976)
video = video.ConvertToYv12()
video = video.BicubicResize(1024,432,0,2)
logo = ImageSource("Z:\watermark\NS_logo.png", fps=video.FrameRate())
logoMask = ImageSource("Z:\watermark\NS_mask.png", fps=video.FrameRate())
Overlay(video, logo,
\ x=(video.Width() - logo.Width() - 15),
\ y=(video.Height() - logo.Height() - 15),
\ mask=logoMask, opacity=1.0)


I used AVC2AVI.exe to get that AVI file and I'm currently uploading the result clip.


Thanks,
- Dan

[Razorholt]

Just tried this setting:

x264.exe --pass 2 --bitrate 1000 --stats ".stats" --ref 10 --mixed-refs --bframes 3
--b-pyramid --b-rdo --bime --weightb --filter 0,0 --subme 6 --trellis 1 --analyse all
--8x8dct --me umh --sar 1:1 --progress --no-psnr

It's not blocky at all but the quality is not very impressive... What would be the right settings for --filter in order to get a sharpy image without any blockiness?

Thanks,
- Dan

[bob0r]

Did i miss something or is --filter 0:0 the same as --filter 0,0 ?

: and ,

[woah!]

-2,-2 is normally a pretty good middle ground

[akupenguin]

":" the only accepted syntax. If you use any other separator, like ",", x264 won't see then 2nd number, and will instead use the 1st number for both. So yes, "--filter 0,0" is the same as "--filter 0:0", but not for the right reason.

edit: typo, manao is right

[twist3d]

If you use any other separator, like ",", x264 won't see then 2nd number, and will instead use the 1st number for both.
akupenguin, latest sharktooth's (b408) megui x264 gives this line from "show commandline" (hq-slow) x264.exe --pass 2 --bitrate 50 --stats ".stats" --ref 5 --bframes 3 --b-pyramid --weightb --filter -2,-1 --subme 6 --trellis 1 --analyse all --8x8dct --progress --no-psnr --output "" ""
note the --filter -2,-1. So megui sets wrong --filter settings?

[Manao]

";" the only accepted syntaxchar *p = strchr( optarg, ':' );You meant ':', not ';', didn't you ?

[akupenguin]

~> x264 352x288.yuv --output foo.264 --filter -2,-1
~> strings foo.264 | head -1
x264 - core 44 svn-408 - H.264/MPEG-4 AVC codec - Copyleft 2005 -
http://www.videolan.org/x264.html - options: cabac=1 ref=1 deblock=1:-2:-2
analyse=0x1:0x111 me=hex subme=5 brdo=0 mixed_ref=0 me_range=16 chroma_me=1
trellis=0 8x8dct=0 cqm=0 chroma_qp_offset=0 slices=1 bframes=0 keyint=250
keyint_min=25 scenecut=40 pass=1 qp=26 ip_ratio=1.40

[Razorholt]

OK, this one is blocky (the clip is hanging every 5 or 10 secs):


2 pass:

x264\x264.exe --pass 2 --bitrate 1400 --stats ".stats" --ref 16 --mixed-refs
--bframes 3 --b-pyramid --b-rdo --bime --weightb --subme 6 --trellis 1
--analyse all --8x8dct --me umh --sar 1:1 --progress --no-psnr



This one is OK:


Const. Quant:

x264.exe --qp 23 --ref 16 --mixed-refs --bframes 3 --b-pyramid --b-rdo
--bime --weightb --subme 6 --trellis 1 --analyse all --8x8dct --me umh
--sar 1:1 --progress --no-psn


As you noticed, --filter was set to 0 in both cases...

[bond]

screenshots?

[Manao]

Razorholt : you can only compare things that can be compared. In your case, does qp23 produce the same size as br1400 ? Somehow, I doubt it.

Furthermore : the clip is hanging every 5 or 10 secsWhat do you mean by hanging ? Halting ? Pausing ? Or something else ?

[stax76]

argh:

Just one thing, use comma instead colon (-2,-2) in CLI.
Hope that will help you.

I've fixed the bug with the --nf switch and changed it to comma like in MeGUI, I guess that works but I understand the docs different:

-f, --filter <alpha:beta> Loop filter AlphaC0 and Beta parameters [0:0]



I just don't understand how a app popular like MeGUI can have a bug with a important switch like Loop Filter and nobody is realizing it.

[Manao]

Easy, because nobody can see the difference between -1:-1 and 0:0 :p That also implies nobody can see the difference between -1:0 and -1:-1. Finally, almost nobody uses different alpha:beta, and x,x <-> x:x, so...

[Razorholt]

Yes, the clip is pausing and skipping frames. But you're right Manao, q23 produced a 40MB file and br1400 a 28MB one.

Here is the file: download (http://nubastream.com/dan/thehillshaveeyes_2pass-1400.avi)


Thanks,
- Dan

[Manao]

Yes, the clip is pausing and skipping framesWhat computer do you have ? What do you use to play the video back ( player, play back filter, video renderer ) ?

[Razorholt]

PC: P4, 512RAM
Players: mplayer2 or mplayer classic


Thanks,
- Dan

[Manao]

PC: P4, 512RAM
Players: mplayer2 or mplayer classicYou can do better than that ;) What's the cpu frequency, and what directshow filter is actually used during decoding ( media player classic, open the file, then check the filters used ). And if you don't already use it, try CoreAVC.

Finally, the jerkiness is hardly related to the original issue, which was blockiness.

[Razorholt]

Ok, more info... sorry about that ;)

PC: P4, 2.20GHz, 512RAM
Filter: ffdshow MPEG-4

And if you don't already use it, try CoreAVC.


Tried it a few weeks ago but I couldn't make it work. Well, I'll try again. The thing is, I'm not sure the users who would want to watch this file will fancy the installation of a new filter.


Thanks,
- Dan

[gaekwad2]

Finally, the jerkiness is hardly related to the original issue, which was blockiness.
I think he meant jerkiness all the time. Why else would reducing the bitrate solve it?

[bond]

i also get pausing and skipping frames with coreavc on the posted sample but i assume thats simply a lack of cpu issue

[Razorholt]

@bond: are you somehow saying that the "2pass" file (28MB) is using more CPU than the "const. quant. 23" one (40MB) ? hmm.. Well, when I reduce the screen resolution, down to 848w, the file is fine.

One thought: should I try and adjust the Rate Control (using Megui) or is it useless?

[Manao]

I think he meant jerkiness all the time.I reread the first post, indeed, it didn't see he had written choppy.Why else would reducing the bitrate solve itBut it doesn't : the 40 MB files isn't jerky, the 28 MB is. Unless the bitrate varies wildly, both should be as jerky. But lets assume he switched the two sizes.

If it's bitrate, CoreAVC will definitely help. Else, using a more lightweight player ( vlc, mplayer ) might be an alternative, but that has the same drawback as CoreAVC, ie it needs to install something.

[bond]

i simply tried playing this file:

Here is the file: download (http://nubastream.com/dan/thehillshaveeyes_2pass-1400.avi)no idea how it has been created

anyways the smaller the resolution, the easier to decode the file

[Manao]

Razerholt : bond "only" has a p3 766, so jerkiness is to be expected on his side. You, however, should have all the "horsepower" needed to play it back fine ( i do with ffdshow on a A64 3200+, with less than 50% of the cpu used ).

should I try and adjust the Rate ControlYou can play with the vbv option, to make the bitrate more constant.

[Razorholt]

no idea how it has been created

I used the AVS script that I posted (#4) then I used the Megui (Sharktooth's version). I tried the command line also but it was of no avail. Finally, I used AVC2AVI to convert the .264 to an avi file.


anyways the smaller the resolution, the easier to decode the file

Yup, you're right. No doubt about it. But the thing is that I have to provide a 1024w file. :(


Thanks,
- Dan

[Razorholt]

@Manao: So, you agree with bond? It's a CPU issue here?

You can play with the vbv option, to make the bitrate more constant.

Ok. Should I set "VBV Max. Birate: 1412" or just reduce the "Birate Variance" to 0.9 (original setting: 1.0)?


Thanks,
- Dan

[Manao]

Actually, I still think you CPU should be up to the task. But there's no other culprit, so... For the bitrate, you have to set the VBV size & max bitrate buffer ( the bigger the size, the more variable the bitrate, the higher the max bitrate, well, the higher the max bitrate :)

Bitrate variance might help too, but I'm not sure about it.

[Razorholt]

Thanks a lot Manao! Encoding now...

[Razorholt]

Megui bug: the small arrows for the "Birate Variance" don't increase/decrease the value well... unless I'm wrong?

[Manao]

Report it on the dedicated thread on the gui forum then.

[Razorholt]

Ok, I think I got my blockiness problem fixed. I had to make the following changes:

1. Allocate a value to "VBV Maximum Birate" (1500)
2. Increase the Minimum Quantizer, from 10 to 20
3. I've also changed the Filters, from "-6,-6" to "-5,-5"

I have some questions:

1. Does "M.E. Range" have an impact on the image quality? For example, what if I change the value from 16 to 32? Worth it? I'm not being lazy here, it's just that it may save me another 3 hours encoding :)
2. Will you guys recommend using any matrices to improve the quality?
3. Is it safe to remove ffdshow Mpeg-4 and use CoreAVC instead, while using mplayer2?


Thank you all for your help.

- Dan

[Manao]

Does "M.E. Range" have an impact on the image quality? For example, what if I change the value from 16 to 32Default value is quite good. More won't slow down the encoding, but won't improve it either. Reducing it too much is not a good idea.Is it safe to remove ffdshow Mpeg-4 and use CoreAVC instead, while using mplayer2There's no issue afaik with CoreAVC.