YouTube jako nieskończony storage? (film, 5min)
BK Binary postanowił przetestować pomysł wykorzystania YouTube jako nieskończonego medium do przechowywania danych. Podstawowa idea polega na tym, że YouTube pozwala na nieograniczone przesyłanie filmów, co teoretycznie umożliwia przechowywanie nieograniczonej ilości danych w postaci plików zakodowanych w filmach. Autor zastanawiał się nad różnymi metodami, jak przeprowadzić ten proces, a pierwszym pomysłem było manipulowanie strukturą plików mp4, aby wkomponować surowe dane. W praktyce odkrył, że struktura pliku mp4 jest znacznie bardziej skomplikowana niż się wydaje, co prowadzi do wielu problemów związanych z kompresją i odnawianiem danych.
Kolejnym pomysłem BK Binary'a było przechowywanie danych w postaci wizualnej. Zauważył, że dowolny plik na komputerze można zinterpretować jako sekwencję zer i jedynek. Przypisując odpowiednie kolory dla tych wartości, udało mu się stworzyć obraz, który reprezentuje zawartość pliku. Po ustaleniu oraz obliczeniu rozmiaru „płótna” w rozdzielczości 1080p, który może pomieścić znaczną ilość bitów danych, autor wyjaśnia proces kodowania oraz tworzenia obrazu z tych danych, a także użycia bibliotek takich jak OpenCV2 oraz FFmpeg do wygenerowania filmu.
Tworzenie filmu to jednak tylko połowa sukcesu. Aby odzyskać zakodowane informacje, konieczne było skonstruowanie dekodera, który działał na zasadzie odwrotnej do enkodera. BK Binary wskazuje, że dekoder rozbija film na klatki i odczytuje zakodowane dane, a następnie zapisuje je jako plik wyjściowy. Oba procesy wymagają podobnych obliczeń, dlatego autor nie zagłębia się w szczegóły dekodera, pozostawiając więcej miejsca na omówienie praktycznych ograniczeń tego projektu.
Mimo udanej konwersji z pliku na film oraz z powrotem, BK Binary zauważa szereg praktycznych ograniczeń, które sprawiają, że ta metoda jest mało wykonalna w prawdziwym świecie. Kluczowym problemem jest kompresja wideo, która drastycznie zwiększa potrzebną przestrzeń. Przy jego konfiguracji przekształcony plik może zyskać 20 razy więcej niż w oryginale, co powoduje, że pomysł ten staje się bardziej eksperymentem, niż praktycznym rozwiązaniem przechowywania danych. Warto zauważyć, że autor przewidział ten efekt i myślał nad ulepszeniem tej metody, ale podkreśla, że celem projektu było udowodnienie tezy, co udało mu się zrealizować.
Film na YouTube zdobył już 777661 wyświetleń oraz 39519 polubień, więc widać, że pomysł z pewnością przykuł uwagę. Fani technologii i innowacji mogą docenić podejście BK Binary'a do nietypowego wykorzystania platformy. Autor zaprasza do zapoznania się z jego kodem, który zamieścił na GitHubie oraz zachęca do kontaktu z pytaniami i sugestiami na temat dalszego rozwoju projektu. W miarę jak technologia wciąż się rozwija, być może pojawią się lepsze sposoby na wykorzystanie YouTube jako medium do przechowywania danych.
Toggle timeline summary
-
Wprowadzenie do korzystania z YouTube jako niekończącej się pamięci w chmurze.
-
Wyjaśnienie koncepcji przesyłania nieograniczonej liczby filmów w celu przechowywania danych.
-
Teoria dotycząca kodowania i dekodowania plików w filmy.
-
Wyzwania związane z nadpisywaniem danych wideo w formacie mp4.
-
Skomplikowane kwestie, takie jak kompresja i korekcja błędów w mp4.
-
Przechowywanie danych wizualnych poprzez kodowanie wartości binarnych.
-
Ustawienie rozmiaru płótna do przechowywania informacji.
-
Przechowywanie pierwszych 260 000 bajtów pliku w obrazie.
-
Szczegóły dotyczące zapisywania bitów do odpowiadających kolorów w celu wizualnego przechowywania.
-
Tworzenie klatek wideo przy użyciu bibliotek do przetwarzania.
-
Potrzeba dekodera do odzyskiwania przechowywanych informacji.
-
Omówienie niepraktyczności metody z powodu kompresji wideo.
-
Zwiększenie rozmiaru pliku po konwersji do formatu wideo.
-
Podsumowanie celów i wyników projektu.
-
Zaproszenie do obejrzenia kodu i przekazania opinii.
Transcription
Using YouTube as an infinite cloud storage medium isn't a new idea, but I wanted to test the functionality and practicality of it myself. The basic idea is that YouTube lets you upload unlimited amounts of videos, and therefore infinite amounts of data. If you were to somehow encode a file into a video as well as decode that video back to the original file, you'd theoretically be able to store as many files as you want, completely for free. There's a couple different ways I thought of going about this. If you were to analyze the file structure of an mp4 and sneak in raw bytes of the file you want to encode in such a way that you could retrieve the data back, you would be golden. Seems easy enough, right? Just write over the parts of the mp4 that contain the video data, since it wouldn't matter what the video was displaying. Turns out it's not that easy. The file structure for an mp4 is surprisingly complex, and there's lots of issues that arise from simply overwriting the video part of an mp4. You have to account for compression, error correction codes, corruption, and so much more. Which gave rise to my second idea, storing the data visually. We know any file on a computer is just stored as a sequence of 1s and 0s on your disk. If we take those binary values and assign a color to them, let's just say 0 is black and 1 is white, we can store any file visually, given a big enough canvas. We can assign a canvas to be a discrete chunk of information of a file, and store the canvases sequentially in a video file to put all of the information into video format. Okay great, so now we have the basic idea of the video encoder, so let's look at some of the code. First thing we need to do is define a canvas size for the information we're going to be storing. Since YouTube allows for 1080p video, I chose that resolution. If we do some calculation, we can store 1920x1080 bits of information in one canvas, or about 260,000 bytes. Next, we'll take the first 260,000 bytes of the file we intend to encode, store them, then create the image represented by those bytes. We loop through each XY position of the canvas, writing the corresponding bit to each pixel. We calculate which bit to write with a little bit of binary math. First, we take the corresponding byte with this equation, then bit shift the byte to the right and take the rightmost bit with this equation. This is the bit we need to write at this specific XY position. We then convert the bit to its corresponding color and put it on the canvas. In my implementation of this, I stored 2 bits per pixel of canvas, assigning these values to different colors. This allows us to double the amount of information stored in each frame, shortening the final video. After all this, we take each of those images and use them as frames of a video, giving us an output like this. Luckily, instead of having to create a video file by scratch and editing the data directly, we have libraries such as OpenCV2, FFmpeg, and LoadPNG to do this process for us. Well, that's the end of this. We've successfully stored whatever file we want as a video. But how do we get that information back? Well, we have to write a decoder as well. The decoder works essentially the same way as the encoder, but in reverse. We take the video, split it up into all its different frames, then read the data from each of the frames and write the corresponding data to an output file. The math encoding for the decoder works in essentially the same way as the encoder, so I won't go too far into detail for it. Now, before you go and drop your Google Drive subscription, there are quite a few factors that make this method completely impractical and more of just a fun proof-of-concept project. Storing with the method I've just talked about completely destroys the file because of one factor, video compression. Video compression is a necessary component of video storage, since completely uncompressed video takes up vast amounts of data. So rather than storing a bit or multiple bits in each pixel of each frame, we have to expand the size each bit takes up. To achieve lossless conversion, I've found I need at least four pixel-wide information blocks, meaning each bit takes up 16 pixels, which drastically increases storage size. With this factored in, with my setup, a file sees about a 20x increase in size when converted to its video counterpart. I knew this would be the result of the project before I started, but 20x still seems a little bit ludicrous to me. There are a few ideas I have to bring this factor down a fair bit, but I'm not going to bother to implement them, since the point of this project was just to successfully convert a file to a video and back to a file again, which is something I've achieved. But more importantly, just to complete a fun project. Anyways, if you want to look at the code, the GitHub link will be in the description, and if you have any questions or tips on improvement, let me know, and thanks for watching.