Google Drive: Support streaming formats for video files

Feature
1

Since I registered in the rclone forum almost 7 years ago, the tool has made huge leaps. I would like to express my deepest thanks to @ncw for not only providing and maintaining the software open-source, but also for continuing to be active here in the forum! Thanks, Nick!

I would like to make the following feature request:

Like so many people, I use rclone to mount my movies and series from Google Drive on a server running Plex, Emby or (in my case) Jellyfin.

Since some films use DTS audio, others AC3, some use avi, mp4, mkv as the file format, some use x264, x265, etc. as the video codec. Not all end devices can handle these many formats and also due to the available bandwidth between the media server and the device, the media servers transcode the video formats on the fly. However, this costs a lot of computing capacity. Otherwise, I would like to run the media server on a small VM or a Raspberry. But even if I rent a very expensive server, like the one I currently have, it often reaches its load limit (even if two people are streaming).

With Kodi, which is unfortunately less of a media server and more of a local media library, there is a plugin for Google Drive where you can choose to play the streaming version instead of the original file either for each video or as a standard setting. As many people know, Google Drive also creates streaming formats for every video file, similar to YouTube (the same player is even used).

For example, a 1080p film in Google Drive has 10.2 GB - as a streaming format in 1080p it only has 3.1 GB. That's brilliant: Google Drive has taken over the transcoding work. It converts any video, including 4k films, into streaming versions that use mp4 x264 as the video codec and mp4a aac as the audio codec - codecs that almost every device supports. Transcoding by the server would be unnecessary.

This would save a lot of resources if it could be used. And that would also be my wish: Please add a “preferred-1080” (or -720 or -480(***) or -360) option for Google Drive. If this command is entered, rclone will retrieve the 1080p streaming version for each video file instead of the original file. In addition, a fallback to the next available lower version should be pre-programmed, which could be overridden by a "no-fallback" command.

With Google Drive the qualities are uniform: there are 360, 720 and 1080p (***: there used to be 480p). But: of course there is never a higher quality than the original video. So if the original itself only has 480p, there will only be a 360p version, but not 720p or even 1080. I also noticed that many files only have a 360p version, even though the original was 1080p, for example (BTW: In this case, you can simply duplicate the file using the “Create a copy” function and Google Drive will completely restart the process of creating the streaming format).

Even if you have a video with a higher resolution than 1080p: a resolution sharper than 1080p will not be created. So if you want to watch in 4K, you have to use the original.

Here I have two open source tools that can also intercept the streaming formats (such as the Kodi-Google Drive plugin above) or can even download them (JDownloader):

GitHub - cguZZman/plugin.googledrive: The Google Drive addon for Kodi (since I'm no developer I don't know where exactly the code for the streaming variants is)

(JDownloader2 source code will be delivered later)

2

Do you realise that most people store their files (including videos' collections) using crypt? And functionality you described could only work without it which makes IMO its real life appeal very limited.

3

How do you know that most users encrypt? Are there statistics to back this up or are you just drawing conclusions from yourself to others? Encryption sounds illogical, at least with videos. This undermines Drive's internal data deduplication - for sure one reason why Google is increasingly kicking out data hoarders.

So: just because YOU encrypt your files doesn't mean almost everyone does. There are certainly many who had put their files on Drive before using rclone and the encryption with rclone is not an automatic mechanism, but requires a targeted setup. That alone makes it unlikely that most people will use the crypt function. But even if there were, there would still be many rclone users, whether relative or absolute, who would save unencrypted and would also prefer such a function. Do you realize that?

4

Generally, majority of people I see/read/post/peruse on other reddits/forums/etc are generally security concerned so they encrypt their data (video or otherwise) when storing on 3rd party repos.

That would be the same for video/data/etc.

I'd not even touch this one as there have been way too many discussions on that one.

(joking) based on what? your assumptions? you have statistics? (/joking)

This is the first feature request I've seen asking to incorporate video streaming in rclone as rclone is a cloud storage tool, not a video player. Generally for something on an edge case, you'd either write it, find someone to write it or sponsor it if it is something that's meaningful to you.

5

I think you didn't fully understand that my request had nothing to do with video streaming in rclone, but simply that rclone does not ask for the original file from the Google Drive API for supported file types (Google Drive supports all common video formats) at the user's request, but the transcoded video file, which is even made for streaming it, however, unlikely stored "hidden" by Google.

And allow me to make the following comment
You shouldn't draw false conclusions: just because the group concerned about data security discusses the topic a lot does not mean that they are the majority. Comparable to our society: the majority is mostly silent and only the marginalized groups rebel.

6

To cut your discussion about crypt. You ask for numbers but at the same time cannot deliver any statistics yourself. So just leave that topic alone.

About your actual request. Yes, you are asking for streaming/video! You even mentioned the whole thing at the beginning. Rclone does exactly what it is supposed to be. It handles all the files in your google drive.
The transcoded files you want aren't in your drive.
You let it sound like there are dozens of different files that are transcoded. It's only videos and maybe photos at most. Haven't seen any audio files being transcoded.
What you want or need is yt-dlp.
And if you want the exact same functionality you need to request it or code it yourself.
But this is such an edge case. It's doubtful anyone is interested in doing it.

7

I assume that most people make logical choices knowing what are risks and consequences of storing unencrypted content. But fair enough I do not have stats.

There is though more important reason why it is not good idea to include such functionality in rclone. It is simply something outside rclone core functionality.

rclone is rsync for the cloud + few key additions like virtual overlays and mount.

Video transcoding supported by one particular remote is like a square peg in a round hole here.

Please note that every feature comes with cost attached - development time, bugs time, new dependencies and all code increased complexity leading to extra maintenance time for all project.

IMO it is much better to spend limited resources on core functionality - metadata handling, folders metadata, VFS directory disk caching are for example few areas waiting for improvements. Instead of adding niche features with questionable usability (at least for wider audience) and increasing rclone's bloat making it more and more difficult to use and maintain.

I would prefer some open bugs to be fixed - there is 150 on the list - than look for some exotic use cases.

8

I didn't start by claiming that most people would use encryption anyway. I was just questioning this claim. Encrypting video files (I was explicitly talking about films and series, but not any private files) doesn't seem to make much sense. Apart from that, I am not convinced by the argument that a feature should not come because most (and therefore not: all, but it is left open whether a large proportion of rclone users might not use encryption after all) wouldn't need the feature at all. rclone has countless features that most people don't need. Nevertheless, rclone has them because some people need them.

For example, I only know or read about people who use rclone as a mount for their Plex or Emby library and primarily store films and series. But I don't often spend time in the rclone forum or Reddit, but rather on various scene sites. An encryption? People who simply want to run a functional private media library have not ventured into such subject areas. It's also not about a function like yt-dlp. First of all, yt-dlp does not support interception of streaming formats from G Drive, secondly it uses ffmpeg, which would not be necessary for the feature I want rclone to have. The files do not have to be transcoded. Like any other file, they should be output by rclone as normal. This means: if you retrieve a file "video.mp4" on Google Drive and have previously said "preferred-1080" in your rclone command, then rclone does not intercept the original file from the Drive API, but the MP4 that is on the Google servers and which can be received via HTTP request instead.

I also cannot accept @kapitainsky's argument that my wish is outside the core functionality of rclone. As has already been said several times: it's not about video transcoding - as you repeatedly claim here - but it's much simpler: It's just about retrieving already transcoded files that are in mp4 format and can be accessed directly via HTTP request . The function that rclone would get would be: retrieve the streaming variant from the Google server instead of the original file. This is the basic functionality of rclone. Rclone is not supposed to transcode videos itself - I neither claimed nor, if you had read my text properly, would you conclude that I meant something like that.

I spoke to a developer of JDownloader: he said the implementation was very simple. You would see the stream files in the network traffic in the browser's developer tools and quickly find the request with which the streams are fetched. He points to the getStreamDownloadurl function

You will also see a URL there in the plugin in line 1031:
https://drive.google.com/u/0/get_video_info?docid=

After the variable docid you then set the ID of the file from your sharing link ( https://drive.google.com/file/d/_ID_/view?usp=drive_link ) (this can also be called up via the API , which rclone does anyway), press enter and then get a file "get_video_info". I had to enter the contents of the file into a URL decoder and decode the decoding result again so that it would be easy for a human to recognize.

This get_video_info first contains some information about the file, after a "url_encoded_fmt_stream_map=itag" there follows a variable "url". This URL contains:

https://rr2---sn-4g5lzned.c.drive.google.com/videoplayback?expire=1694362441&ei=CENSORED&ip=CENSORED&cp=CENSORED&id=CENSORED&itag=18&source=webdrive&requiressl=yes&mh=mj&mm=32&mn=CENSORED&ms=su&mv=m&mvi=2&pl=37&ttl=transient&susc=dr&driveid=DRIVEID_CENSORED&app=explorer&mime=video/mp4&vprv=1&prv=1&dur=6518.561&lmt=CENSORED&mt=CENSORED&subapp=NONE&txp=0011224&sparams=expire,ei,ip,cp,id,itag,source,requiressl,ttl,susc,driveid,app,mime,vprv,prv,dur,lmt&sig=CENSORED=&lsparams=mh,mm,mn,ms,mv,mvi,pl&lsig=CENSORED==&type=video/mp4

This is followed by the codecs of the stream and, above all, the quality information. In my case: codecs="avc1.42001E, mp4a.40.2"&quality=medium,itag=22 - medium means 360p. This is followed by the URL to 720p and then the one to 1080p. If you enter one of these URLs in the browser, the stream starts - as long as you are in the same session. An authorization error occurs in a different network or just in a different application (e.g. VLC).

I don't want to presume to be able to judge this, but it seems to me as if there is a function in the rclone plugin for Google Drive, instead of requesting the file from an API, simply performing the HTTP request for video formats and the MP4 Intercepting the file is not particularly complicated. At least not as complicated as you're trying to make it seem here.

And precisely because you are now coming with 150 bugs that have not yet been fixed, my suspicion seems to be confirmed that you and your friends are only against my idea because it is in your interests that the functions you frequently use are improved , could move further back.

9

We're all on the same side here. If you want to implement it, please do as it improves rclone as I laid out some steps in my previous posts.

10

Well this is how it works. Do not expect that everybody will be supportive of your ideas.

Me personally I think it is bad for rclone to add such thing and I would vote against - but it is my own opinion.

Of course I might be wrong with my assessment what is popular demand for this feature and how useful it might be. I am not pretending I know all.

1 Like
11

Thanks for the laugh in the morning. :rofl:
This must be troll and if it is not then you cannot explain it anyways because basic concepts of understanding the functionality of rclone is simply missing.
I am quite surprised this person has made it this far.
To people stumbling over this thread:

When you have a western cloud company they are basically obliged to check if their service is used with criminal intent.
They look for hashes of pirated files and other forbidden media. When you download those "scene"-releases that you mentioned you are not doing a "backup" of the BluRays you physically own but you are clearly pirating and any western cloud provider will at least block access to those files when those are shared, but most likely they will terminate your account as a whole.
On the other hand when you are from China, Russia, Turkey, Indonesia, Singapur, India whatever - the reach of western company advocates is not that great. When you put unencrypted piracy on their cloud most likely nothing will happen and they behave exactly as you expect here.
Actually this might be maybe a business model in the future from China or Russia. They offer a cloud for media without encryption and make deduplication. With that they have a big advantage over the western services when it goes to this sort of clients.

And regarding the idea of some videoplay-shennanigans in rclone this is absolutely not what people want and it goes against good linux principle to have one tool to do one thing, and this do very good stable, and not create some software monstrosity that does everything but nothing good.

2 Likes
12

I've read this thread with great interest.

The way @Unvency is using the cloud (supposedly storing scene releases) is not my cup of cake honestly and depending on the country it even have legal implications of course but I think you all know that a HUGE portion of the rclone userbase is not exactly using it for storing their collection of cats pictures.

Also most of you guys still haven't really understood what he's talking about and I'm quite baffled.

He is NOT talking about streaming AT ALL.

He is asking to be able to download other VERSIONS of the file already sitting on Google Drive servers.

This is extremely similar to "versioning", but with the HUGE benefit of leveraging Google's immense computing power to offline convert video files.

I'm using rclone to manage my footage archive (I'm a video shooter and for example some interviews when shooting with the latest 4K/6K cameras can generate single video files in excess of 100GB each), also a ProRes444 video master of a feature documentary film is approx 1TB (again SINGLE FILE).

So being able to DOWNLOAD the alternative VERSIONS already converted by Google servers would be VERY handy for sure in some situations!

I know I'm not alone among video creators.

In fact I think that this feature would benefit MORE who like me is using rclone to manage original and unpirated content, versus many features like mount which are HUGELY more popular among users who store pirated content on the cloud.

So please (especially if you didn't even understood well the request) STOP talking about pirated content because this feature request has NOTHING to do with piracy, Plex and Emby both have support for real time hardware transcoding for example, rendering this feature unnecessary for users who use the cloud to store movies and tv series, especially because these users store everything usually encrypted which disable this feature since Google servers can't see video files at all.

My 2c, I come in peace.

1 Like
13

It doesn't matter for whatever reason OP wants this functionality.
This feature got requested a couple of timea already.
So far drive implementation is based on official api. The different transcodings of a video on your drive are not available through the official api but an undocumented one. It's likely not even possible to use the api key to download the transcoded files.

These are the current options:

  • Request this feature so someone might implement it (already done)
  • Code it yourself
  • Use yt-dlp which does EXACTLY what was asked for

What would be the benefit over using rclone only vs another program? This is once again an edge case.

14

@Staroy
I have rarely read such nonsense!
First of all: lumping the whole “West” together is completely stupid. You cannot compare the law of Great Britain with the law of the USA, not even EU countries have a similar legal system.

In the EU, the “Notice & Takedown” (NTD) principle applies - this means that you do not have to actively ensure that no pirated data gets onto the servers. In the event of an abuse report, it is sufficient to take the file offline within two to three days (so you don't even have to delete it, just stop sharing).

However, the exact details vary from EU country to EU country and if the federal legislature even leaves regulations open, the respective jurisdiction still has a say.

While in Germany, France and some other EU states the law is based on Roman law, in Great Britain it is Anglo-Saxon law. In the USA, completely different principles apply.

While in Germany, for example, downloading pirated copies gives rise to a claim for damages (i.e. action can only be taken against it under civil law) and only offering them could be prosecuted, in Switzerland - the direct neighboring country with a very similar culture - downloading is legal and only sharing is can be punished (but only at the request of the injured party and a penalty cannot exceed 1 year).

You see: it is completely irrelevant to simply speak fundamentally about the West. As an American company, Google must apply local law in the country in which it does business, not American law.

What you are claiming is complete nonsense. Although I only allow a limited number of people to access my archive, there has never been a report from Google in all these years.

Incidentally, it should be noted that this is not about “Scene”, not about the West, not about China, not about Russia. Back to topic!

@dia3olik
You are the first user who understands my request. Thank you!

@blackjack4494
I've told you before that yt-dlp does NOT offer what I need right now. Neither can yt-dlp download this version that I need nor can it mount the drive as a drive.

15

I think we've covered this topic as noted above.

^^^^

Closing as we're not being nice to each other.