high quality mpeg-2 encoding

[poisondeathray]

Sounds good to me. How did you get a test chart that fits? or did you just resize it?

[jagabo]

I just resized the test chart along with the rest. I don't think we really care about the resolution portion of the test chart. I'm mostly interested in levels and colors shifts since a lot of people claim (incorrectly in my opinion) that various codecs screw up the levels and colors. If you prefer I can crop instead. It only takes a minute or two.

[poisondeathray]

It's up to you

I run that test chart workflow test often - especially on NLE's which usually do RGB conversions; I learned that trick from you and edDV!

And I agree, the levels coversions and color shifts are usually user error, or playback/setup issues

[jagabo]

OK, here's the vote clip as a 960-x544 Lagarith YV12 file:
http://www.sendspace.com/file/zpdsi6

I decided to go with YV12 instead of YUY2 since all the high compression codecs us YV12 internally. And the file is a little smaller, 123 MB.

Everyone happy with that?

[poisondeathray]

Thanks for doing that jagabo

Do we assume rec709 for this?

[jagabo]

Thanks for doing that jagabo

Do we assume rec709 for this?

Yes. The original MPEG 2 file did not indicate the decoding matrix but HD MPEG 2 is normally rec709. And I thought rec709 looked more accurate. So I assumed rec709 when I made the chart.

[deadrats]

OK, here's the vote clip as a 960-x544 Lagarith YV12 file:
http://www.sendspace.com/file/zpdsi6

I decided to go with YV12 instead of YUY2 since all the high compression codecs us YV12 internally. And the file is a little smaller, 123 MB.

Everyone happy with that?

awesome, thanks, downloading it now, will be doing a wide variety of encodes, i'll stick with 3000 kb/s, no resizing and upping the resulting encodes.

i'm going to go out on a limb here and say that xvid using the hi def profile will prove to give the best results.

just for kicks i'll also do a vc-1 encode and possibly a real media 10 encode as well...

edit: ok, don't know what's wrong but vlc says that it doesn't support the LAGS format, media player classic just hangs when trying to play the file, tmpg express 4 says that there is no video or audio data, mpeg streamclip pretends to open it, shows only a white screen when i try and preview the file, says there's no audio data, says that it has a bit rate of 33.30 Mbps but when i try to encode it i get a file 283 kb with no audio or video data, avs video converter says it can't open it because the acm video codec is not installed but googling acm video codec just brings up references to audio codecs, and avidemux "opens" the files but all it shows is a green background.

i have the latest ffdshow set to decode all audio and video formats, so i'm at a lose to explain what the problem is, any ideas?

[jagabo]

VLC doesn't used installed codecs and it doesn't include a Lagarith decoder so it can't play the file. For all the other programs you can install the Lagarith codec. ffdshow doesn't include Lagarith either.

xvid using the hi def profile will prove to give the best results

Note that Xvid's profiles only set limits on what features and settings you can use. They don't specify any particular settings.

[poisondeathray]

Another thing I don't like about trailers is the quick shots. It's hard to see anything with 1/2 second long shots, except for loss of details in still frames. But with still frames you miss the creepy crawly posterization artifacts that can only be seen in animated shots.

Yep that's a good point. The trailers usually have quick scene changes so you have a disproportionate amont of I-Frames. These shorter sequences are usually not representative of the entire movie. Encoders who have heavy weighting on I-frames, or that cannot adapt IP ratios (either manually or adaptively) will suffer. The benefit of using trailers is they are a tougher test for the encoder for those exact reasons, and they usually have more action & motion which require more bitrate.

It looks like the appended test chart has TV levels , was this done on purpose (not that it really matters, we're just interested in changes from the original, correct)?

Given the medium quality and dimensions of the clip , I don't think there's anything major that will separate these encodes at the selected bitrate; but I disagree with deadrats - I seriously doubt xvid will look the best

[minidv2dvd]

I've actually gotten some great encodes from CCE at 4000kbps or less, but they were low complexity video clips - you won't get such results for all. If you really want to flirt with bitrates that low you are better off with H.264. However, if you want a BD profile that works well with SD, good luck with x264 - issues with interlacing, pulldown, etc. I've spent way too much time testing this only to go back to MPEG-2 for BD playback at SD.
manono wrote:
... but if you care at all about quality use multi-pass VBR encoding. Either that or go for 1-pass quantizer encodes, but then you'll lose all control over the final file size.
I'm assuming you're using CCE? I agree with VBR. Using 1-pass Q does give very good results too, but I've noticed, with my eyes at least, plugging that same exact resulting bitrate you got from Q into a VBR encode afterwards and, with maybe 3 passes or so, re-encoding that same source gives better results on the more complex scenes.

I don't find CCE's Q as good a scheme as similarly with DivX, Xvid or x264 which do use one pass very effectively. (Or maybe it's an MPEG-2 thing in general, don't know.)

If you're using certain Q-specific settings for CCE that achieve results just as good as VBR (at similar bitrate) I'd love to know. I love one-pass and don't care for the no-control final bitrate if the results are optimal to the quality I ask for.

cce is hard to beat. for anything other than 8000kbps cbr, i use 3-5 passes vbr. in olden svcd days that was 7-9 passes to squeeze the most from the format's low bitrates.

[jagabo]

It looks like the appended test chart has TV levels , was this done on purpose (not that it really matters, we're just interested in changes from the original, correct)?

Yes, the chart is encoded with standard rec709 levels because we are working with high definition video. For anyone who isn't familiar with this, here's an oscilloscope graph from the lagarith video (performed in YUV space):



The Belle Nuit chart includes a whiter-than-white section. You can see that the four blocks at intensity 231, 239, 251, and 255 are at the right levels (Y, luma) in the graph. When this is viewed on a TV or computer monitor the 239, 251, and 255 blocks may all be the same brightness. The 231 block should appear slightly darker than the 235 and 239 blocks. You can see the differences here because I used the PC.709 matrix to avoid the usual contrast enhancing scaling used for viewing video.

In the blacker-than-black section the levels can be seen to be correct in the graph. When watched on a TV or computer monitor you should not see any difference between the 0, 4, 12, and 16 patches. They should all be black. The 20 patch should be just barely lighter. Again, you can see them all here because of the non-contrast enhancing matrix used to prepare the image. Many computer monitor crush blacks so you may not see much difference in this area.

In the 709 matrix area all four colors should have the same intensity (Y, luma). In the graph you can see that the luma varies by a small amount (1) because of the initial RGB to YUV conversion. The 601 matrix area varies much more because the chart uses the 709 matrix. Ie, the 601 colors are wrong.

In the colored patches at the top and bottom each of the RGB primaries should be either 180 or 16 (in this image). They are slightly off (again, usually only by 1) in a few of the patches because of the RGB to YUV to RGB conversion. When viewed at normal levels on a TV or monitor the 180 primaries should be about around 190 and the 16 primaries should be about 2.

Here's what the graph should look like on TV or your monitor:



Note the brighter brights and darker darks.

I'm not too concerned about whether the video is displayed at rec709 or rec601. Exactly how the video is displayed on your computer varies depending on the codec, the player, and the graphics card. But the levels should remain the same. (I suppose it's OK if the blacker-than-black and whiter-than-white sections are clamped in YUV space -- since technically video should not have those levels). The chart should make these issues obvious.

The following AviSynth script generates the graph I posted above:

AviSource("lagarith.avi") # open video
ConvertToYUY2() # VideoScope requires YUY2
VideoScope() # draw scope graphs
ConvertToRGB(matrix="pc.709") # to RGB for display, maintain luma levels

If you want to be technically correct with codecs, software, and computers that assume YUV is rec601 you can use the ColorMatrix() filter in AviSynth:

AviSource("lagarith.avi")
ColorMatrix(mode="Rec.709->Rec.601")

[deadrats]

ok, i did a bunch of encoding tests, all of them using tmpg express 4.7.1.284 as the front end. the first link is of the jagabo's lagarith file as source, with the tv test pattern:

http://www.sendspace.com/file/cd01ad

2 things to keep in mind, i tested with xvid@hi def profile, x264@max quality settings, divx@insane settings and main concept's h264, all with a target video bit rate of 3000 kbps (though as you will see they vary from that target) and tmpg express does not seem to allow the creation of avi files with no audio so it included an empty uncompressed pcm stream which made the resulting avi's significantly bigger than the divx and mp4 file.

the second link is of a test that i feel is more representative of what video help readers are likely to do and it encompasses more codecs, basically i took the 720p mpeg-2 that comes with the x264 benchmark and resized it to 720x480 16:9, using maximum quality settings of each codec as well as setting the quantization factor to 1 (i.e. max) for each codec, basically i allowed the bitrate to be unconstrained, i allowed the codec to produce the highest quality file it was capable of, also since all encodes were done via tmpg express as a front end and since i used the exact same resize filter for each output, namely lanczos-3, i feel that the results are directly comparable.

the tested codecs are apple's h264, sorenson 3, vc-1, xvid, x264, divx, main concept's h264 and mpeg-2, all settings were tuned for max quality:

http://www.sendspace.com/file/jml26v

i leave it up to you guys to decide which codec won this test.

[poisondeathray]

ok, i did a bunch of encoding tests, all of them using tmpg express 4.7.1.284 as the front end. the first link is of the jagabo's lagarith file as source, with the tv test pattern:

http://www.sendspace.com/file/cd01ad

2 things to keep in mind, i tested with xvid@hi def profile, x264@max quality settings, divx@insane settings and main concept's h264, all with a target video bit rate of 3000 kbps (though as you will see they vary from that target) and tmpg express does not seem to allow the creation of avi files with no audio so it included an empty uncompressed pcm stream which made the resulting avi's significantly bigger than the divx and mp4 file.

the second link is of a test that i feel is more representative of what video help readers are likely to do and it encompasses more codecs, basically i took the 720p mpeg-2 that comes with the x264 benchmark and resized it to 720x480 16:9, using maximum quality settings of each codec as well as setting the quantization factor to 1 (i.e. max) for each codec, basically i allowed the bitrate to be unconstrained, i allowed the codec to produce the highest quality file it was capable of, also since all encodes were done via tmpg express as a front end and since i used the exact same resize filter for each output, namely lanczos-3, i feel that the results are directly comparable.

the tested codecs are apple's h264, sorenson 3, vc-1, xvid, x264, divx, main concept's h264 and mpeg-2, all settings were tuned for max quality:

http://www.sendspace.com/file/jml26v

i leave it up to you guys to decide which codec won this test.

deadrats - I've examined your encodes from jagabo's link. I don't want to sound like a jerk, but all this shows is that you're unfamiliar with the encoder settings. I realize it's probably TMPG's fault, but that's all the more reason to learn the proper settings.

I'm going to post some representative screenshots along with some encodes (you have to click on the screens for full size, or download the link below). Ignore the color differences, we used different matrices. Not all the frames show differences this big, but given the medium source quality / content complexity / frame size / bitrate chosen, theoretically the differences should only be minor anyways (a higher quality clip would have more easily differentiated them). Only the most observant viewers will be able to pick out big differences during realtime playback, but if you use avisynth and interleave() them, the differences are quite clear

The original "challenge" was to encode using decent settings, then come back and we can discuss... You obviously haven't done this.... I'm not trying to turn this into a me vs. you or us. vs. them thingy, as we are all here to learn and discuss things... You somehow managed to b0rk the xvid encode and get a fair bit of pixellation in several of the scenes, especially those with action. My xvid encode has some pixellation too in some of the other scenes , but it's relatively minor. Part of the reason is both your xvid and divx encodes are undersized ~10%. But if I were to guess, I would say weren't using VAQ and probably low motion precision settings.

Original


Deadrats XviD


PDR XviD



Your x264 encode uses 1pass ABR (as opposed to 2pass VBR), and low quality settings (definitely not optimized). It uses all I-frames (no b or p frames - this greatly reduces x264 efficiency advantage) . Yes I-frames are higher quality than B or P, but only if you have unlimited bitrate. In a bitrate constrained scenario don't expect to use all intra with good results....

Some people love Mainconcept h.264, but IMO it is a poor h.264 implementation. I've extensively tested many different versions. I've said this and posted samples in several forum threads, it oversmooths things and that's how it achieves it's compression. Fine details and grain are gone, except at high bitrates. Note this example isn't a fair comparison, because I know you used bad settings (e.g. 1 reference frame, and no b-frames) , but I've posted dozens of samples showing the same thing using appropriate settings.

Original


Deadrats x264


PDR x264


Deadrats Mainconcept h.264



Included in the link below are my x264 and xvid encodes, and a few more screenshots numbered by frame. The stills don't do a good job of showing temporal changes, but if you watch in slow mo or advance by frames, you will see one common problem with xvid is fluctating quality levels. e.g. Grain and detail will be present in 1 frame, but will become blotchy and fade out in the next, giving an undulating fluctuating appearance. This is a clear sign that this bitrate isn't sufficient for xvid in these testing conditions. This also happens because xvid b-frames are comparatively lower in quality than x264 b-frames.


http://www.megaupload.com/?d=4NVQ5ZKW


Some people might not be used to looking for differences. If you can't clearly pick out the differences in the screens or the videos, let me know and I'll guide you where to look


As for your other test, I haven't looked at it, but if you used the similar settings used in the 1st "test", I would say they are not representative of the full potential of the encoders. x264 quality exists on a contiuum and eventually reaches lossless at qp=0. So if you used "best" settings as you claim, the lossless encode would obviously be best. The other encoders do not have a lossless mode.

[jagabo]

For what it's worth here are my encodes. I left the video as rec709 even though most computers will display the video as if it was rec601.

http://www.mediafire.com/?zwcmt3lqjfm

XVID3: This is my baseline "watchable" video. I use this for stuff that I'll watch but don't need in high quality. I use Xvid in Target Quantizer mode with a Quantizer of 3.0, single B frame, VAQ enabled, max GOP 100. The average bitrate of this encoding is about 1500 kbps. It shows significan't macroblocking and DCT ringing as you would expect. But it's not all that visible at normal playback speed, especially with Xvid's deblocking and deringing enabled. There's also a lot of film grain loss (a bad thing in my opinion) and loss of small details.

XVID2: This is my typical "high quality" Xvid setting. This is also Target Quantizer mode but with a Quantizer of 2.0 and no B frames, VAQ enabled, max GOP 100. This happened to turn out about the same bitrate as deadrat's Xvid encode. It's much cleaner than the Q=3 encode.

X264 CRF20: I don't do a lot of x264 encoding (I don't even know what several of the specific settings are) but as a quick test I used x264gui, fed by a simple AviSource("lagarith.avi"). I started with the DXVA-HD-HQ setting then changed to Single Pass CRF mode with a quantizer of 20. I changed the Min I Interval to 1, the Max I interval to 50, Max consecutive B frames to 2. (Actually I did encodes at a few different quantizer values and decided to upload this one because it was about the same bitrate as my high quality xvid encode.) I'm using an x264 build from about 9 months ago.

[creamyhorror]

I'm following this comparison with interest. Hope we'll get to see clear demonstrations of the differences between encoders at this fairly generous bitrate. Of particular interest will be the level of smoothing and deblocking going on, since I've read claims that x264 smooths too much.

[poisondeathray]

I'm following this comparison with interest. Hope we'll get to see clear demonstrations of the differences between encoders at this fairly generous bitrate. Of particular interest will be the level of smoothing and deblocking going on, since I've read claims that x264 smooths too much.

Yes, any h.264 encoder has the potential to oversmooth, largely as a side effect of deblocking. But people that make those claims usually use bad settings or are not familiar with encoding. Or when challenged they do not provide any substantial proof of their claims. This little exercise clearly shows that.

This is probably one of the biggest quality complaints of using h.264 - e.g. the "plastic doll" look. If you are familar with rmvb, you should be familar with this look. Some h.264 implementations oversmooth more than others (e.g. Mainconcept). But x264 has made huge improvements over the last few years (and I was one of those loud complainers a few years ago). If you were to encode using a x264 build from 3 years ago, it would look just as smooth without details like those encodes typical of Mainconcept's h264 encoder, or deadrats' encode. Things have definitely changed.

High alpha, and beta values will cause oversmoothing, as will lower quality settings in a bitrate constrained scenario. You can (and should) adjust the deblock values. You can't use the same settings for every scenario. Different types of content and bitrate ranges require different settings for best results. For example, I would have used different settings for a cartoon vs. this live action sequence.

Here is the same frame from the same encoder using 4 different settings. Note I've deliberately chosen a frame with clear differences, not all frames will show this large of a difference. I've corrected for the colormatrix (used rec709), and cropped these so they wouldn't be resized by the browser page. Pay attention especially to the grain detail, and how "smeary" it can look with unoptimized settings.

Original


Deadrats x264


Jagabo x264


PDR x264


I'm just making the point not to pass judgement an encoder so swiftly because of user unfamiliarity or because of the rumor mill. Instead of blindly believing me , anyone else , or something you read, I challenge everyone to do some testing for themselves on various types source material, and see with their own eyes. Take the time to learn the settings and how to use them in different scenarios; this is true for any encoder.

[deadrats]

deadrats - I've examined your encodes from jagabo's link. I don't want to sound like a jerk, but all this shows is that you're unfamiliar with the encoder settings. I realize it's probably TMPG's fault, but that's all the more reason to learn the proper settings.

fair enough, i'm redoing the test encodes using the test file i originally wanted to, years ago, when HDTV was just coming onto the scene panasonic released a 1080i demo with the file name [PIONEER][HDTV][1080i]Pioneer_HDTV_Demo, if anyone wishes they can do a google search, it's still available on numerous torrent sites but panasonic no longer has it for download on it's site.

i don't see there being any issue with violations of this sites rules since panasonic released it to the public and i would think that this constitutes fair use.

the file is 1920x1080i, 20 Mbps, mpeg-2 and i have yet to see any encoder choke on it, it's crisp, clear, lots of vibrant color and features a really hot chick (don't worry, it's well within this forums rules).

i will be redoing the test, using a resize to 960x540p, at 2500 kb/s, so that differences between each codec is readily apparent. i will upload the results in a couple of hours.

[Xpenguin17]

I thought I'd just add that all of you obsessed with the H264 deblocking feature are on crack. H.264 is not a "XviD with deblocking." H.264 is a completely redefined codec with a number of features besides deblocking, including different block sizes, quarter-pixel motion prediction, more B-frames, multiple motion vectors, RDO and a hell of a lot more.

The deblocker is not like some crap-ass linear filter that you find for Virtualdub; the deblocking strength is dependant on the quantization level. In other words, even a +6 +6 deblock setting won't affect the picture much on higher bitrates.

Besides, if the lack of "warm" dirt and grain on your video really gets your panties in a twist so much, turn the ******* deblocker off and shut the **** up.

[creamyhorror]

Yes, any h.264 encoder has the potential to oversmooth, largely as a side effect of deblocking. But people that make those claims usually use bad settings or are not familiar with encoding. Or when challenged they do not provide any substantial proof of their claims. This little exercise clearly shows that.

Indeed. I saw a thread in this or the other Conversion forum where Puzzler insisted that x264 had a horrible smoothed look, but he didn't post examples there and I couldn't find any on a cursory Google search. I personally don't find that there's oversmoothing, and I don't get how MPEG2 could look better than x264 (even at high bitrates) when it's technically so much more inferior. I'm willing to change my opinion given a fair comparison, of course.

If you were to encode using a x264 build from 3 years ago, it would look just as smooth without details like those encodes typical of Mainconcept's h264 encoder, or deadrats' encode. Things have definitely changed.

I certainly agree. I assume it was FGO/AQ/psy-RDO that changed that?

Here is the same frame from the same encoder using 4 different settings. Note I've deliberately chosen a frame with clear differences, not all frames will show this large of a difference. I've corrected for the colormatrix (used rec709), and cropped these so they wouldn't be resized by the browser page. Pay attention especially to the grain detail, and how "smeary" it can look with unoptimized settings.

Now that is a striking difference. It looks like psy-RDO (and maybe AQ) was off for deadrat's, and I don't know what's up with jagabo's (looks like bitrate starvation somehow). Was everyone using deblock -1:-1 at the least?

[jagabo]

The DXVA-HD-HQ profile set deblock to -2:-1.

[poisondeathray]

Indeed. I saw a thread in this or the other Conversion forum where Puzzler insisted that x264 had a horrible smoothed look, but he didn't post examples there and I couldn't find any on a cursory Google search. I personally don't find that there's oversmoothing, and I don't get how MPEG2 could look better than x264 (even at high bitrates) when it's technically so much more inferior. I'm willing to change my opinion given a fair comparison, of course.

Ah yes Puzzler... there's a few threads where we have disagreements. I have posted samples, screenshots, encodes, PNSR/SSIM charts in dozens of different threads, and he has yet to post a shred of evidence illustrating his claims... This is not an I'm right/you're wrong thing...this is about learning and using the encoders properly. I just can't believe we are observing such different results! I have a big suspicion he is not using them properly either, like deadrats. So yes, any encoder can produce bad results if you use bad settings...At blu-ray bitrates using good quality transfers with lots of grain, I'm seeing about 1.6-1.7x the size required for xvid to have equivalent quality. MPEG2 requires even slightly more. Of course, this varies by source etc....but I mean it's not even close! Have a look at the lossless Island trailer link I posted earlier if you want to do some testing. That is heavy with grain, typical of some decent blu ray transfers. The differences are much much more clearer on a better quality source than the one used here.

If you were to encode using a x264 build from 3 years ago, it would look just as smooth without details like those encodes typical of Mainconcept's h264 encoder, or deadrats' encode. Things have definitely changed.

I certainly agree. I assume it was FGO/AQ/psy-RDO that changed that?

There were a bunch of little things, and when you add up 0.1% compression advantage here and there, it adds up. But you're right AQ/psy-rd were the biggest; but mb-tree is starting to have a dramatic effect especially on lower bitrate scenarios. There's still some bugs with fade though, but weighted-p is supposed to help with that in a coming patch. That's the thing though, some of them are actually destructive and counter productive if you're not careful, like the psy settings and AQ can be horrible on low bitrate scenarios and anime type content.

Now that is a striking difference. It looks like psy-RDO (and maybe AQ) was off for deadrat's, and I don't know what's up with jagabo's (looks like bitrate starvation somehow). Was everyone using deblock -1:-1 at the least?

I explained the some of the big contributing reasons in a previous post: The biggest reason was deadrats used all intra (no b, p) and 1pass ABR. Minor contributing factors were probably: 0,0 deblock, no psy/trellis, 3ref.

A contributing explanation for jagabo's encode was he limited b-frames to 2, when this sequence has several runs take can take advantage of 5 or 6. You can tell this by looking at the 1st pass log. The performance hit is big, however, when you are using b-adapt 2 (ie. very slow) . Looking at a stream analyzer, his encode is a low weighted p-frame on that frame, where as on mine, it is a higher bitrate b (his was forced to place a p). I used slightly higher quality settings like subme 10, analyze all, mbtree, et.c.. the little things also addup, 0.5% here and there... even on similar quality frames you can consistently see slightly more detail if you examine frame by frame. You can download them and have a look yourself

[jagabo]

poisondeathray, what are the command line options you used for your x264 encode?

[creamyhorror]

The DXVA-HD-HQ profile set deblock to -2:-1.

Oh okay, that's certainly alright.

Ah yes Puzzler... there's a few threads where we have disagreements. I have posted samples, screenshots, encodes, PNSR/SSIM charts in dozens of different threads, and he has yet to post a shred of evidence illustrating his claims...

Ah yes, that was the thread. Maybe he can provide some evidence here...

but mb-tree is starting to have a dramatic effect especially on lower bitrate scenarios.

mbtree is indeed pretty exciting. I'm looking forward to weighted prediction to fix the fades issue, but I'm all ready to use mbtree as it is.

I explained the some of the big contributing reasons in a previous post: The biggest reason was deadrats used all intra (no b, p) and 1pass ABR. Minor contributing factors were probably: 0,0 deblock, no psy/trellis, 3ref.

Don't know how I missed it originally. Using all I-frames...yes, I can see how that would hurt video quality

A contributing explanation for jagabo's encode was he limited b-frames to 2, when this sequence has several runs take can take advantage of 5 or 6. You can tell this by looking at the 1st pass log. The performance hit is big, however, when you are using b-adapt 2 (ie. very slow) . Looking at a stream analyzer, his encode is a low weighted p-frame on that frame, where as on mine, it is a higher bitrate b (his was forced to place a p). I used slightly higher quality settings like subme 10, analyze all, mbtree, et.c.. the little things also addup, 0.5% here and there... even on similar quality frames you can consistently see slightly more detail if you examine frame by frame. You can download them and have a look yourself

Mm, good info here. I don't see the logs linked. Normally, though, max b-frames above 4 don't help much for live-action content, so at what % of consecutive b-frames does using 5-6 really help?

I think it would be good to do a medium-high-quality encode that doesn't use the slowest settings (maybe subme 6-7, UMH, etc.) to see how it performs against your max-quality encode. I'd do it, if anyone else were interested in the results.

[Xpenguin17]

I wouldn't use "psy" anything if I were you. They were implemented by a dumbass fanboy who thinks he is a developer. You will end up with degraded quality and far more distorted edges if you turn on any psychovisual feature, both on low and high bitrates. Compare it and you'll see.

[poisondeathray]

poisondeathray, what are the command line options you used for your x264 encode?

If you downloaded the video, the encode stats should also be printed in the metadata. 1st pass was just a vanilla turbo analysis pass, so I'll just list the 2nd pass. Note I am using a beta testing build r1217kmod which is still buggy (eg. things like --b-pyramid don't work with mbtree, --keyint and --min-keyint changes cause mbtree to crash...etc..but apparently this has been fixed in today's commit). Some options like mbtree have made it into the main x264 branch, so they are "on" by default, so you won't see these options listed in the command line. I noticed your encode was r1060, so things like mbtree or subme 10 will not be accessible unless you use a newer build

x264.exe --profile high --pass 2 --bitrate 3000 --stats "E:\video.stats" --ref 8 --no-fast-pskip --bframes 5 --b-adapt 2 --b-pyramid --direct auto --deblock -2:-1 --subme 10 --trellis 2 --partitions all --me umh --merange 24 --threads 3 --thread-input --sar 1:1 --aq-mode 3 --no-dct-decimate --output "E:\output.mp4" "E:\input.avs"

Writing library                  : x264 core 72 r1217kMod 5e9ae4c
Encoding settings                : cabac=1 / ref=8 / deblock=1:-2:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=3 / nr=0 / decimate=0 / mbaff=0 / bframes=5 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=3000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=3:1.00

[poisondeathray]

I wouldn't use "psy" anything if I were you. They were implemented by a dumbass fanboy who thinks he is a developer. You will end up with degraded quality and far more distorted edges if you turn on any psychovisual feature, both on low and high bitrates. Compare it and you'll see.

Obviously you haven't much experience. It depends completely on the situation, bitrate range, type of content. Quality is a subjective measure, and percieved quality can differ from objective measures like PSNR, SSIM. If you were a robot, then use turn off psy. I can show you many scenarios where it helps, and many where it hurts.

[creamyhorror]

I wouldn't use "psy" anything if I were you. They were implemented by a dumbass fanboy who thinks he is a developer.

Why don't you tone down the personal attacks?

You will end up with degraded quality and far more distorted edges if you turn on any psychovisual feature, both on low and high bitrates. Compare it and you'll see.

If you've compared it, maybe you can post your samples up to see?

[poisondeathray]

Mm, good info here. I don't see the logs linked. Normally, though, max b-frames above 4 don't help much for live-action content, so at what % of consecutive b-frames does using 5-6 really help?

I mean when you do your own encodes, you should be looking at your log files. It will tell you the max b-frames consec used. You're right, 3 is usually ok for live action, but there are repetetive frames in this sequence. You should always examine the content before deciding what basic settings to use

e.g.
---[NoImage] x264 [info]: consecutive B-frames: 8.3% 13.2% 43.9% 7.7% 6.2% 20.7%

This means 8.3% used zero, 13.2% used 1, 43.9% used 2, etc....

[creamyhorror]

e.g.
---[NoImage] x264 [info]: consecutive B-frames: 8.3% 13.2% 43.9% 7.7% 6.2% 20.7%

Yup, I already use this statistic. (Although lately I've gotten lazy and just used CRF with b-frames 5 or so.) I was actually asking at which specific % you decide to cut off the max b-frames.

[poisondeathray]

e.g.
---[NoImage] x264 [info]: consecutive B-frames: 8.3% 13.2% 43.9% 7.7% 6.2% 20.7%

Yup, I already use this statistic. (Although lately I've gotten lazy and just used CRF with b-frames 5 or so.) I was actually asking at which specific % you decide to cut off the max b-frames.

The speed penalty is huge when using b-adapt 2 with increasing b-frames. I tend to only use it if it's more than a few percent. I think it drops off after 5 in this example. But you can see from these figures where using 5 vs. 2 could make a difference for this sequence , and why I think it contributes to the differences between jagabo's encode and mine

Everyone probably already knows this, but we should mention the other important part of the equation besides encoder settings is preprocessing i.e. filtering. e.g. deadrats was going to post some resized 1080i encodes, and I can definitely say things like the choice of deinterlacer would have a way bigger effect on quality than things like subme7 vs subme9 or analyze all etc.... Or for a low bitrate encode, preprocessing with denoising or degraining filters. The absolute worse is when you are stuck in the middle with splotchy grain or detail. I usually go for full detail preservation, or smooth. It's an all or none strategy for me. The stuff in the middle looks crappy.