Comment by netsharc
9 hours ago
I wonder if it has to be a real computer, display, and camera, or if doing it with a "headless display" that is nonetheless being fed to a "video recorder" would work...
Funny how it'd be like The Matrix...
9 hours ago
I wonder if it has to be a real computer, display, and camera, or if doing it with a "headless display" that is nonetheless being fed to a "video recorder" would work...
Funny how it'd be like The Matrix...
I have written software to do this kind of recording on a laptop, running 4 of the stream itself (different episodes of the same show).
It opened DRM enabled browsers side by side, ffmpeg captured the video from the respective parts of the screen, and each browser's audio was piped into a different dummy output, which ffmpeg also captured of course.
The tech stack was linux, bash, PHP, php-webdriver, Selenium, Firefox, ffmpeg. So yes, this idea absolutely works! That is, until they crank up the DRM so that software screen capture doesn't work.
It depends on a lot of factors. But even if it works in a virtual machine, your CPU is going to be pegged at 100% the whole time to handle the re-encoding. Unless you use a hardware h.264 encoder, but then the quality is pretty terrible since it's explicitly optimized for speed over quality and isn't tunable the way software encoders are.
It's always doable, it's just an option of last resort. You always just want to access the original compressed bitstream if possible.
I think the real key is to only compress enough initially so that you don't blow out your storage in terms of size and throughput... Once you have the stream captured at a higher quality, you can always recompress more optimally.
A relatively low compression with hardware h.264 will still take up a lot less space and throughput than mpeg-2 or raw.