youtube-dl is a tool that allows the downloading of streaming videos into a single container file. It had stayed mostly under the radar for quite a while, despite being in existence since 2011. It's recent rise in mainstream popularity comes from the DMCA take down from the RIAA, which was eventually reversed after a fight with the assistance of the EFF, of which a better summary of the details may be found in Github's own blog entry from 2020-11-16.
It's a useful tool.
A related tool is avconv. It's like the audio-visual version of ImageMagick, providing at its core commands that allow manipulation of source audio/video streams, with a heavier focus on codec and container file transformation.
It is also a useful tool.
But funny enough, like all things relating to video/audio, only the source code is made available---to actually use it requires one to do some compiling locally. This is the same with The LAME Project.
The whys of such a strange occurrence may be found in the long-time campaign of the RIAA/MPAA to smear as many tools that manipulate sound/video as being agents of piracy as possible. Now, whether piracy actually hampers the media company businesses or liberates the consumers from the cabalistic behaviour of the middlemen to create a monopoly/oligopoly against free market principles is a large topic of research in itself that I won't go into detail due to the many confusing arguments that is deliberately pushed by the lobbyists keen on helping to preserve an antiquated model to avoid having to innovate in the face of new technology.
I will hint that the fight between these lobbyists and technology has a long history that makes a really bizarre bed-time reading. It's sufficiently long and twisted that I won't even try to find URLs for suggested reading.
Back to building from source. It's usually quite straightforward when I already have Cygwin set up. Cygwin is close enough to being POSIX/UNIX-y that most sources can be built directly. There are some minor issues every now and then, usually revolving around O/S detection strings since the output of [say]
uname -a
often yields a string that has no ``Linux'', ``BSD'' or anything that remotely looks UNIX-y. That tends to screw up some of those auto-configuration scripts that prepare the system-specific include files/compilation options. And that's where having know-how with the POSIX/UNIX system comes into play---just need to roll up my sleeves and tweak at the sources so that it can be compiled.There are also other compromises, like not having access to any assembly code for super efficiency, mostly because the ABI is different enough in Cygwin as compared to regular POSIX/UNIX. It's usually not a problem---if I really wanted some kind of efficiency, then it's off to the virtual machine we go, and even then, things are usually not that clear-cut anyway, since the best efficiency improvements are often at the algorithm level, with other lower-level optimisations only helping with the constant term. Constant terms are critical only in situations where latency is important---for batch processing, it's usually not that big a deal if the overall run-time is ``reasonable'' (usually means around the 5 min mark or so).
Anyway, that's all the rant for now. Till the next update.
No comments:
Post a Comment