Page 99 of 107

Re: LP Update/Comment Thread

Posted: Thu Jun 07, 2018 6:34 pm
by IskatuMesk
EDU 5-4 has been released. This EDU discusses XLR vs USB microphones and my experiences with the transition.

Re: LP Update/Comment Thread

Posted: Sat Jun 09, 2018 7:48 am
by KnoutOut
YES another EDU! Downloading that shit right away, sir!

Re: LP Update/Comment Thread

Posted: Wed Jun 20, 2018 12:11 am
by IskatuMesk
A new XXE has been released!

Re: LP Update/Comment Thread

Posted: Thu Jun 21, 2018 1:07 pm
by IskatuMesk
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 good.


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 - Encode

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 - New

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 - New

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 - New

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.


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?
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.
Yeah... no.

Re: LP Update/Comment Thread

Posted: Sun Jun 24, 2018 12:37 pm
by IskatuMesk
I have released a new coffee hour.

Re: LP Update/Comment Thread

Posted: Wed Jun 27, 2018 1:42 pm
by IskatuMesk
Today we're seeing a little bit of work on GP. Mostly updating some terminology, and I'll also be cleaning up some sections or whatever. Mostly small stuff. Eventually, probably later today, I'll be posting a new 2018 Encoding article that goes into the aforementioned subjects with a bit more clarity and research as well as some other new stuff.


While I've done some updating and some parts refer to the 2018 encoding article it isn't actually finished yet.

I've done some organization on the About Video Content section but I'm not done with it yet.

Re: LP Update/Comment Thread

Posted: Fri Jun 29, 2018 8:25 pm
by nu1x

Re: LP Update/Comment Thread

Posted: Fri Jun 29, 2018 8:48 pm
by SteakofStake
pressure cook my greasy balls

Re: LP Update/Comment Thread

Posted: Sun Jul 01, 2018 12:14 pm
by IskatuMesk
I was busy the last few days - processing and recording for once - so the article release got delayed a bit.

I still might clarify a few things like how the chroma subsampling works but overall it's ready for viewing. ... sing-guide

Re: LP Update/Comment Thread

Posted: Mon Jul 02, 2018 11:48 pm
by IskatuMesk
Alright, so I have even more developments for video media.

First off, we found a set of commands for megui that (should) replicate the encoding of ffmpeg described in the article. Once I test it and verify I'll add the information.

Second off, HKS spent all day trying to get OBS to be usable for my recordings. As it turns out, OBS only superficially supports lossless encoding - it has all the options necessary, but the result is this awful red bleeding.

Screenshot - OBS Capture

The cause? What appears to be some untested copypasta in OBS' code related to the colorspace handling. This bug has been well-known and reported ever since 2015, but because of the kneejerk reactions of "youtube doesn't support 444!!!" no one apparently has ever actually looked into it until today.

Now, according to my own testing...

Screenshot - OBS Capture

Other than the particle effect being different because it's actually a different frame, the screenshots are practically 1:1.

This is important because Fraps actually uses 420 Chroma Subsampling by default which, despite the high quality source/encode, still results in softening of the image and outright deleting of some fine details.

According to my tests with HKS' OBS build thus far, these are the following benefits.

> Truly accurate colors in all of my tests with no noticeable artifacting of any kind (all the encode features for x264 like ME are disabled and it's just fed raw bitrate)
> Significantly less performance impact. I tested FF14 and Skyrim and didn't really see much, if any, FPS hit.
> Significantly (up to 4x less or more) smaller file sizes for source files.
> Dual audio channels means defeating a long-hated nemesis troubling audio.
> Would likely be able to hook some things I couldn't hook before.

There are, however, some major caveats.

> Vegas doesn't support 444 chroma subsampling, period. I'll either need a different OBS profile or just use fraps for anything destined for vegas.
> OBS seems to have more trouble hooking games than fraps. Skyrim is a prime example, but FF14 also gave me major issues. Fullscreen programs seem to really struggle so far, but my sample size is very low.
> Highest quality audio OBS can spit out in this configuration is 320 AC3 VBR. That's not very good... and I've read that the VBR behavior of OBS is particularly bad. This will require testing.

The fact that Fraps encodes to 420 without the unusable Lossless RGB setting rules it out as a future-proof option. The more we get into understanding video codecs and forcing out archaic TV-oriented behavior the more we come to question the source material we're handing our pipeline. Particularly with Skyrim's intensive testing processes, in which circulates all the rescaling and other fuckery, I've wondered how much of our final product may be suffering from Fraps. After learning about Chroma Subsampling, I've just been feeling really disgusted by the total lack of support from Fraps' alleged developers for countless years. OBS is far from a polished product, but with source code modification HKS was able to get its shaky support for modern PC media up to spec. Really, Fraps doesn't even need much in the way of updates, just exposure of the settings it uses to manage its YUV encode. We'll never see that. Chances are if fraps ever does see an update it'll completely destroy what makes the program good to begin with. That tends to be the way these kinds of things go.

The OBS developments are super promising, but should I choose to switch all of my major recording to OBS I'm going to have to make some compromises when it comes to XXE and similar. I'll still need to use Fraps, or an entirely seperate OBS profile, and somehow remember to actually use them. It's the remembering part that will really get me. I'm hardwired to hammer the numpad + whenever anything pops up.

Whatever the case may be, when we finally see some new releases we're going to be looking at Fifth Generation for my LP's. Enough has changed, between the mic and the visuals, that we can declare new releases as being substantially more advanced than old ones.

Re: LP Update/Comment Thread

Posted: Mon Jul 09, 2018 8:35 pm
by IskatuMesk
Things are a mess with all the new encoding/video editing stuff but I can tell you I straight recorded a full LP in two sittings and it should be finished and released in a week or so if nothing else silly happens.

I also updated the article a bit.

Re: LP Update/Comment Thread

Posted: Sat Jul 14, 2018 10:37 pm
by IskatuMesk
Doom 2016 is now available!

This marks our first Fifth-Generation release and the first LP release in very close to a year. This run was the testbed for the proposed OBS pipeline and a vast swath of research that has slowly amassed ever since December. It represents the most significant updates to my encoding and recording process since I first switched away from Youtube, bringing us truly accurate 1:1 source picture, high-quality encoding and independently-processed mic and game audio.

Re: LP Update/Comment Thread

Posted: Mon Jul 23, 2018 1:50 am
by IskatuMesk
Kingdom Hearts is now available!

Re: LP Update/Comment Thread

Posted: Sat Jul 28, 2018 3:42 pm
by Jee-Host[gm]
Last XXE is following rich traditions of gargling down horse-flavored marmalade. Appreciate that, m8.

Re: LP Update/Comment Thread

Posted: Mon Jul 30, 2018 9:26 am
by IskatuMesk
You thought we'd get by a month without something stupid happening, didn't ya? Think again, bozo!

Now the government is withholding my grandmother's pension for no reason and every single bill imaginable is about to bounce in two days. It could take weeks to even find out why, much less do anything about it. We have no food and the cats have no food.

The ride never stops.