This is definitely really cool, too. I like that it shows that a node in a filesystem is just another way to represent some resource, but in a way that's a little more familiar to most people than something like procfs.
That said, it's also amazingly wasteful, and abusing a free service for a purpose it isn't intended for.
Edit: @ionforce hints at same here: https://news.ycombinator.com/item?id=9840838
Wouldn't be terribly efficient though. Wikipedia says max bytes per code is 2953 per QR code . So 2953Bps * 60fps = 177KBps data encoding. I guess that's what you get for encoding it in a visual (human readable) format instead of a datastream directly.
Another idea is YT as code repo: essentially one makes a movie that shows code files. On retrieval, OCR can be applied to transform the movie back to code in text.
If this is a concern for people (recording at 60fps to upload for 60fps), I doubt that Google would downgrade the framerate except for maybe the lower quality versions of the video (does 60fps really matter for 240p video?).
trying to upload a pdf file :
"The video has failed to process. Please make sure you are uploading a supported file type."
It definitely needs a mount option to set the default quality. Changing it later might be tricky, maybe passing options in directory names would be a good idea? for example: mkdir "foobar [q:720p]"
I'm sure there are ways to merge streams on the fly though.
It changes every comment to a mix of
> Derp herpy derp derp
while still allowing you to click and see the "quality" comment that the person left.
would make it easy to reexport this file system, e.g. Over http or smb.
A reasonable solution would be ability to set max results and disabling next/prev. All desired results would show up in the search directory (if you can assume that results beyond some point are useless).