Doing It Wrong: Hardware Support, Null Frames, And Why You’re Overscanning Your Usefulness
Sure is a lot of updating from me recently, if you actually read/appreciate these pages upon pages of tl;dr and/or read them, leave a comment with your thoughts. It’s a bit depressing to see high stats on reading and 30~ comments across the entire blarg.
Everyone knows some guy with a DivX player right? Those guys that pop in CD’s with XviD or DivX DVD rips and whatnot on them and get to watch it on their TV, who haven’t yet figured out streaming matroska or watching MP4 AVC encodes? A lot of anime encoders still like to use XviD for “hardware compatibility” reasons. Some use H.264 but still in the AVI container, like “timecop”, but they are so utterly beyond help I don’t see any point in commenting here. There seem to be an awful lot of issues with these supposed hardware compatible encodes though. I’ll attempt to explain why, and hopefully people will stop using XviD/AVI or at least come to some concessions.
The three main fuckups I see in AVI encodes are overscan, variable framerates, and to a lesser degree, resolution. I’ll start with overscan. Overscan is something that happens on older (and some newer) TV’s, effectively anything that uses a cathode ray tube (ie, not LCD or Plasma, the bulky TV’s) along with flat-panels set to overscan mode for whatever silly reason. An image on a CRT can be broken into three parts: title-safe, action-safe, and overscan. Title-safe is the innermost part of a frame, where everything is certain to remain correct. Action-safe is a slightly larger area where somethings may be cut off but is usually ok, especially on the horizontal as far as subtitles go. Vertically, subtitles should always be in the title-safe region, which most often means a vertical padding margin of 5% of the vertical resolution. For example, for 720p, that would be 0.05 * 720, or 36px. About 5.5% however is the optimum reading zone for most people across almost all reading distances and font sizes. Overscan is the part that is guaranteed to be cut off.
I’m going to go and assume that anyone reading this is somewhat knowledgable about digital subtitling and is familiar with Aegisub. One of the lesser-known features of Aegisub is the overscan mask. It can be enabled under Video -> Show Overscan Mask. A blue mask will appear over your video. The darkest blue part is the overscan mask. The lighter, inner-blue part is the action-safe mask. The clear unmasked part of the picture is the title-safe section. Your subtitles should always vertically be within the title-safe section, and horizontally at least in the action-safe section. While you would imagine it preferable to be all within the title-safe region, on widescreen video the action-safe zone is actually quite wide, and very few CRT’s will actually cut it off. It also makes your subs look less crushed and bulky, and prevents multiple lines when going a tiny bit further can be achieved on one. You must always keep clear of the overscan-mask however.
Daiz wrote a decent page on some popular XviD re-encoders that appear on some torrent sites that supposedly support hardware playback yet don’t. It shows the masks in action and illustrates how each screenshot fails to fit what is needed properly. The supposed point of most of these re-encodes is to provide compatibility for hardware players, but every single one I have seen so far breaks 1 and occasionally 2 or even 3 of the things I mentioned above.
The AVI Container doesn’t support Variable Frame Rate. There is however a nify function called drop frames or null frames, which allows a frame to be dropped and the previous one to show through. This allows a way to ‘fake’ VFR, however it can make the framerate exceedingly high if you have somewhat arbitrary rates, as all different rates must have a common multiplier, most often 120fps. By using the null-frame trick, one can make a faked VFR AVI encode. There is only one problem: Hardware players BREAK HORRIFICALLY on null frames. It is completely unsupported in every player I have ever seen it on. So either you get fucked motion, or you don’t get hardware compatibility. Alternatively you can duplicate frames up to a rate, and make your file roughly 4x bigger, but I can’t say I’ve ever seen someone do this. Usually people use lower-resolution XviD encodes, so being twice the size of an HD matroska encode yet far poorer quality is somewhat silly. This especially goes for people backing up their DVD’s: if it’s VFR, don’t ever use AVI, you will ruin your motion if you intend to watch it on a hardware player.
Another limitation of hardware players is their strange need to be mod16, that is, the horizontal and vertical resolutions must be perfectly divisible by 16. That’s due to the way DCT codecs work and the fact that a macroblock is 16×16 in these codecs. The DivX specification’s max resolution is 720×480 and as such, the most ‘common’ resolution is 704×396 to keep to 16:9. The problem with 704×396 however is that it is not mod16. That would require 704×400, which is a lot more common now, but back when these low resolutions were mostly used it was far from it. It seems it’s gotten more of a following now, probably because the XviD codec is far more efficient at mod16 resolutions.
The final issue I’d like to bring up is the use of AVC in AVI. Using something as nice as the AVC codec in something as hacky and broken as the AVI container, which doesn’t support the codec fully in the first place, is just sheer stupidity. I would like to warn everyone against using Komisar and BugMaster’s shitty x264vfw. No matter what someone says, you do NOT need AVC in AVI and you do NOT need x264vfr. If you think you need these things, you need to educate yourself further.
Colour Matrices And Why Typesetters Make Encoders Look Bad
It seems that a lot of people still have issues with when and how colour matrix conversions should be used. After talking to some fellow encoders and a few typesetters I figured it was about time to write something useful here again.
There are two main colour matrices used in pretty much everything: ITU-Rec.709 and ITU-Rec.601. Contrary to popular belief, both use what we call TV levels, that is, on the luma scale, black is 16 and white is 235 as opposed to the PC levels of 0 and 255 respectively. Rec.709 (also called bt709 which I will use from now on) is used on HD material, that is anything with MORE than 576 pixels vertically, while bt601 is used on SD material, or anything up to and including 576 vertical pixels.
The trouble people seem to have is WHERE to use these. You can say that for anything at each of those resolutions, you will use what is appropriate, but what happens when someone takes a screenshot? Video is almost always encoded in the YV12 colourspace, yet screenshots are RGB. A conversion there needs to use the correct matrix, however most mediaplayers will assume bt601. Playback itself they will either read the stream info or assume based on resolution, but it isn’t so for screenshots most of the time.
As another example, what happens if you have something broadcast on an HD stream at bt709 but it’s really upscaled, and you decide to encode it at say 480p, which would you use? Effectively you can use the fancy colormatrix() plugin for avs to convert bt709 to bt601, but why not just flag the stream? It’s my own personal practice to convert SD material because I know people will screenshot it, and if it’s an SD encode, there is no point keeping the other matrix.
Furthermore, what happens when you need to process video? Most programs that use RGB outputs, say for encoding overlay files with an alpha channel, will assume bt601, I know VirtualDub and Adobe After Effects do. AutoDesk Inferno has an option to set it, although I’d assume AE does as well, but then again it isn’t something the industry likes to think about. So lets assume we have a source at bt709, and it’s HD. We then do some processing on it and output a lossless file for someone else to typeset onto, which is then encoded as RGB32, and overlayed with an alpha channel back onto the original clip. The following is a flowchart of sorts in how this normally goes, and results in incorrect colours:
Source (bt709 YV12) -> Processing (bt709 YV12) -> Lossless AVC (bt709 YV12) -> Typeset (bt601 RGBA) -> Overlayed (bt709 YV12)
You could of course encode your lossless as for example, Lagarith, at RGB24, but are you going to use a colourspace conversion in that? Yes. Are you going to do it yourself? No. The encoder will do it and assume bt601. The colours are then off. The correct way to do it would be to set your source going into the LAGS encoder as already RGB, pass that to the typesetter who has correct colours and outputs RGBA for you correctly, and everything is hunky dory. Example avs code that goes right at the end of the script:
ConvertToRGB24(matrix="Rec709")
That’s it. LAGS now has RGB data directly, and there is no problem. Because people get that wrong though, typesetters bork colours slightly (it’s really quite unnoticable to most people, and even then only on certainhues) and then the encoder looks stupid.
I think deciding which matrix to use in final encodes is really up to personal preference, as long as the stream has it correct there is no problem. All that matters is that the same colourspace is used consistently or if changed, any conversions are done correctly. Using the Colormatrix() filter is optional, if you intend to output bt601 then it’s a great way to start off in that colourspace (it goes in the header of your avs file, before anything that changes frames in any way is run) and if not, making sure to flag bt709 in x264 (–colormatrix bt709) should be done instead. At encoding time, flagging for bt601 is also good. I’d say for SD shows doing a bt601 encode is a better idea due to the aforementioned screenshot issue, but for HD stuff it’s ok to use bt601 as well really. Rec.709 is of course preferred for HD content.
I hope this has made it a little clearer about WHERE to put conversions and maybe one or two people actually learn something.
Racism? In MY Media Player? It’s More Likely Than You Think
Normally I am fairly lazy when it comes to muxing anything I encode, I have some shellscripts that do everything I need. After my CPU fiasco the other day, I have been rather edgy about what I do on my system, so a bunch of things I normally have open are being closed while I encode, with the encode being run in a screen session in case X dies on it due to RAM abuse or something. One thing I did was stop using my muxing script as well, although I don’t really see why anymore, I figure I had a reason at some stage. Yesterday, I used MKVMergeGUI (mmg) to mux an encode, and today, another. Because my script normally sets some things forcibly, it didn’t occur for me to double check it in mmg. This was when I found out the horrible truth: Several popular media player are racist against certain mimetypes.
Is there even a word for mimetype discrimination? I can’t think of one, but I’m sure Darkhold will if I cared to ask. Now, anyone who has experience with muxing fonts for soft subtitle styling will know that you have to be picky with what mimetype mkvmerge or whichever other muxer you choose to use writes in for each font. The works-for-everything mimetype is application/x-truetype-font, however by default, opentype fonts get written in as application/vnd.ms-opentype and some others get even stranger. From what my brief testing showed, MediaPlayer Classic – Home Cinema (MPC-HC) works correctly regardless. ZoomPlayer and MPlayer seem to break on that but are fine with the general application/x-font or application/x-truetype-font. VLC breaks on everything besides application/x-truetype-font, and it seems gstreamer based splitters/players will fallback to the font file extension to get it right, which is interesting as normally gstreamer Does It Wrong(tm).
I did find however that mplayer is able to link back into the system fonts if it cannot find what it needs. This made testing a bit annoying but once I had spoken to Greg, the lead libass developer, everyone became clear. So in summary, always mux your fonts as application/x-font to ensure it works correctly on all good players, even if they are discriminatory against your native mimetypes. Chances are I am the only one who would ever forget this anyway, but it’s always good to point things out to people who don’t know.
Bonus Points: Find my discriminatory comment in this post.
On the Topic of Stupid
“If I master a movie with Windows Movie Maker and I burn it to a DVD-R as a DVD, how can I get it back onto the computer?”
…was the question that I was just asked. Besides the stupidity of using WMM, what really got to me here was the way he tried to sound so knowledgeable about the topic. I would imagine that if he was able to encode the thing, he would have a copy already on his computer, but apparently not. Short post that isn’t really important but is just a minor vent about encoders being retarded.
In that regard, a Certain Man in Sydney that I will not name has gone and shown himself to be just as stupid as I suspected by going on about how great encoding on servers is. Sure it’s faster on the upload and possibly on the processing depending on the gear, but that doesn’t make it better. For one thing, CLI encoding is almost impossible to watch over and ensure quality on. YATTA isn’t exactly made for server use either. Fuck you, CommieSubs, for bothering to put out shit when all you do is kill the scene.
Wafflesub
Earlier today, ScR3WiEuS was complaining about the current splashscreen of Aegisub being rather weird, especially as he got strange looks from people every time he opened it. Personally, I think movax’s imouto is fine, if a bit dull, but it’s no big deal. Screw requested we replace it with waffles. Never one to back down from lulz, I came up with this patch. It works on the WINDOWS version of aegisub, specifically r2494.
The patch includes, but is not limited to, waffles, maple syrup, butter, strawberries, and aegisub. It does not include delicious imouto. The actual replacement image is as follows, however the two others are options I guess I could use. Can be applied to linux as well if/when I care. Also I suck at burn effects, and the warp is kinda wonky.
I Hate Typesetters
I really hate it when typesetters don’t set the resolution for the script properly. Especially when I just burnt 350MB of my bandwidth on an encode and script that isn’t that great. Not to say it was bad video wise, but I saw no reason for the HUEG filesize given that on my 1080p monitor the SD encode looks about the same.
What does shit me off is when the subs are set for 704×400, and libass being broken as fuck but fairly good at what it does scales the \pos tags in the sub track, as floats. VSFilter on the other hand (I’m assuming here, but it seems the most valid explanation) uses an integer. For the non-coders, this means that when libass scales positioning tags, it creates decimals, while VSFilter truncates that down to a solid number. That or VSFilter is capable of rendering to decimals, whichever. Point is libass can’t render to decimal and therefore shits itself.
It’s really not hard for typesetters to fix this. Static and Eclipse do it all the time, Menclave are starting to. Shinsen on the other hand seem to think there is nothing wrong with it. From a windows user point of view, yeah, its fairly ok, as 99% of windows users will be using VSFilter anyway. However SHS DO tell people to use mplayer on linux/OSX/whatever, which uses libass, thus rendering incorrectly like so.
Clearly not everyone will be pissed at this, but for the increasingly large number of mplayer users, it’s goddamn annoying and so easy for the group to fix. You can argue the user can demux it themselves and fix, but honestly is it that hard for the typesetter to do? I normally get the SD encode and accidentally grabbed the HD today, I guess I learnt my lesson.
TL;DR fuck shinsen and any other typesetters that don’t set the res properly.
Matroska Attachment Scripting
Earlier today, martino asked in #darkhold about extracting large ammounts of fonts and other attachments from mkv files. Noting that on linux there is no mkvextract gui, I went ahead and wrote a poorly formatted script. Copy to where ever and run it how you will, syntax is ./mkvattachex.sh infile.mkv a b c, where a, b, and c are optional. a is the number of video tracks, b the number of audio, and c the number of subtitle tracks. These are important so that the script can tail properly however I am pretty sure I can fix this. Defaults are all 1 so if it’s a standard file with only 1 of each then they can be ignored. The script will extract all attachments, which generally means all included fonts. I have no idea if it will kill your system and if it does, as always, blame movax.
Here be the actual script, I’ll be updating it later on with proper functionality:
http://ophion.pastebin.com/f8437ff2
Ordered Chapters and You
One of the most interesting features of the Matroska container is Ordered Chapters. Admitedly until recently I wasn’t such a big fan of it, due to lack of support for them in linux, or anything other than Haali’s splitter really. I understood the point and found them to be clever and useful (although after using them I disabled it due to not wanting to have to watch the OP of a series at the time) however I never really thought much about how good they are. Recently Kovensky and elenril patched the mplayer PKGBUILD for Ophion, it now has support for ordered chapters.
Ordered chapters are a function of matroska that allows segments of a file to be externally linked. Think of the video file as a php web page for example. Obviously the site looks like 1 big page, but on the server end its a series of php includes to ‘mux’ a bigger file out of. With ordered chapters, segments are linked to allow clips from other files to be included in the main file without it being seen by the viewer. Take for example the DVD rip of Shigofumi I am watching at the moment. The episodes themselves contain the opening scene, the main episode, the ending, and the next episode preview, but no opening theme song. The OP is a separate file, but with ordered chapters in my mplayer, smplayer reads it like one file, along with timestamps and subtitles.
It took a bit of tweaking to get subtitles using the ssa/ass library to work (-correct-pts in mplayer options will fix it) however I’m pretty happy with it now. I haven’t commited the new package to the repository yet, considering making a testing repository, but it all seems fairly solid and stable so far. If anyone would like to try it out, the package can ge found here.
For more information, read what TheFluff has written over on Walls of TL;DR
Speaking of fail…
Also, xvid in matroska, upscaling, streamrip, fail ivtc, and a whole host of other problems. Please don’t watch this, for your eyes sake. Also mkvmerge used is 3 major versions out of date.
#Ophion
[09:23:50] <rofflwaffls> mkfifo + wget + mplayer = instant streaming :D
[09:26:09] <Kovensky> uhh…
[09:26:15] <Kovensky> why not just mplayer? :V
[09:26:22] <Kovensky> mplayer can open http:// and ftp://
[09:26:32] <rofflwaffls> uhhh
[09:26:36] * rofflwaffls facepalms
[09:26:43] <rofflwaffls> how did i not think of that
That’s my lulz for today. In other news we moved Ophion to git, I split the 64-bit repo into stable and sandpit on the actual repository, and added a few things, like sx264, a nice little Qt based x264 GUI. 32-bit is not yet updated, so keep that in mind. For 64-bit users, the new syntax is as follows:
[ophion-stable]
Server = http://emess.developersatlarge.com/packages/x86_64/stable[ophion-sandpit]
Server = http://emess.developersatlarge.com/packages/x86_64/sandpit
This should really go on the Ophion development blog but currently it’s not active. Any complaints about gitweb being down can go to rofflwaffls as well, as I didn’t break it.