Overall Bit Rate, Bit Rate with Respect to Quality and Filesize

[Slipster]

...

[hello_hello]

Sorry if I skip another of your posts but I actually got out of bed to check this so I could sleep, but I'm posting and going straight back. I used ffdshow with it's on screen display to show the input bitrate during some fast motion action scenes. The birates between the 2 pass and CRF encodes only ever differed marginally. Something like 50Kbps or less. During the second scene I checked, the encode which appeared to have the slightly lower bitrate was the 2 pass encode.

[Slipster]

...

[hello_hello]

No. The stats file/MB-tree decides which way the bitrate steering goes and when in order to reach the target average bitrate. There will be times when it sees that less or more bitrate is needed in relation to the target, so it throttles the bitrate to and fro accordingly. If it's used less than the target bitrate at any given time then it also has more than the target bitrate available to use elsewhere. It's not, strictly speaking, a bit reservoir, but it behaves very much like one. That's how predictive ABR works.

Which still leaves me wondering how 2 pass encoding could do a better job at the same bitrate as CRF, given CRF doesn't encode using the same restraints.
Surely if they're using the same algorithm, and CRF is free to adjust the bitrate any way necessary to achieve the requested quality, while 2 pass encoding needs to throttle the bitrate to and fro to achieve the desired bitrate, there's no way 2 pass encoding could be better over-all, all else being equal. If anything it seems logical to me that while 2 pass is busy adjusting the bitrate, there must be times when the quality of 2 pass encoding is lower than CRF, and times when it's higher.
The only way 2 pass could maintain the same quality would be by adjusting the algorithm used according to the bitrate. ie if it's using a lower bitrate during low motion scenes it's using a more efficient compression method than CRF would, and while it's spending the extra bits during high motion scenes it uses a less efficient compression method. Even if that's the case, how could it translate to the 2 pass encode looking better?

Try watching the real-time bitrate of a long 2-pass encoding while it's playing and I'm sure you'll see exactly what I mean. The numbers are right there in front of you if you run MPC-HC with the ffdshow plug-in and enable the relevant OSD, so you don't need to take anyone's word for anything.

I'm doing it as I type this post. So far, the biggest variation I'm seeing in bitrate between my CRF18 DVD encode and the 2 pass encode is 100Kbps. Obviously though, the 2 pass encode isn't just saving up bits to use on fast motion scenes. The scene I'm watching at the moment is fairly low motion, it's been running for a couple of minutes, and the bitrate for the 2 pass encode is still averaging about 50Kbps more. If anything from what I'm seeing at the moment, the 2 pass encode is spending any extra bits on low motion scenes where a slight quality boost would be more desirable. And thinking about it, that'd make more sense.

Mind you I'm starting to wonder..... I've had these two encodes synced and running on the same monitor for at least 10 minutes now and regardless of the scene the bitrates being displayed are increasing and decreasing in near perfect sync, only for the 2 pass encode the bitrate being displayed by ffdshow has remained fairly consistently around 40Kbps higher. Actually no..... things just changed, the bitrate difference has dropped to 15Kbps. Yep, we're into some harder to compress stuff now, only 10Kbps higher for the 2 pass encode........ 2Kbps now...... and now CRF has hit the lead...... by 3Kbps.... 5Kbps...... 10kbps..... okay we seem to have reached a stable point again.... now it's the CRF encode's turn, it's sitting fairly constantly at about 20Kbps higher than the 2 pass encode.

So no, these bit rate spikes you've referred to.... I'm not seeing them at all and I've been watching these two side by side for at least 20 minutes now. Currently the CRF encode is sitting on a consistent 30Kbps higher bitrate. Looking at the bitrates it certainly seems to be in line with the slight compression differences I was seeing when examining each encode frame by frame, but compression differences only. Nothing which you could translate to a tangible quality difference. I'm really starting to wonder about MediaCoder....

[Slipster]

...

[hello_hello]

The above is what happens when I compare the same 15 second section when encoded in isolation and with total file sizes roughly matched. As you can see, bitrate distribution on a frame-by-frame basis is very different here, yet it's not necessarily so on longer encodings, hence my argument that you can only ever carry out an accurate comparison on lengthy equivalent encodings.

Yeah but you're still saying even with lengthy encoding 2 pass looks obviously better, while at the same time saying lengthy encodings give 2 pass the time to achieve what CRF does, only with unexplained bitrate peaks and higher overall quality..... ahhhh.... I'm getting confused now.

2-pass happens to be making the wiser decisions though even in this case, as artifacts are clearly visible in the CRF encoding and not in the 2-pass encoding. It could be argued that that's a product of having to drop to CRF25, but that was necessary to achieve similar encoding sizes. Whatever, short encodings definitely skew the results, although I can't say for certain in which direction in all cases.

But "artifacts are clearly visible in the CRF encoding and not in the 2-pass encoding" bit is where we completely disagree. And when I looked at the two encodes I wasn't comparing them to do anything else but look for differences. The quality wasn't great, because the source wasn't great quality, but the bottom line is while there were differences in the way sections of individual frames had been compressed, they were just slightly different. Neither retained more detail than the other, neither looked better than the other, neither showed more re-encoding induced compression artifacts than the other. Aside from the possibility of comparing frame "A" and saying the small area on a person's face where it looks a little blurry might be situated 4 pixels higher and 3 pixels to the left when compared to the second encode, or for frame "B" it might be a few extra pixels larger in size, or the dancing blocks on the rear wall had moved a little to the left in frame "C" for the first encode, but didn't move left until frame "D" in the second..... these two encodes looked virtually the same. There's no way you could compare them frame by frame and say one looks better than the other, they just have slight differences, and if they were played in sync side by side on a TV I'd defy anyone to say the look different at all. At one stage I had MPC-HC playing them both in sync on my TV, one using the top half of the screen, the other on the bottom half (wide aspect ratio movie) and because I was tired and visually they're virtually indistinguishable, I kept forgetting which was which.

Anyway, I'll have to do some other stuff today. I'll probably run a couple more comparison encodes later on but while it might be a couple of days before I get a chance to put any serious amount of time into this again, I'll be back when I can. I won't bother with screen shots but I did load the two encodes into Bitrate Viewer and the results were:
CRF18 encode: Average 1201 Kbps, Peak 9504Kbps
2 pass encode: Average 1177 Kbps, Peak 9208Kbps

I'm not sure where it went slightly wrong in terms of average bitrate. MediaInfo disagrees with Bitrate Viewer when it comes to the CRF encode as it reported 1178Kbps which is why it's the bitrate I specified for 2 passes, although either way, we're still only talking about a 30Kbps average bitrate difference. And those two peak bitrates above..... for the record they apply to frame number 35 for both encodes.

(Edit: no I assumed "sample" meant frame, but it was "sample" 35 in both cases. Sample 6260 produced the next highest bitrate peak. 7407Kbps for the CRF18 encode vs 6962Kbps for the 2 pass encode, so I'm not getting these 2 pass bitrate spikes you refer to. What does Bitrate Viewer call a "sample". Sample 6962 is around 1 hour 44 minutes in according to bitrate viewer, which ffdshow says puts it around 150,000 frames in. I assume Bitrate viewer doesn't sample every frame???)

Once again, what I'm seeing by looking at the two encodes, what I'm seeing when displaying the input bitrate using ffdshow, and what Bitrate Viewer displays all seem to co-incide, yet they contradict what you're saying in terms of really high bitrate peaks and obvious quality differences. With maybe one exception..... according to Bitrate Viewer, 4Kbps was the bitrate for the very last frame of the CRF encode. For the two pass encode it was 3575Kbps. Okay, so I'll concede there's a very good chance 2 pass encoding made that final black frame look a hell of a lot better.
Actually if moving the curser in bitrate viewer is any indication, the 2 pass encodce was throwing a reasonably higher number of bits at the final part of the credits than the CRF encode. I guess it was busy spending some of those bits it'd saved earlier to hit the desired file size, but the end of the credits probably looks awesome.

[hello_hello]

Excellent! I think we've managed to prove two things so far...

1/ Bitrate allocation on a frame-by-frame basis is almost the same in CRF and 2-pass mode on lengthy encodings, but not necessarily so on short ones,

Well I haven't tried any short ones. Well only one, but I didn't get the bitrates close enough for it to really prove anything one way or another.

2/ The bitrate distribution at the individual macroblock level within each frame can vary wildly between CRF and 2-pass encodings leading to possibly visible artifacts.

So far I'll concede the lower the quality, the more any differences in bitrate distribution may effect quality. Well no, I wouldn't even be willing to concede "quality" yet. I'd go as far as saying it'll effect the way each frame is compressed in maybe a very noticeable way, but if you're comparing two very overly compressed frames you're not necessarily comparing quality differences if the upshot of it is they're both just a different flavor of crap.
And that's all I'm seeing so far, although as yet I've really only compared CBR and 2 pass at both ends of the quality spectrum, so maybe when I'm working in the middle ground things might change, but to me it looks like they're both going to scale from different flavors of crap at one end, to marginal compression variations at the other, in a pretty similar manner.

Even your Bitrate sceenshots are comparing 5 minute encodes with average bitrate differences high enough not to be dismissed, so it's not apples and apples, whereas in my case the average bitrate difference was only 30Kbps over a 2 and a half hour duration. To be honest you'll have to show me short CRf vs 2 pass encodes which use the same bitrate to convince me of anything there. And even then, I'd still like to repeat the process myself while taking MediaCoder out of the equation, and also while taking encoder "tweaks" out of the equation just to see if they're causing any variation in the results.
And even then, if there are improvements when using 2 passes over CRF for encodes a few minutes long, I'd still have to be convinced those results apply to an encode of a normal duration, because from what I'm seeing, they don't. Although to be honest I've encoded the DVD extras on ocassion and sometimes they consist of 30 second outtakes, that sort of thing. I've always used the same CRF encoding as I used for the rest of the DVD and not once have I looked at the encodes of the "extras" and thought their quality differed in any way to the encode quality of the main movie, and if the quality difference was anything like you're describing, I'm absolutely sure I'd see it. I've encoded enough video now that even when I'm relaxing at a friend's place watching a movie, it often takes a little while to slip into "movie watching mode" and not be distracted by compression artefacts.

I'm talking big numbers here. Often a massively high quantiser value in CRF for a few localised macroblocks where close to a zero gets used for them in 2-pass, hence massive amounts of detail being dropped from those particular macroblocks whilst giving back a miniscule benefit to all other macroblocks within that frame as the bitrate spared gets shared between hundreds of them. It's very destructive.

Want screenies?

Screenies would be good, and maybe when I get a chance I'll do the same in order for you to show me what I must be missing, but if you post screenies can we at least ensure the bitrates are virtually identical? And maybe if it's a short duration clip you could upload the source for me to repeat your tests to see if I get the same results. At the moment I still think that's the real issue, where running similar tests but getting different results. Once we've run the same tests and gotten the same results, or at least worked out why our results differ (did I mention MediaCoder? ), Then we'll actually be getting somewhere.

Anyway..... I've got to fly for now....

[hello_hello]

PS. I just worked out how to zoom in using Bitrate Viewer. I'll have to play around some more later, but the differences in your screenshots aren't anything like the differences I'm not seeing.

I don't know if there's a way to reduce the scale I'm missing, but in your case the middle line is 1000Kbps whereas for me it's 5000Kbps and because the 100 frames I'm currently looking at are in the 800Kbps range and the difference between them is under 30Kbps it's hard to see if the very, very slight differences in the graphs translate to anything meaningful. I'd suspect not, they probably just translate into the very, very minor compression differences i see when comparing the video frame by frame.

[Slipster]

...

[Slipster]

...

[hello_hello]

The behaviour of both in terms of bitrate peaks may not always be as different as the earlier lengthy test encodes I made led me to believe, but the decisions the encoder makes relating to bitrate at any given time obviously do change between 2-pass and CRF when encoding short versus long content, so the bitrate-determining mechanisms clearly aren't the same. Using the specific x264 tweaks I'm using definitely gives 2-pass SD encoding at 1333kbps the edge over CRF20 here most of the time. Stray from that target bitrate without retuning the psychovisual parameters to suit and I have no idea what the effects will be, so all bets are off then regarding 2-pass versus CRF.

I really should be doing other things at the moment, but anyway......
If the decisions relating to bitrate at any given time changes between 2 pass and CRF, it's because the first has to work within the bitrate restrictions you've enforced on it while the second does not. How that equates to the first producing better quality is still beyond my understanding.

But we're looking at encodings of different sources with different eyes on different playback equipment, and I still don't know whether you're using any of the psychovisual settings I recommended for 2-pass at 1333kbps which do make a considerable difference, plus you've changed the target bitrate for 2-pass anyway. Comparing my exact 2-pass settings to CRF20 for a lengthy encoding of a hard-to-encode source here, the difference is clearly visible either frame-by-frame or in motion.

I'm not using your teaks as yet. I will at some stage, but I wanted to start off with x264 defaults first to see what the results are. After-all, this discussion is really based on my comments that CRF encoding is generally the better option because you can predetermine the quality, and at the same bitrate that quality will be virtually identical to 2 pass encoding. You claimed otherwise, but you're pretty much qualifying it by saying you're only sure it's true at CRF values of around 20 and when applying your specific x264 encoder tweaks. Even if that's correct, how can I modify the opinion I give to others as a general rule unless I'm sure they'll download and encode using MediaCoder after I've supplied a link to the preset you use and they'll also download and use it? At this stage, my advice/opinion would be based on the assumption it applies to encoding without fiddling with any of x264's advanced options.

Bear in mind that I'm watching this content entirely 'in the raw' on a Full-HD PC monitor with no additional postprocessing besides an identical precision upscale for both sources. The difference between both encodings when viewed on my 32" Full-HD TV is much smaller because, like nearly all modern TVs, it's chucking so much postprocessing at the image that it's totally incapable of displaying a WYSIWYG picture so largely masks the differences. Maybe that's a contributing factor at your end too?

I'm still using Trinitron CRT monitors and I've never attempted to calibrate them for watching video. They're set up so I can comfortably do general computer type tasks, so as a result I'd not be in too much of a hurry to use them for comparing encoding artifacts as video tends to look a little darker than it otherwise should.
The first thing I did after setting up my TV was to disable all the picture enhancing/noise reducing stuff, and while I can't actually see differences between inputs any more (HDMI vs VGA), as a general rule I tend to use the VGA input for comparing video in the hope that if the TV does still have some "messing with the image" functions hidden and active, hopefully when connected via VGA it'll just be in PC monitor mode.
What size PC monitor do you run? Mine are 22" but even if calibrated properly I'm not sure I'd generally be looking at a large enough version of the image to really look for encoding issues. I assume the video is being converted to PC levels before it hits your PC monitor? I've got my video card configured to do it so I don't have to rely on media players or renderers getting it right.

Anyway, even with the browser up on the TV displaying your pics, all the numbers were kind of making it hard to compare the video properly, but I can see the distortion you refer to in the Chinese lady's shirt cuff, and after several switchings of the video between the PC monitor and the TV I finally worked out the button you were referring to and of course it looks different, but seriously..... these aren't the noticeable quality differences you've been referring to when comparing 2 pass encoding to CRF are they? I mean, obviously one is better than the other in two small areas in that particular frame, but I'd kind of like to see the next frame and the next.... I mean it's very hard to judge looking at a single screen shot, but going by one covered in numbers on it's own, it's hard to imagine anyone would notice those two things while the video was running.

I was thinking about the video tweaks you apply too.... not that I can even remember what they are off the top of my head, but I remembered some of the encoding comparisons done as a result of a couple of threads where people were having problems with small sections of video. The original poster uploaded a sample and a few various x264 tweaks were offered. They were generally fairly similar (tweaking the same options but by different amounts etc) and at the time I gave some of them a spin. Based on those test encodes (and admittedly even the couple of "experts" in the thread failed to suggest 2 pass encoding as an alternative, so all the encoding tests were done using CRF encoding) I came to the tentative conclusion that tweaking the encoder offered very little gain. Not because some of the suggested tweaks weren't effective, one of them in particular encoded the video very well, but all increased the file size to some degree, and then it became a question of "if you're going to increase the file size, why not just lower the CRF value in the first place?" Because according to the tests I carried out, the best of the tweaks at CRF18 encoded the video with a fairly similar degree of accuracy as CRF16 defaults, only the output file size was slightly larger.
Of course I don't know if encoder "tweaks" would have the same effect on file size over the entire duration of a movie as lowering the CRF value would, but it certainly raised the question for me, and as a result I've never got around to doing much "tweak" testing since. I kind of figured you could spend time testing and apply tweaks to encode difficult video better, or you could just lower the CRF value and/or use a slower speed preset if need be and be done with it.

Well seeing as I've wasted a bit more time that I shouldn't have today, I wasted a little more and looked at a my encodes again, also comparing them to the source. I navigated to the middle of the video, stopped them all on identical frames, maximized them on the TV and switched between them. And I've still got to say, neither were perfect, but neither was worse than the other. The scene was of people eating at a table with a dark background, and I could switch between the two encodes and really nitpick, even say well over here the CRF did a slightly better job while over there 2 pass did it better, but when it came to comparing them both to the source that kind of changed a bit..... and this is still real nitpicking stuff because it's comparing frames a couple of feet from a 51" plasma..... once I added the source video into the mix while switching between them "better" was too subjective and "accuracy" took it's place and there was just no winner.

In the end I focused on one particular person's face (almost in the background) because that's where I could see the biggest compression differences between encodes, and while initially I assumed the 2 pass encode had done the better job there, once I compared them to the source it wasn't so simple.. The 2 pass encode burred his mouth a little more compared to the source, but when I looked at the shadow on the side of his face I thought maybe the 2 pass encode replicated the edges of it slightly more accurately, yet the CRF encode retained a tad more detail. I tried the same comparisons using a reflection off the table and even after switching between them numerous times I couldn't decide which encode got it closer to the source because it just came down to slight differences.

Finally I sat back while switching between them and trying to take the picture in as a whole to see if compared to the source one looked more accurate over-all, and I'll admit just by trying to get an over-all impression that way I'd probably have given the CRF encode a very marginal edge, but once again this is frame by frame nitpicking and the next frame 2 pass might be the winner. Normal viewing distance, normal playback speed, they're effectively the same.
It did occur to me right near the end that maybe if I switched MPC-HC to a different resizer and went through the process again.....

Anyway I'm pretty convinced. Yes when comparing my CRF 18 and 2 pass encodes there are compression differences to be seen frame by frame, but the upshot of it is neither equates to a quality difference as such and at normal playback speed they're effectively identical. I'll try some more testing in a day or two.

[Slipster]

...

[hello_hello]

Maybe it was somewhat my fault, but I guess we weren't exactly on the same page with this CRF vs 2 pass discussion, in relation to "tweaks vs no tweaks" at least, although I thought I was pretty clear from the get-go I'd be starting out using x264 defaults. However I think we're on the same page now anyway. So.... and even though I've only run one 2 pass vs CRF comparison encode without tweaks, for the moment I'm going to make the possibly hasty assumption that when using x264's defaults, the results of a CRF encode and a 2 pass encode at the same bitrate.... at least at the medium to high quality end of the quality scale.... are going to be pretty much the same. So whether it's ultimately correct or not.....
With that in mind my next comparison encodes will be while using your MediaCoder preset, using MediaCoder as the GUI, and while re-encoding the same DVD to see what CRF vs 2 pass then looks like to me. So if I do that using CRF 20 as the birate for the 2 pass encode (your settings each time), that's fine?
Assuming I get the same results you do, then I'll probably do the same again while duplicating your settings in MeGUI just to make sure nothing changes. Unless of course you've already gone MeGUI crazy and used it to confirm the results are the same as when using MediaCoder yourself. Thinking about it, I might even run another MeGUI encode using the same CRF value (20), but instead of using your settings I'll go with x264's defaults. Just to see what the quality differences might be, and of course to marvel at the 30% file size reduction for myself. Seriously though, I'm not clear what to expect there. Should I see a quality drop using x264's defaults, a file size increase, or some combination of the two etc?
I guess once we're on the same page after I've run some comparison encodes using your settings..... well maybe I'll wait to see if we are before I get ahead of myself......

Regarding your encoder tweaks..... I'm not arguing with anything you're saying, I haven't tried them for myself, but much of the time when it comes to encoder tweaking I've found myself asking, "well if that's obviously better, why isn't that the default setting?". A rhetorical question I suppose.... I'm thinking out loud a bit, but I came to similar conclusions even back in the days of playing with various Xvid matrices.... sure, at bitrate "X", matrix "X" was probably best on average, and at bitrate "Y" matrix "Y did a pretty good job, but once bitrate stopped becoming the determining quality factor as such..... meaning once you aimed for quality and let the bitrate be whatever it needs to be.... well I kept going back to the standard h263 matrix.

Anyway.... I had a quick look at your videos, but I'll need to come back to it when I can dedicate more time and not rush it..... either encode, VGA vs HDMI, I'm not sure the TV inputs looked any different. Same input, 2 pass vs CRF, first impression at least, 2 pass looks a little better, but I did stop the video on a quite a few identical frames and for a few of them 2 pass looked better, a few CRF, there were a couple where I thought CRF left 2 pass for dead..... but realistically, while at first look I'd probably give 2 pass the gold star there, we're still comparing average with average, or average with a little more average. I'm not sure I'm seeing "2 pass good, CRF bad" as such yet. At least when sitting a few feet from a 51" screen.

The first thing I thought when looking at your encodes (and this is nothing to do with the actual encoding) is "wow, that looks wrong". So I broke out my encodes taken from a 23.976fps Bluray source and looked at the same scenes..... what a difference. I haven't watched mine for maybe a year or more, but even if I'm mentally backward when it comes to picking encoding differences, that I noticed right off the bat. For some reason, it appears the contrast was given a good nudge and the color saturation reduced a bit for the PAL version.... or they fixed it for the Bluray transfer, or maybe the DVD version assumed a CRT would be used..... I don't know.... whatever the reason, the Bluray version looks noticeably better (resolution aside).

HDMI vs VGA.... well maybe when I was comparing the two originally I just didn't pick the right videos..... although thinking about it when I first bought the TV I didn't have a DVI to HDMI cable so I was comparing PC/VGA to HDMI connected Bluray players. I came to the conclusion pretty quickly the two players here weren't created equally, but there wasn't any loss of detail playing the same video via VGA.... least not from what I recall. But anyway, rather than argue without checking, I checked...... using the Firefly Bluray encode. I tried pausing on identical scenes and switching TV inputs (both PCs running MPC-HC and using the same brand/model video card). I guess you could say the HDMI input has more detail if noise is detail, but yeah I do see what you're saying. I'm sure I didn't see the same VGA difference when comparing it to the Bluray player..... I might have to try that later as an experiment with this video.... PC vs Bluray player, both via HDMI.

Anyway. I really should get out of here now. To be continued.......

[Slipster]

...

[hello_hello]

Okay..... so I'm understanding this..... you want me to use your preset to run a 2 pass encode and if I've got the right preset, it uses a bitrate of 1333Kbps. Have I got the right preset? Then you want me to run a CRF 20 encode and compare the two. I can do that, but isn't it comparing apples and oranges if the bitrate for the CRF encode is significantly different? I figured I'd be doing it the other way around.... CRF 20 first, then the resulting bitrate for 2 passes.

I'm with you on the running out of patience bit. As I'm not familiar with it, MediaCoder quickly tests mine.
For instance when I load your preset and put the interface into expert mode, MediaCoder displays the command line under the Video Options tab. I'd expected changing an encoder option would also change the command line but that seems not to be the case. I'm happy to just go with your preset for the tests, but if I change stuff at some stage I don't know whether it's having an effect or not. I've tried ticking and unticking the "auto" box, but the only difference seems to be one way the whole command line is repeated under Video Options, while the other way it isn't, yet either way none of the parameters change.

Edit: Okay I got that MediaCoder stuff a bit wrong but the problem's still similar. According to MeGUI, the different "Tune" presets change the --deblock setting. So it appears your preset uses "--tune film" even though "--tune film" isn't in the command line, as "--deblock -1:-1" does the same thing, but once your preset is loaded if I change the tuning option to (for example) Grain, I get "--tune grain" and "--deblock -1:-1" in the command line yet MeGUI says the Grain tuning uses --deblock -2:-2. So which is MediaCoder going to use?
And now while I'm playing if I change an option... b frames as an example again.... the b frame value in the command line is changing accordingly, while I'm 100% sure earlier it wasn't. Mediacoder is doing my head in....

Edit 2: And now I'm really confused because if I choose Grain as the tuning and --tune grain is added to the command line, and I then load your preset, --tune grain remains in the command line. I'm really having a hard time trying to work out wtf this program is doing.

I did try experimenting with resizers at one stage, although I tend not to use ffdshow for playback so I'm limited to the MPC-HC options, but I did try an experiment only recently.... taking the same DVD and resizing it to 1024x576 (or therabouts) before encoding using spline36, then anamorphic encoding without any resizing. The difference on playback was fairly obvious... well at least up close when pausing the two encodes on identical frames using MPC-HC to do the resizing.... the 1024x576 encode was noticeably sharper than the anamorphic encode, which in turn, for reasons I don't understand, was a little sharper again than the original DVD.
Experimenting just by changing MPC-HC's resizer a while back, I settled on sticking with a softer resizer, mainly because while a sharper resizer no doubt looked sharper for HD video, for average quality AVIs (of which I have plenty) I preferred not to sharpen the compression artifacts, and back at normal viewing distance I'm not sure I could see any difference in resizers when playing HD video anyway.

I don't think the Firefly contrast difference is anything to do with your encoder settings. I thought about it later and while I'm not sure I didn't give the discs away, I'm fairly sure at one stage I had Firefly AVIs encoded from DVD myself and I'm sure the contrast/color difference was the same. In fact the more I think about it.... I have a feeling at the time I wanted to keep an AVI copy so I encoded them using the Bluray source for that very reason. The resulting AVIs looked better (they retained a little more detail but it was mainly due to the contrast/color reason). I've probably still got those encodes burned to disc somewhere. I might try to dig them out later.
I've encoded lots of HD sources as AVI in the past and compared them to my old DVD encodes. Aside from it confirming ITU DVD resizing is rarely used (at least in PAL-land), and the potential for AVIs taken from a HD source to retain a little more detail, it's surprised me how often the colors are different (ignoring NTSC's natural horridness). But sometimes they're identical. The Back To The Future trilogy and the Pirates Of The Caribbean series come to mind. I think in both those cases I could have easily kept the original DVD encodes without missing out on anything. Not because the Bluray quality was bad but because for a change the DVD quality was quite good.

By the way.... did you happen to see my post regarding ReplayGain and target volume? This one? https://forum.videohelp.com/threads/348212-Looking-for-copy-of-avs2avi-wrapper-v0-3?p=2...=1#post2184315
You apeared in the thread briefly but I thought maybe you'd have some thoughts on what to my way of thinking just shouldn't happen. I've only experimented using a single dts source so far.... that's something else I mean to get back to when I have a chance.

[Slipster]

...

[hello_hello]

Can't stay for long, but I'm running the first MediaCoder encode as we speak. I gave up, uninstalled it, re-installed it then immediately loaded your preset. Seemed to work. The only things I changed aside from cropping was to make sure everything under effects was disabled (I think Auto Level was set to full range for some reason so I disabled it) including Deblocking given I didn't use any when encoding this DVD with MeGUI and I've already run a CRF20 encode with default x264 settings to use as my quality starting point. I'm not sure I've ever encoded a DVD with deblocking enabled anyway. I also disabled de-interlacing as the video is progressive.

The video looks correct in the preview window and I've selected "keep pixel aspect ratio" so I'm hoping I'm encoding this "as-is" without any resizing, but MediaCoder's summary tab still insists the output will be 720x576 even though Resize is unchecked..... I don't know what to believe but if I think the output is anything other than 716x424 anamorphic I'm just going to uninstall this thing and give up.
On "keep pixel aspect ratio"..... which pixel aspect ratio are we referring to for DVDs? Not that it probably matters for the purpose of this exercise as I can always modify the aspect ratio later if the resolution is correct, but which DVD resizing method does MediaCoder use and can you change it?

Oh...... and I just noticed Color Space is set to I420. I'm not sure if that's a good thing or not so I changed it to Original, cancelled the encode and started again.

One other thing I can't work out... can you set up multiple encoding jobs, add them to a job queue and then run them? I'm not seeing an obvious way to encode using anything other than the currently selected parameters. No way to load a video, crop it this way, encoded it with encoder A using these options, add it to the job queue, load another video, crop it that way, resize it this way, encode it with encoder B using these options, add it to the job queue.... that sort of thing? If not, how do you use this program?? I've literally set up and added enough encoding jobs to the job queue using AutoGK or MeGUI to keep either of them busy for well over a day and just left them to get on with it, yet there's no way I could do it if every job had to be cropped/resized/filtered and encoded in exactly the same way.

Oh.... and all those presets in the MediaCoder\codecs\ffpresets sub folder. The 40 or so with the ffpreset extension. How do you load them? The MediaCoder preset function only seems to want to play with xml files.

Anyway, got to fly...... hopefully when I get back this encode will have the correct resolution/aspect ratio and I can start on the CRF 20 version. I'll be interested to see how this 2 pass compares to x264 defaults.
CRF18, slow x264 speed preset gave me a 1247MB output (audio not included).
CRF20, medium x264 speed preset gave me a 920 MB output (I haven't compared those two yet).
Slipster MediaCoder preset will give me a 1402 MB file according to MediaCoder. Should be awesome!

That was odd. I thought I caught a flash out of the corner of my eye. Maybe it was the monitors flickering, but both PCs immediately popped up with a "network cable disconnected" type message which quickly went away again. Spooky......


Ahhhhh.... a program which automatically minimizes itself to the statusbar when you use the "Show Desktop" Quicklauch shortcut. Now I really do hate it......

[Slipster]

...

[hello_hello]

So now deblocking, colorspace and cropping are new qualifications you're throwing into the mix? Even if you originally qualified your CRF vs 2 pass claims by saying it only applies to using your particular preset/encoder tweaks, I think compulsory de-blocking, colorspace conversion and resolutions might have rated a mention. To be honest had I known, I doubt I'd have considered doing these comparison encodes. For the record, what decisions are we allowed to make when encoding.

Anyway, I'm running a CRF20 encode using the same settings as previously, although whether I start again while including color space conversion and deblocking etc later, I'm almost at the "what's the point" stage now, given with or without them I can't see the CRF20 encode having a bitrate close to 1333Kbps so I'm not really sure what I'd be achieving by attempting to compare the two. After noticing your deblock setting I thought maybe I'd re-run the MeGUI encodes with it included, although at this stage I don't think it'll change much. My primary interest was whether my claim CRF and 2 pass encoding at the same bitrate being identical is accurate or not. If it's not accurate only when applying specific filtering, color space conversions and using particular resolutions.... well maybe if you try some comparison encodes without enforcing those restrictions and your results change.....

When it comes to resizing and cropping I'm only doing what a fair percentage of the people who encode DVDs do.... crop the black bars, remove any crud and encode the video at the resolution remaining.... ie pixel for pixel. In this case it's black bars plus 2 pixels each side. How that'd change the results I'm not sure given resizing when encoding is removed from the equation, but I think if it's necessary to resize to standard definition resolutions or refrain from cropping etc then I'll give up at this point.

I had a look at the 2 pass encode using your settings minus deblocking and color space conversion and did a bit of comparing to the MeGUI CRF18 encode as it's got the closest bitrate to 1333Kbps... although it's still 155Kbps light. Quality differences? No. It's late here and I'm getting tired so I've not done an extensive comparison but I watched the two side by side briefly and couldn't see any differences, then I tried pausing on a few identical frames and switching between them. The only real difference I could see, and once again this is just when comparing individual frames, is the encode using your preset (minus the stuff I mentioned above) probably reproduced the noise a little more accurately, whereas the CRF18 encode blurred it a little, and whether that's due to the use of Tune Film, a slightly higher bitrate, your specific x264 tweaks, or some combination of the three, I'd have to say if I had to picked which encode I'd prefer to look at (rather than pick accuracy) I'd probably go for the CRF18 version.
Aside from reproducing the noise a little more accurately, when it came to reproducing the images in the video in respect to detail and accuracy etc, the 1333Kbps encode using your settings and the CRF18 encode using x264 defaults seem all but identical so far.

For the record, the 2 pass MediaCoder encode gave me exactly the same resolution and aspect ratio as MeGUI, which is what I was after. I guess that also means MediaCoder doesn't use ITU resizing for DVDs (I generally don't, and I'm sure I didn't in this case).

Time for bed. I'll look at the CRF20 encode using your settings tomorrow (less the deblocking and color space converting), although given the inevitable bitrate differences between encodes, I'm not really sure why I'm doing it any more.

[hello_hello]

Well the CRF 20 encode using your settings finished while I slept. I might take a look at it later (I'm not awake enough yet) but after seeing the resulting file size relative to the CRF20 encode I ran using x264 defaults (even the default speed preset) your settings increased it from 918.3MB to 925.4MB (or a 7Kbps higher bit rate), so I can't imagine the two are going to look terribly different.

Looking at the encoder settings written to the video stream I guess the differences in reference frames etc might have allowed the encoder to compress the video more efficiently using your settings, and given using Tune Film generally increases the resulting file by size a reasonable amount I guess that's the case, so I may see some marginal quality improvements as a result.

I'm going to run another CRF20 encode using your settings (deblocking and color space conversion included) then a 2 pass encode using the same to compare the two, given the whole reason for this was to compare CRF and 2 pass at the same bitrate, but other than that I don't seem to have proved anything while running these tests.

PS Although I forgot MediaCoder doesn't like to refresh the settings displayed in the GUI and because loading your preset didn't seem to have an effect again I uninstalled MediaCoder and re-installed it again. Seems converting the color space to I420 is the MediaCoder default, although why I don't actually know. I really don't understand the logic behind setting Auto Level to Full Range but I've left it this time. It'll be interesting to see what difference it makes. The only change I made (aside from the same cropping and setting of the aspect ratio) was to disable auto de-interlacing as I know the video is progressive.

PPS If there's ever a DVD where you might want to apply deblocking, the one I'm playing with at the moment would be it. So I created a couple of AVIsynth scripts to open the video. One with no processing and one with deblocking enabled. I didn't get as far as comparing them using the TV as even on the CRT monitor the differences were obvious. Relative to not using any filtering, the deblocking (while it no doubt works) also removes a noticeable amount of fine detail as deblocking invariably does. I just can't imagine leaving blocking enabled by default. Each to their own, I guess.....

[Slipster]

...

[hello_hello]

So what's the logic behind converting the color space again?

Well I guess I'm not going to achieve much more by continuing. I can't replicate your CRF issue so far, even just using MeGUI, so I guess maybe it must be an x264 issue specific to certain hardware setups, probably being certain CPUs. What CPU are you running?
From my point of view, until yesterday, using your preset was only ever mentioned in reference to your particular encoder tweaking and comparing encoding accuracy. I had no reason to believe the preset would include compulsory resizing/cropping, color space conversions, deblocking etc as generally they're applied on an "as-needed" basis and never form part of any "how well can encoder "X" compress this video" discussion I've ever been involved in, so I don't see it as me moving the goal posts, it's something new of which I've only just been made aware.

I'm obsessed with the bitrate matching because it's ridiculous to try to compare results otherwise.

a) Cropping would skew results in favour of the 2-pass encoding at 1,333kbps when comparing it to CRF as the 2-pass encoding has more bits to share around when there are less pixels. As there is no direct relationship of bitrate to pixels, it would be impossible to calculate an exact adjustment to make to the 2-pass bitrate to guarantee unskewing it.

Then there's also a possibility the black bars, if they make up a good portion of the picture, could effect the way the actual picture area itself is compressed.
I'm fairly sure that was an issue back in the early days, ie black bars effecting encoding decisions in terms of over-all motion estimation in a frame, and probably the main reason why applying cropping became the defacto standard, but whether that still applies to x264 to any huge degree I'm not sure. If I recall correctly from the couple of times I've done it, leaving the black bars intact doesn't effect the final file size all that much when using CRF encoding. I can however think of at least one instance when I was encoding some DVD extras..... pretty much the entire DVD was 4:3, but in one case the image was actually letterboxed 16:9. Once I realized, I re-encoded it while cropping, keeping everything everything else the same (ie width in pixels and pixel aspect ratio unchanged) and much to my surprise, with the black bars cropped, the file size increased a little. I even repeated both encodes to make sure I hadn't done anything silly and got the same result again. So while this was probably only a 10 minute video, maybe less, it's at least one example where I've seen CRF encoding use a slightly higher bitrate in the absence of black bars.

b) When encoder tuning targets a specific target bitrate, adjusting away from this could skew the results away from 2-pass as the tunings are no longer optimal, so I'd have to encode possibly another 20,000,000 frames of video umpteen times to re-optimise the encoder tuning to suit your umpteen choices of target bitrate.

I'm not making any bitrate choices. That's being done by the CRF encoding, and that's the original topic. CRF vs 2 pass at the same bitrate.

c) Resizing in two different GUIs obviously might make a considerable difference as both are quite likely to be using different resizing methods that could affect picture quality drastically in one case and barely at all in the other.

In the same way deblocking using two different GUIs wouldn't?
But it's exactly why I didn't resize. I'm not sure why we're not on the same page there. I cropped the video in the same way each time. Each time I was left with 716x424 of active picture area. Each time I encoded the video using the same 716x424 resolution. The aspect ratio (same each time) is set while encoding and resizing is done on playback just as it would be when playing the original DVD. Had I done it any other way, then I would have been resizing while encoding, which is exactly why I didn't.

These statements are all contradictory, except that you'd voluntarily pick the result with lower accuracy of reproduction in a specific case where both files sizes nearly match which is, to my mind, just plain odd.

Nothing odd about it. I stated which one looked the most accurate, then which one I'd prefer to look at. I guess you'd have to see the encodes and frames I was checking to realize I wasn't actually contradicting myself.... in fact you described the result best while trying to defend the use of deblocking. Even if the CRF encoding didn't reproduce the noise completely accurately, it didn't noticeably strip any actual detail, but still retained genuine detail. Not really much different to applying deblocking in that respect. The end result mightn't be the same, but the principle is.

Original noise as part of the source is part of the source. It's not a separate entity. Original noise = original detail. Either you want to get closer to the original source within predictable file size limits or you don't. I'd assumed that you did. If you prefer something that looks less like the original then I'm at a loss as to what it is you're hoping to achieve with your encodings.

Exactly. Which is why I disabled, and I don't think when it comes to DVD encoding, I've ever used deblocking. How is deblocking anything other than noise filtering with a different name? I've experimented with deblocking lots of times using a few different deblocking methods, and I've never seen it applied without some loss of detail. But whether you think deblocking is a wonderful idea or you tend to dislike it as much as I do, either "original noise as part of the source is part of the source" or it's not. Either original noise = original detail or it doesn't. You can't have it both ways.

Maybe MediaCoder is making use of an adaptive deblocking filter that throws away next to nothing in terms of actual detail on largely static scenes but ramps up its effectiveness as the motion level increases in the same way that VirtualDub's MSU deblocking filter does?

Wishful thinking? Well given there's no point in my running any further CRF vs 2 pass encodes, because if for no other reason it appears I'm not going to be able to reproduce your CRF encoding issues, for funzies I might run a couple of comparison MediaCoder encodes with and without it (just some short sections of video). Whatever the result though, no matter how special it's deblocking might be, either it's altering the source in some way or it isn't.

It's been left enabled by default throughout all encoding here (after extensive testing proved it to be beneficial) and hasn't noticeably stripped any actual detail whilst giving an improvement in terms of compressibility that seems to allow the encoding to retain more genuine detail than it would otherwise keep, generally speaking.

No doubt, especially if you're encoding everything using a per-determined, one size fits all bitrate. However I don't, and while I wouldn't argue deblocking allows the encoder to compress the video more easily, in my case deblocking = lower bitrate, no deblocking = higher bitrate. Both of the same quality relative to their sources, even if one source includes deblocking.

Anyway, I'll leave you to ponder this while I run a couple of de-blocking test encodes. Screen shots saved by MPC-HC (reduced to 75%). I didn't bother posting any additional sceenshots, but the test encodes using MeGUI and those using your preset with the adjustments I made all display in exactly the same way as the original DVD on my PC using MPC-HC. It's only the encode using your preset untouched which doesn't.

Original DVD video:


MediaCoder encode using the Slipster preset without any additional adjustments:

[hello_hello]

Well I ran a couple of short test encodes, your preset, color/level conversion disabled, two with and two without deblocking, CRF15. I picked the two scenes I'd looked at earlier when testing out the effect of MeGUI's mpeg2 deblocking.

The first was very static, close up of the actors face, light background blocking. The second a fairly dark scene, blocking and noise for days. In both cases applying deblocking reduced the file size, so no doubt it was doing something, but in both cases while it didn't seem to have any visual effect on detail (just using my CRT monitor to compare them) it seemed not to do much in the way of deblocking either.

Tentative conclusion..... MediaCoder's deblocking doesn't appear to be doing anything special. It seems it just uses a less argessive deblocking threshhold than MeGUI does by default, hence retaining more detail but reducing the blocking by a far lesser degree.
No different to any other deblocking I've tried, I'd imagine. The more you crank it up, the better it deblocks and the more detail you lose. In the case of MediaCoder and it's deblocking, assuming what I've seen is typical, I'd agree it has virtually no effect on detail. Just don't expect to see much actual deblocking happening either. I could see some minor blurring of the worst of the blocking when comparing identical frames. Nothing more.

[Slipster]

I'm not going to waste my time by replying to your last two posts as pretty much everything has already been addressed in my previous replies umpteen times that you've clearly (and self-admittedly on more than one occasion)...

Sorry if I skip another of your posts...

...not even bothered to read. On that basis, I've removed them, as not reading them proves that my opinion is of very little interest or worth to you.

I'll stop short of labeling you as a troll, but the end effect has felt akin to being on the receiving end of a rather long and elaborate trolling session with questions being asked of me, answers being given, then the same questions being asked again and again.

[hello_hello]

Wow...... I'll confess, I'd never have picked you for someone who'd turn into a baby because he's not agreed with. You never can tell..... LOL! Which questions did I repeat in my last post, aside from asking why you convert the color space because you've ignored it each time. No answer given there, let alone repeated. Just a lie you're using to fool yourself.

I skipped a couple of your posts at the time because I was tired and needed to get some sleep, stating I would read them the next day, which I did. Of course you neglected to quote me there and you're obviously too busy having a tantrum to realize accusing me of not being interested in your opinion or failing to read your posts, given the number of times I've replied to them in detail, makes you look pretty childish. How old are you exactly?

And to be honest, after having run an encode using your all-wonderful, finely tuned, Slipster preset, unmodified in any way.... so little miss can't be wrong wouldn't keep complaining I'd failed to do so..... well if I refrained from letting the fact you use MediaCoder taint my view on whether you should be taken seriously..... encoding with your preset and looking at the mess it made of the levels certainly has. If that's how you're encoding and haven't realized.....
Anyway I wouldn't be offering links to your preset or advising anyone else to use it till it's fixed, because for someone who expects their opinion on encoding to be accepted as gospel.... it's quite embarrassing.

[jagabo]

Why did Slipster erase all his posts? I guess he wins then.

[hello_hello]

I guess so...... LOL! I hadn't realized till now he's deleted all of them. Wow.... it's been a while since I've seen anyone remove the evidence to that extent.....

[jagabo]

And not just this thread but a few others too!

BTW, I pretty much agree with you that, although there are some differences between CRF and 2-pass at the same bitrate, there's no clear-cut winner in terms of overall quality. The bigger issue is that you can't know what bitrate will deliver the quality you want with any particular video. So CRF has the advantage of always delivering the expected quality (relative to the source, obviously) in addition to being faster.

[hello_hello]

I was actually prepared to believe Slipster was experiencing some weird CRF encoding anomaly and 2 pass was better for him (I had no reason not to), although I'm not sure he actually offered any examples where that was obviously the case. There's always a chance there's a specific platform/version/CPU type bug I guess..... but I have serious doubts now..... and he's obviously not comparing apples with apples anyway. I thought we were having an adult discussion until his last post, even if I was finding it a bit frustrating myself at times. Why he's deleting his posts from other threads too, I don't know.

At least I tested the CRF vs 2 pass thing for myself again and learned a few things along the way. Seems even at the same average bitrate, slipster's theory on 2 pass using slightly different bitrates to CRF at any given time is probably correct, which also probably accounts for the small differences in the way individual frames are compressed, but as you said, it in no way equates to a perceived quality difference. At least not for me.

Oh well..... even if MediaCoder does some things in odd ways.... at least it seems to uninstall itself pretty cleanly.

[jagabo]

Yes, I tried duplicating his observations too. I used the CLI version of x264 to avoid any possible issues due to the GUI. I started with Blu-ray rips, reduced the frame size to 1280x720, then saved as lossless AVI. That AVI was the high quality starting point so I could easily compare the "original" to the encoded videos as well as the two encoded videos. As a general trend 2-pass may have been retaining a little more edge detail, at the expense of small scale, low contrast detail. There's something more going on than just variations in bitrate distribution.