We can see that data is encoded as "pixels" that are quite large, being made up of many actual pixels in the video file. I see quite bad compression artifacts, yet I can clearly make out the pixels that would need to be clear to read the data. It looks like the video was uploaded at 720p (1280x720), but the data is encoded as a 64x36 "pixel" image of 8 distinct colors. So lots of room for lossy compression before it's unreadable.
No, YouTube is not lossless.
The video that is created in the example in the README is https://www.youtube.com/watch?v=Fmm1AeYmbNU
We can see that data is encoded as "pixels" that are quite large, being made up of many actual pixels in the video file. I see quite bad compression artifacts, yet I can clearly make out the pixels that would need to be clear to read the data. It looks like the video was uploaded at 720p (1280x720), but the data is encoded as a 64x36 "pixel" image of 8 distinct colors. So lots of room for lossy compression before it's unreadable.
Imagine a QR code that changes once every X milliseconds.
That's an excellent analogy, thank you.
The data is represented large enough on screen that compression doesn't destroy it.
e.g. similar to a QR code stored as a JPEG will still work fine.
things like redundancy and crc checks I assume