You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Make it possible to play unsupported video codecs #1207
Is your feature request related to a problem? Please describe.
Some video containers are not supported by webbrowsers and probably will not be in the near future.
A word of caution though.
Ffmpeg as a child of a php thread is probably a limited experience, prone to hanging the whole system. Even rewrapping could be too much.
My first thought appart from this, was to offload the task to a mature standalone server, also capable of using GPUs, and providing an IN/OUT API for nextcloud. The vast amount of combinations in containers and codecs regarding web delivery also seems to me a very standalone project idea.
I think the memories app has the pssibility to transcode videos on the fly. So maybe we could have a look at the app how they are doing it which sounds like the best approach to me.
IIRC ffmpeg as a subprocess of php would limit to 1 thread.
Encoding ProRes to h264 can easily eat 500% cpu on 2.2Ghz.
That's why I recommend ffmpeg to be an instance that is independent and can take care of itself.
IMO this is about much more than supporting other video formats. Note that modern cameraphones don't encode their videos with HLS for streaming, and can produce very large files. Here are some of the other reasons I have in mind:
Devices, browsers, and connections vary greatly in their capabilities
All browsers suck at skipping around in a 400MB remote 4k video file without HLS and chunking.
Present implementation seems to start a new process reading the entire video file for every reload (or maybe every time the user skips around in the file), which is very IO heavy. And since the whole experience is dead slow for a big video file, users do a lot of reloading. (This has brought my storage cluster to its' knees several times)
modern users expect adaptive resolution adjustment for bandwidth and browser capabilities..
Other parts of Nextcloud (Memories, namely) transcode, so the user experience of video watching changes drastically depending on where they launched the file from.
Recommend:
changing the Issue title to "Implement transcoding to playback video on variety of devices, bandwidths, and file formats"
making it easier for 3p apps to replace parts of the interface for video/photo viewing, so e.g. memories doesn't need to implement it's own whole modal window to get their improvements to the video experience... they can just replace part of Viewer's video modal interface and use that.
for reference i recommend to also open the research looking at bigger scale applications:
i'm in awe how much optimization Jellyfin is doing to get as far as possible without encoding (basically rewrapping). Every browser has its own limits in combination of stream+container. Their Progress is slow and as such very impressive to find respect in.
Streaming servers such as the Mistserver (now open source) built their whole businessmodel on the fact that no app wants to do what they do, if not necessary. Mistserver doesn't even do encoding primarily. It primarily works on finding the best possible combination for the specific browser. It is heavy on API implementation, which is impressive. Built to be invisible.
There are simpler give/take platforms that do the handling/encoding externally that may be more measured for NC plugging (think in terms of what NC did for external office servers).
I work in postproduction and tried a lot of things to automate our facility. I believe we should keep a good look at hw limits. Because if something works, doesn't mean it works always. The devil is in the details. Sometimes a higher bitrate means game over. Or a different codec. When you reach the need for a GPU, you also dont want to have this inside a NC instance since it's very bulky hardware-whise.
I think this could be something to burn our fingers on.
It may be worthwhile to check on an external encoder. Maybe something smaller, a docker instance even. I think at some point the problems that video online delivery holds, should be contained in a separate instance.
I found multiple projects at first glance, but not the promising one right away, i earlier found trustworthy and mature, Sorry. Mistserver doesn't do GPU, so i would not recommend it as a sole solution (i deliver preencoded multichannel mpeg_ts to mistserver, but thats streaming not VOD)
My remarks seem overkill,
but if there are fitting solutions out there, this may well overlap with the desire for NC to be a video delivery platform, which for files it already is.
That's actually how Memories does it - the app downloads go-vod at runtime. In settings you can choose to use an external go-vod over HTTP, specifically so you can separate hardware requirements as necessary.
While I agree that there are lots of potential solutions to investigate, given that there's already a Nextcloud-based implementation that offers the all the desired capabilities using Vue, we should focus on leveraging that work. I also created a ticket on Memories to add the option to override the video/photo viewers globally.
Thank you for the suggestion and for taking the time to report it.
The Nextcloud Viewer is no longer developed as a standalone app. Its code has moved to the @nextcloud/viewer library, which is now maintained at https://github.com/nextcloud-libraries/nextcloud-viewer. Because of this, we will not add any further enhancements to this repository and are closing open feature requests here.
Activity
labor4 commentedon Dec 21, 2022
I see what you mean ;-)
A word of caution though.
Ffmpeg as a child of a php thread is probably a limited experience, prone to hanging the whole system. Even rewrapping could be too much.
My first thought appart from this, was to offload the task to a mature standalone server, also capable of using GPUs, and providing an IN/OUT API for nextcloud. The vast amount of combinations in containers and codecs regarding web delivery also seems to me a very standalone project idea.
szaimen commentedon Dec 21, 2022
I think the memories app has the pssibility to transcode videos on the fly. So maybe we could have a look at the app how they are doing it which sounds like the best approach to me.
labor4 commentedon Dec 21, 2022
IIRC ffmpeg as a subprocess of php would limit to 1 thread.
Encoding ProRes to h264 can easily eat 500% cpu on 2.2Ghz.
That's why I recommend ffmpeg to be an instance that is independent and can take care of itself.
szaimen commentedon Mar 1, 2023
The memories app features on-the-fly transcoding now
skjnldsv commentedon Mar 1, 2023
Done via php and ffmpeg btw
https://github.com/pulsejet/memories/wiki/Configuration
szaimen commentedon Mar 1, 2023
No, the transcoder is written in go IIRC:
https://github.com/pulsejet/go-vod
ohthehugemanatee commentedon Oct 10, 2023
IMO this is about much more than supporting other video formats. Note that modern cameraphones don't encode their videos with HLS for streaming, and can produce very large files. Here are some of the other reasons I have in mind:
Recommend:
labor4 commentedon Oct 10, 2023
for reference i recommend to also open the research looking at bigger scale applications:
I think this could be something to burn our fingers on.
It may be worthwhile to check on an external encoder. Maybe something smaller, a docker instance even. I think at some point the problems that video online delivery holds, should be contained in a separate instance.
I found multiple projects at first glance, but not the promising one right away, i earlier found trustworthy and mature, Sorry. Mistserver doesn't do GPU, so i would not recommend it as a sole solution (i deliver preencoded multichannel mpeg_ts to mistserver, but thats streaming not VOD)
My remarks seem overkill,
but if there are fitting solutions out there, this may well overlap with the desire for NC to be a video delivery platform, which for files it already is.
best wishes
m
ohthehugemanatee commentedon Oct 10, 2023
That's actually how Memories does it - the app downloads go-vod at runtime. In settings you can choose to use an external go-vod over HTTP, specifically so you can separate hardware requirements as necessary.
While I agree that there are lots of potential solutions to investigate, given that there's already a Nextcloud-based implementation that offers the all the desired capabilities using Vue, we should focus on leveraging that work. I also created a ticket on Memories to add the option to override the video/photo viewers globally.
ohthehugemanatee commentedon Oct 11, 2023
related #330 nextcloud/server#39560 and nextcloud/server#19567
susnux commentedon Oct 25, 2026
Thank you for the suggestion and for taking the time to report it.
The Nextcloud Viewer is no longer developed as a standalone app. Its code has moved to the
@nextcloud/viewerlibrary, which is now maintained at https://github.com/nextcloud-libraries/nextcloud-viewer. Because of this, we will not add any further enhancements to this repository and are closing open feature requests here.If you are still interested in this feature, please open a new feature request in the library repository:
https://github.com/nextcloud-libraries/nextcloud-viewer/issues/new/choose
Feel free to link back to this issue so the existing discussion is not lost.