Under review

Transcode Videos On Upload?

metal450 3 years ago updated 3 years ago 8

What I've found is that the vast majority of times I share videos, people tell me "I can't view them."  This is because the original is very large, so when someone tries to view it over slower remote connections, it seems to just be loading forever (or super slowly).  I realize that a solution to this is to simply turn off the web viewer & thus force people to pre-download the whole file remotely.  However, a more elegant solution - the way Dropbox handles it - is to transcode/downsample the videos to a lower bitrate on-upload; when viewed in the web viewer, it plays this stream-friendly version, and also provides a link to download the full quality original.  It would be awesome if FileRun might do something similar - transcode/downsample videos on-upload, making it possible for even larger (or i.e. HEVC-encoded) videos to be played directly in the browser.

Under review

Transcoding takes a long time, so it would be impractical to do it at upload time.

But we're looking into having FileRun use a third-party tool, such as FFmpeg to transcode in real-time when previewing. This would also avoid excessive usage on the storage space for videos that might not get previewed.


>>Transcoding takes a long time, so it would be impractical to do it at upload time.  But we're looking into having FileRun use a third-party tool, such as FFmpeg to transcode in real-time when previewing.

If transcoding takes a long time...wouldn't it be much more impractical to do it in *real-time*, rather than queueing a task on upload that could take as long as needed to produce the preview, just once?  Many NAS/servers don't have CPUs capable of realtime transcoding, whereas any CPU could transcode to another file (i.e. via ffmpeg) given enough time.

>>This would also avoid excessive usage on the storage space for videos that might not get previewed.

Certainly this would be optional, so users who don't need/want it could disable previews - and if the quality(s) were customizeable, space usage could be limited.  But certainly there are many scenarios where usage wouldn't be "excessive" - i.e. it could be configured to do just one half-res preview, or for people who only share videos occasionally, etc.

Transcoding for streaming is not an issue on any modern machine.

FileRun will never have a feature where it automatically stores different versions/formats of a video file, or any type of file for that matter. That's something that the user can do, manually, if he wants/needs to.

Bummer.  I figured this would be a great candidate for a feature, as: 1) It's definitely how Dropbox operates, & Dropbox is precisely what I'm working to replace with Filerun; 2) I've had multiple users specifically express issues with videos due to this.

As far as doing it manually, besides the fact that would make sharing videos significantly more cumbersome/time-intensive, and that some users likely wouldn't know how to do this themselves, it also makes it more difficult on the viewer end too, as the viewer has to choose separately if they want to view the low-res vs high-res version (i.e. if they want to view vs download) - rather than it just appearing as one file, where you can view it (transcoded) or select the download (shown as available on the same page), as it works on Dropbox.

But anyway, I guess it is what it is.  If it will "never have this feature," I guess the option is to stick with Dropbox for video-sharing :/

Just out of curiosity, how can I make it so that visiting a shared video link will *never* try to play in the browser - it will only send it to the visitor as a download?  Users have reported to me that the way it operates currently, sharing videos effectively never works as the browser just tires to buffer indefinitely.

Your case usage is just one out of many. Our goal is not to replicate how Dropbox works.

You can simply delete "customizables\plugins\video_player". Or if you share via links, check the advanced options panel, as there is an option specifically for forcing the download.


>>Your case usage is just one out of many.

Of course, I don't imply that my use case is the same as everyone's - "FileRun will never have a feature..." just made it sound like you view this use-case as utterly invalid/useless/etc, where frankly I'd be a bit surprised if it were that uncommon where someone might want to share videos where the source is very high-quality, but viewers may not have sufficient bandwidth. Anyway tho, just my 2c - obviously it's your call :P

>>Our goal is not to replicate how Dropbox works.

Again, understood/agreed.  But you must admit the feature set is very similar, so whether or not your goal is to replicate everything, I figured it wouldn't be unreasonable to present its handling as an example to possibly draw inspiration.  There's a difference between "make this identical!" and "hey, here's a possible good idea, and you can see an example of how one very similar service handled it (which may also lend some credence to its usefulness)."

In any case, I see that your view is that it's not useful, so I guess for now I'll just force-download all videos to prevent further users from reporting them as broken.

"FileRun will never have a feature..." just made it sound like you view this use-case as utterly invalid/useless/etc

Not at all. It's just that it is not aligned with FileRun's development direction. FileRun not being a media streaming or viewing software, having support for various video formats or adapting to various bandwidths, is not something we would put development time in. Saving duplicate versions of a file is not a solution we would adopt for any problem, thus, the real-time transcoding would be the only solution we would consider for this particular need.


Sure, I mean if realtime transcoding could indeed be made to work reliably, it would be an even more ideal solution - similar user-facing result with no duplicate storage.  I just have doubts about how feasible this would be in practice, as many NASs probably don't have sufficient CPUs (there might also be issues due to virtualization, i.e. running it in Docker).  But if it could work...I think it'd be a great solution :)