I wonder if something similar could be useful for transmitting data optically, like an animated QR code. Maybe a good way to transmit data over an air gap for the paranoid?
YouTubeDrive: Store files as YouTube videos
201–210 of 316 posts
Re: YouTubeDrive: Store files as YouTube videos
#202I only looked at the example video, but is the concept just "big enough pixels"? Would be neater (and much more efficient) to encode the data such that it's exactly untouched by the compression algorithm, e.g. by encoding the data in wavelets and possibly motion vectors that the algorithm is known to keep[1]. Of course that would also be a lot of work, and likely fall apart once the video is re-encoded. [1] If that's…
YouTube let’s you download your uploaded videos. I’ve never tested it, but supposedly it’s the exact same file you uploaded.[a] It probably wouldn’t work with this “tool” as it uses the video ID (so I assume it’s downloading what clients see, not the source), but it’s an idea for some other variation on this concept. [a] That way, in the future, if there’s any improvements to the transcode process that makes smaller…
They may retain the original files, but they don't give that back to you in the download screen. I just tested it by going to the Studio screen to download a video I uploaded as a ~50GB ProRes MOV file and getting back an ~84MB H264 MP4.
Re: YouTubeDrive: Store files as YouTube videos
#203Earlier quoted context omitted.
I believe YouTube supports random access, or otherwise you wouldn’t be able to jump around in a video. Youtube-dl also supports resuming downloads in the middle, I believe.
True... But guessing YouTubeDrive 'decoder' needs whole video to get you back anything close to what you put in. Otherwise each frame would have to have a ridiculous amount of encoded overhead. Ahh, NM cant even see that working. edit: Maybe a file table at built from from specified first N frames, that delivers frameset/file map ... Still nothing like skipping spots in a video. That relies on key frames and time sig…
Why would you need a map or overhead?
Each frame gets the same amount of the file, about a kilobyte. So each frame is basically a sector. You need to read in a few extra frames to undo the compression, but otherwise it's just like a normal filesystem. And reading in a batch of sectors at once is normal for real drives too.
Even if you did need the frames to be self-describing, you could just toss a counter/offset in the top left corner for less than 1% overhead.
Re: YouTubeDrive: Store files as YouTube videos
#204This works on the same principle as the video backup system (VBS) which we used in the 1980's and the early 1990's on our Commodore Amigas: if I remember correctly, one three hour PAL/SECAM VHS tape had a capacity of 130 MB. The entire hardware fit into a DB 25 parallel port connector and was easily made by oneself with a soldering iron and a few cheap parts. https://www.youtube.com/watch?v=VcBY6PMH0Kg SGI IRIX also…
"one three hour PAL/SECAM VHS tape had a capacity of 130 MB"
This reminds me of the Danmere Backer.
"The entire hardware fit into a DB 25 parallel port connector and was easily made by oneself with a soldering iron and a few cheap parts."
This reminds me of the DIY versions of the Covox Speech Thing: https://hackaday.com/2014/09/29/the-lpt-dac/
Re: YouTubeDrive: Store files as YouTube videos
#205Earlier quoted context omitted.
I wrote one of these as a POC when at AWS to store data sharded across all the free namespaces (think Lambda names), with pointers to the next chunk of data. I like to think you could unify all of these into a FUSE filesystem and just mount your transparent multi-cloud remote FS as usual. It's inefficient, but free! So you can have as much space as you want. And it's potentially brittle, but free! So you can replicat…
I was an eng manager on Lambda for a time, and we definitely knew people were doing this, and had plans to cut it out if it ever became a problem. :D
Yeah, you'd need to find some sort of auto-balancing to detect this kind of bitrot from over-aggressive engineering managers & their ilk and rebalance the data across other sources. I think the multiple-shuffle-shard approach has been done before, maybe we could steal some algo from a RAID driver, or DynamoDB.
Re: YouTubeDrive: Store files as YouTube videos
#206This reminds me of an old hacky product that would let you use cheap VHS tapes as backup storage: https://en.wikipedia.org/wiki/ArVid You would hit Record on a VCR and the computer data would be encoded as video data on the tape. People are clever.
Yes! There were many such systems, LGR made a video for one of them, also showing the interface (as in: hardware and GUI) for the backup: https://youtu.be/TUS0Zv2APjU
Re: YouTubeDrive: Store files as YouTube videos
#207Earlier quoted context omitted.
Back of the envelope estimate: 4096 x 2160 x 24 x 60 is your theoretical max in bits/second, 127 billion. Assume that to counter YouTube's compression we need 16x16 blocks of no more than 256 colors and 15 keyframes/second; that reduces it to 256 * 135 * 8 * 15 = 4.1 million bits/sec. That's not too awful. Ten minutes of this would get you about 300MB of data, which itself might be compressed.
4k video is almost always 3840x2160
4K consumer video is 3840x2160, 4K Cinema video is 4096x2160.
Just like 2K consumer video is 1920x1080 and 2K Cinema video is 2048x1080
Re: YouTubeDrive: Store files as YouTube videos
#208I'm a GOOGL investor and I find this offensive.
Re: YouTubeDrive: Store files as YouTube videos
#209Turns out any site that allows users to submit and retrieve data can be abused in the same way: - FacebookDrive: "Store files as base64 facebook posts" - TwitterDrive: "Store files as base64 tweets" - SoundCloudDrive: "Store files as mp3 audio" - WikipediaDrive: "Store files in wikipedia article histories"
Re: YouTubeDrive: Store files as YouTube videos
#210How much data can you store if you embedded a picture-in-picture file over a 10 minute video? I could totally see content creators who do tutorials embedding project files in this way.
Back of the envelope estimate: 4096 x 2160 x 24 x 60 is your theoretical max in bits/second, 127 billion. Assume that to counter YouTube's compression we need 16x16 blocks of no more than 256 colors and 15 keyframes/second; that reduces it to 256 * 135 * 8 * 15 = 4.1 million bits/sec. That's not too awful. Ten minutes of this would get you about 300MB of data, which itself might be compressed.
To do PiP (picture in picture), you would be restricted to a much smaller size, but otherwise good calculations.