x264 "Macroblock Tree Ratecontrol" testing (committed) [Archive] - Page 9

Redsandro

1st November 2009, 19:07

Thanks.
Let me translate that into something that makes it more easy to read:
commit bb66c482242a0747823661b212114c1a2f015fe3 r1197
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Tue Aug 4 17:46:33 2009 -0700

Macroblock-tree ratecontrol
On by default; can be turned off with --no-mbtree.
Uses a large lookahead to track temporal propagation of data and weight quality accordingly.
Requires a very large separate statsfile (2 bytes per macroblock) in multi-pass mode.
Doesn't work with b-pyramid yet.
Note that MB-tree inherently measures quality different from the standard qcomp method, so bitrates produced by CRF may change somewhat.
This makes the "medium" preset a bit slower. Accordingly, make "fast" slower as well, and introduce a new preset "faster" between "fast" and "veryfast".
All presets "fast" and above will have MB-tree on.
Add a new option, --rc-lookahead, to control the distance MB tree looks ahead to perform propagation analysis.
Default is 40; larger values will be slower and require more memory but give more accurate results.
This value will be used in the future to control ratecontrol lookahead (VBV).
Add a new option, --no-psy, to disable all psy optimizations that don't improve PSNR or SSIM.
This disables psy-RD/trellis, but also other more subtle internal psy optimizations that can't be controlled directly via external parameters.
Quality improvement from MB-tree is about 2-70% depending on content.
Strength of MB-tree adjustments can be tweaked using qcompress; higher values mean lower MB-tree strength.
Note that MB-tree may perform slightly suboptimally on fades; this will be fixed by weighted prediction, which is coming soon.

Jeeb's build is from september so looks like I can use both! :)
But it looks like it's on by default, so I already have been using it, with default lookahead settings. Don't remember seeing a separate statsfile hanging around, though.

Dark Shikari

1st November 2009, 19:54

There are NAL-HRD patches for newer x264s. You should avoid using old versions of MB-tree as there were a lot of early bugs (read: at least 1-2 dozen) that we have fixed since.

Redsandro

1st November 2009, 20:00

Ah yes, HRD was it, my television likes that. I will check them out. But honestly I used MeGUI to construct a command line for my scripts and I thought whoever supervises the package updates probably has a compatibility reason for making included x264.exe choises. There were regular updates but x264.exe hasn't been updated since that november version.

I guess I can grab a new patched version with better MBtree implementation. I could at the same time get the 64 bit version to push the lookahead farther.

Dark Shikari

1st November 2009, 20:12

Ah yes, HRD was it, my television likes that. I will check them out. But honestly I used MeGUI to construct a command line for my scripts and I thought whoever supervises the package updates probably has a compatibility reason for making included x264.exe choises. There were regular updates but x264.exe hasn't been updated since that november version.What? MeGUI has autoupdates for the latest x264. Let me guess, you're using that broken 1051 version that never gets updated because the autoupdate server is broken? :rolleyes:

Redsandro

1st November 2009, 20:15

Uuuuhhhhhh....

Yep. That's me. Looks like you're right..

In my own defense, I hardly ever start MeGUI, only occasionally to see if there's a newer x264 or some new profile settings I can steal. (I use scripts for encoding but I just like the way MeGUI conveniently updates stuff.)
Thanks for pointing it out, :P I will manually update now.

Digital Corpus

4th November 2009, 20:20

ajp_anton

4th November 2009, 20:35

I'm using x264 through mencoder. I'm currently on v1301. I'm having problems with my two pass encodings failing due to mbtree. Should I post what is going on or upgrade to the latest and try again to see if the same thing happens?Since you're not posting what's "going on", you're assuming the devs already know about the problem, which means it's most likely already fixed in the latest version. Why don't you try it?

LoRd_MuldeR

4th November 2009, 20:38

Digital Corpus, most important you should try to use x264 directly, not through MEncoder. If it works okay then, there must be a problem on MEncoder's side.

Also you didn't mention what problem with 2-Pass and MB-Tree you get in detail...

microchip8

4th November 2009, 20:51

@Digital Corpus

This is a MEncoder problem and one of my h264enc users also contacted me about this. I advise to switch in using crf if you can instead of 2-pass. It does not happen in crf mode (of course)

I set up the script the usual way; using '-2p -p vhq' preset, pretty much default all the way, nowdays I pick 'neroAAC' for audio and Matroska container.
Both movies encode fine until the very last frames, in the second pass, when I see

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
Pos: 0.9s 52f ( 0%) 6.92fps Trem: 0min 0mb A-V:0.083 [0:1536]
Skipping frame!
Pos:2515.1s 60334f (23%) 47.94fps Trem: 68min 3642mb A-V:0.082 [1318:1536]
Skipping frame!
ODML: Starting new RIFF chunk at 1023MB. 62min 3561mb A-V:0.024 [1290:1536]
ODML: Starting new RIFF chunk at 2047MB. 32min 3364mb A-V:0.058 [1233:1536]]
ODML: Starting new RIFF chunk at 3071MB. 0min 3074mb A-V:0.050 [1200:1536]
x264 [error]: Incomplete MB-tree stats file.min 3073mb A-V:0.035 [1200:1536]
x264_encoder_encode failed
Pos:9414.2s 225749f (99%) 47.17fps Trem: 0min 3073mb A-V:0.038 [1200:1536]
Flushing video frames.

Now the thing just hangs and if I Ctrl-C it, the mux gets corrupt. The second movie also complains on the last frames in the second pass, with a similar
error message from x264.

Dark Shikari

4th November 2009, 21:02

Such a failure can occur if the first and second pass don't have identical frames.

Redsandro

5th November 2009, 03:14

What? MeGUI has autoupdates for the latest x264. Let me guess, you're using that broken 1051 version that never gets updated because the autoupdate server is broken? :rolleyes:
Why isn't there a fixed version on sourceforge then? Even the latest unstable release doesn't update beyond the tools I already have. The update server is not broken, because it updates back when I revert to an even older version I have backed up.

Digital Corpus

5th November 2009, 08:36

Since you're not posting what's "going on", you're assuming the devs already know about the problem, which means it's most likely already fixed in the latest version. Why don't you try it?I know I didn't post detail making my post in itself a bit weak. I developed a corrupt ssh session in the terminal window I was using so I didn't have a chance to grab the output. Once I have a complete non-mbtree file encoded, I'll post the repetitive errors involving something with invalid motion vectors and attempting to fall back to a I frame, iirc.

Digital Corpus, most important you should try to use x264 directly, not through MEncoder. If it works okay then, there must be a problem on MEncoder's side.

Also you didn't mention what problem with 2-Pass and MB-Tree you get in detail...Also, I'm not familiar with using x264 directly when working with raw MPEG-2 transport streams that may have possible corruption (I get 99.9% reception). I know I can pass those through mencoder without an issue, but not x264. I haven't had time to test passing a YUV stream to x264 via a pipe yet either so if you guys could help on that, that would be cool.

@Digital Corpus

This is a MEncoder problem and one of my h264enc users also contacted me about this. I advise to switch in using crf if you can instead of 2-pass. It does not happen in crf mode (of course)Yeah I gathered that so from looking at the errors a little more closely earlier on. I'm concerned with first attempt getting finite bitrates/file sizes within about +/- 5%. I'm developing my server as kinda like a public DVR so I need to know how much space each recording and encoded copy will take up when it come to maintenance and judging capacity.

McArty

5th November 2009, 09:48

Why isn't there a fixed version on sourceforge then? Even the latest unstable release doesn't update beyond the tools I already have. The update server is not broken, because it updates back when I revert to an even older version I have backed up.

Take a look here:
http://forum.doom9.org/showthread.php?t=149383
Worked for me.

LoRd_MuldeR

5th November 2009, 10:40

Why isn't there a fixed version on sourceforge then? Even the latest unstable release doesn't update beyond the tools I already have. The update server is not broken, because it updates back when I revert to an even older version I have backed up.

Maybe the update server is still alive, but obviously nobody does update the files on the update server. So it's broken - in a way ;)

Digital Corpus

5th November 2009, 23:13

Okay, server kernel panicked last night so I had to redo the encoding to duplicate my bug. I have a 20Mbit up connection so if you wish to download any of the files below, my end usually isn't the bottleneck.

Terminal output:
http://pastebin.com/m517d6f30

Command used:
mencoder "~V~_11-03-2009_20-00-00.ts" -o /hdhr/demux/"V"/"~V~11-03-2009~720.avi" -aspect 16:9 -tskeepbroken -really-quiet \
-passlogfile /hdhr/demux/"V"/"V~11-03-2009~720.log" -ofps 30000/1001 -sws 9 -vf harddup,scale=1280:720 -ovc x264 -x264encopts \
bitrate=5500:frameref=5:me_range=16:level_idc=31:subq=6:threads=4:pass=2:nofast_pskip:nodct_decimate:keyint=300:keyint_min=15:\
mixed_refs:deblock=1,1:bframes=0:nob_adapt:cabac:qp_min=1:qp_max=51:qp_step=25:ratetol=25:qcomp=0.75:qblur=0.25:direct_pred=auto:\
partitions=all:8x8dct:me=umh:psy-rd=0.4,0.2:trellis=1:psnr:ssim -oac pcm -channels 2 -srate 48000
(I know that CRF is better than 2-pass, but I need to carefully portion disk space thus I use 2-pass. If any of the above can be optimized to be better, I'm all ears)

The two-pass log file is automatically deleted via my scripts. I'll re-run the encode if someone wants to have a look

mbtree file:
http://atlas.selfip.net/V~11-03-2009~720.log.mbtree (521MiB) (http://atlas.selfip.net/V~11-03-2009~720.log.mbtree)

Source:
http://atlas.selfip.net/~V~_11-03-2009_20-00-00.ts (~4.7GiB) (http://atlas.selfip.net/~V~_11-03-2009_20-00-00.ts)

Encoded file:
http://atlas.selfip.net/~V~11-03-2009~720.mov (863MiB) (http://atlas.selfip.net/~V~11-03-2009~720.mov)
Edit: I doubt this matters but despite .mov extension, this is a MP4Box created .mp4 container. The Xbox 360 is picky about extensions.

I pulled this from the .h264 file just to be on the safe side:
x264 - core 78 r1301M bcba15d

I'm going to go work on using mencoder with -tskeepbroken to pipe to x264 and see if this bug/problem happens again.

poisondeathray

10th November 2009, 19:12

As some may recall, there were issues with fades when using mbtree. The original source & post can be found here
post #167
http://forum.doom9.org/showthread.php?p=1312672

So I tested the weightp r1332 generic build from x264.nl

--preset slower --pass 2 --bitrate 1000
http://img338.imageshack.us/img338/8672/069slower.th.png (http://img338.imageshack.us/i/069slower.png/)

--preset slower --pass 2 --bitrate 1000 --no-mbtree --b-pyramid normal
http://img338.imageshack.us/img338/4034/069slowernombtreebpyram.th.png (http://img338.imageshack.us/i/069slowernombtreebpyram.png/)

To my eyes, not much has changed with the addition of weightp on this source. I suppose I should test mbtree with weightp disabled to see the difference that weightp (only) makes - but in regular use, my decision is usually mb-tree vs. no mb-tree with b-pyramid.

Yes, qualitatively, other frames are improved with mb-tree, but the trend seems to be fades are significantly worse. It's almost as if bitrate is redistributed from fades/low luminance frames to other frames

burfadel

10th November 2009, 19:29

poisondeathray

10th November 2009, 19:40

well, if you look at it objectively the --no-mbtree encoded are larger, in 2-pass mode this translates into higher quality with --no-mbtree disabled! In CRF mode, it means the ability to use a lower CRF (even if you use a decimal CRF), which again leads to a higher qulaity picture. I'm talking about the main part, not the fades!

Are you looking at the .png size? The coded frame size is higher without mbtree, so yes it should be larger. weightp was supposed to detect fades in improve those coded frame sizes... I think... but there was little to no improvement in the couple of sources I've tried so far.

mbtree can definitely be beneficial in some scenarios, but it almost always comes with signicantly worse fades and dark scenes. Perhaps the default --qcomp value isn't optimal, but increasing it will lower the mbtree effect, and basically we are back to square one. What i am seeing is a sort of "tradeoff." Some frames are improved at the expense of others. But the "expense" is quite severe in my opinion, at least with default qcomp. I'm looking for more balance.

Remember this is a bitrate constrained scenario @1000kbps, but "martinfrombern" did tests with varying bitrates, and the trend was still the same.
http://forum.doom9.org/showthread.php?p=1313104#post1313104

Also these are just some observations, so be careful to draw any firm conclusions yet

Dark Shikari

10th November 2009, 19:46

poisondeathray

10th November 2009, 19:51

What the hell do you want me to do, turn fade detection on all modes and lower the quantizers by 10 in every fade? :rolleyes:

I'm giving up; people won't be satisfied unless their fades look flawless even while the rest of the video looks like utter crap. And even then, they'll complain that 90% of the bitrate of the video is spent on the fade.

Relax DS, I'm not "complaining", I'm just providing some observations and feedback on this new weightp patched build... Is it possible something was wrong with the build?

In my opinion, mbtree with some settings is not suitable for some sources in some scenarios - but people can choose to use what ever settings they want to. :)

juGGaKNot

10th November 2009, 20:39

Maybe weightp + new normal b-pyramid :)

Betsy25

10th November 2009, 20:48

After the abysmal puzzle MeGUI has become to go searching for a trustable version, now also x264 joins this clan.

Happy encoding days for the end of the year....:rolleyes:

Inspector.Gadget

10th November 2009, 20:59

Boo hoo I don't know how to use search.

Fr4nz

10th November 2009, 20:59

After the abysmal puzzle MeGUI has become to go searching for a trustable version, now also x264 joins this clan.

Happy encoding days for the end of the year....:rolleyes:

Well, given that x264 is opensource, no one is paid for it and you didn't give any help in making it, I think a ban from this forum is a proper thing for you!

Betsy25

10th November 2009, 21:12

Well, given that x264 is opensource, no one is paid for it and you didn't give any help in making it, I think a ban from this forum is a proper thing for you!

Oh My ! A forum can sometimes also be used to vent a little.
There's nothing really wrong with that. Are you a communist ?

What my biggest gripe is, for 6 months this forums gets filled with thousands of posts of people trying to get MeGUI working, now the same thing is going on for some month regarding x264 ?

Are you going to ban all of them also ?

Perhaps a little sticky regarding the state of MeGUI and latest x264 releases would make it much easier for those serving nothing more that "Use the Search!".

A little addition to the toppost of the main MeGUI thread is not that much to be asked ?

Guest

10th November 2009, 21:24

Guys, stop the flame wars and stay on topic.

thewebchat

10th November 2009, 21:37

What the hell do you want me to do, turn fade detection on all modes and lower the quantizers by 10 in every fade? :rolleyes:

I'm giving up; people won't be satisfied unless their fades look flawless even while the rest of the video looks like utter crap. And even then, they'll complain that 90% of the bitrate of the video is spent on the fade.

How about a mode where every frame is visually indistinguishable from the source, regardless of however many bits this will cost. One of the things that bothers me with x264 is that no matter how high I drive the bitrate, some parts just tend to look Pretty Bad, and fades/dissolves are one of them.

LoRd_MuldeR

10th November 2009, 21:38

How about a mode where every frame is visually indistinguishable from the source, regardless of however many bits this will cost.

That mode exists for a long time:

--qp 0 :D

thewebchat

10th November 2009, 21:39

Visually indistinguishable is quite a bit different from mathematically, Lord_Mulder. What I'm talking about is some way to get even quality distribution over all frames, without doing something dumb like setting every frame to be IDR. This is probably not psychovisually optimal, but I'm sure someone somewhere cares about getting archival quality across all frames.

LoRd_MuldeR

10th November 2009, 21:43

Visually indistinguishable is quite a bit different from mathematically, Lord_Mulder.

Yeah. And as we all know, the perfect objective quality metric that 100% agrees with the HVS doesn't exist! So how do you want to define "visually lossless" in a computable way?

The best thing we have as a "constant quality" mode nowadays is x264's CRF mode. So if you want "visually lossless" quality, go and find the CRF value that looks lossless for your eyes.

And another remark: Take 10 random people and let them subjectively define "visually lossless" quality. You'll get 10 different results. So how should a computer program know ???

Sharc

10th November 2009, 22:07

How about a mode where every frame is visually indistinguishable from the source, regardless of however many bits this will cost. One of the things that bothers me with x264 is that no matter how high I drive the bitrate, some parts just tend to look Pretty Bad, and fades/dissolves are one of them.
A plain 1:1 copy will serve the purpose best, I guess ....:rolleyes:

Dark Shikari

10th November 2009, 22:29

Yeah. And as we all know, the perfect objective quality metric that 100% agrees with the HVS doesn't exist! So how do you want to define "visually lossless" in a computable way?

The best thing we have as a "constant quality" mode nowadays is x264's CRF mode. So if you want "visually lossless" quality, go and find the CRF value that looks lossless for your eyes.

And another remark: Take 10 random people and let them subjectively define "visually lossless" quality. You'll get 10 different results. So how should a computer program know ???
<pengvado> there's nothing wrong with a high level analysis of which areas are important. it's just that our strong AI isn't quite advanced enough to make it work :)
<Dark_Shikari> the thing is you don't only need an AI, you need a human-like AI, since you need to measure which areas a *human* would judge as important
<pengvado> oh right. we don't need an AI, we can just use the chained grad student strategy

juGGaKNot

10th November 2009, 22:52

<pengvado> there's nothing wrong with a high level analysis of which areas are important. it's just that our strong AI isn't quite advanced enough to make it work :)
<Dark_Shikari> the thing is you don't only need an AI, you need a human-like AI, since you need to measure which areas a *human* would judge as important
<pengvado> oh right. we don't need an AI, we can just use the chained grad student strategy

Old, old.

Disabled

10th November 2009, 22:52

... turn fade detection on all modes and lower the quantizers by 10 in every fade? :rolleyes:

Well... wouldn't it be possible to give us a switch that with weightp enabled allows us to increase quants for them, or disable/reduce the effect of mbtree for fades or something like that?
Or I remember you didn't want us to give 1000 switches nobody really understands, so wouldn't it be possible to tune the quants for fades per default now that fades are detected with weightp?

Dark Shikari

10th November 2009, 22:54

Well... wouldn't it be possible to give us a switch that with weightp enabled allows us to increase quants for them, or disable/reduce the effect of mbtree for fades or something like that?
Or I remember you didn't want us to give 1000 switches nobody really understands, so wouldn't it be possible to tune the quants for fades per default now that fades are detected with weightp?It already does that.

Weightp improves quality in fades by at least a few quantizers "worth" of quality. Then, Weightp is run in lookahead to change the macroblock costs for MB-tree, which then effectively lowers quantizers by 1-3. Further, if weightp isn't on, the former is still done, and in order to compensate for lack of weightp, the quantizer in fades is lowered by another 1-2.

LoRd_MuldeR

10th November 2009, 23:07

Well... wouldn't it be possible to give us a switch that with weightp enabled allows us to increase quants for them, or disable/reduce the effect of mbtree for fades or something like that?

Remember that lowering the quantizers in some places (e.g. fades) means raising the quantizers in other places. It's a trade-off!

(Assuming we don't want to increase the overall size. Of course we can always "buy" better quality by spending more bits. But that's not the point here, I think)

benwaggoner

11th November 2009, 00:06

Old, old.
If it worked for fractal compression...

poisondeathray

11th November 2009, 00:40

Weightp improves quality in fades by at least a few quantizers "worth" of quality. Then, Weightp is run in lookahead to change the macroblock costs for MB-tree, which then effectively lowers quantizers by 1-3. Further, if weightp isn't on, the former is still done, and in order to compensate for lack of weightp, the quantizer in fades is lowered by another 1-2.

In this particular example, weightp alone changed the frame quantizer from 24.80 (--weightp 0) to 24.31. Without mb-tree and using normal b-pyramid , the frame quantizer was 20.78. So the net change was 0.49 for weightp in this sample

I took the frame quantizers from ffdshow's osd - I don't know how accurate the values are - but they seem to correlate with the "quality" of the frame.

--preset slower --pass 2 --bitrate 1000
frame quantizer 24.31
http://i37.tinypic.com/6dra53.png

--preset slower --pass 2 --bitrate 1000 --weightp 0
frame quantizer 24.80
http://i33.tinypic.com/641168.png

--preset slower --pass 2 --bitrate 1000 --no-mbtree --b-pyramid normal
frame quantizer 20.78
http://i36.tinypic.com/a3igwk.png

And even at 3x the bitrate, although the reported frame quantizer is lower than the 1Mbps encode without mbtree, I think the without mbtree looks better on that frame. (For completeness, no mbtree at 3Mbps was included as well)

--preset slower --pass 2 --bitrate 3000
frame quantizer 19.15
http://i35.tinypic.com/vfib05.png

--preset slower --pass 2 --bitrate 3000 --no-mbtree --b-pyramid normal
frame quantizer 15.17
http://i36.tinypic.com/2nbdnxt.png

me7

11th November 2009, 01:01

poisondeathray

11th November 2009, 01:19

Does weightp have an effect on VBV-limited devices? I just did a few test encodes for my iPod touch 3G and noticed that weightp causes short freezes, can be a decoder bug too of course (Main Profile at Level 3.0, same settings apart from --weightp 0 and --weightp 2).

this is from the changelog, not sure if your device falls into that category ?

All weightp modes may cause minor breakage in non-compliant decoders that take shortcuts in deblocking reference frame checks.
"Smart" may cause serious breakage in non-compliant decoders that take shortcuts in handling of duplicate reference frames.

yuvi

11th November 2009, 03:10

A stab in the dark: try lowering the refs. My iPod touch 1g maxes at 6 at any resolution despite claiming to support baseline level 3.0, and weightp increases number of ref frames.

thewebchat

11th November 2009, 07:18

Yeah. And as we all know, the perfect objective quality metric that 100% agrees with the HVS doesn't exist! So how do you want to define "visually lossless" in a computable way?

The best thing we have as a "constant quality" mode nowadays is x264's CRF mode. So if you want "visually lossless" quality, go and find the CRF value that looks lossless for your eyes.

And another remark: Take 10 random people and let them subjectively define "visually lossless" quality. You'll get 10 different results. So how should a computer program know ???

The problem is that no matter how many bits you throw at it, with the current bit distribution, none of them go to the parts that look bad. Instead, you just end up wasting space and CPU making already transparent parts "more" transparent. For example, on a downscaled BD test I did, even at CRF14, there was significant degradation and ringing in dissolves and fades to/from white (with weightp), loss of grain/fine particle details, and banding. Now, I'm sure most people don't look at individual frames and compare them, but I think every encoder should be able to reach transparency within a few multiples of normal rates. Actually, maybe there's magic options that I should be tweaking, but I really am not an expert in x264.

Sharc

11th November 2009, 08:00

......even at CRF14, there was significant degradation and ringing in dissolves and fades to/from white (with weightp), loss of grain/fine particle details, and banding. Now, I'm sure most people don't look at individual frames and compare them, ....
For the discovery of banding one does actually not need to look at individual frames because bandig often spans many frames (e.g. flat, dark scenes). I agree that lowering the crf does not always help. Perhaps some 'adaptive' dithering of the source could help here? Just guessing, don't know if it is viable.