One request: could you also include an explicit LICENSE.TXT file stating that you have licensed it under the MIT license as opposed to just putting it in the comments? It would make it a lot easier for people to find if they might have requirements in terms of various licensing.
This is a huge step forward for the javascript community. Having _real_ binary communication for WebGL games, media streaming, data analysis, etc etc is going to be huge.
For now the problem is consuming it. For instance, it seems Google still hasn't implemented a full API around the Audio object which could be used to flow wave data through your program. See here: http://code.google.com/p/chromium/issues/detail?id=113676... (and many other similar issues exist within the more advanced parts of the V8 JS arch runtime)
You can stream binary data through the Web Audio API to play it.
That bug is really for capturing audio, but the spec has substantially changed since that bug was filed. If you want to get started with it, there are several decent tutorials about WebRTC and getUserMedia out there...just keep in mind that the spec is still being written, so problems are to be expected.
(also, minor nit: WebRTC and the like are implemented in the browser (for Chrome, often at the Webkit level, but sometimes in Chrome itself), not in the Javascript engine. V8 is pretty isolated from those APIs)
Yes, perfect timing! I've been needing something like this for a video streaming project I've been working on. I've been using Node for everything and haven't wanted to resort to (and purchase) Adobe Flash.
Thanks for making this!
Are there are disadvantages to this in terms of optimization compared to something like Flash?
You can build a streaming Flash app without having to pay a cent to Adobe, the Haxe compiler or the Flex SDK are some of the solutions available. So I don't really understand the "(and purchase)Adobe Flash" part.
They state that performance is untested. While this is interesting for transporting binary data that needs no encoding or decoding, i suspect the use cases will be minimal. JSON is actually highly efficient already. Ebay did benchmarking of the various binary formats for server-to-server api's, and while JSON wasn't the fastest, it was fast enough. http://www.infoq.com/presentations/Dealing-with-Performance-...
I felt that it'd be helpful to allow people to send any JSON type rather than just binary data. You can actually write Javascript objects, arrays, strings, and numbers to any stream or stream metadata in addition to binary. By using it as part of wire protocol it only adds exactly one byte to each message, so why not.
Is it possible to send raw bytes as WebSocket messages or are we forced to use MessagePack. I can see the benefit of sending structured data but for images or sound, what's the benefit of a intermediary serialization format vs chunked binary?
First of all, this looks great. But is there a reason to use this custom BinaryPack format, over another binary JSON-alike such as msgpack, which already has a lot of bindings in other languages?
I'm glad you asked! BinaryPack is actually a extended version of msgpack. Specifically msgpack doesn't differentiate between binary and string types. This is fine for most dynamic languages as "strings" can hold both string and binary data. However Javascript has very distinct binary types and thus we need separate types within the serialization format.
> Your browser doesn't support binary websockets and is not yet supported by BinaryJS. Fallbacks are in the works but not yet complete. Chrome 15+ and Firefox 11+ are known to work.
I do see a picture of a flower, so it looks like it did actually work despite the message..?
Video or audio chat? Why? You need the new media stream components to get a usable stream for those anyway, and if you have that, you might as well use PeerConnection.
Javascript can do real-time audio decoding in modern browsers, and can almost do real-time video decoding as well. While in general a site should use the standard components rather than reinventing them, the ability to do so allows experimentation with creative ideas that browser vendors haven't thought of yet. The more you can do without increasing the surface area of the browser-to-site interface, the better.
One request: could you also include an explicit LICENSE.TXT file stating that you have licensed it under the MIT license as opposed to just putting it in the comments? It would make it a lot easier for people to find if they might have requirements in terms of various licensing.