2,474 karma · joined September 17, 2011
It's always hard to know whether you're going too deep or too shallow, what are the target people?! I'm afraid, in this case, I didn't put as many details as I planned because every time I read it, it started to become be too difficult for newcomers and my idea was to show to anyone this idea of "we should try to do good code design despite the language since it works for many giant projects such as Linux"
I appreciate the time you took to read it and for the issues pointed: clarity and cover more thins, I'll pay more attention to the future posts and I'm open to suggestions, thanks. Maybe I miss the balance and I should put more details/examples into it.
we often, as developers, see something as useful or not only from our point of view, which is fair since you're reading and you want to learn more, but we can't forget that there are many developers out there being formed/mentored that might benefit from this kind of post.
I'll fix these attributions but also feel free to point me more or even PR.
* We were only allowed to broadcast to Brazil.
* We already have all the servers and needed bandwidth, why would you pay when you already have all the servers?About why chose HLS over RTMP, in our experiments HLS showed to be easier to scale than RTMP (maybe because the latter is stateful + the current players don't have an optimized adaptive bitrate algorithm + it's easier to scale http over rtmp)
The architecture up from what was described is almost purely to provide caching capabilities, aka bunch of edge servers caching content to final users.
You can send metrics from Cassandra to graphite http://www.datastax.com/dev/blog/pluggable-metrics-reporting...
Since the streaming is similar to HTTP page flow, it's not that hard.
Ex: http://blazemeter.com/blog/how-load-test-http-live-media-str...
* We used 20G ethernet, we could get 19G from each machine.
* All the content is hosted by us.
For sure, you can experiment changing video .... and so on!