x264 development

[CruNcher]

MBAFF needs some more bits that's expected how much difference do you see ?

[aegisofrime]

Just to clarify, am I right to say that MBAFF is only useful for interlaced content? There's no reason to use it for pure progressive content?

[mp3dom]

Yes, MBAFF is only useful for interlaced material. Also if you have a video with huge parts of progressive material and only some slight interlaced parts (for example a progressive video with some interlaced fades or interlaced cross-dissolvences) PAFF is more appropriated.

[aegisofrime]

Yes, MBAFF is only useful for interlaced material. Also if you have a video with huge parts of progressive material and only some slight interlaced parts (for example a progressive video with some interlaced fades or interlaced cross-dissolvences) PAFF is more appropriated.

Thanks for the quick reply. I understand now :thanks:

[kieranrk]

Yes, MBAFF is only useful for interlaced material. Also if you have a video with huge parts of progressive material and only some slight interlaced parts (for example a progressive video with some interlaced fades or interlaced cross-dissolvences) PAFF is more appropriated.

You should let the encoder decide this for you. Any other ways will almost certainly be based on conjecture.

[Boulder]

MBAFF needs some more bits that's expected how much difference do you see ?Oh, I thought that it was more efficient so it would require less:p

[mp3dom]

You should let the encoder decide this for you. Any other ways will almost certainly be based on conjecture.
Are there 'known' examples of true progressive clips that can be encoded in a better way with MBAFF than true progressive?

[CruNcher]

Oh, I thought that it was more efficient so it would require less:p
It depends on the content if you use mainly interlaced content it should save bits but if you do mixed content it depends on different factors also on how well its optimized obviously :)

[sneaker_ger]

Are there 'known' examples of true progressive clips that can be encoded in a better way with MBAFF than true progressive?

He probably meant the decision between MBAFF and PAFF, not between progressive and MBAFF.

[kieranrk]

He probably meant the decision between MBAFF and PAFF, not between progressive and MBAFF.

Yes, exactly. The next step for x264 is to have PAFF and decide between MBAFF and PAFF.

[Mini-Me]

Holy crap! I've been following Simon Horlick's git respository, doom10, and DarkShikari's blog, and none of them gave any indication that MBAFF was actually DONE. (Well, I did just notice that the MBAFF commits were merged into the main branch a couple days ago. Maybe that was the hint. ;))

Was any kind of announcement made anywhere? Reading the last few pages of this thread is a bit bizarre, because it seems like all of a sudden it's common knowledge that it's done. Is it really finished, or is there some kind of catch (i.e. it's sort of working but buggy/unreliable/not as efficient as it will be)?

[Dark Shikari]

Read the development newsletters, they're good for you.

[Mini-Me]

Read the development newsletters, they're good for you.

I must be looking in the wrong place, because the newest one I had seen was Volume 12 from February. Now that you brought it up, I just ran a search and found Volume 16 here (http://mailman.videolan.org/pipermail/x264-devel/2011-May/008508.html). Is there anywhere the newsletters are regularly announced, or do I just need to scan the mailing list archives for them?

[Dark Shikari]

Is there anywhere the newsletters are regularly announcedEr... the mailing list? Where they're sent out?

[ckmox]

any news on the audio encoding support of x264? is it still alive? what audio formats are gonna be included?

[sneaker_ger]

You can always get a patched build from http://x264.fushizen.eu. No idea about it getting committed, though.

[ckmox]

i hope it gets committed it will be awesome to see x264 having audio support, and i check JEEB's patches too although its glitchy when encoding at low bitrates

[burfadel]

How is the work going on psy-rd v2? still coming along, scrapped?

[laserfan]

Read the development newsletters, they're good for you.[x264-devel] x264 Development Newsletter: Vol 16 (MBAFF edition!)
Jason Garrett-Glaser jason at x264.com
Thu May 12 08:41:23 CEST 2011
...

Improvements:

MBAFF support is now in! Typical compression improvement is around
15% for an ordinary 1080i HDTV source.I'd just finished one of these using 1936 --tff so I did it again with 1995, and saw a 15% increase in speed for my 2-pass project, at least in one of the episodes (others as low as 6%).

Dunno how to determine "compression improvement" but visually it looked the same (or better i.e. how to improve on perfect?) so I'm very happy with it.

[Mini-Me]

Er... the mailing list? Where they're sent out?

I guess I was asking if they were announced anywhere that sets them apart from a sea of commits. ;)

[Lyris]

Just to satisfy my (justified) disc replication paranoia: the introduction of MBAFF doesn't do anything to break Blu-ray compliance, does it?

[kieranrk]

Just to satisfy my (justified) disc replication paranoia: the introduction of MBAFF doesn't do anything to break Blu-ray compliance, does it?

No it does not.

[Dark Shikari]

There might be bugs in the new x264 due to all the changes, which is why I recommend using the stable revision for anything mission-critical, but "supporting MBAFF" in and of itself is not a compliance issue.

[LigH]

I am not sure how much it says, and if these results are at all useful ... I just ran a quick test with revisions 1913 (used in the TechARP x264 bench 4.0 HD) and 1995 (currently available in MeGUI), simply a "x264.exe --crf 18 [--tff] -o *.264 *.avs", comparing the ten PAL snippets of the VQEG video test set. Looks like my expectations about the efficiency of MBAFF were a little wrong? Or where is the mistake in my assumptions?

The table lists file sizes in MiB.

VQEG src r1913 P r1913 I r1995 P r1995 I content description
01 0.30 0.31 0.30 0.30 Tree: still
02 12.26 13.52 12.26 12.45 Event: slow zoom-out; interlaced
03 10.21 8.82 10.21 10.07 Harp: slow zoom-in and regional motion; interlaced
04 2.18 2.43 2.18 2.18 Ant: CGI motion and vertical scrolling; interlaced
05 8.09 6.61 8.09 7.29 Kayak: heavy motion; interlaced
06 12.05 8.49 12.05 9.24 F1GP: heavy motion; interlaced
07 5.52 5.75 5.52 5.66 Fastfood: heavy motion + noise; progressive
08 3.06 2.68 3.06 3.01 Text: horizontal scrolling + background; interlaced
09 11.89 8.79 11.89 9.88 Rugby: heavy, unsteady motion; interlaced
10 8.65 8.29 8.65 8.80 Train: little, mainly steady motion; interlaced

P.S.:

r19xx P = progressive encoding mode
r19xx I = interlaced encoding mode (with "--tff")

[Dark Shikari]

You didn't keep quality constant. Constant CRF over multiple different revisions and prog vs interlaced isn't constant quality. Try at least keeping constant PSNR.

[Boulder]

How to adjust things compared to the situation without MBAFF, is it simply time to tweak CRF to taste when it comes to interlaced encoding?

[LigH]

Maybe not exactly what you said, but a bit closer, with --qp 18 instead of --crf 18 this time.

Now that looks more like success: As small as progressive encoding for mainly/nearly progressive content; only a little bigger than always-interlaced for clearly interlaced content.

VQEG src r1913 P r1913 I r1995 P r1995 I content description
01 0.32 0.34 0.32 0.32 Tree: still
02 22.96 25.48 22.96 22.94 Event: slow zoom-out, interlaced
03 18.49 17.52 18.49 17.90 Harp: slow zoom-in and regional motion, interlaced
04 3.49 3.94 3.49 3.41 Ant: CGI motion and vertical scrolling, interlaced
05 14.92 13.08 14.92 13.33 Kayak: heavy motion, interlaced
06 23.10 18.43 23.10 19.02 F1GP: heavy motion, interlaced
07 11.28 13.53 11.28 11.30 Fastfood: heavy motion + noise, progressive
08 6.09 5.69 6.09 5.67 Text: horizontal scrolling + background, interlaced
09 22.56 18.29 22.56 19.03 Rugby: heavy, unsteady motion, interlaced
10 16.54 17.11 16.54 16.49 Train: little, mainly steady motion, interlaced

Sum 139.76 133.42 139.76 129.41

If you have suggestions for different parameters, just tell me.

[Manao]

LigH : at least, print both PSNR difference and bitrate ratio. Bitrate ratio alone is meaningless. Or do as Dark_Shikari said and keep either bitrate or PSNR constant

[LigH]

If there is no way to have x264 encode with a fixed PSNR ratio, then I would have to keep the bitrate constant, which means that I have to encode in 2-pass mode and compare PSNR ratios afterwards. But that's not a "lunch-break job" anymore...
__

Concatenated VQEG PAL clips 01-10 and ran a 2-pass encode with 2000 kbps.

r1913 P: PSNR Mean Y:34.149 U:38.783 V:39.076 Avg:35.130 Global:34.351 kb/s:1994.17
r1913 I: PSNR Mean Y:34.496 U:38.723 V:38.984 Avg:35.418 Global:34.698 kb/s:1988.28
r1995 P: PSNR Mean Y:34.154 U:38.785 V:39.077 Avg:35.135 Global:34.356 kb/s:1994.40
r1995 I: PSNR Mean Y:34.891 U:39.276 V:39.589 Avg:35.839 Global:35.080 kb/s:1993.04
__

And because I was warned that the results would be invalid, again with "--tune psnr":

r1913 P: PSNR Mean Y:34.697 U:38.270 V:38.562 Avg:35.455 Global:34.748 kb/s:1989.88
r1913 I: PSNR Mean Y:34.960 U:38.108 V:38.401 Avg:35.642 Global:34.963 kb/s:1987.15
r1995 P: PSNR Mean Y:34.705 U:38.274 V:38.571 Avg:35.462 Global:34.754 kb/s:1989.69
r1995 I: PSNR Mean Y:35.414 U:38.689 V:39.014 Avg:36.125 Global:35.424 kb/s:1993.67

I'll relinquish the interpretation to you.

[Sagittaire]

MBAFF increase 0.6 dB for the same bitrate. Here it's certainely something like 10% gain for quality efficiency. Anyway 35 dB are really poor quality I think. Better to try with more usefull quality. Choose crf at 20 for your bitrate target reference and make encoding test for the 2 pass with this bitrate.

[IgorC]

It will be more interesting to see ssim results rather than psnr.

[Manao]

It will be more interesting to see ssim results rather than psnr. Or not. I don't really trust that much SSIM, so SSIM on interlaced content ? At least, PSNR doesn't care about the fact that the content is interlaced or progressive.

[LoRd_MuldeR]

Or not. I don't really trust that much SSIM, so SSIM on interlaced content ? At least, PSNR doesn't care about the fact that the content is interlaced or progressive.

For interlaced video, does x264 apply SSIM onto weaved frames consisting of two fields or on each field separately?

[LigH]

Choose crf at 20 for your bitrate target reference and make encoding test for the 2 pass with this bitrate.

http://www.cosmosfactory.org/images/aol/rocky/aol_riff3.jpg As you wish, master... ;)

7000 kbps this time. FRF from 1st pass, SSIM + PSNR from 2nd pass.

r1913 P: final ratefactor: 20.08 | SSIM Mean Y:0.9732868 (15.733db) | PSNR Mean Y:41.500 U:43.317 V:43.768 Avg:41.973 Global:40.733 kb/s:6986.16
r1913 I: final ratefactor: 19.64 | SSIM Mean Y:0.9743073 (15.902db) | PSNR Mean Y:41.769 U:43.451 V:43.878 Avg:42.211 Global:40.888 kb/s:6981.45
r1995 P: final ratefactor: 20.08 | SSIM Mean Y:0.9732895 (15.733db) | PSNR Mean Y:41.499 U:43.319 V:43.768 Avg:41.972 Global:40.732 kb/s:6985.28
r1995 I: final ratefactor: 19.43 | SSIM Mean Y:0.9759900 (16.196db) | PSNR Mean Y:42.089 U:43.864 V:44.323 Avg:42.554 Global:41.270 kb/s:6986.44

All runs with "--tune psnr"; you cannot tune for both PSNR and SSIM optimization at the same time (--aq-mode 0 vs. 2).

[CruNcher]

http://www.cosmosfactory.org/images/aol/rocky/aol_riff3.jpg As you wish, master... ;)

7000 kbps this time. FRF from 1st pass, SSIM + PSNR from 2nd pass.

r1913 P: final ratefactor: 20.08 | SSIM Mean Y:0.9732868 (15.733db) | PSNR Mean Y:41.500 U:43.317 V:43.768 Avg:41.973 Global:40.733 kb/s:6986.16
r1913 I: final ratefactor: 19.64 | SSIM Mean Y:0.9743073 (15.902db) | PSNR Mean Y:41.769 U:43.451 V:43.878 Avg:42.211 Global:40.888 kb/s:6981.45
r1995 P: final ratefactor: 20.08 | SSIM Mean Y:0.9732895 (15.733db) | PSNR Mean Y:41.499 U:43.319 V:43.768 Avg:41.972 Global:40.732 kb/s:6985.28
r1995 I: final ratefactor: 19.43 | SSIM Mean Y:0.9759900 (16.196db) | PSNR Mean Y:42.089 U:43.864 V:44.323 Avg:42.554 Global:41.270 kb/s:6986.44

All runs with "--tune psnr"; you cannot tune for both PSNR and SSIM optimization at the same time (--aq-mode 0 vs. 2).

looks good so far on paper :) what about the code complexity factor aka speed difference would be nice if you would include that too :)

[Sagittaire]

Good improvement but not 15% here like say the patch note. Perhaps that 15% is for more "realistic source" like movie or TV interlaced source.

15% for gain efficiency is enormous. For comparison difference between MPEG4 ASP and MPEG4 AVC for progressive source is something like 25%.

[LigH]

Of course, the VQEG test set contains academic samples. Realistic samples are *YOUR* task now (to anyone who reads here). ;)

[Didée]

What makes me wonder with your latest (2-pass) test is that there is some (small) improvement on the I frames, but basically no change at all on the P frames. (?!?)

[cyberbeing]

I was under the impression LigH did four tests. Is this wrong?

r1913 (P = Progressive)
r1913 (I = Regular Interlacing)
r1995 (P = Progressive)
r1995 (I = MBAFF Interlacing)

[LigH]

Oh darn, that's the detail I forgot to document ... you are perfectly right, cyberbeing. Sorry.

I compared the encoding of partially combed content between progressive encoding and interlaced encoding mode, not I-frames with P-frames.

[Didée]

(P = Progressive)
(I = Regular Interlacing)

Oh, of course!:o - I feel a little stupid now. :D

[kypec]

I feel a little stupid now. :D
Please don't. To err is human and we all been there few times :p

[IgorC]

For comparison difference between MPEG4 ASP and MPEG4 AVC for progressive source is something like 25%.
Depends of the bitrate. And it is still more safe to check the quality visually.

The difference between H.264 and ASP can be much more than >25%. Visually x264 is near twice or really twice (with highest possible quality preset) better than Xvid at low and middle bitrates where the quality is already great.

Metrics tell the same. It is worth to check the last MSU reports (especially subjective part).

[Sagittaire]

Depends of the bitrate. And it is still more safe to check the quality visually.

The difference between H.264 and ASP can be much more than >25%. Visually x264 is near twice or really twice (with highest possible quality preset) better than Xvid at low and middle bitrates where the quality is already great.

Metrics tell the same. It is worth to check the last MSU reports (especially subjective part).

Well it's not the case for metric. AVC at 500 Kbps don't produce same quality than ASP at 1000 Kbps (for metric or visual quality). 50% gain it's for comparison for MPEG2 and H264.

Anyway % is relative. If H264 is your reference then it's 100% for MPEG2 improvement. If MPEG2 is your reference then it's 50% for H264 improvement. MSU use certainely best H264 reference for have more spectacular result. Anyway the reality is like that: if you want reproduce MPEG2 quality at 1500 Kbps, you must use ASP at 1000 Kbps and AVC at 700-750 Kbps.

[IgorC]

AVC at 500 Kbps don't produce same quality than ASP at 1000 Kbps (for metric or visual quality).
Says who?

[Dark Shikari]

Well it's not the case for metric. AVC at 500 Kbps don't produce same quality than ASP at 1000 Kbps (for metric or visual quality)Actually, that's exactly what the MSU tests show, using SSIM.*

*Note this is partially because x264 is a much better encoder than Xvid, not merely because AVC is better than ASP. But there never was an x264-class ASP encoder.

[nurbs]

Do you know when the new MSU test will be published? It still says May 12th on their page.

[Sagittaire]

Actually, that's exactly what the MSU tests show, using SSIM.*

*Note this is partially because x264 is a much better encoder than Xvid, not merely because AVC is better than ASP. But there never was an x264-class ASP encoder.

You are sure?

MSU say 40% in really best case (for Y-SSIM).

[nm]

You are sure?

MSU say 40% in really best case (for Y-SSIM).

Or slighly more with high quality presets. And that's just SSIM -- x264 also has better psy optimizations than current ASP encoders.

[LigH]

7000 kbps again, but this time a slightly longer video (3235 frames @ 25.0 fps = 2:09.4 min), taken with a rather low-quality HD Cam, anamorphic 1440x1080i.

Content: Zooming and panning around a woodworking machine, sometimes with flying wood shavings and moving grippers

I will upload the original later, because FFMS2 is unable to decode that correctly, the video jumps forth-and-back... tests were run using DGAVCDec. | 96.5 MB (http://www.holzon.de/PRIVAT/holzon_k2.m2ts)

r1913 P: final ratefactor: 17.62 | SSIM Mean Y:0.9677229 (14.911db) | PSNR Mean Y:43.647 U:49.150 V:49.665 Avg:44.835 Global:44.680 kb/s:7031.11 | 13.04 fps
r1913 I: final ratefactor: 16.90 | SSIM Mean Y:0.9747748 (15.982db) | PSNR Mean Y:44.853 U:50.153 V:50.603 Avg:46.030 Global:45.902 kb/s:7013.13 | 8.84 fps
r1995 P: final ratefactor: 17.62 | SSIM Mean Y:0.9677235 (14.911db) | PSNR Mean Y:43.648 U:49.151 V:49.663 Avg:44.836 Global:44.680 kb/s:7031.35 | 13.10 fps
r1995 I: final ratefactor: 17.14 | SSIM Mean Y:0.9723570 (15.584db) | PSNR Mean Y:44.387 U:49.944 V:50.474 Avg:45.599 Global:45.455 kb/s:7031.06 | 9.95 fps

x264 revisions 1913 (TechARP HD Bench 4.0) and 1995 (currently available in MeGUI); "P" = progressive, "I" = interlaced (--tff); FRF from 1st pass, SSIM + PSNR + fps from 2nd pass. All runs with "--tune psnr".

If you know any public sources of high-quality interlaced SD/HD "compression benchmark" videos, please link them for me. :thanks: