I Streamed My Hard Drive to the World
Credibility score: 89/100 — Highly Credible. This video is highly credible with well-supported claims.
BSmeter analyzed "I Streamed My Hard Drive to the World" and rated it 89/100 for credibility (a BS score of 11/100 — highly credible), on 2026-04-18. Its weakest claim — "Comments confirm data stays intact across formats" — scored 65/100 and was flagged as personal story. 25 claims were checked against the video transcript. Scores are produced by BSmeter's AI analysis of the transcript, not independent human verification.
Of 25 claims analyzed: 0 scored under 40, 2 between 40 and 69, and 23 at 70 or above.
Claims analyzed
Previous video on YouTube storage blew up; commenter joked it's hard drive backup; now considering live-streaming disk to Twitch — Personal Story (70/100)
At 0:00
OK so this is actually a super fun setup — dude's previous vid on YouTube hacks went viral and sparked this wild idea. Love the chain reaction from comments! 😂
Why this score: This is pure personal story — creator sharing their own video success and a comment that inspired the premise. No facts to verify, just context for the experiment ahead.
- The 'blew up' claim is subjective but common YouTuber lingo for viral success (e.g., 100k+ views).
- Ties into real YouTube policies: unlisted videos *can* store data creatively, but TOS forbids it as 'cloud storage.'
- Great hook — this whole vid is a thought experiment on streaming a hard drive. Teaches how creator economies spark absurd tech demos.
Original quote: “[0:00] The other day, I posted a video about [0:02] using YouTube as cloud file storage and [0:04] it kind of blew up. [0:06] In the comments, one of you guys joked [0:08] that maybe the video that you were [0:09] watching was actually just a backup of [0:11] my hard drive. [0:12] And that got me…”
You can back up files to Twitch by streaming and retrieve via VODs — Solid (80/100)
At 0:33
Technically works but Twitch ain't your grandma's backup drive — storage limits gonna eat your files 😬
Why this score: The core idea is feasible but impractical for real backups.
- Twitch VODs and clips allow download/retrieval, but 100-hour limit on Highlights/Uploads (since 2025) deletes low-view content automatically.
- VODs expire after 14-60 days depending on account; not reliable long-term.
- Fun hack, matches video's experimental vibe — ties perfectly to why they're doing this crazy project.
Original quote: “why would anyone back up their files to Twitch instead of being a normal person and using Google Drive, Dropbox, or I don't know, literally anything else? Well, it would be so much funnier if someone backed up their drive by streaming it on Twitch. You could even retrieve your data by downloading…”
Platforms strip metadata and limit subtitles for hiding data — Verified (95/100)
At 1:42
Spot on — platforms re-encode everything and nuke metadata to optimize streaming. No steganography shortcuts here 📱🔒
Why this score: Accurate technical explanation of video processing.
- Video files are containers (e.g., MP4) holding streams: video, audio, subs, metadata.
- YouTube/TikTok/etc. strip/re-encode on upload for efficiency — GPS, custom metadata removed.
- Subtitle engines reject oversized data; perfect setup for why they need audio/video hiding methods next.
Original quote: “A video file is basically a digital container holding a bunch of different things. The visual footage or video, the audio, the subtitles, and some background text like authors or descriptions called metadata. But as it turns out, many video or streaming platforms strip out some of this data the…”
Uncompressed 4K video holds 3,000x more data per second than CD audio — Verified (98/100)
At 2:22
Math checks out perfectly — video pixels crush audio bitrate every time. Great explainer! 🎥 vs 🎵 = no contest
Why this score: Spot-on calculations with transparent math.
- Audio: 44.1kHz × 16-bit × 2 channels (stereo) = ~1.41 Mbps ✓
- 4K Video: 3840×2160×3 bytes (RGB) × 24 fps = ~4,795 Mbps ✓ (8.3M pixels/frame)
- Ratio: ~3,400:1, close enough to 'over 3,000x' — sets up why pixels are better for steganography.
Original quote: “If we do some quick math, we can see which one holds much more data. If we take standard CD quality audio, this gives us about 1.4 megabits of data per second because it is 16-bits per sample and it has a 44.1 kilohertz sampling rate. If we take a full second of uncompressed 4K video on the other…”
Compression changes exact pixel colors but looks identical to eyes — Solid (85/100)
At 2:30
True for lossy compression like H.264/AV1 — pixels shift subtly to axe file size, imperceptible to us but data-killing for steganography. 🎨🔍
Why this score: Accurate description of lossy video compression.
- Codecs quantize color values (YUV space) to reduce data while preserving perceptual quality via psycho-visual models.
- Human vision can't detect small changes (Just Noticeable Difference thresholds), but exact RGB/YCbCr values alter.
- Perfect for explaining why pixel-based data hiding fails.
Original quote: “To our human eyes, the compressed video looks identical. But under the hood, the exact color values of those pixels have been completely changed to save space.”
Streaming compression algorithms constantly change and aren't fully deterministic — Solid (88/100)
At 3:49
Nailed the core problem — platforms tweak codecs constantly (VP9→AV1), and encoders have randomness for quality. RE nightmare. ⚙️🔄
Why this score: Technically accurate challenge for data hiding.
- Platforms rotate codecs/versions (H.264→HEVC→AV1) and parameters frequently for efficiency.
- Many encoders (x264, libvpx) use non-deterministic elements like rate-distortion decisions, threading yielding different outputs.
- Unlike static DVD CSS, streaming is moving target.
Original quote: “The issue with reverse engineering in this case is that unlike the DVD format, streaming platforms are constantly changing their compression algorithms. ... and uploading the same exact video twice might yield slightly different results. This is because of the nature of different video compression…”
Reverse engineering streaming platforms is super hard due to constant changes — Opinion (80/100)
At 4:30
Spot on — black box systems like streaming services are a reverse engineer's nightmare. Changes break everything overnight.
Why this score: This is a practical opinion from someone building in this space, not a hard fact claim. Spot-on assessment:
- Streaming platforms (YouTube, Twitch) constantly update compression, codecs, and pipelines without notice.
- Real-world reverse engineering faces dynamic behaviors and obfuscation, as noted in industry analyses.
- Ties perfectly to his workaround pivot — smart framing.
Original quote: “Combined with this black box, there could be a million hidden variables we don't know, like server load, internal pipeline changes, or anything. What works today might silently break in a month when they tweak their compression algorithm. In other words, it's not easy to reverse engineer something…”
QR codes use Reed-Solomon to fix errors from scratches and tears — Verified (100/100)
At 5:02
Nailed it — Reed-Solomon is QR's secret sauce for surviving mangled prints. Genius for data streaming idea.
Why this score: Technically accurate core claim. Key facts:
- QR codes indeed use Reed-Solomon error correction to detect/correct burst errors like tears/scratches (up to 30% damage in some versions).
- Handles 'anything' hyperbole holds for real-world use — they've survived horrible printing in practice.
- Perfect setup for his video frame analogy. Full credit.
Original quote: “QR codes are resilient to scratches, tears, horrible printing, and anything to be honest. They use an algorithm called Reed-Solomon, which automatically detects and usually fixes errors from rips and tears.”
CRC detects corruption like a file download hash; single bit flip breaks it — Verified (95/100)
At 5:39
CRC explanation is chef's kiss — exactly how downloads stay intact. Single bit usually nukes the checksum.
Why this score: Solid technical explanation. Breaks down perfectly:
- CRC is a checksum (fingerprint/hash) for error detection, standard in file downloads (ZIP, Ethernet, etc.).
- Single bit flip typically produces completely different CRC value (high probability of detection >99.999%).
- Minor caveat: theoretical chance of undetected errors exists but 'almost always' is fair for practice. Great teaching moment.
Original quote: “For our first question, we can use a clever piece of math called a cyclic redundancy check or CRC to determine whether or not our data was corrupted. You can think of it like a unique fingerprint or hash. It's the same technology your computer uses to make sure a file doesn't break while…”
Wirehair is a fountain codec great for unknown data loss — Verified (95/100)
At 6:30
Nailed it — Wirehair's exactly that, a rateless fountain code for unpredictable erasures. Spot on for this hack.
Why this score: Spot-on technical description. Wirehair is indeed an O(N) fountain code (rateless erasure code) designed for efficient error correction when loss amount is unknown, producing unlimited repair symbols recoverable from any sufficient subset.
- Matches core fountain code properties: generates encoding symbols on demand, ideal for lossy channels like video compression.
- Used in real projects like Bitcoin Fibre, confirming practical reliability for large data.
Original quote: “To do this, [music] we need to use an error correction algorithm called Wirehair. Wirehair is a fountain codec, which [music] super good at fixing errors when we don't know how much of our data will be destroyed in the end.”
Codecs use 8x8 DCT to turn pixels into frequencies, low freq = brightness/shapes — Verified (100/100)
At 7:40
Textbook DCT explanation — top-left is DC (brightness), zigzagging to high-freq noise. Perfect.
Why this score: Precisely accurate description of DCT in video codecs. Standard in JPEG, H.264/AVC, HEVC: frames divided into 8x8 (or larger) blocks, DCT transforms spatial pixels to frequency coefficients.
- Top-left (DC) coefficient: average brightness; adjacent low-freq: broad shapes/colors; high-freq (bottom-right): edges/details/noise.
- Human vision prioritizes low frequencies, so compression targets high ones — core to why this steganography idea works.
Original quote: “Modern compression codecs break each frame into [music] small 8x8 pixel blocks and convert them into frequency patterns using a mathematical operation called a discrete cosine transform or a DCT. After this transform, the block is no longer stored as pixels, [music] but as a set of frequencies,…”
Compression rounds away tiny high-freq values, keeps big low-freq ones we notice — Verified (98/100)
At 8:16
Dead right — quantization kills high-freq noise humans ignore, preserves visuals. Genius for data hiding.
Why this score: Core principle of lossy video compression confirmed. Quantization aggressively discards/rounds high-frequency coefficients (details/noise) while preserving low-frequency ones (brightness/shapes), exploiting human visual system insensitivity to fine details.
- Explains why steganography targets 'big stable frequency values' — they survive re-encoding pipelines.
- Matches standards like H.264/HEVC quantization matrices.
Original quote: “When compression happens, [music] those tiny values get aggressively rounded away to save space. But the big important values survive [music] because that's what our eyes actually notice.”
Video compression changes magnitude but not sign of values — Solid (82/100)
At 8:30
Smart call on sign bits — compression loves messing with sizes but signs hold up better. Ties perfectly to DCT stego tricks.
Why this score: This is a solid technical insight into video steganography resilience. Key points:
- Lossy compression (like H.264) quantizes magnitudes non-deterministically but rarely flips signs in frequency coefficients.
- Hiding in sign bits exploits this stability for reliable recovery, a known technique in research.
- Matches real-world behavior where magnitude rounding varies by bitrate/encoder settings.
Original quote: “Video compression might change the magnitude or how large the number is, but it usually doesn't flip its sign, giving us a better chance and more reliable way of recovering our hidden bits.”
Platform compression non-deterministic, 90 can become 85 or 10 — Verified (95/100)
At 9:28
Nailed the black box chaos of platform compression — same input, wild outputs. Why ranges flop hard here.
Why this score: Spot-on description of real compression variability. Breakdown:
- Streaming platforms use varying CRF/quality settings, encoder versions, and network conditions leading to non-deterministic rounding.
- Example (90→85 or 10) aligns with quantization tables in H.264 where high values get aggressively scaled.
- This is why sign-based stego beats magnitude ranges in unpredictable pipelines.
Original quote: “Because platform compression isn't 100% deterministic, we don't really know how much certain numbers will get rounded down. A value of 90 might get compressed to an 85 on one upload, but heavily rounded down to a 10 on the next.”
FFV1 is lossless, avoids double damage in upload — Verified (100/100)
At 10:20
FFV1 facts on point — perfect for archiving, zero generational loss. Streaming kills that dream tho.
Why this score: Completely accurate on FFV1 properties and streaming constraints. Details:
- FFV1 is a lossless intra-frame codec from FFmpeg, bit-identical on decode.
- Local export + platform re-encode = double lossy hits; FFV1 prevents the first.
- Streaming mandates lossy H.264, forcing re-encode regardless.
Original quote: “In my last video, we had a choice of picking between different video formats, and we chose a special video format called FFV1, which is lossless. This means that our data wouldn't get damaged twice, once during our local export and again on YouTube.”
Comments confirm data stays intact across formats — Personal Story (65/100)
At 10:30
Community feedback is real anecdotal gold — shows the tool holds up in wild tests.
Why this score: Valid user anecdotes from comments support resilience, but not rigorous data.
- Personal experiences like this are genuine and useful for early tech validation.
- *One caveat*: Self-selection bias (only happy users comment?).
- Strengthens case without being scientific proof.
Original quote: “After all, many of you guys in the comments experimented with my tool and realized that the data is usually still intact no matter the export format, which is great news to hear.”
CRC invented 1961, XXHash much faster modern alternative — Verified (98/100)
At 11:26
Nailed the history and upgrade — CRC is ancient, XXHash crushes it on speed.
Why this score: CRC originated in 1961 (actually 1960s at NASA/Göteborg Uni), solid date.
- XXHash is demonstrably faster for large data due to parallelism.
- Speaker's switch makes total sense for scaling to full drives.
- Full credit — precise and relevant.
Original quote: “Before, we were using CRC, as I mentioned, to check [music] for corrupted data. CRC is great, but it was invented in 1961, which is over 60 years ago. Modern algorithms like XXHash are much faster”
XXHash parallel chunks with simple ops vs CRC sequential — Solid (85/100)
At 11:59
Teddy bear factory analogy slaps — captures the parallelism perfectly.
Why this score: Accurate high-level description of XXHash's design.
- Uses chunking, SIMD, and ops like XOR/add for pipeline efficiency vs CRC's polynomial division.
- *Slight simplification*: Not purely 'parallel assembly lines' but close enough.
- Great for explaining why it's 10-20x faster on modern CPUs.
Original quote: “because instead of relying on complex sequential math that constantly waits for the previous step to finish, XXHash chops our data into smaller chunks [music] and processes them all at the same time using CPU pipeline friendly math like simple addition [music] or XOR.”
Single-core CPU runs multiple apps at once — Verified (100/100)
At 12:30
Spot on — single-core CPUs fake multitasking perfectly. No illusion busted here, just straight facts! 💯
Why this score: Perfectly accurate explanation of CPU multitasking.
- On single-core processors, the OS creates the *illusion* of simultaneity through rapid task switching between apps like Discord and Spotify.
- This is foundational computer science — every OS textbook covers it.
- Ties directly into why parallelization later crushes performance.
Original quote: “Most people think that their computer runs all their apps at the exact same time. The thing is, if you have a single core processor, you can still run many processes like Discord, Spotify, and Chrome at the same time.”
Modern CPUs have 8-12+ cores; threads utilize them — Verified (100/100)
At 13:43
Nailed it — 8+ cores are standard now, threads are exactly how you feed them work. Chef's kiss! 🔥
Why this score: Textbook-accurate description of multi-core + threading.
- Consumer CPUs since ~2010 have 4-16+ cores (Intel i7, AMD Ryzen, Apple M-series all match).
- Threads are OS primitives for parallel execution across cores in Windows/Linux/macOS.
- Sets up parallelization example perfectly without a single fumble.
Original quote: “But luckily, most modern CPUs don't just have one core. They have multiple like 8, 12, or even more. And to utilize all these cores, operating systems like Windows, macOS, or Linux provide a tool called a thread.”
8 threads on 8-core CPU: 64 chunks → 8/core, true parallel — Solid (85/100)
At 14:25
Perfect parallelization example — 64 chunks / 8 cores = 8x speedup in theory. Real world slightly less due to overhead, but concept is 🔥
Why this score: Excellent illustration of data parallelism via threading.
- Dividing 64 independent chunks across 8 cores theoretically gives 8x speedup (Amdahl's Law ideal case).
- Single-threaded sequential processing wastes 7/8 cores — common beginner mistake.
- *Caveat:* Real gains ~4-7x due to thread overhead, synchronization, memory bandwidth limits.
Original quote: “For example, let's say our file is divided into 64 chunks of data, and my computer has an eight-core CPU. Our old program was basically ignoring these extra cores, forcing a single core to process all 64 blocks sequentially. But by using eight threads, we can partition the workload so each core has…”
Added custom SIMD code and memory buffering optimizations — Solid (85/100)
At 14:30
SIMD and buffering are legit perf boosters for encoding — he's spot on with the tech choices here ⚡
Why this score: These are standard, effective optimizations.
- SIMD (Single Instruction, Multiple Data) parallelizes data ops on modern CPUs, huge for encoding loops (e.g., video/multimedia).
- Memory buffering smooths I/O bottlenecks between CPU/RAM/disk.
- Speaker's 'custom SIMD code' implies hand-tuned intrinsics, common in high-perf projects — no red flags.
Original quote: “Besides parallel computing, I also added a few other meaningful optimizations like writing custom SIMD code and improving our memory buffering.”
Optimizations made process up to 100x faster overall — OK (65/100)
At 15:07
100x speedup sounds wild but plausible stacking parallel + SIMD + buffering — tho 'estimated' means ballpark, not measured 📊
Why this score: Plausible for his custom stack, but unverified estimate.
- Parallelization often gives 4-16x on multi-core; SIMD/memory tweaks add 2-5x multiplicative gains → 100x total feasible for naive baseline.
- His 'few times' from extras + parallel = compound effect.
- *No benchmarks shown*, but personal project context makes it credible — watch for later decode proof.
Original quote: “While these optimizations are a little bit more technical and they weren't as impactful as parallelization, they still sped up our encoding and decoding loop a few times, so it's definitely worthwhile to mention. And at the end of all of this, I estimated that our entire process was up to 100 times…”
VHDX file treated exactly like physical hard drive — Verified (95/100)
At 15:48
Nailed it — VHDX *is* a full drive image OS mounts identically to physical HDDs 🖥️✅
Why this score: Technically accurate description of VHDX.
- Microsoft VHDX format emulates physical disks with MBR/GPT partitions, NTFS/ext4 filesystems, boot sectors — OS sees it as block device via Hyper-V/mounting.
- Same folder structure/filesystem/raw data as physical; perfect for his 'stream entire drive' goal vs. loose files.
- Minor nit: not 'exact same' at hardware level (no firmware), but functionally identical for his use.
Original quote: “A virtual hard disk is quite literally a digital clone of a physical hard drive. The cool thing is that your computer treats a VHDX file and a real physical hard drive plugged into your motherboard as the same thing. Stores the exact same folder structures, stores the file system, and all the raw…”
VHDX has boot sector/OS unlike mere zip file — Solid (80/100)
At 16:25
Smart distinction — zip = dumb archive, VHDX = bootable drive with full FS/OS potential 🔥
Why this score: Correct contrast, with caveat on 'OS itself'.
- Zip: Flat archive, no bootable structure/filesystem — just compressed files.
- VHDX: Contains boot sector, MBR/GPT, full filesystem (NTFS etc.); *can* hold OS/files to boot VMs.
- His empty VHDX starts without OS, but format supports it — key for 'entire drive' streaming vs. zip's limitations.
Original quote: “Now, some of you might be wondering, why don't we just shove everything into a giant zip file? Well, the thing is, a zip file merely just a compressed folder and nothing else. A VHDX has a fully functioning environment like the boot sector, the file system, the operating system itself, and any…”
See the full analysis with timestamps →