Boot Optimisation Is Entirely Useless When You Reboot Once Or Twice A Year
A few months ago, I spent a weekend optimising the shit out of my system to the point where I could press the power on button and be fully logged into KDE with all my shit open in 8 seconds flat. It seemed like a cool idea at the time as I didn’t have an SSD and that was FuckingFast.png, however I didn’t really think about the fact that I reboot maybe 5 times a year (I totally hotload my kernel: don’t do this) and the fact that fsck likes to run every 90 days.
Enter KDE and nvidia collectively shitting themselves this morning somehow, and Xorg eating my CPU like it was ice cream in a heatwave. I managed to SSH in from another PC to get KDE to cleanly close down (didn’t actually work it seems) and then reboot the PC. At this point I had to leave my house in 5 minutes and needed to check something really important rather quickly. Then I got fscked. Hard. See, it never occurred to me that fsck would need to run on my enormous LVM, nor how long that would take.
I ended up checking what I needed to on my phone and then coming home a few hours later to see fsck at about 80%. Eventually it finished it’s shit and I got logged in to find my KDE session opening shit I closed months ago, and about 6 hours of YATTA work lost (maybe not) as it was open when the system crapped a brick. I still have no idea what happened, nor why YATTA was using 37% of my RAM yet still slow as hell, and where all my swap went, but at least I know that boot optimisation is entirely useless. I am totally getting an SSD in a few weeks to bring this down to sub 5 seconds.
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.
Theora, H.264, HTML5, and Why Software Patents Are Giving Everybody Fansub Ice Cream
DISCLAIMER: This post is mostly about debunking myths and incosistencies. I’m going to start off by stating that I don’t know all that much about software patents, and that I really don’t care about them or legality. If the GPL Legal Team wants to sent a van for me, go right ahead, I violate your shitty license daily and I’m not going to stop for some freetards and their dignity. Additionally, although I condone and support piracy in some circumstances, this does not include supporting piracy of most commercial applications, especially those of Adobe and Apple. I wholeheartedly support stealing whatever you want from Microsoft.
Recently, there has been a lot of talk of Mozilla and HTML5, specifically over the proposed video tag. Mozilla and Opera are opting for Ogg Theora while Apple and Google are going for AVC (H.264). While I am a long-time Opera user, the change away from Qt has not pleased me, and the 10.5 screenshots are ugly as sin, so it looks like I won’t be concerning myself with that any time soon. I hate GTK so Firefox isn’t really an issue either. That does of course leave me with no browser to use but I’ll figure something out. The important thing though is that Mozilla Firefox is the biggest open-source browser in the world, as far as numbers go, so using Theora as opposed to AVC is a bit of a problem, and that is where the issue that prompted this post came in.
There is what I like to think of as a communal uproar on the internet about this. A schism if you will. Everyone is divided on what Firefox should use, even though the team has said (for the moment) that they’re going with Theora. The one thing that really got to me is people assuming that OGG == Theora. This is not the case. Another problem is that people assume x264 is an open-source implementation of H.264, also not the case. This article really shows that off fairly well. While x264 is an encoder, H.264 is a standard. OGG is a container and Theora is a codec. People messing up their terms has made following articles like that one rather difficult at times.
The main problem as I see it is that people are disillusioned by what Theora is capable of, and exactly how the royalties for H.264 work. Freetards say things like “contribute to Theora to make it better then” but as the codec is patent-free, it is fairly limited in what can be added to it. There is very little more that Theora can do, and nothing it can do to even approach AVC’s quality.
H.264 on the other hand has some difficult to comprehend and confusing patents involved. As long as you don’t intend to sell your stuff publically enough to grab the MPEGLA’s attention, there is really no issue though. Not all patents are even valid outside of the US. A patent in America isn’t really going to mean much to someone in Europe as the European Patent Convention doesn’t allow software patents, and from the pool of developers I know quite a few are european. There are of course countries where AVC is patented in Europe, but I don’t think the MPEGLA isn’t going to track someone down to backwater Norway (or anywhere else) just to yell at them for using unlicensed H.264. If you encode something with AVC and stick it on your website, they’re hardly going to come after you. It certainly does explain a bit about why Madman and other silly companies use VP6 though.
Another thing I see a lot of is people going on about “x264 is ok to use, just not H.264!” As I wrote above, they are not comparable like that at all. Additionally, some people are writing that OGG/Theora have patents too, where they don’t at all. The whole point of Xiph is to have no patents, which is mostly why it’s so shit terrible. There is of course the ffmpeg project which sort of ignores patents altogether, although they are very heavy-handed on GPL violations, especially of their own work, to the point of a wall of shame. It just shows how childish and bigotted the FOSS community can be.
What it comes down to is that H.264 has royalties and patents, Theora does not. Theora can be used in anything but as it’s a piece of shit as far as codecs go, it shouldn’t be used under any circumstances. H.264 is free for non-commercial use, something people seem to either forget or ignore, and the fees for commercial use are usually covered by your software and/or hardware, and not as Ben Shwartz writes, completely separate.
For an Operating System or commercial encoder/decoder to say that distributing your AVC files may require an additional fee is entirely correct, and there is no problem with it. If you are using that software in the first place and distributing commercially, you can afford the fees anyway, they really aren’t that high, and they have thresholds on where they begin and are scaled depending on your needs. That is to day, if you distribute only one copy, or even more than one but still relatively small, say as a video editor for functions, the fees don’t really apply. The standard does have a royalty-free period to encourage adoption, which has also just been extended.
As far as royalties go for a browser to decode things, it would be far simpler for it to rely on the system. On windows that would mean using VFW to select a decoder, and in *nix, my guess is libavcodec. This really kills the argument that free browsers cannot decode AVC without having to pay for it. Nothing is stopping Mozilla from making a paid version of Firefox that links to MainConcept’s decoder but I hardly see the point in that: almost all video online currently is H.264 and the browser handles that perfectly well in the flashplayers, why does it need to suddenly stop handling it so well?
Furthermore, along with codec wars, people are starting to get into container wars. There has always been a cold war as far as containers go (Hi NUT) but the arguments that one cannot stream Matroska for example are just ridiculous. Almost all streaming now is just sequential downloading of the file or beginning from a specific point and then downloading, as opposed to ‘real’ streaming. Calling a container a codec or incapable of streaming just shows off people’s ignorance and stupidity.
Naturally there is some contestation in the business world, something Jason Garret-Glaser (Dark Shikari) covers extremely well over at his blog, mostly about Adobe trying to take over the world and how everything besides Windows is irrelevant. In Ben Schwartz’s article above, Aki Jäntti (Kuukunen) makes some interesting comments about comparisons of AVC and Theora, and how optimisation effects it.
I too was present during the discussion of the –tune option in x264, and the developers really did put a lot of thought into it, especially on the Touhou setting. Something to note is that a game like Touhou is excellent for comparing codecs, its rapid changes in motion and bright simple colour make it rather good for testing at lower bitrates, which is about the only thing Theora is capable of being compared against.
I believe that most people comparing codecs aren’t really good at optimising all the codecs they’re working with, and as such most comparisons are skewed. As far as commercial use goes, x264 is on the brink of nal-hrd being committed, and once VFR works with nal-hrd I would imagine x264 could then be used for mastering standards compliant blurays, and would become a real contender. As far as visual quality is concerned, x264 is by FAR the best encoder in the world at this point in time.
Finally, to link this all back to patents and ice cream, this comic shows what I am talking about rather aptly. People in the FOSS community are so anti-patent and buying ANYTHING that they will use any free alternative, no matter what. They shun people for deciding against free things even if there is no better commercial option purely because they believe too strongly in flawed ideals. This is the main problem in the argument against AVC and for Theora in Firefox. They are too hung-up on using something free, even though it’s terrible, to notice that they CAN use H.264 without any problems. The entire argument is pointless, but it still drags on.
I think this is the longest post I’ve ever written, I completely and utterly blame stupid freetards for this, especially the Mozilla foundation, which honestly needs to die. Firefox is a terrible browser and I’m going to be an opinionated little elitist and not use it and there is nothing you can do about it. Long live x264 and Qt based webbrowsers.
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.
Telecide Will Kill Your Children
It was recently pointed out to me that Certain Content Authoring Communities are still living in the dark ages. I occasionally speak to someone who writes their ‘guides’ but really it’s about time things were updated, especially to be clearer on The PAL Situation. Long ago in the bleak days of everything being shit, Donald Graft wrote his Telecide filter, a filter for performing Inverse Telecine. For those familiar, IVTC requires both field matching and decimation of resulting duplicate frames. Telecide is the field matcher.
While speaking to a friend named Vincent, I discovered that a video he was showing me was a little jerky, so I took a look. It was quickly apparent that every 5th frame was a duplicate. A classic sign of field matching without decimation. So I said “Hey Vincent, what the fuck did you do?” to which he replied “Oh I just followed the guide on the .org, it says just use telecide().” He was quickly informed of a longer filterchain to use which included decimation, however this had me a bit worried.
Tritical’s excellent field matcher and decimation filters (TFM+TDecimate) were written years ago and are effectively the standards inside the non-shit open source video editing crowds. I still use telecide myself for specific reasons at times however for blind IVTC it’s mostly useless. I couldn’t comprehend why people were still using it, and then it hit me. ‘AMV Editors’ are fucking retarded and have no clue as to what they are doing in the slightest. Every last one of them. Learn to RTFM guys, it’s not hard.
tl;dr amvfags suck cocks and can’t encode for shit, everyone go use TFM+TDecimate now k <3
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.
Lucky For My Siblings That Homicide Is Illegal
This will be a short post, as I don’t trust myself to write anything that properly conveys my rage without murdering a member of my family. I like to download my TV shows. My sister likes to watch TV shows. Occasionally stuff I download and stuff she likes to watch overlap. This is what I refer to as the “Oh Shit” zone. Problems that arise in the Oh Shit zone usually happen when someone, in this case my sister, wants to use one of my machines, and has no idea how to. I guess she experimented and figured out I had a dropdown documents folder, and somehow got into my videos, and subsequently my TV. This is where Windows Syndrome kicked in.
Windows Syndrome is what I call the computer using habits of Windows users. They like everything to be all GUI friendly and clicky. My machine is not like that. At all. I play all my movies and whatnot from CLI. I barely use a GUI file browser. It stands to reason that I was unaware that the standard action for clicking a media file was that it would open in SMPlayer, a decent GUI for mplayer, and a SHIT GUI for mplayer-uau. I use mplayer-uau. I happened to go out last night with some friends before the new semester starts, and when I returned home, I remembered that I had left my SD keyring in my machine, and that it was completely unlocked and in KDE. This is where I got a bad feeling.
On reaching my computer, I prepared for the worst. I didn’t prepare enough. What greeted me was KDE, with no window borders, dmesg shitting bricks, conky going crazy, and a completely unresponsive desktop. Ctrl+Alt+fn+F2′ing to VT2 (sorry, apple keyboard) revealed something I did not expect. A shitload of smplayer cache processes, AND A BURNT OUT CORE. How in the hell did my sister manage to burn out a core by just watching a video in a player that throws a minor segfault on good days?
This is where I got a bit scared. I looked at the hostname, and that was when shit hit the fan. This was not my desktop, this was my main rendering box. An octocore Xeon setup. A very expensive octocore Xeon setup. I didn’t pay anywhere near full price as I got it second-hand but it still cost me rather a lot. I’ve since disabled the core in /sys/devices/system/cpu/online but I’m still running some tests on my beautiful ECC registered RAM and my Quadro 4800 but I am hoping extremely hard that it was just the CPU. Needless to say she won’t pay for it.
On the side, and this is just icing on the cake, she got pasta sauce or something on my insanely sexy scope node mouse. I laughed at that. Then I remote wiped her laptop. Petty vengeance is so satisfying. That concludes this episode of Emess Hates People Who Touch His Stuff.
The Only People Dumber Than The Scene Are The Industry
Long time since I’ve last posted as there is so much fail around I couldn’t think of anything special, but today I came across some comedy gold relating to video processing and encoding. I was speaking to a friend in The Video Industry this afternoon about why the hardware encoders we use suck. Now ‘Steve’ likes to think he knows a fair bit about things, as do most other video authoring type people. Unfortunately for them, they only really know the TOOLS they use, and not all that much about the content they work with.
Steve was telling me that his new IVTC machine is super awesome and capable of matching with the current, previous, and next frames unlike his old one that only did c/n matches. It’s all cutting edge in the industry apparently. He has declared that he can now compete with my own IVTC stuff now, except on a few really tricky clips we get from DVD imports. He still has no idea how I do it he says, but eventually he’ll beat me. I didn’t comment on tritical’s excellent TIVTC filters for avisynth doing what his expensive machine does for the past 6 years, or my own usage of YATTA, an extreme manual IVTC application.
Steve then gave me another GEM of wisdom. Apparently the latest AVC encoding hardware boxes have some really cool shit called FMO that my beloved x264 doesn’t have. I recalled speaking to Jason Garret-Glaser from the x264 project a while ago about the feature, where it was pointed out that FMO is only used in the extended AVC profile, which barely anything plays and nothing encodes fully anyway. What all the hardware DOES have though is pretty much everything that is stupid about AVC, and nothing that is good. x264 has CRF. I don’t even care about other features. CRF makes me happy every day. 2-pass encoding is stupid. The hardware boxes I have used all just pick a bitrate somewhat arbitrarily and then encode with it on a 2-pass program. They don’t have any fancy RDO or magic-block trees like x264, and they certainly don’t have the speed. If x264 had full BD standards support I don’t see the industry using shitty hardware and proprietary applications when they don’t have to, certainly not in small studios.
I think the point I am trying to make is that the industry relies too much on what it is TOLD is better as opposed to actually going out and evaluating different things. Quite a lot of free applications for various things insanely better than their professional adversaries. Sometimes, I hate working with these people, and at others I love the confused looks I get for using some obscure free software to do a job faster and better than their beloved machinery.
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.
This One’s on Kovensky
Kovensky linked me a VERY interesting article, particularly for Sonictail I believe: http://insanecoding.blogspot.com/2009/05/will-linux-ever-be-mainstream.html
I like how he goes on about Qt being awesome because frankly it is. Then Nokia pumped this out at the end of last year and it looks to finally be going somewhere interesting: http://labs.trolltech.com/blogs/2008/12/02/widgets-enter-the-third-dimension-wolfenqt/
The stuff in the first article is quite a good read for any tech people, especially the part at the end about how fixing the way X and *nix sound servers work coupled with Qt/OpenGL/Phonon would revolutionise gaming. I for one would love to see a natively built game using Qt like that. With a bit of simple hax it could even be rigged to work on Sony’s Phyre Engine, given it already uses OpenGL. Phonon support would not be hard to add, and if Phonon got support in the PS3 firmware Qt itself wouldn’t be far behind.
I can only see coding the PS3 interface from Sony’s part becoming easier with such a toolkit, if they are not already using it secretly internally, CyberLink seem to be.
Which actually gets me a bit annoyed. Has anyone else attempted to run CyberLink PowerDVD HD in WINE? It came with my BDROM. The first thing I noticed after it failing to do anything useful was that it used Qt, which really makes me wonder why they haven’t put out a *nix version of the software. Sure it uses custom UI blobs, but they’re all included in the binary and it should run perfectly well natively. The only problem I can see is that external software CyberLink provide, such as ArcSoft’s Home Theatre software, won’t run natively.
If a company has gone to the trouble of using a toolkit that runs in *nix, why haven’t they spoken to affiliate companies about a 3rd party native DTS-MA/True-HD decoder? Plenty of soundcards support *nix, and with it the decoding of these formats, so why are we not seeing anything? I think that article above really explains this quite well. Linux already has excelletn MPEG4-AVC decoding support, with VDPAU which even outperforms DXVA as far as GPU assisted decoding goes, why don’t we have the same thing for audio?
I seem to have answered my own question, the “audio situation” in linux specifically is terrible. FreeBSD has no problem. Solaris has no problem. OSX has no problem. Linux has OSS, ALSA, aRTS, PulseAudio, ESD… I could go on. They are all slow, they are all a pain to configure. Phonon is excellent but still acts as a server of sorts. All the factioning is destroying linux.
NB: I could be incorrect about CyberLink using Qt but I don’t believe so. Point still exists that we have the option of having an excellent OS yet factioning keeps destroying that possibility.