Looks like a nice little library, and very relevant to my interests. My personal "dream scenario" is to have true multisource P2P video streaming in the browser with no extensions required - with WebRTC, this seems quite feasible as implementations mature.
The fun thing about JavaScript's type coercion and concatenation is that you can use it to create fun brain benders like this:
+[[+!+[[]]]+[![]][+[[]+[]]]++] === 10
Couldn't get it to find the unicode snowman[1]: http://i.imgur.com/gaIY9Gd.png (my drawing skills are awesome, no?)
But that aside, this looks like a neat idea. Not something I have any immediate use for myself, but could certainly be useful in some situations.
[1] http://www.fileformat.info/info/unicode/char/2603/index.htm
>But you know when the data is changing -- when an article has been updated and republished ... or when you've done another load of the government dataset that's powering your visualization. Waiting for a user request to come in and then caching your response to that (while hoping that the thundering herd doesn't knock you over first) is backwards, right?
>I think it would be fun to play around with a Node-based framework that is based around this inverted publishing model, instead of the usual serving one. The default would be to bake out static resources when data changes, and you'd want to automatically track all of the data flows and dependencies within the application. So when your user submits a change, or your cron picks up new data from the FEC, or when your editor hits "publish", all of the bits that need to be updated get generated right then.
You mean most things don't already do this? I've been working on a personal blog engine with this as one of the core ideas (basically all static assets and pages are compiled on edit), and I thought it was a pretty obvious way to go about it. Looks like I'm indeed not the only one to think of it, but how "new" you present the idea as is a bit surprising to me.
>MeGUI profiles
MeGUI is hardly necessary - x264 has a good set of presets and tunes built in to begin with. --preset veryslow --tune film/animation/grain will already get you very far, beyond that pretty much the two most important things to possibly tweak are the strengths of AQ and psychovisual optimizations (--aq-strength and --psy-rd).
>it is totally within the realm of possibility to put two hours of 1080p content on a single-layer DVD (4.4GB), in a format compatible with any Blu-Ray player out there (AVCHD, a subset of the Blu-Ray standard that accepts DVD as the storage layer), while keeping video quality at a very high level - basically indistinguishable from commercial Blu-Ray discs.
You might get away with an hour of almost-transparent content if it's not particularly bitrate-demanding, but two hours of live action will not look "indistinguishable from commercial Blu-ray discs". 5 Mbps High Profile L4.0 H.264 just won't look as good as ~30-40 Mbps H.264 High Profile L4.1 H.264 commonly found on BDs (unless the BD is really screwed up). At 720p you'd get pretty good results, though.
Sent a mail your way with more detailed impressions and thoughts.
The thing that annoys me about both this and Zencoder is that for people who are actually experienced with video encoding, there is absolutely no way to tweak eg. the underlying x264 settings. There's quite a few settings that have no effect on decoding in any way but are pretty important in getting the most out of the video at a given bitrate (most notably the strength/mode of AQ and psychovisual optimizations). In case of AWS, there doesn't even seem to be any kind of "general" tuning (like whether the content is film, animation, extremely grainy or so - x264 has --tune settings for these among others - Zencoder at least allows you to access this option[1]) options available, making it pretty much "one size fits all". I could always rent a generic server and use that for my encoding needs, but it'd be much more convenient if these cloud transcoding services simply offered advanced configuration for people who know what they are doing.
Also, even for a "simple" cloud transcoding service, Amazon's offering is pretty limited in what it can do right now[2] - you can basically only encode H.264 & AAC in MP4, define the profile, level and bitrate, and that's about it. Zencoder has much more options in comparison and has generally more transparency in regards to what their encoding software actually does (sadly when I asked them about getting access to x264 settings directly, they replied along the lines of "they could change and things might break for users!" - which I don't think would be an actual issue since the direct settings ought to be for advanced users only, and they should be aware of things changing - plus Zencoder could just notify users of direct settings before they upgrade so they have time to adjust their settings if necessary).
[1] https://app.zencoder.com/docs/api/encoding/h264/tuning
[2] http://docs.aws.amazon.com/elastictranscoder/latest/develope...
This isn't directly related to the blog post as it's about stuff available on OS X, but if you're on Windows I can very much recommend checking out Construct 2 by Scirra[1]. They have a pretty fantastic HTML5 game engine and an editor (and the whole "no programming required" is really just marketing - even though it uses a "visual" event system you still need to understand programming concepts like loops, conditions and such in order to make effective use of it). They have a feature-limited (no other limits though) free edition available for it too.
One problem is that even if I found that VP8 performed very well at one or two particular clips (out of the 28 HD test clips available), I couldn't say for sure why that is the case. There seems to be no clear information on what clips benefit from what kind of features, and as I'm not an expert on video encoding technology, it'd be hard for me to deduce these things by myself. General conclusions could still be reached, obviously, but if I was going to such lengths it'd suck if I couldn't get more overall detailed results.
Anyway, I brought up the subject to some Xiph folks over at IRC. Maybe in the future the test clips will come equipped with more detailed information to help in testing. It'd also benefit smaller scale tests, since it'd allow one to identify possible biases more easily.
>If your test was to compare an intraframe between vp8 / baseline h264 / and Theora, you would have concluded Theora was the best by a wide margin.
But it wasn't. I was comparing the visual quality of the whole video, and provided the full encoded clips for people to download and compare for that reason.
I am willing to do further test encodes, but have no interest in doing something like encoding all 28 HD test clips available on derf's test clip page[1], since as a purely visual comparison, especially with the actual encodes, it would be incredibly exhausting.
EDIT: I added a notice about the downsides of single clip comparison to the top of the post.
>not very representative clip
I chose the clip based on what Dark_Shikari (x264 developer) had to say about it[1]:
It shouldn't bias too heavily towards any one encoder like many of the other standard test clips will:
a. It's relatively high motion, so it won't bias heavily against encoders without B-frames or qpel (as, say, mobcal does).
b. It's not so high motion that it would cripple video formats that don't support motion vectors longer than 16 pixels (e.g. Theora).
c. It's not something that benefits an unreasonably large amount from some of x264's algorithms (which is why I picked this and not parkrun).
[1] http://forum.doom9.org/showthread.php?t=154430
I could have done multiple test encodes, sure, but the problem in this case was that downloading several gigabytes of raw source material isn't exactly instant. And even if I tested with multiple clips, I doubt the conclusion would be that much different.
H.264 isn't exactly "closed" per se - the standard itself is freely available[1], which is why we have great free and open source encoders and decoders for it. What you mean by "closed" is most likely just "patent-encumbered", which it most certainly is and which affects anyone wanting to use it commercially (at the moment you can use it freely for non-commercial purposes on the internet, but this may or may not change in the future).
That he has. My test clip choice was inspired by him[1], and I also link to another blog post of his[2] in the conclusion. That VP8 blog post is almost three years old now, though, and the comment I'm replying to in my article claimed that VP8 is better than H.264 "at this point". This is why I did my test with the latest and greatest encoders available for both formats today.
Okay then, I'm done with the comparison. You can find it here: http://news.ycombinator.com/item?id=5122855
>VP8 (which is also slightly better than h.264 at this point)
I'm sorry, but you have been mislead - VP8 is not better than H.264, and comparison you linked is bad for multiple reasons, like not telling the exact encoder settings used, not providing actual video for users to compare and only showing one frame (for all we know, it might be a keyframe on VP8 and it pumped the bitrate up for it and x264 didn't), not providing source for test replication and so on - just read these:
http://x264dev.multimedia.cx/archives/458
http://x264dev.multimedia.cx/archives/472
I can do a proper comparison between H.264 and VP8 if you or anyone else is interested, though it'll take at least a few hours (I intend to use the park_joy test clip found in derf's test clip collection[1]).
Also, On2 is famous for hyping up their products to heaven and have yet to match their claims, so I remain skeptical about VP9. There's also Xiph working on Daala, but right now it doesn't seem to be much beyond big words.
While I would love an open format to provide better quality than H.264 and even H.265, I wouldn't hold my breath for such a thing.
The way I see it, writing command-line utilities in Node is really no different than writing command-line utilities in Python. Both offer a nice scripting environment, and while Node is more web-oriented, there's still quite a bit of libraries out there to do stuff with, making it potentially perfectly suitable for writing an utility for doing X. Hell, I personally even consider it somewhat more attractive than Python in this regard because Node has no equivalent to the 2.X/3.X compatibility mess that Python has. (Python wins in having more "general purpose" libraries, though, making it potentially more suitable for not-directly-web-related-development in nature.)
And while this was mentioned a few times in the previous thread, it bears repeating again: There are quite a lot of people out there using Windows, which includes developers. Node is a first-class citizen on Windows, and grep, sed and friends won't be there out of the box for you. A properly done Node command-line utility is generally more cross-platform than a shell script using grep and sed would. And there's quite a bit of command-line utilities made with Node out there (most revolve around web development, such as build tools like grunt and things like CoffeeScript/TypeScript/etc compilers), so it's not like this one is unique in that regard either.
>There'll be plenty of cases when the content is inherently infringing.
True, and it seems that Mega's copyright infringement reporting page[1] has an option for that:
Takedown Type: Remove all underlying file(s) of the supplied URL(s) - there is no user who is permitted to store this under any circumstance worldwide
>then serve it to Mega along with a DMCA takedown notice.
The thing with copyrighted content, though, is that even if the file you're checking might be infringing on copyrights in certain cases, in other cases it might as well be completely legit. I wrote about this on some earlier MU submission[1], so I won't repeat all that here, but all in all, even if you knew that file X existed on Mega's servers, it would be pretty damn haphazard to just outright delete it, because you might be hurting many legitimate users by doing so.
Anyway, I think Mega could secure user's files simply by encrypting the locator keys they have with the user's own key, and this data only gets decrypted and parsed client-side when the user uses Mega with the user's own key. This way you could only prove that a file exists on Mega's servers, but had no way to check which user(s) it belongs to without cracking the individual user data one by one. And of course, if you don't have any exact files to check against Mega, then you wouldn't be able to even figure out whether "content X" is hosted there somewhere, and neither could Mega (since they'd naturally only store locator hashes and encrypted data itself).
Based on the other HTML-based weather app submission[1], I decided to submit something more accessible in the same category that I've been using a lot recently. Provided by the Finnish Meteorological Institute. My favorite part is that it includes a "feels like" temperature - especially useful during the winter around here!
There's lots of great free-for-commercial-usage typefaces out there. If you don't already have Fontsquirrel[1] (who also has a fantastic @font-face generator[2]) bookmarked, you should fix that immediately. Google Web Fonts[3] is also another (obvious) resource.
[1] http://www.fontsquirrel.com/
[2] http://www.fontsquirrel.com/fontface/generator
[3] http://www.google.com/webfonts
Also, while I'm at it, I guess I could name some typefaces I've grown quite fond of: Alegreya, Aller, Cabin, Delicious, Fontin Sans, Lato, Open Sans, PT Sans, Puritan, Quattrocento Sans, Rosario, Source Sans Pro, Ubuntu. All great stuff!
Nothing against building Chrome extensions here either (hell, I started learning JavaScript with userscripts myself), but Wikipedia has indeed had a "Random article" feature for the longest time, and it's right there in the main navigation too: http://puu.sh/1BQ3O
I knew I could also drop the "var ", but I like to operate within the 140bytes challenge rules that say you're not allowed to leak into the global scope. I'll give you the 3 chars from the parens and semicolon, though - I got caught up with the idea of "hey, you can do this whole thing inside the for statement itself!" back when I did this!
71 characters (129 points) with JavaScript. I actually wrote this quite a while back (and have also posted it on HN before) - code golf is pretty fun every now and then!
for(var i=0;i++<100;console.log(((i%3?'':'Fizz')+(i%5?'':'Buzz'))||i));
I have never liked the threaded model, largely for the reasons pointed out in the link. Threaded discussion is nice when you first read something, but becomes a total pain in the ass instantly afterwards if you want to participate in the discussion and/or actively follow it (oh hey, there were 85 comments in the last refresh. Now there's 89. Time to go comment hunting, since they could be literally anywhere!). One of the most annoying cases I've seen is Techdirt - it offers both flat and threaded view, but everyone seems to assume that everyone is using the threaded view and doesn't properly quote the posts they are replying to, which essentially makes the flat view completely useless for trying to follow the discussion. And in threaded view, you can end up with ridiculously thin posts where they're practically unreadable. Oh dear.
This is why a strong quote system is absolutely essential for a great flat discussion model. I personally consider 4chan (powered with an userscript like 4chan X or with the inline extension introduced a while back) to be a fantastic example of this. With simple quote links, backlinks to replies, hover previews and inline quote expansion, you can follow discussion within a thread incredibly easily and even do basically on-demand threading! Allow me to demonstrate it with this image: http://i.imgbox.com/adss6lfu.png (functionality and style in this case provided by 4chan X[1] and OneeChan[2] with a slightly customized Photon theme)
[1] http://mayhemydg.github.com/4chan-x/
[2] http://seaweedchan.github.com/OneeChan/
Also, in regards to HN, a while back I thought about writing a userscript to turn the comment view to flat (with some sort of auto-quote links), but turns out it's not really possible because there's no way to get the accurate post times for comments due to the "X minutes/hours/days ago" - though this could be easily solved if the relative timestamp was wrapped in a <time> element (or heck, even a <span> with the accurate timestamp in a title attribute or something, anything).
While it obviously makes no sense to use client-side crypto for verification, there can still be use for things like MD5 and SHA-1 on the client side. I have a script that does SHA-1 hashing for images fetched via XHR, for example (which is used for reverse image searching purposes).
Seeing this, I guess I should do some benchmarking and see whether it gives better speeds than my current implementation (and also look for any other options and test those too).
Congrats! I should probably get around to actually testing Vagrant one of these days too...
Also, the website looks absolutely gorgeous. Fantastic work there.
For some reason the icons appear to be broken (appearing as the kind of squares you see when a character isn't supported) for me on this work computer using the latest stable Chrome (23, running on Windows 7 x64). They show up right in Firefox, though. Seeing as every other icon font website is working fine in Chrome here, it seems like something is amiss.
Speaking of archaisms, especially in case of video/film content, there's also one other thing... exclusive licensing.
Seriously, exclusive licensing has absolutely no place whatsoever in the digital market. Yet they're still generally bundled with physical licenses like DVD rights and whatnot and then you end up with digital stores region locked to a single country because they haven't "licensed" it to stores operating in other countries or they have licensed it to some entity in said country that doesn't give the slightest toss about serving people in a nice digital manner.
Think about it: if exclusive licensing didn't exist for digital distribution, all TV shows and whatnot would be given out to any interested party. It could actually be feasible to have some real competition on what entity gives you the best service instead of what entity has the most content licensed. Sure, we have that now too, but I'm fairly certain that this would accelerate it quite dramatically.
And the biggest reason why digital exclusivity is completely dumb is because it isn't actually exclusive. If your content is popular, it's bound to get pirated, and they sure don't care who or what might happen to have an exclusive license for legitimately streaming or selling that particular show in whatever particular country an user might be downloading from. Keeping up this game of pretend about "exclusivity" does ultimately no good for anyone.
Gotta say I have to give props to Australia for objecting to most of these. Some relevant reading:
http://www.techdirt.com/articles/20120613/12491719310/rip-of...
http://www.techdirt.com/articles/20121116/02455021073/domain...
I've seen many people bring up the fact that MegaUpload had the same file for multiple links and that they only took down links reported as infringing. Many people seem to come to the conclusion that this is automatically somehow representative of bad behavior, but I strongly disagree. Just because something is covered by copyright and is on MegaUpload, does not automatically make it infringing, even if some of the links to it might be.
Consider that someone legally backs up his own files to MU and never shares links to them with anyone. Then someone else uploads the same content in an infringing manner. Should the first guy with his completely legal backups have his stuff deleted just because someone else did something infringing with the same files? He most certainly should not. Assuming that all links of the same file that was uploaded are automatically infringing is basically "guilty until proven innocent", and is very much not the way they should be treated. Hell, I have music and other copyrighted content perfectly legally backed up in the cloud myself, and I sure as hell wouldn't want to see it deleted just because someone else might have used the same service for infringing sharing of the same files. (and what cloud provider wouldn't want to optimize their service to only have one copy of each file in their back-end instead of wasting space with duplicates?)
And, of course, this is very different to something like child porn, which is always illegal under US laws (where the stuff was hosted in case of MU). There can be no "non-infringing" use there, so it makes sense to delete all and every link to it. Not so much with just copyrighted content. And as we also know, deducing whether something is infringing or not isn't very clear cut either, like with Viacom issuing takedowns for Youtube videos its own employees had legitimately uploaded for marketing purposes.[1]
[1] http://techcrunch.com/2010/03/18/youtube-viacom-secretly-upl...
Viacom’s efforts to disguise its promotional use of YouTube worked so well that even its own employees could not keep track of everything it was posting or leaving up on the site. As a result, on countless occasions Viacom demanded the removal of clips that it had uploaded to YouTube, only to return later to sheepishly ask for their reinstatement. In fact, some of the very clips that Viacom is suing us over were actually uploaded by Viacom itself.