|
|
|
|
|
|
by ductsurprise
1494 days ago
|
|
|
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 signatures. Cool stuff nonetheless... |
|
|
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.