Sensible Erection | Flash Royalties

Thursday, 29 March 2012

Flash Royalties

quote [ Starting Aug. 1, 2012, Adobe will begin taking a 9 percent cut of game developers’ net revenue over $50,000. ]

Didn't think HTML5 or iOS were the nail in Flash's coffin, but this might be.

http://www.adobe.com/devnet/flashplayer/articles/premium-features.html

[sci&tech] [by buckaroo50@9:29pmGMT] [+10 WTF]

Comments

Barnabas_Truman said @ 9:44pm GMT on 29th Mar
I wonder if they've tried updating shockwave.

sherlock said @ 9:50pm GMT on 29th Mar [Score:2 Informative]
To clarify, the royalties only need to be paid if you use both their 3D graphics API and "domain memory" which is some kind of native C/C++ sandboxing feature. Both of these are new features, and C/C++ support is not really necessary to make high quality next gen games on the web. You could get by with Actionscript just fine. Hell, with WebGL we've seen that even Javascript is fast enough since all the heavy lifting is done on the GPU if an application is programmed correctly.

Still, this news will benefit WebGL and other open, plugin-free standards.

buckaroo50 said @ 10:23pm GMT on 29th Mar
Yeah, and 99.999% of flash users won't run into this, but it's putting up another barrier for decisions on what to use for new projects... that is until Oracle starts charging royalties on javascript.

eIfish said @ 11:13pm GMT on 29th Mar
I understood ECMAScript's patents to have been freely licensed as part of its standardisation process?

But this is Oracle.

foobar said @ 11:55pm GMT on 29th Mar
Javascript has nothing whatsoever to do with Java.

eIfish said @ 12:04am GMT on 30th Mar
Except that they're both trademarks of former Sun Microsystems.

Oh, and they're both managed OO curly braces languages that run on a VM.

I might go sort wikipedia thinking that Sun wrote Javascript, but I'm not sure if I can be arsed.

foobar said @ 12:40am GMT on 30th Mar
Wikipedia correctly credits Netscape as the original developer.

How many modern languages don't use something similar to c/curly brace style? There's Python and...

sherlock said @ 12:46am GMT on 30th Mar
Ruby and MATLAB to name two.

sherlock said @ 12:49am GMT on 30th Mar
While we're on the subject of languages that require that you indent as part of their syntax ... what the hell were they thinking?

foobar said @ 1:00am GMT on 30th Mar
Religious wars don't just start themselves.

eIfish said @ 1:21am GMT on 30th Mar
I guess they really really Unified Diff...

manbaby said @ 3:51am GMT on 30th Mar
I don't mind it. The omission of curly braces contributes to the terse and readable style of the language. And honestly, how often do you not indent a block of code in a C-like language?

manbaby said @ 3:51am GMT on 30th Mar
(I should note that I was talking about Python, I don't think I've tried any other indentation-sensitive languages.)

foobar said @ 4:31am GMT on 30th Mar
Rarely, and the cases you see it can usually be done better with the ? operator.

EPT said @ 11:27am GMT on 30th Mar [Score:1 Interesting]
The dude who created python regrets the slavish adherence to whitespace rules it requires.

krupa said @ 7:39am GMT on 1st Apr
source?

mechanical contrivance said @ 12:18am GMT on 2nd Apr [Score:1 Funny]
No, that's usually html and javascript.

azazel said @ 9:38am GMT on 30th Mar
Why the hell not? Because blocks are denoted by indentation in Python, indentation is uniform in Python programs. And indentation is meaningful to us as readers. So because we have consistent code formatting, I can read somebody else's code and I'm not constantly tripping over, "Oh, I see. They're putting their curly braces here or there." I don't have to think about that. It also helps to avoid obfuscating code (which you don't want).

Honestly, it's mostly non-Python programmers that gripe about Python's indentation requirements; probably because they've never used it.

eIfish said @ 11:46am GMT on 30th Mar
Because it fucks things up royally if you want to use diff/patch?

That's the only complaint I've got.

But it does make things a royal PITA moving features from one branch to another.

buckaroo50 said @ 4:01pm GMT on 30th Mar
I have the power of FOOOORTRAAAAAAN!

eIfish said @ 1:22am GMT on 30th Mar
Yeah, not in the ECMAScript article it doesn't.

happiest_sadist said @ 8:51am GMT on 30th Mar
"JavaScript was originally developed by Brendan Eich of Netscape under the name Mocha, later LiveScript, and finally renamed to JavaScript."

That's from the article you linked. Does that not count as "crediting Netscape" to you?

You sound as if you know what you are talking about, so I'm wondering if I've missed something in interpretation of if you didn't read the article to which you linked. What it is?

eIfish said @ 12:06pm GMT on 30th Mar

It's nothing that complicated.

happiest_sadist said @ 12:12am GMT on 1st Apr
If it was a snake it woulda bit me.

So I did miss something. Thanks for clearing that up.

eIfish said @ 11:00pm GMT on 29th Mar
Further, these are all new features.

You're free to use an old Flash under the existing licenses.

eIfish said @ 11:07pm GMT on 29th Mar
Yeah, I skimmed. Sorry.

rezties said @ 10:09pm GMT on 29th Mar
Flash has been kicked around since 1995. If they wanted the outdated Frankenstein platform to be replaced, they could've just asked nicely.

psychotim said @ 10:28pm GMT on 29th Mar
I guess they're really exercising their stranglehold on the market, since obviously nothing can ever compete with Flash's features.

sherlock said @ 10:35pm GMT on 29th Mar
I support WebGL heavily, but I have to acknowledge that there's at least three major advantages Flash has here:
1. Market penetration: more users will have an up to date flash player than use a WebGL supported browser. Internet Explorer shows no signs of ever supporting WebGL, and Safari still doesn't support it despite it being a hidden option in the developer menu for over a year.
2. Native C/C++ support. Game developers aren't going to want to port their C/C++ code to Javascript for WebGL. It's doable (I've done it) but a pain. And Javascript is still slow.
3. Plugins make cross browser compatibility easy.

eIfish said @ 11:25pm GMT on 29th Mar
From what I can tell from their blurb, if you use a popular middleware, this 'domain memory' will let you port your game with no more work than a bit of boilerplate and a John Hancock on the chequebook.

Unity announces Flash as a platform.

foobar said @ 11:26pm GMT on 29th Mar [Score:1 Insightful]
For the moment, that's true, but I doubt it will hold for long. Really the only thing that's keeping flash at near universal penetration is Youtube. If Google were to drop Youtube's flash player, a lot of people would lose the only reason for still having it. Since universal penetration is the primary, if not only, reason to develop for flash, many developers will abandon it once that's gone. Which will prompt more users to abandon it...

With IE down to 35% market share and plummeting, it's edging into acceptable losses for more and more developers. (Especially since most of those aren't even on the most recent version.)

Jaxon said @ 11:37pm GMT on 29th Mar [Score:1 Underrated]
If Flash isn't available then Youtube will use an HTML5 player.

buckaroo50 said @ 11:50pm GMT on 29th Mar
With webm or h.264?

eIfish said @ 11:57pm GMT on 29th Mar [Score:1 Informative]
h.264.

Mozilla.org forced to support h.264, blames Google.

RhesusMonkey said @ 12:04pm GMT on 1st Apr
I find that thread very interesting to read and realize that there is a huge set of people who have a glossy-eyed view of the world and are, basically, idiots.

So first off, WebM is not "free" and it certainly isn't "unencumbered". The licensing around WebM includes non-assert against el Goog for VP8 or any future codec; and technically may also reach back to VP6/7 depending on how you interpret the language. This is why MPEG-LA is actively working against Google on getting things like WebRCT to specify as a standard that you must a) include and b) default to WebM as the AV codec. Oh, and also as the only AV codec, therefore excluding H.264 or HEVC (H.265) for even having consideration.

MPEG-LA has basically already assumed that there are significant parts of VP8 that infringe on patents as part of H.264; I'm still not entirely sure why they have not started to push legal action, but again the licensing from Google basically says "sure, you can use our codec now, royalty free, as long as you'll never sue us". So for OEMs that may want to deploy this on their products, they need to assume all the risk that they won't get sued by MPEG-LA in turn. And for those OEMs that are part of MPEG-LA? Very much a catch-22 scenario.

Now, on the "There's no support for WebM in Mobile" argument, that will be fixed next year. Everyone who is anyone has WebM decode support HW accelerated (and most of it is from Verisilicon, who bought the HW part of ON2's business AKA the "Hantro" engine, when Google picked up the SW codecs and licensing. Except that any device currently in-market will have a really hard time getting SW codecs working in any useful state - there are certainly some designs (like TI's OMAP4) that have a flexible AV system that theoretically could support new codecs like WebM, but they may not be able to meet full 24-30 fps decode, we'll just have to see.

From my opinion, there is no reason that HTML5 should not include multiple codec support for decoding, because all of the features that are part of MPEG4 or H.264 are already licensed under FRAND terms, and for the most part as an end-consumer you are already paying for this "somewhere". As well, things like HEVC are actually better than VP8, in terms of image quality for compression level, so why should the HTML5 standard exclude the use of this in things like WebRTC? To me this doesn't make any sense - extending the

RhesusMonkey said @ 12:06pm GMT on 1st Apr
"< video />" tag to include the codec used (if it isn't already) should be a joke, and if the client doesn't support that video codec, then it doesn't play. Or you extend the tag to include multiple source locations like "< video webm="www.blahblah.vp8" h264="www.blahblah.264" />" and let the client choose which source file to decode based on their codec support.

This should be an easy ting to do and yet the people guiding the standard seem to want to force the consumer into a box based on some skewed principles.
Support for the Ogg codecs would also be a nice compromise, however - this goes back to the HW support on in-market (or future) devices, which is to say that there is no Theora support anywhere. Vorbis (or any other audio codec) would be very simple to implement, but video, in particular video that requires multiple passes on large screen resolutions (we are going to 4k x 2k after all), consumes so much bandwidth and CPU resources that you simply can't implement them on the current ARM systems and expect to get a good frame rate (with a few exceptions, as noted).

eIfish said @ 4:06pm GMT on 1st Apr
The issue, AIUI, is that actually encoding these codecs is heavily patent-encumbered, far more so than decoding them. So if you, as a site, need to support h.264 and vp8, you need patent licenses from both MPEG and whoever turns out to have a patent on something necessary for webm.

And then there's the practical contstraints of encoding and storing two copies of everything.

RhesusMonkey said @ 6:42pm GMT on 1st Apr
You are right, the H.264 standard and the 'license pool' only provide a standard on how the stream should be decoded, and encoding is a wild west of techniques and patented ideas - this is why the WebM license (covering both encode and decode) is such a minefield, because lots of people who own IP for the MPEG cases do not want to 'give up' their right to sue for infringement (in this case, Google).

So you have assumed that the server needs to provide content in two (or more) formats, but I don't believe that to be true - if Google only wants to provide content in WebM, then let them - and if my phone doesn't support WebM (or Flash) then I guess I just don't go to YouTube anymore :) They are already in a bit of a bind because almost no mobile phones support WebM, and won't for at least another 12-18 months; the lone exception seems to be Medfield based handsets, but how many of those exist?

So sites like Google, Hulu, etc are already putting the same content available using multiple codecs, in some cases just based on the frame size (eg: 480p or lower is H.264, 720p and higher is WebM) - there really isn't an extreme burden for the site owners to have to store multiple copies of the same thing, because they are already doing this today (in some cases). Besides, data storage is cheap*, it is data streaming that is the pricey bit nowadays, so if another codec like HEVC provides the same visual fidelity at 1/20th of the bandwidth as H.264 (or WebM), then why the hell wouldn't you as a consumer want to have the option of viewing the content in that format? The Firefox community members of that post seem to be drinking the FSF Kool-aid of "if it has a royalty attached it's bad", and that this somehow will enable a 'free' internet; however "free" does not always mean "best", or "most efficient" or "highest quality" - these are things that you pay for, one way or another - that is the entire motivator for progress these days. I could sit on my ass and keep churning out the same thing, but I tell you - I Gots To Get Paid, and eventually I will only get that through continually introducing newer, better, faster, stronger shizz - I don't really want a bunch of self-righteous Freetards limiting what I can do with the internet just because I want to actually pay for something better. /rant

eIfish said @ 7:31pm GMT on 1st Apr
Just quickly, doesn't google/YouTube do h.264 and only h.264? That's what I get on my iPhone*, whatever resolution I ask for. On the desktop it offers h.264 in a <video> tag if you support it, or h.264 in a Flash applet if you don't.

* Which itself presents a problem: there are more iProducts than macs, and they will probably never support webm. Also Windows Phone which nobody owns: MS is a massive owner of h.264 patents.

eIfish said @ 7:44pm GMT on 1st Apr
I guess what I'm trying to say is that as a content provider or carrier, you have to support at least one codec that every device supports. It is simply not acceptable to tell your customers to sod off and get a better computer. For this reason, I can't see anyone moving to an 'alternative' codec for any technical reason - the network effect trumps almost all technical considerations.

ATM, going with h.264 allows you to support every platform: the only platform that doesn't support it is Mozilla's boot-to-gecko, and they appear to be changing their tune. (Mozilla's desktop browsers (and Opera?) can be worked around using Flash. As a provider, were you to move to webm, there'd be a massive installed base that you'd have to either provide h.264 or lose as customers. So there's no way of avoiding h.264 or the related fees.

Were the Android phones to start supporting only webm, then video providers would have difficult choices to make. Yes storage is cheap, but it's not cheap enough that you can just double it and not worry about the bill.

foobar said @ 11:54pm GMT on 29th Mar
Things will get interesting when they default to html5.

sherlock said @ 12:52am GMT on 30th Mar
Good to know!

Also, if you do have flash installed there is an HTML5 opt in page.

What God Said said @ 8:43pm GMT on 30th Mar
universal penetration every night, any sex, any living/dead thing i choose

eIfish said @ 11:05pm GMT on 29th Mar
Further, these terms are positively cake compared to actual games industry middleware.

RedRiverRat said @ 5:00am GMT on 30th Mar
the cake is a lie...

RedRiverRat said @ 5:27am GMT on 30th Mar
Since I haven't done any coding in at least a decade and while I understand concepts I have no working knowledge of current and upcoming languages, I give you a geek nostalgia tour.

For the record my first computer was a TRS-80.

My First Computer - A Visual History

mrcucumber said @ 3:04pm GMT on 30th Mar
I had to take Pascal in college.

Room full of computer geeks typing away hitting the return button with fervor every 5 seconds while I was looking for :, - () > thinking I was in a nightmare. No mice, screens that displayed only green text on a black background, and you sent your code to print so that you could review, and it would be spit out on a different floor in your student number box 24 hours later.

Fuck I hated that.

azazel said @ 9:33am GMT on 30th Mar
So this was amusing (and a bit scary), but not postworthy: http://blog.tastebuds.fm/worst-album-covers-of-all-time/.

azazel said @ 9:56am GMT on 30th Mar [Score:4 Funny]

mrcucumber said @ 2:56pm GMT on 30th Mar
I think joecam posted something like that a while back.