About: Formats & Playback
We do not provide technical assistance for setting up your player. The MPC guide is enough for any and all users. I verify all video files start to finish with MPC to be sure they are working. While it is unusual for me to miss problems, it does happen. If a very new release has a clear and reproducible issue, let me know ASAP and I'll investigate. I offer zero support for any alternative software and cannot guarantee they will function well or at all with my files. I especially do not support Chrome or VLC, and certain issues are well known that crop up only in these archaic players. Don't use them.
Having issues?
- Make sure you actually downloaded the entire file. Use DownThemAll or Jdownloader to manage downloads. 99% of reported problems are because of Western ISP's being extremely aggressive about throttling. Certain ISP's overseas, including some Swedish ones, throttle everything going through them, and the American infrastructure is anything but reliable. This has been well-documented, so it's your responsibility to make sure you have functional downloads in spite of this.
- Many recordings, especially those released after 2016, are 10bit (also known as Hi10), and recordings after Q2 2018 use i444 to ensure color accuracy. Older software may not support these modern standards, so if you have trouble with those files, it's time to upgrade.
- Never, ever, ever use a codec pack to try to fix your video player or any other such issue. This is like trying to bandaid a paper cut with a rusty cactus.
- Chrome can supposedly stream some videos, but I have received dozens of reports about compatibility issues. Do not use Chrome or VLC ever. Don't complain to me about problems with videos in these players. I don't support hipster software and goofy viewing methods, so I won't be configuring videos just to support them. Watch things the normal way.
It has been asked if people can re-upload my files to youtube. Don't. Youtube is a low quality experience that forces end users to download larger, badly recompressed files, and disconnects users from content producers e.g. me. I have no desire to support streaming in any shape or form, nor do I ever intend to put my content on third party servers.
Organization
Before being released for viewing, a video project must be processed in one of two ways which turns large source files into Canadian-acceptable sizes suitable for distribution. This process is called Encoding. Encoding is a complicated and computationally expensive process that takes a great deal of time to learn, and there is no one glove fits all solution for videos. Throughout my projects I aim ever higher for quality and size returns.
Segments -
A segment is effectively a "part" of a video. Video productions after a certain point in Third Generation are attempted to be divided by logical recording separations (referred to as sittings). These are periods in which I physically stopped the recording, general during idle time or between gameplay. Diving the videos like this, unlike earlier recordings which were exclusively time-based, results in less abrupt switches - but particularly long recordings may get divided into multiple segments, or multiple sittings may get lumped into one segment, and often times I have to pause during fights or such anyways. The primary distinction between a Segment and a Part is that Segments make no attempt to divide game content logically, only my actual recording activity.
When I encode a video I look to produce an average of time and filesize from segment 2 and onwards. Traditionally I try to make segment 1 shorter and smaller file. What combination of size and length I choose to go with depends on the source content and game, as well as what kind of settings I opt to use for the game. I use a variety of different quality settings tailored to specific kinds of releases. As I am Canadian and my host is American, and thus bandwidth is an extremely rare and valuable commodity, I must be ever conscious about file sizes, and I continually try to push the boundaries between size and quality. For a shorter production I may opt for a less size conscious encode. Generally speaking, I don't sacrifice noticeable macroblocking or degradation for size, and may employ resizing in very rare cases for supersampling extremely problematic encodes.
Generations
Generations are mostly time or event divided. Generation 1 LP's were my very first recordings and were distributed largely via youtube. Generation 2 LP's were more advanced and involved consoles as well, and were the first FTP distributions. Generation 3 began when my old mic died and I underwent several changes to my audio and video processing, so they sound different (should be better) and such. Generations are there for easy chronological sorting, although I will also provide encode dates to give a real-world idea of how old projects are.
Understanding Video Formats
Almost all videos are encoded in x264, and may be 8bit or 10bit, and may use aac or mp3 for audio, but commonly use ogg post-2019. These are codecs, and 8bit and 10bit refer to color depth. I traditionally use the mkv container for the video itself. If there are exceptions they are noted in the specific releases. "Containers" can typically hold a number of codecs, so one mkv may not contain the same kind of video or audio as another mkv.
Almost all of my releases are delivered in 30fps except for very early ones. Generally, I try to record most sprite-based console games as 60fps since the size increase is minimal, and I sometimes encounter oddities (like the sprite issues in Yoshi's Island).
A handful of videos, mostly League of Legends casts, have DUAL AUDIO. This means they have two audio channels (like Nippon and Engrish for Anime releases). MPC can switch between them at will.
Understanding Compression
My responsibility as a video content developer is to learn how to create the highest possible quality video while also taking advantage of the compression features available to me so the Canadian government doesn't knock down my door and send in a gaggle of malnourished foreign children armed with sharp sticks because I used the last drops of our extremely limited and finite bandwidth. It is a difficult subject to break into because of the vast amount of incomplete, inaccurate and blatantly misleading information on the internet.
A video is not simply a string of images like a flipbook. It is data that attempts to average between images - frames in this context - to produce a visibly coherent motion picture. The job of the codec is to reduce the amount of unique data between frames so it has to store less information, which means the resulting file will contain less information and thus be smaller. The process of deceiving the eyes into thinking a motion picture is different (re: higher quality in this example) than it really is has sometimes been refer to as psychovisuals. Compressing video is in large part about deception - pulling fidelity, color depth and information away from unimportant parts of the picture to devote more resources to important parts, and even reducing color fidelity and accuracy of individual pixel values.
Typically, aggressive compression is extremely bad because even the most distracted viewer will notice when a video is off-key in color or when artifacting from compression - just like a jpeg - manifests. However, compression is a complex subject and I've had to spend over a decade learning how to deal with it to produce reliable and high-quality results.
Compression is not linear
Videos with more motion, higher contrast, framerate and of course larger resolution equate to more information or make the codec work significantly harder to keep information stable. Therefore many elements, including ones that may seem insignificant like color depth and brightness, greatly impact the size of videos. For example Hunted will produce larger segments than Starcraft 2 because Hunted's textures are significantly higher resolution and produce more visual noise, there is more motion in the image and therefore less information can be shared between frames, and the contrast is typically harsher, further hurting the ability to share information between frames and individual pixels. Encoding is one of the most computationally complex and demanding processes in consumer media and there isn't really a one glove fits all solution, especially for one who isn't technically versed like me. Each project is a learning experience.
i444 and Color Ranges
i444 and i420 are settings that refer to Chroma Subsampling. In a nutshell, the i420 profile halves the color resolution of a video. You are literally axing the accuracy of the color information in a video by using this setting. i444 is a modern standard that disables this destructive behavior, but I only learned about it in 2018. The concept of crushing color dates back to the introduction of the Color TV as a result of a desire to preserve bandwidth in radio spectrums, and is a long deprecated and unnecessary concept that persists in modern media only out of sheer ignorance of content producers. The compression benefits offered by Chroma Subsampling even in extremely large media are negligible at the absolute best while the destructiveness of losing so much information hurts all viewers.
The Limited Color Range originates from analogue Cable TV for very much the same reasoning - to conserve space in a limited analog signal. It's still a standard that somehow survives to modern day on an entirely unrelated platform despite having long outlived what necessitated its existence. While some media players and many televisions upsample Limited Range to Full Range (16-235 to 0-255), it is not a pixel-accurate process and information is needlessly lost because content developers refuse to adopt the superior standard. We want to avoid such automated processes altogether, especially since compressing a limited-range video hands the x264 codec extremely inaccurate information that greatly diminishes its effectiveness.
As discussed in this article, during Q2 2018 I started releasing productions using i444 and proper full-range color profiles once I had learned enough about them to implement them seamlessly into my pipeline (as it turns out, i444 is extremely simple to get into once you fix the few lines of code intentionally ignored by OBS developers because lazy). Previously, videos had color inaccuracy and suboptimal compression due to using Analog TV standards from the 1950's. It is important to highlight this evolution in understanding the features of video media because most honeypots, such as Youtube, downsample media to the lowest possible quality settings and destroy visual authenticity in favor of, at best, marginal and unnoticeable file size compression gains that are then thrown away by extremely ineffecient configurations elsewhere. Using Mediainfo in MPC you can determine if a video is using accurate configurations or not - most media outside of this site won't be.
Using accurate colors ensures the compression coming out of x264 is accurate and efficient, and in fact allows me to save more space by using more aggressive settings elsewhere. For some media, however - especially those with extremely noisy post-processing - there is no way around having a large file if I want the result to be legible.
Youtube vs FTP
If you have to ask why a video producer prefers not to use an extremely shady, low-quality and unreliable service like youtube, you're probably not in the audience best suited for my productions.
If you wish to share my content with friends or family please link them the actual site. I do not endorse social media and have no desire to accrue public traffic.