h-hewwo? owo are you rdy for some fucksy wucksy?
Drunk Swedes catapulted us once more on a wacky wild adventure that is resulting in some updates to our encoding pipeline. These are very minor in the grand scheme of things, but the super annoying technicalities are worth bringing up and maybe making an article about once I discuss them, since they don't seem to be widely known much less discussed outside of specific about converting colorspace.Colorspaces are traps, are traps are gay
As we explored a half-year ago now, colorspaces are like dinosaurs that somehow endured God's almighty and just smiting of a hedonistic paradise and have transformed into these unsightly abominations in more shapes and sizes than you can shake a cute penis at. As discussed in this article
, I was running into issues with PTBI, component cables, and Limited (16-235) vs Full (0-255) colorspaces which were really fornicating with my Ico run.
It should go without saying, but the process of converting from Fraps to x264 is a similar process to the one of Playstation 3 to the monitor. It is highly unlikely that anyone sane is actually making the software responsible, so chances are there's a ton of rigamole cucks getting their spouses exchanged in the local leather club.
Indeed, that takes us right back to our initial problems with the fraps "Lossless RGB" feature. Remember how this destroyed my Men of War recordings? I don't easily forget such events. It's caused me other problems, too. Well, suffice to say, I've never used that feature because of this exact problem. By default, fraps uses something called yuvj
. This is pretty nice and dandy and all. Buut... our final encodes use something called yuv420p10le
Furthermore, Vegas doesn't support any of this crap when it comes to encode time, especially when you throw in the Frameserver which allegedly only supports 16-235 to begin with. Why would you make an encoding process that only supports an ancient and archaic colorspace only used by ancient and archaic hardware when 99% of the people who want to use this to avoid insane uncompressed filesizes are people working locally with digitally-produced footage? Because Vegas is a ridiculously illogical piece of software, so it makes sense everyone working for it is also insane.
More notable than the allegations of the Frameserver's limitations is this >
That's right... the Frameserver, and as far as I can tell Vegas itself, don't support the colorspace Fraps or the final encode are using.
And yet, our final encode does look pretty similar to the fraps source...
Except it doesn't, and never has.Fraps Source
- Encoded Frame
- Vegas Frame
There's two major things to note in these comparisons. The first is that, very clearly, the frame actually gets darker when encoded. It gets even more
dark when taken from Vegas. Also, the text completely changes colors in many cases - especially the blues. This in particular is very noticeable in WoW's recordings, where the red text is very commonly fucked up.
That's correct, the encodes, no matter what pipeline they use, have never been quite 1:1 with fraps, and fraps was never quite 1:1 with the game.
To cut a long-winded rabbit chase short, the Drunk Swede eventually concluded that in order to get otherwise lossless encodes with fraps you need to go through quite the overhaul in your configurations. The first is to use lossless RGB in fraps. Neither vegas nor the frameserver innately crush colors so long as you use lossless source from fraps
. The second trick is to use ffmpeg - because megui doesn't support RGB encoding for x264.
He didn't make these experiments because of my observations with fraps and my encodes, however. My observations came afterwards.Step On Me Daddy - An upscaling filter's tale
As it turns out, the actual frames for the videos are completely fucked.
Without getting into a real lengthy technical post about stuff I am not particularly educated on, I'll try to summarize it as best as possible.
With my videos, what you're seeing is not actually what the video file contains. Since it's YUV of some perverted nature, and not RGB, there is a conversion process going on, much like the upscaling PTBI was doing for 16-235 in that article. The difference here is that the YUV > RGB conversion process just happens to be really
Despite going through jpg and x264 compression, this colorband image generally only shows off by 1 errors. For comparison, using ConvertToRGB inside AVS resulted in an image that had error margins as high as 6 or 8.
The off by 1 errors are as a result of colorspace conversion. The neat fact is, is that x264 was never actually intended
to use PC range RGB to begin with - RGB was something added on later into the codec's lifespan, and megui doesn't support most of the functions ffmpeg itself does. The best part is, if you export the source frame with something like ffmpeg to bypass MPC's colorspace conversion 99 times out of 100 you'll end up with either a super blown out image or a very crushed one. The above colorband picture is one such frame, but captured from MPC - after a conversion has already been applied. It's pretty impressively close to the source given how destructive we've seen colorspace conversions be in the past. But it isn't ideal.
In a bizarre twist of fate, allegedly OBS doesn't suffer the same level of conversion issues Fraps does, since it isn't using fraps' mind blowingly stupid encoding garbage to begin with, provided it's configured correctly. That said, it still isn't 100% perfect. It's also unusable for me for anything besides desktop recordings and doesn't produce 10bit video, so it's out of the question for a solution to this anyways.
Ideally, you want to avoid this colorspace conversion you need to step in at every point in the pipeline to prevent colorspace conversion entirely and hand the video player something that both tells it not to convert and have no need to convert at all. However, the requirements for this are unfortunately where I run short.
First of all, in order to actually record fraps lossless RGB you need nearly double the IO speed. The bitrate for a few FF14 tests yields double the numbers - and up to 60% increase in file size. This means the hard disk speed demands for recording colossally increase and
the resulting filesize is astronomic. During a mere 15 minute test in a game that normally runs at a reliable 100+fps I was getting constant slowdowns and stalls that were very clearly as a result of io bandwidth strain. It's likely I could record 720p at this, but only at 30fps.
Second of all, you have to use ffmpeg and not megui. This isn't necessarily a problem in itself, though. It's just less convenient because I'd have to spend quite a while adapting all of my settings to ffmpeg and trying to get similar results. It's quite possible the resulting files would also see a size hike and an encoding speed hit as well, since I believe YUV and its iterations are in large part being used for performance reasons.
Even if I wanted to adopt this pipeline change I can't actually do it.
That's not where this tale ends, however. When I brought HKS into the slaptorium he brought up several new commands I know virtually nothing about.
--output-csp i444 --input-csp i444 --profile high444
A lot of x264 is based on something called Chroma Subsampling. I've read several discussions in which Fraps users lament the subsampling behavior of x264 and laud its ability to utterly destroy fraps footage. The problems they were having were nothing like mine, though. They described completely destroyed colors entirely. It did get my almonds activating, though - what does Chroma Subsampling actually do
and why is it relevant? No one seemed willing to part with this critical information.
So, I blindly tested HKS' suggestions.
When placed on Lossless RGB this had absolutely no impact. But, not one to give up on wasting more than necessary time on blind adventures, I tested it on standard fraps encodes.
Oh boy.Fraps Source
At first glance... the frames are practically identical.
So, with crow watch on the horizon, I decided to put these settings on something more testing. How about that XXE I just released?
Since getting source Fraps frames for this footage would be way too much a pain in the ass, I instead sought to see if I could see a transition from the old footage to the new footage that was consistent.
Test 1 - Old
Luminance increases just as if it was accounting for the luminance loss observed in earlier comparisons. Since this is CRF 28, the compression changes are too convoluted to really address.
Test 2 - Old
Steak's footage is ripped off of streaming websites. Its quality is atrocious. I was absolutely floored by these results. It's almost like the new encode is shredding a TV space conversion. That doesn't even make sense. How is that happening here? Maybe something else I changed during my tests did this... but even so, it's cleaner and more accurate.
Test 4 - Old
Test 3 is omitted from this post since it was different frames and I am an idiot, but it was basically a repeat of 1. This test is also different frames, but clear luminance changes are apparent across the interface in particular. This is consistent with adopting for changes observed in older comparisons. Furthermore, I did compare to the source footage but couldn't find the exact frame for this comparison, and the mid-glow ui was basically 1:1 with the new frame. However, since this footage is upscaled resolution-wise it makes for poor comparison to the source anyways.
The new XXE is about 60mb larger. I'll probably replace the old one sometime today with it. It isn't necessary to redownload it, unless you'd like to make comparisons yourself.Conclusion
In a structured test, the new settings HKS dug up seem to fix a ton of problems and make encodes 1:1 with source. However, there's some problems here. The encode is not actually 1:1, it's being converted internally and only superficially appears 1:1. In order to fix this and create wholly lossless colorspace conversions I'd need to do recordings my system can't handle. Since I'd rather not suffer insane performance loss and chew HD space even faster than I already do, I can't adopt those changes. Furthermore, due to the nature of x264 and related things, there's generally some kind of processing taking place anyways. To simply remove off by 1 errors it seems quite a hit to my already strained pipeline to adopt major changes.
What we did end up with was an improvement to visual quality overall, though.
The only question is why?https://www.rtings.com/tv/learn/chroma-subsampling
Chroma subsampling is a type of compression that reduces the color information in a signal in favor of luminance data. This reduces bandwidth without significantly affecting picture quality.
A signal with chroma 4:4:4 has no compression (so it is not subsampled) and transports both luminance and color data entirely. In a four by two array of pixels, 4:2:2 has half the chroma of 4:4:4, and 4:2:0 has a quarter of the color information available. The 4:2:2 signal will have half the sampling rate horizontally, but will maintain full sampling vertically. 4:2:0, on the other hand, will only sample colors out of half the pixels on the first row and ignores the second row of the sample completel
Indeed, x264 is a long-winded series of tricks and hacks in an effort to save space. Only thing is, the space we're saving by compressing in this manner is marginal at best (60mb in a 1.5gb encode is worthless) and the impact on the picture seems to be quite significant.
It also highlights that people complaining about Chroma Subsampling when using Fraps weren't aware of there being a setting that outright disables it.
There is virtually no advantage to using 4:4:4 for consuming video content. If anything, it would raise the costs of distribution by far more than its comparative visual impact.
While some PC games that have a strong focus on text might suffer from using chroma subsampling, most of them are either designed with it in mind or implement it within the game engine. Most gamers should therefore not worry about it.