What does a state of the art sample look like?

[gronne]

I'm really a newbie in this and I don't understand what hardly any of the settings one can choose does. So I was wondering if some of you guys could upload clips that really shows what's the state of the art in x264 today! You guys seem to understand all the settings and what effects they have, so I'm just eager to see some examples of the quality nowadays. Or maybe there hasn't happened much lately?

[Danisan]

How about this one? It's shows what x264 can do with a low bitrate.

http://www.flashvideofactory.com/test/DEMO720_Heima_H264_500K.html

It was done by this dude, Fabio Sonnati (http://www.progettosinergia.com/flashvideo/flashvideoblog.htm).

[@MeGui]

What are the settings for it?

[Dark Shikari]

Here's one at 1.7 megabit (http://mirror05.x264.nl/Dark/Flash/index_lowbitrate.html). Other encoders tend to fail miserably (http://mirror05.x264.nl/Dark/x264vsElecard/) at this one, even in the H.264 scene.

[*.mp4 guy]

X264 does so well on Touhou, and indeed, anime, and video games in general because of Trellis+AQ, put together you get better looking lines and backgrounds on sources like that. X264 also has more aggressive default deadzones then, for example, Xvid mpeg4-ASP encoder, and Ateme mpeg4-AVC encoder, which helps it perform very well on the perfectly clean, perfectly sharp content in both of the examples here. Of course any example of state of the art video encoding is going to utilize amazingly perfect sources, because they make an absolutley Huge difference in the final quality of the encode.

Its very impressive what a state-of-the-art encoder like X264 can accomplish given the right conditions, unfortunately, other types of content can really dampen the performance. Personally I'm more interested in what can be done with pathalogically dificult sources, which often require significantly different settings to look good. Of course a dificult source is never going to look as good as an easy source, even when large anounts of bitrate are thrown at it, so they never get used in codec demos.

[Dark Shikari]

X264 does so well on TouhouOther reasons it does so well on Touhou:

1. Artificially raising keyint to 600 (reasonable, given its a 60fps video).
2. Artificially raising ipratio to 2.5 (makes the interface very sharp and generally helps quality). I notice that in twopass mode Elecard also raises the ipratio on some clips, so I suspect they have a heuristic for this rather than a set offset.
3. Extremely large number of reference frames (there are a number of extremely complex scenes where the bit cost is nearly zero because of multiref).
4. p4x4 (almost no other encoders have this).

[*.mp4 guy]

Other reasons it does so well on Touhou:

1. Artificially raising keyint to 600 (reasonable, given its a 60fps video).
2. Artificially raising ipratio to 2.5 (makes the interface very sharp and generally helps quality). I notice that in twopass mode Elecard also raises the ipratio on some clips, so I suspect they have a heuristic for this rather than a set offset.
3. Extremely large number of reference frames (there are a number of extremely complex scenes where the bit cost is nearly zero because of multiref).
4. p4x4 (almost no other encoders have this).

I really woundn't have expected 2 and 4, though 1 and 3 are quite standard for this sort of thing. I have to say that 4 surprises me the most, isn't p4x4 required for profiles that don't support the 8x8 transform? Also, wound't B-pyramid with a very high number of b-frames be quite an edge, or is that a common encoder feature?

[Dark Shikari]

I really woundn't have expected 2 and 4, though 1 and 3 are quite standard for this sort of thing. I have to say that 4 surprises me the most, isn't p4x4 required for profiles that don't support the 8x8 transform? Also, wound't B-pyramid with a very high number of b-frames be quite an edge, or is that a common encoder feature?2 helps because of the very large portion of the frame that is static, and because there are so many P-blocks (so basing stuff on the high-quality I-frame helps future frames a lot).

p4x4 isn't used by any encoder I've seen other than x264.

More B-frames than 1 doesn't seem to be particularly useful on the Touhou clip from what I recall.

[unskinnyboy]

p4x4 isn't used by any encoder I've seen other than x264.Probably because it's nearly useless for practical purposes.

p4x4 doesn't hurt, it just doesn't help. At large resolutions, individual objects in the movie are bigger than 4x4 pixels, so there's no point in partitioning mvs that small. Typically it might be enabled in 0.5% of macroblocks, and improve compression by 0.1%, making it one of the worst compression-per-cpu tradeoffs.

Based on the above, I can't really see how p4x4 has really helped here - except maybe by a very negligible amount?

[Dark Shikari]

Probably because it's nearly useless for practical purposes.Its generally mildly useful at very high bitrates, low resolutions, or both.

Based on the above, I can't really see how p4x4 has really helped here - except maybe by a very negligible amount?If you look at the stream, especially the "high quality" Touhou stream, you'll notice a huge number of p4x4 blocks due to the very complex small-scale motion patterns of the bullets. p4x4 also helps deal with the problem of the bullets overlapping.

[unskinnyboy]

Its generally mildly useful at very high bitrates, low resolutions, or both.That's been my understanding too, which is why I said p4x4 is useless for practical purposes, namely SD, which is neither very high bitrate nor low resolution. Also, from akupenguin's explanation which I quoted above, I understand why p4x4 is useless at high resolutions. But, what about very high bitrates? How does p4x4 help there?

If you look at the stream, especially the "high quality" Touhou stream, you'll notice a huge number of p4x4 blocks due to the very complex small-scale motion patterns of the bullets. p4x4 also helps deal with the problem of the bullets overlapping.Would Elecard StreamAnalyzer show this, or must I get ldecod.trace? Where do I get hold of ldecod.trace anyway? I've been after it for a while now.

[Dark Shikari]

That's been my understanding too, which is why I said p4x4 is useless for practical purposes, namely SD, which is neither very high bitrate nor low resolution."Low resolution" in this case is defined by the size of objects in the video, not the resolution itself. So a very low-resolution video might not get much benefit from p4x4 if it has only large objects, or a higher-resolution clip might if its objects are very small.
But, what about very high bitrates? How does p4x4 help there?If you throw more bitrate at a source, it becomes worthwhile to spend more bits on MVs. Past a certain point, this reaches the "p4x4 gets used" level.
Would Elecard StreamAnalyzer show this, or must I get ldecod.trace? Where do I get hold of ldecod.trace anyway? I've been after it for a while now.Streameye is sufficient. Ldecod.trace is simple; just download the JM reference (enc|dec)oder, grab the trace diff from Akupenguin's website (http://akuvian.org/src/x264/), and compile with trace on.

[Japhsoncross]

I am doing some game video (Arcade games, such as FTG & STG) tests recently.
I am surprised by the point 2 which DS mentions.
But after some tests, I find that it did help.
I got SSIM 0.9347741 with ipratio 2.5, while the default setting gives 0.9271689 at the same bitrate.
With ipratio at 3.5 SSIM goes up to 0.9363673.

I also find esa helps alot on such source.

@DS,
How do you capture 640x480@60fps losslessly? Is the captured format RGB32, or YV12?
I capture with HyperCam2, 384x224(or 304x224)@60fps, RGB32 lossless compressed to the Ramdisk (700MB/s bandwith), but I don't think I can capture 640x480@60 losslessly.

[Dark Shikari]

@DS,
How do you capture 640x480@60fps losslessly? Is the captured format RGB32, or YV12?
I capture with HyperCam2, 384x224(or 304x224)@60fps, RGB32 lossless compressed to the Ramdisk (700MB/s bandwith), but I don't think I can capture 640x480@60 losslessly.FRAPS. :p

Fortunately, Touhou is a DirectX game, so you can use FRAPS on it. Of course, it seems that at least on my machine I can't record at 60FPS realtime; fortunately, FRAPS locks the game to its recording speed, so it records the replays correctly so they can be played back at 60FPS. I suspect this is an issue with the game engine, since I can capture 30FPS 1680x1050 just fine in EVE Online. You can do the same on Vista with FRAPS for any 2D game from what I've heard because of Aero's overlay.

Have you tried recording in HuffYUV instead of uncompressed?

[Japhsoncross]

OK, I will try with FRAPS :)
The last time I tried with HuffYUV (probably 1 year or 2 ago), IIRC, it crashed.
YV12 doesn't seems to do a good job with this kind of source, it omits a lot, especially with red/blue single pixel sized grid, though x264 only supports YV12.

[unskinnyboy]

"Low resolution" in this case is defined by the size of objects in the video, not the resolution itself. So a very low-resolution video might not get much benefit from p4x4 if it has only large objects, or a higher-resolution clip might if its objects are very small.Ah, makes sense now. I misunderstood the meaning of "resolution" earlier. Thanks.
If you throw more bitrate at a source, it becomes worthwhile to spend more bits on MVs. Past a certain point, this reaches the "p4x4 gets used" level.Understood. Thanks.
Streameye is sufficient.Which flag though? I have been looking at the specs and trying to correlate it with the parse output, but no go. For example, this is how the first P-slice looks like:
0x00006B49 P slice # 1
first_mb_in_slice = 0
slice_type = 5
pic_parameter_set_id = 0
frame_num = 1
field_pic_flag = 0
pic_order_cnt_lsb = 10
num_ref_idx_active_override_flag = 1
num_ref_idx_L0_active_minus1 = 0
ref_pic_list_reordering():
ref_pic_list_reordering_flag_l0 = 0
dec_ref_pic_marking():
adaptive_ref_pic_marking_mode_flag = 0
cabac_init_idc = 0
slice_qp_delta = -4
disable_deblocking_filter_idc = 0
slice_alpha_c0_offset_div2 = 0
slice_beta_offset_div2 = 0
How do I make out if p4x4 was used in this slice (if it was used, that is)?

[Dark Shikari]

How do I make out if p4x4 was used in this slice (if it was used, that is)?There is no flag. Look at the partitions in the frame with your eyes.

[unskinnyboy]

There is no flag. Look at the partitions in the frame with your eyes.Hmm, this maybe a stupid question and I must be missing something obvious, but how do I see the partitions in the frames with my eyes? Which tool would I load into, which would show me the partitions?

[Dark Shikari]

Hmm, this maybe a stupid question and I must be missing something obvious, but how do I see the partitions in the frames with my eyes? Which tool would I load into, which would show me the partitions?http://img228.imageshack.us/img228/587/p4x4wv0.png

Streameye is your friend.

[unskinnyboy]

Gotcha! I hadn't realized that earlier you had said StreamEye. I was trying to see this in StreamAnalyzer, and of course wasn't getting anywhere with it. :thanks:

[Inventive Software]

http://img228.imageshack.us/img228/587/p4x4wv0.png

Streameye is your friend.

Looks like Pacman! :D

[Comatose]

Is there somewhere I can read about the X264 options, and possibly be given a scenario where it would be most beneficial to use them? :3

[J_Darnley]

Do you mean something more than x264 --longhelp ? Try: http://ffmpeg.x264.googlepages.com/mapping

[Comatose]

Yes! That's awesome. longhelp says what each setting is, but it doesn't actually explain what exactly they do.
Thanks :)