Version freezing attack can be done even if the client tries to connect over TLS, simply by dropping SYN requests to the update server, or by DNS manipulation, etc.
The BitTorrent protocol uses UDP only when using a congestion control mechanism on top of it (uTP). In fact uTP is aware when the send buffer is filled and when latency is introduced so that it automatically back-off and let interactive traffic some time to be exchanged in priority.
The standard BitTorrent protocol uses TCP by default and is arguably worse: since it uses more TCP connexion by nature compared to a client-server file delivery, it have more chances to be prioritized.
So BT over UDP with uTP transport protocol is in fact a clever way to balance heavy traffic and interactive one.
It's on the roadmap for VLC 4.0, the new medialibrary (C++11) is in the process of being added as a module. The interface is also being reworked in QML.
This medialibrary is already used in VLC for Android for music album classification in an SQLite database.
> help serve those videos from their home connection
While it's what we usually do when we uses BitTorrent and similar protocols, this is ignoring network topology, and somewhat inefficient.
Of course, theoretically not the global bandwidth, but the pipes congestion.
Home connections are not connected to the internet, but to a service provider connected to the internet. Home are behind distribution trees connected to the internet graph.
Nothing forces ISPs to optimize routing flow inside their AS to distribute content. Could be at their root tree. How can we expect people with capped upload speed and high latency to IX servers, while some global CDNs are already closer to homes on ISPs regional level PoP?
And besides, traffic shaping, throttling, protocol blocking on private ISP infrastructure is now unregulated in some parts of the world. Massive outbound traffic could unbalance their (massively inbound) peering contracts, this is a threat.
The principles of free, open and decentralized internet do not necessarily apply to users of ISP infrastructure.
Libre software and the open source spirit existed long before Internet. Sure, It was really hard to find projects and contribute to them, but we can do it since the dawn of computer science.
Path tracing in general do not technically terminate since it's trying to approach an integral (the rendering equation) with sums. It's up to the user to determine the sample per pixel threshold with which he is satisfied. The goal is often to not have too much noise for the time spent. It's not easy because noise reduction over time tends to be logarithmic.
Indeed! This implementation was started by some people working on AV1 to test libaom's specification implementation correctness.
There was a presentation about it at VDD17, if I remember correctly.
The base was VP10 + tools from Thor (Cisco) and Daala (Xiph.Org/Mozilla), and it evolved from there to AV1 through a process of "experiments", test, IP checks and then its enablement.
Assuming that VP10 shares a significant base design with VP9 it would not be surprising if some part of VP9 sillicons decoders could be leveraged on customer hardware, while awaiting for more dedicated circuits.
But on the software end, libaom (AOM reference implementation) is indeed a fork of libvpx. But this library is not broadly considered a good implementation, even for VP9.
Pehaps the guys behind EVE for VP9 [1] will produce an AV1 implementation based of their codebase.