I hadn't heard of Red Queen's Race before, and your use of it in a somewhat novel way was awesome. That was 15 minutes well wasted.
224 karma · joined June 5, 2011
We can support almost any valid h264 file :D
In an ideal world, you'd send 1080p high profile h264 encoded with a bitrate above 8Mbps (or CRF 18 for x264 nerds), with a max keyframe interval of around 5 seconds. Closed GOPs also makes processing more efficient.
In addition, the SDP exchange also sets up DTLS, making sure that whoever the WebRTC SDP was exchanged with is the same as whoever connects at a low-level. While you can implement this as a messaging exchange over UDP once the connection is established, its a nice property that WebRTC doesn't even allow the connection to be established with a non-secured link.
I think the hardest part of the stack is getting a decent, stand-alone implementation. With things like Websockets creating a server is straightforward, but libraries for low-level webrtc are much harder to build.
The ICE RFC does a good job of explaining it: https://tools.ietf.org/html/rfc5245#section-2.7
Once you realize its just ICE + DTLS + SCTP, and that each layer has a corresponding library, the work getting it up and running is mainly just 'plumbing'.
Here's a link to the library I've been working on: https://github.com/chadnickbok/librtcdcpp
Its still new, but we're starting to pick up some steam in the pace of development, and we have a pretty easy demo in the repo.
Thanks! Keep up the great work ;)
If you're interested in this sorta thing, try taking a look at Broadway JS: https://github.com/mbebenita/Broadway
Here's a simple demo page they have setup: http://mbebenita.github.io/Broadway/foxDemo.html
Its entirely possible to use WebSockets to stream H264 to a browser and decode using broadway, and the performance is pretty good, even on mobile.
Also on desktop this link points to latest: https://twitter.com/search?f=tweets&vertical=default&q=route...
This is actually one of the few times Twitter is super-helpful!
Through passion, I gain strength.
Through strength, I gain power.
Through power, I gain victory.
Through victory, my chains are broken.
The Force shall free me.
Playstation bought Gaikai and turned it into Playstation Now. They also use the technology for PS4 Remote Play.
Its awesome and you should check it out :D
At what point does 'early stage' no longer matter?
We don't use TCP because its fast. We don't use it because its reliable (although that's really useful). We use it because _we kept breaking the internet_. Once you get above a certain threshold, the network can't keep up with you and packets start getting dropped. The problem is that backing off just a little doesn't allow the network to recover.
Instead, we need to use exponential backoff in the face of packet loss to ensure that the network as a whole can recover.
But if you're pretty much the only connection misbehaving, and everything else backs off, then you can kinda get away with not using exponential backoff. The problem is that the applications that is was "kinda okay" to do this for was VOIP and friends, where realtime delivery is really important and exponential backoff causes noticeable drops in quality.
For a great read about these kinds of issues, check out the TCP-Friendly rate control RFC: https://tools.ietf.org/html/rfc5348
Once you break apart the acronym its pretty clear you should fire this guy.
As I understand it, even "getting drunk and trash talking a previous employee" in front of the wrong people can be seen as impacting someone's employ-ability, and can land you in some difficult legal situations if you're high up enough. Essentially the only safe thing to say about past employees is nothing.
Do you think that youtube will provide enough engaging content for people to start getting into the platform? How could you go about getting 'real' popular content onto the platform, and if this works how can you compete with Twitch?
You mentioned that your process doesn't require a clean room. What are the regulations around getting a catheter "approved" for human use? Do you need to run some expensive trials or is this something that you can scoot around?
ie. If I wanted to use your catheters tomorrow, other than a repeatable manufacturing process whats stopping me from ordering a few thousand and putting them to use?
Cool idea - I've always loved reading through the Hugo Awards each year to find new books, but I can never really trust that they're doing a great job. And sometimes Amazon does an even better job, recommending books like The Martian before anyone I knew had even heard of it.
What do you imagine 'Premium Content' being? And how do you think you can differentiate from what platforms like Amazon Kindle are doing?
You say your background is a game developer - care to expand a little? It seems like something like this would need lots of web development and payments integrations; when you say something like Steam, would this be primarily a website or a desktop app?
And would it let me get things in formats I can easily put on my Kindle/e-reader/iPad? Are those formats difficult to generate or pretty straightforward?
But it's not the argument made by the author :-/
Saying that this is somehow more complex than updating a single commit and learning a whole new tool doesn't change that if you want to convince me, you at least need to correctly identify what's going wrong.
Perhaps if the author had specifically called out their perceived failings of the very latest GitHub pull request changes I'd have given the article more time. But unfortunately the justification given for switching was really shallow.
The process might seem more complex initially but think
of it like this: If you add a new member to your team,
they would have to fork the repositories on GitHub, clone
them locally, make the changes, push to their own fork
and then create the pull request
In addition, the new GitHub code review tools address most (if not all) of the stated reasons for this switch. And in my opinion, GitHub's ease-of-use, alongside it being an incredible single point of reference, far outweigh any clunky other tools I've used (like Gerrit).
What's most interesting to me personally is that if you squint, Martin is essentially making an argument for a low-level parallel to Java's Thread.stop method (although in much more detail). I always thought that Java's deprecation of Thread.stop was a huge cop-out from actually solving the underlying causes of its issues, and very disappointing. But from a high-level view, there are often differences between whether a thread should be stopped when its ready, or if a thread is no longer useful and should be terminated immediately.
Its also interesting that go's solution to this is to pass a context with a 'done' channel through every function call dealing with a specific session, and every time a channel is waited on you also wait on the done channel. While its an effective method, its a bit of a shame that the concept wasn't built into go more deeply.
Some relevant articles:
- Why Thread.stop was deprecated: http://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPr...
- Go concurrency patterns: https://blog.golang.org/context