#SoftwareThoughts: I'm envisioning a web video platform where the audience make collective decisions about transcoding, which can then we used as a way of navigating quality when browsing the video library.
(1/?)
Discussion
Loading...
Post
Here's how I see this social video platform working. Every video file that's uploaded is stored as is, for later use, but transcoded down to the same, fairly low level for its initial streaming audience. People who are willing to sift through all the new stuff for diamonds in the rough, and have their app filter for that.
(2/?)
When the review audiences sifting through new videos see stuff they like, they hit an 'enhance!' button and recommend a transcoding quality.
With enough recommendations the stored original of the video file is transcoded again, into higher quality levels. For streaming to more general audiences who will repeat the process, recommending videos they think are particularly well-made for even higher quality levels.
(3/?)
To the point where audience can filter for quality videos, to some degree at least, just by pushing up the minimum video quality in their video app.
Cons:
* vulnerable to popularity contest dynamics, like elections are, and brigading tactics, like RottenTomatoes has been. So transcoding level can't be treated as a scientific measure of video quality, in either production or content
* Like any algorithm, can probably be gamed in at least one or two ways that are hard to foresee
(4/?)
Pros:
* provides a way of navigating a huge (and ideally decentralised) video library beyond chronological orders, without opaque automated filtering (The Algorithms™️)
* reduces resource waste on transcoding and storing larger file versions of videos that don't need higher video quality, or aren't popular enough to justify the costs
(5/5)
@strypey ... And add useres favorites to their seedbox, so popular videos always have high bandwidth from manymany seeds.
@strypey I like the collaborative library idea
i think busting the encoding down to lowres, await +1s, re-encode at higher = *more* encoding (in order to save bandwidth, _b)
i wonder what the energy costs of encoding vs storage vs bandwidth are.
could this be provided be a shared jellyfin or similar?
do you know about https://www.solidaritycinema.com/ which uses, of all things, a google drive (i love this, it's punk)
@xurizaemon
> do you know about https://www.solidaritycinema.com/
I do now, thanks for the tip.
> which uses, of all things, a google drive (i love this, it's punk)
What would be even more punk is exploiting Goggle's free storage, while wrapping the video stored there is a metadata layer and WebTorrent player that allowed it all to be discoverable in the PeerTube network, searchable in SepiaSearch, etc.
(2/2)
But what I'm mainly excited about here is the wisdom-of-crowds curation. The ability to switch between audience roles; mass culture fan, avant gardists, and reviewer (it's new, is it garbage, future cult classic, or popular hit?).
How that inherently creates an ability to toggle between watching popular stuff in high video quality, indie stuff with a cult followers in medium video quality, and trawling through the bleeding edge stuff in lower video quality. All from one library.
(1/2)
@xurizaemon
> i wonder what the energy costs of encoding vs storage vs bandwidth are
Unless you're storing in RAM, or some other kind of volatile memory, storage has no energy cost. Except in the initial save, and any subsequent retrievals.
Whereas the more data you send over the wire per video the more energy it uses, right? So doing most streaming with lower file sizes would have to be more energy efficient than streaming everything in larger file sizes.
1 more replies (not shown)
@strypey I see they have a Plex now too :)
bonfire.cafe
A space for Bonfire maintainers and contributors to communicate
Automatic federation enabled