If you like DNray Forum, you can support it by - BTC: bc1qppjcl3c2cyjazy6lepmrv3fh6ke9mxs7zpfky0 , TRC20 and more...

 

YouTubeDrive's experimental program

Started by rafiazafar, Sep 19, 2022, 09:11 AM

Previous topic - Next topic

rafiazafarTopic starter


Unlimited hosting may seem impossible, but many internet services offer unlimited storage, such as social networks and photo web hosting. While YouTube limits individual video size to 12 hours or 256 GB, there are no restrictions on the number of videos uploaded.



In theory, embedding an encrypted copy of an SSD into multiple 256 GB videos is possible. The challenge is bypassing file format checks designed to avoid service abuse. Traditional methods such as changing file extensions or metadata do not work on most web hosts. However, steganography methods offer a solution.
One tool available for steganography is YouTubeDrive, which recodes files into RGB pixels and transcodes them into a video stream. The intermediate video format is created for video hosting purposes, allowing YouTube to upload and download videos automatically.

Since YouTube does not limit the total number of uploaded videos, this provides virtually unlimited hosting. Nonetheless, this method is slow as it involves encoding/decoding at both the local PC and YouTube servers. YouTubeDrive employs standard utilities such as FFmpeg, youtube-upload, and youtube-dl. Before opening the YouTubeDrive package, users must install these programs and specify their installation locations. The package itself contains two main functions, one of which encodes data as a simple RGB video, uploads it to YouTube, and returns the video ID.

The YouTubeDrive package encodes 64x36 RGB pixels that are scaled into 2304 squares of 20x20 pixels in a 1280x720 frame. The RGB values are either 0 or 255, therefore, three bits per square are obtained, which are written to the .PNG files that are then combined using the FFmpeg codec into an MP4 video that can be transcoded on the YouTube server.

Large squares of 20x20 pixels act as an error correction mechanism where the YouTube transcoder randomly swaps the values of individual pixels. The program has two functions, with YouTubeRetrieve decoding and returning a YouTube video with the specified videoid ID. It usually takes 5-10 minutes to process a small video of about 10MB in size on the YouTube server before the video is available to download.

YouBit, on the other hand, improves upon the encoding quality of its predecessors and works with videos of any resolution, optimally 1920x1080. The tool encodes information in the brightness channel only, and the author has implemented an original way to optimize videos for a specific YouTube encoder to increase decoding reliability. Additionally, it features the "zero frames" function, which reduces bitrate and file size by around 40% by inserting black frames between frames with payload. However, both YouTubeDrive and YouBit are purely experimental programs that are not intended for industrial use.
  •  


Bubunt

In my opinion, the author's creation of these tools was driven by academic interest rather than financial need for cloud storage. It's an interesting task to optimize encoding algorithms for real-life conditions, such as the YouTube algorithm.
While sharing these tools may not be ideal, it's likely that similar options already exist, and the author is not the first in this area. If there is a demand for such tools, they will emerge sooner or later.
  •  

allricjohnson1

It's unlikely that YouTube storage abuse would have a significant impact, even if everyone were to start uploading their data to the platform. An average 4k60 streamer would likely surpass those who upload large amounts of data.
 Moreover, traffic is often cited as an expensive resource for YouTube, while such keepers would generate close to zero traffic, since data wouldn't be frequently uploaded or downloaded. It's possible that YouTube stores uploaded videos in their original format, and only transcodes them for viewing, as evidenced by some older videos with better quality after being recoded in av1. Therefore, storage volumes are not a critical concern, and attempts to influence YouTube through storage abuse would be futile.
  •  

manivel

Some species have better video quality in vp9 or av1 compared to h264 due to their ability to preserve source quality. Videos from 15 years ago compressed in av1 now even have better quality than those compressed in vp9. However, these cases are exceptions, as generally, the bitrates for vp9 and av1 are lower compared to h264, resulting in lower quality.

For instance, h264 often has a file size of 100 MB, while vp9 and av1 have 75 MB and 60 MB, respectively. In this case, vp9 is likely to have worse quality than h264, and av1 is worse than vp9. However, when the ratios are reversed, as in h264 - 100 MB, vp9 - 85 MB, av1 - 76 MB, the situation changes.
  •  

loncookware

 I find the concept of using YouTube for unlimited storage quite fascinating. While most might assume that such a feat is simply impossible, the combination of steganography and available online tools like YouTubeDrive and YouBit provides a creative workaround to traditional data hosting limits.

YouTube Drive's method of encoding data into RGB pixels is ingenious. By compressing information into video format, one leverages an existing platform that already provides vast storage without limits on the number of uploads. However, I must point out that such a system isn't without its challenges. Operating under the assumption that users could embed a significant amount of data into video uploads raises questions about the actual performance and reliability of retrieval later on.

One must not overlook the issues of encoding and decoding times. As mentioned, it takes about 5-10 minutes just to process a small video of 10MB, which presents a considerable bottleneck for those wanting to store larger amounts of data quickly. While the YouBit tool offers improvements in encoding quality and is optimized for YouTube's specific encoder, the experimental nature of these programs calls for caution. They might not be suitable for industrial or commercial needs where reliability and speed are paramount.

Additionally, both tools rely heavily on FFmpeg and other programs, making the setup process a bit overwhelming for novice users. The requirement of installing several utilities before getting started can deter many who might be interested in the concept but lack technical prowess.

Moreover, the approach of using video as a data storage medium may also convolute the process of data retrieval. You have to ensure the integrity of the encoded data throughout the upload and download process, and the possibility of data corruption cannot be ignored.

All in all, while this method of using YouTube as a sort of unconventional cloud storage system opens up interesting possibilities, it also poses challenges that can't be overlooked. For anyone considering this route, it's crucial to weigh the benefits against the potential downsides of slow processing times, possible data corruption, and the need for extensive technical knowledge. It raises a thought-provoking question about the future of data storage and the limits of creativity in tech solutions.
  •  


If you like DNray forum, you can support it by - BTC: bc1qppjcl3c2cyjazy6lepmrv3fh6ke9mxs7zpfky0 , TRC20 and more...