Video playback on link share page

[jancborchardt]

When trying to play a regular mp4 from the share link page, there was this error:

We should really be able to play these files, no? cc @oparoz @Instagit @LukasReschke

[icewind1991]

Being able to play video files is completely dependent on whether your browser feels like it or not

[oparoz]

As long as we don't analyse every video file which is uploaded to extract some metadata, there is no way to prevent this behaviour.

[jancborchardt]

As long as we don't analyse every video file which is uploaded to extract some metadata

So isn’t this something we should maybe do? ;) Sharing videos is arguably a big usecase.

[icewind1991]

We won't be able to play the video anyway as long as the browser doesn't support it

[MorrisJobke]

So isn’t this something we should maybe do? ;) Sharing videos is arguably a big usecase.

The only workaround is to transcode the videos on the server. And you don't want to do this in PHP -.- And it even could take very long. I also thought about this a lot. Maybe something for a nice app, because I had in mind to also transcode videos to a smaller size (depending on the network connection). But I guess this is a bigger task. Even big companies invested a lot of time to get this right and flawlessly :(

The only way is to upload one of the following video files (container format, video codec, audio codec):

• WebM with VP8 and Ogg Vorbis
• MP4 with H264 and MP3
• MP4 with H264 and AAC

https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats#Browser_compatibility

[MorrisJobke]

WebM with VP8 and Ogg Vorbis

WebM support on IE and Safari depends on a to be installed codec

MP4 with H264 and AAC

AAC is not supported in Chromium

MP4, H264, MP3, AAC on Firefox:

To avoid patent issues, support for MPEG 4, H.264 and MP3 is not built directly into Firefox. Instead it relies on support from the OS or hardware (the hardware also needs to be able to support the profile used to encode the video, in the case of MP4). Firefox supports these formats on the following platforms: Windows Vista+ since Firefox 22.0, Android since Firefox 20.0, Firefox OS since Firefox 15.0, Linux since Firefox 26.0 (relies on GStreamer codecs) and OS X 10.7 since Firefox 35.0.

[MorrisJobke]

@jancborchardt As you see: To play a video file in all available browsers you need at least the video available in 2 different containers, with 2 different audio codecs and 2 different video codecs.

[MorrisJobke]

I just gave this another try (because I have another use case for myself). And somehow the files aren't played even if they are MP4 with H264 and MP3. I will give this tomorrow another try and hopefully get this sorted out.

[MorrisJobke]

I ran into #463. @jancborchardt Did you also use PHP7? Maybe check the server logs and test with the linked PR ;)

[Instagit]

We discussed video handling before in a different context (showing videos in the gallery) and there are several possible solutions, but they all have drawbacks.

• use a browser plugin for video playback
• access metadata with external tool like FFmpeg and store it, so we can always tell which video is compatible with the user's current browser
• transcode videos in the background after upload
• transcode videos live

Maybe another solution is setting up an FAQ page that explains the situation and tells the user in simple steps how to encode videos that can be played by all browsers and linking to that whenever a video can't be played. ℹ️

[MorrisJobke]

Maybe another solution is setting up an FAQ page that explains the situation and tells the user in simple steps how to encode videos that can be played by all browsers and linking to that whenever a video can't be played. ℹ️

I like that 👍

[Bugsbane]

Short term the FAQ link seems to be the best ratio of improvement to effort. Longer term though, I'd say that sharing videos and having them play back is an important enough use case that it would be worth working towards having it work. It's a more complex system, but I'd suggest:

1. Read the metadata on upload
2. If the server has FFMPEG installed and an option is enabled in the config file then call that to transcode in the background to mp4+h264+mp3 for Chrome/IE/Edge and Webm+vp8+ogg for Firefox/Chromium.
3. Use the transcoded version for playback, detecting the user agent to determine the correct version, while the originals are used for any download.
4. Display the FAQ link instead if we detect any error (eg unrecognized user agent)

[MorrisJobke]

I'm open to help out here (especially for the first steps with showing a FAQ on error, but if somebody wants to do this: feel free :) I will assign me once I start working on it.

[Instagit]

If the server has FFMPEG installed and an option is enabled in the config file then call that to transcode in the background to mp4+h264+mp3 for Chrome/IE/Edge and Webm+vp8+ogg for Firefox/Chromium.

We've considered that in the other issue I linked. The problem is that real-time transcoding requires quite decent hardware. It would need to encode at 25+ FPS, even for full HD (and in the future 4k), and while we have no hardware statistics, we can assume that many users run Nextcloud on low-powered media boxes, virtual servers etc. I have an i7 and depending on the video content, resolution and encoding options, I can't even reliably hit 25 FPS with that.

Transcoding automatically in the background can be configured to be easier on the hardware, but requires a lot of disk space. Either way, it will only solve the problem for a few users, but maybe it's a nice feature to have anyway. When it's implemented, we could also offer on-demand transcoding for single videos and that would give users some good options.

[MorrisJobke]

Maybe it would also be nice to have specific app that transcode in a background job and places the file then in a "cache" directory. Then when requested this pre-transcoded files could be used and would also allow to transcode to a smaller version (360p, 480p, 720p, 1080p for example).

[LukasReschke]

We can't do any FFMPEG background transcode processes invoked by the same PHP process. That is totally insecure. What you could do is having an app that runs on another server and there invokes some docker magic to securely transcode the videos in a container.

[LukasReschke]

https://habrahabr.ru/company/mailru/blog/274855/ has a good example of why we can't use ffmpeg in a trusted environment on untrusted user data.

Basically: it's defined behaviour of ffmpeg to not use it on untrusted data.

[jospoortvliet]

At least #463 fixes, for my Nextcloud, the problem. Well, the patch doesn't apply (Hunk 1 out of 1 failed) but manually changing 'split' to 'explode' on line 191 of the lib/private/files.php makes videos play properly in a share.

[Newan]

I have the same problem.
But intern (login in with the video owner) run the video. Only on the share link it doesn´t

[bulleric]

Got the same issue... Is it fixed in master?

[Instagit]

We can't do any FFMPEG background transcode processes invoked by the same PHP process. That is totally insecure. What you could do is having an app that runs on another server and there invokes some docker magic to securely transcode the videos in a container.

Using Docker would be nice, it can even run a transcoding web service on the same machine - but is it really an option? Docker can be quite difficult to set up on some systems.

For the realistic short-term improvement, an FAQ page, what would it include and how would it be implemented (local page, link to documentation)? I suggest a link to a list of supported browser formats (1 ^[1], 2, 3) and a program that can transcode videos and is easy to use (Handbrake is probably the best open source, cross-platform option).

^[1] The data from caniuse.com is available as JSON so it could be presented in a more compact form for all required formats.

[szaimen]

If the videoplayer app installed, it works fine in my testing.
So since I cannot reproduce the original issue anymore, I will close this ticket. If this is still happening please make sure to upgrade to the latest version. After that, feel free to reopen.