Handbrake: Flatpak bundles

Created on 26 Dec 2016  路  42Comments  路  Source: HandBrake/HandBrake

Flatpak initial support was merged (#231) some time ago. Are bundles available somewhere?

By the way, upstream is targeting 0.8 series as LTS: https://blogs.gnome.org/alexl/2016/12/22/a-stable-base-for-flatpak-0-8/

Enhancement

Most helpful comment

FYI, I've been working on this over the last few days. It's all working to my satisfaction now. It'll take a bit more time to get our build server set up to build flatpaks, but once that's done we'll be posting them to the nightly builds.

Anyone interested in building their own flatpaks can follow the instructions here (start at "Install dependencies"):
https://handbrake.fr/docs/en/latest/developer/flatpak-repo.html

The infrastructure I put in place can also automatically generate the necessary manifest and appstream files for publishing on flathub. So when we get around to doing a 1.2 release, I hope to publish to flathub.

All 42 comments

We are looking into it at the moment. We haven't made a decision yet about what to do.

If the current state of affairs makes it worthwhile, then we will likely publish them.

As a case you would take a look at snap or appimage(somewhere, somewhat not relevant and obsolescent ) also.
While using debian(e.g.) there is no sense to request only one more deb file while other distributions are need this tool too.

I am really looking forward to Flatpak!

Would be great for all Fedora users as there is no official RPM, only this version http://negativo17.org/handbrake/

Building HandBrake for Linux provides instructions for CentOS/RHEL and Fedora.

Just a "me too".

If I want to compile HandBrake from source I need all the libraries it uses. But it requires newer versions than my distribution provides. So I can either rip out the guts of my distro and update a bunch of multimedia applications, with .src.rpms from random places. Ouch. Or I have to separately compile all those libraries into /opt/ or /usr/local and fix HandBrake's configure to look there. Either way is a ton of busy work.

This is exactly what flatpak and appimage were created for!

When I initially added flatpak support, there were several deficiencies with flatpak portals that resulted in various bugs and limitations (like Help->Guide being unable to open the HandBrake documentation in a browser). The flatpak developers have been working to fill these gaps, but I haven't returned to it recently to check status.

I'll dig back into this once the activity on the recent release settles down and I have more time to give it.

But as bradley points out, I documented the basics of creating a HandBrake flatpak bundle and managing a repo here https://handbrake.fr/docs/en/latest/developer/flatpak-repo.html. I created these instructions at a time when flatpak tools development was in a lot of flux, so it's quite likely some steps may need updates. We can always use help with further development and documentation, so anyone with an interest is welcome to lend a hand.

Now that Flathub is a thing, maybe an official Flatpak manifest should be put and maintained there instead of having users host their own repo?

I'm not certain whether our intent is to distribute via a third-party repository, our own repository, or provide a single file bundle. That said, we'll only go any of those routes when we're ready to support HandBrake and our users via such channels.

i.e., HandBrake Flatpak is still experimental.

I briefly looked into getting this on Flathub but the build system tries to do a lot of bundling and I just got tired of trying to patch it out.

Another "me too" here.

It'd be really great to be able to have functional handbrake without having to compile, and a unified instruction set for all linux would probably help (or at this point it's more of not excluding every entity that's not based on Ubuntu).

@all-the-good-ones-are-gone

The documentation at https://handbrake.fr/docs lists detailed instructions for many other Linuxes and BSDs. Doing our best to be inclusive, where we can reasonably do so!

@bradleysepos
Unless I missed something the docs link here for anything that's not Ubuntu, and here links back to docs for instructions.

Docs:

For other Linux, please compile from the official source code.

github:

For information on downloading, building/installing, and using HandBrake, see the official HandBrake Documentation.

Apologies if I misinterpreted your comments. Indeed, we do not currently distribute binaries for platforms other than Ubuntu.

To clarify, the documentation provides detailed instructions for compiling on multiple Linuxes and BSDs. See the latest Table of contents, and scroll down to the Developer documentation section.

This is the best we can do at the moment, given our resources. Flatpak will be an excellent addition to our offerings should we decide to continue down that road. 馃樃

I was overjoyed when recently Handbrake was made available for Fedora via RPM Fusion!

sudo dnf install handbrake will get you the full GUI version :)

Name         : HandBrake
Version      : 1.0.7
Release      : 8.fc27
Arch         : x86_64
Size         : 406 k
Source       : HandBrake-1.0.7-8.fc27.src.rpm
Repo         : rpmfusion-free-updates
Summary      : An open-source multiplatform video transcoder
URL          : http://handbrake.fr/
License      : GPLv2+
Description  : HandBrake is a general-purpose, free, open-source,
             : cross-platform, multithreaded video transcoder software
             : application. It can process most common multimedia files and any
             : DVD or Bluray sources that do not contain any kind of copy
             : protection.
             : 
             : This package contains the command line version of the program.

@David-Else To my knowledge, we haven't reviewed the RPM Fusion package to verify it is unaltered. I absolutely suggest you read Where to get HandBrake. We unfortunately have a fairly extensive list of packages from popular repositories that are broken in various ways. It's also important to know that 1.0.4 is the latest HandBrake release for Linux/BSD.

I will definitely investigate the source RPM to see whether it is altered and/or broken. That said, if it is not in a good state, it is unlikely it will be fixed. We have a zero percent success rate asking packagers not to make sweeping changes such as removing MP4 support or swapping Libav for FFmpeg, which are not ABI compatible!

To sum, unofficial builds on third party repositories are almost universally broken and cause a lot of support requests for us. We do our best to make compiling quick and painless, and it's the best way to ensure full functionality and stability.

@bradleysepos Thanks for the info, but basically I waited a year to get any kind of working Handbrake for Fedora. I have used Handbrake for years on Windows and was missing it badly in Linux, it is a minor miracle I can finally use it and have absolute trust in the RPM Fusion crew or I would not install any of their releases on my machine!

I would be very grateful if you could post back in this thread any finding you have about the RPM version, and hope you will communicate with them any concerns.

Thanks for helping with the amazing project!

@David-Else Perhaps if you read the spec file, you will see they do not deserve your trust. The log shows a long history of breaking modifications, including swapping in FFmpeg. So I guess they get added to the wall of shame. 馃槥

To be clear, we know why these changes break HandBrake and there's nothing we can do about it. We typically email packagers, but they keep doing what they're doing. It's unfortunate, but I do not have absolute trust in any packaging team. The closest would be the excellent CentOS team, and to my knowledge they've never shipped HandBrake.

Anyway, our very own @jstebbins develops HandBrake on Fedora. I certainly hope you will take his advice over mine, and compile from source (see https://handbrake.fr/docs/en/latest/developer/install-dependencies-fedora.html). Without even installing it, I'm certain John can list multiple broken functionalities in the RPM Fusion package because we've seen other packagers make the same mistakes, and refuse to correct them.

@bradleysepos I am a user of HandBrake, not a developer or packager, it is kind of crazy to think i would understand the spec file?

The fact that "the excellent CentOS team" have never shipped HandBrake is evidence that they are NOT excellent. Maybe they are technical geniuses, but from a user of HandBrake's point of view that is irrelevant.

I tried to switch to Centos myself last year, and was thwarted by a packager simply refusing to compile a 32bit version of Wine for some strange ideological reason... which meant 90% of the Windows software would not run... but that did not matter to him!?

I hope in the future to know more about Linux and be able to help more, but for now I can't compile from source and have zero interest in doing so, like 99.99% of all users of the software.

If @jstebbins develops HandBrake on Fedora, where is it?! A flatpack makes all this nonsense go away, so I really hope it happens sooner rather that later!

Sorry to sound grumpy, I really do apppreciate everything you and the other HandBrake developers are doing, but I think highly technical people sometimes forget things like how a fraction of a minority of people are interested in the development and packaging, everyone just want the software to work on their system, and the more systems it works on, the more successful the software.

Oh absolutely, you don't have to understand a spec file. To be clear, I was suggesting you read the changelog at the bottom of it. It reveals in plain English what is going on, and I've tried to explain further here.

Anyway, this is why we provide step by step instructions you can paste into your terminal application. Providing binaries on other systems, when we are more able, will certainly be quite helpful! Cheers.

I will definitely investigate the source RPM to see whether it is altered and/or broken. That said, if it is not in a good state, it is unlikely it will be fixed. We have a zero percent success rate asking packagers not to make sweeping changes such as removing MP4 support or swapping Libav for FFmpeg, which are not ABI compatible!

All the more reason to use FlatPak! You can decide against which runtime you want to compile and completely control the compilation and packaging process. you are then the packager yourself, the one who knows best.

FlatPak then allows your users to install both the runtime that you reference as well as the package you created, on pretty much any system. This alleviates the need for external packagers.

To sum, unofficial builds on third party repositories are almost universally broken and cause a lot of support requests for us. We do our best to make compiling quick and painless, and it's the best way to ensure full functionality and stability

I'm very sorry to hear that, but compiling an application from source will always be cumbersome and error-prone by nature (no matter how much work you put into making it painless), and excludes a wide range of Users who don't have the technical abilities.

Personally, I severely dislike downloading binaries or source and installing them manually: a) it's much more complicated than getting them from my distros package manager. b) When getting it from my distribution, I can be reasonably certain that the packaging fits my system and that all dependencies are correctly installed. c) Sometimes I might even agree with the "political reasons" for removing parts of the software.

People choose distributions for a reason, and it's usually because they trust their distribution packagers. I think it's not very nice to work against them.

But hopefully, in the Future, when FlatPak or Snaps get widely accepted, these problems should go away completely.

Agreed. 馃樃

Aside, while code alterations are permitted by the license, even a fork would be better. As it stands now, packagers get zero support requests and we get all of them. Packagers are creating needless work for us, and unfortunately it takes away from our time for development and support. It's even worse when people are turned off to the project because of a bad package. There's pretty much no upside for us at this point.

It's also clear they won't stop doing what they're doing even if we published our own packages for more distros and/or Flatpak/Snap. Case in point: Ubuntu ships a broken HandBrake package. I can tell you how to segfault it. So while Flatpak will be a nice option for the less technically inclined, it's sadly not going to prevent all the other issues we have with broken distro packages. Package management is only as good as the managers.

I tried to respond this morning, but apparently I lost internet.

Perhaps an extra sentence fragment on the Docs page or git or both to mention that instructions are at the end of the Doc would help avoid the perceived confusion. I figured the development section was for developers, and didn't bother reading all the things that weren't relevant (don't have Windows or Mac or Ubuntu right now, and not planning on figuring out how to help develop any time soon).

Regarding that last comment, I feel I see your statement completely opposite:

So while Flatpak will be a nice option for the less technically inclined, it's sadly not going to prevent all the other issues we have with broken distro packages. Package management is only as good as the managers.

I agree - package management is only as good as the managers. Which is why you package yourself with your PPA, and why if you instead (or in addition, but that would become increasingly redundant) use a universal packaging system like flatpak you can do it once (the right way) and everyone can use it without the meddlesome distributors hacking and hijacking and calling the end product yours.
And as to people just going with their repo because they don't know better, if you serve it, they will come. If you provide a universal solution, on your site you can have two lines: "if you have flatpak, click this picture to be good to go. If not, click this link for instructions to install on your platform". I imagine all blogs and articles for a time after that would point this fact out, and anyone googling will come across relevant pages more often.

But that's just an end-user's perspective. I'll probably eventually use proper handbrake, but that likely won't be until at least next month. Between uninstalling openjdk, installing oracle java, reinstalling libreoffice because it was removed with openjdk, figuring out how to install ant, installing git, figuring out best practice so things go in a sensible place, that might be conservative. I'm still in the middle of trying to get everything on my server as dockerized as I can to make the OS irrelevant.

Just a status note. Flatpak support is currently blocked by a new build time requirement. x264 and x265 have switched from yasm to nasm and the flatpak gnome sdk does not include nasm.

If anyone has experience creating flatpak sdk extensions (or would like to learn), an sdk extension with nasm support would unblock me.

Just a status note. Flatpak support is currently blocked by a new build time requirement. x264 and x265 have switched from yasm to nasm and the flatpak gnome sdk does not include nasm.

How is that a blocker, just build nasm...?

heh, ok, I suppose that works. But it seems like common build tools such as assemblers belong in the sdk. Someone should eventually create a set of sdk extensions to cover all these corner cases. E.g. someone has built an sdk extension for Rust.

But it seems like common build tools such as assemblers belong in the sdk.

nasm is only required for one library on all of Flathub, x264, so lets not overstate its usage and yasm is in the sdk.

Someone should eventually create a set of sdk extensions to cover all these corner cases.

An SDK extension for NASM could be made but its a bit overkill. Rust is an entire language and tooling that is still evolving quickly, it makes sense to share maintenance of that. NASM is a relatively simple to build tool.

This all sounds super positive for the Flatpak build! Any idea when it might be released?

Sounds awesome, and waiting here also. linux container support is becoming a big thing in ChromeOS right now (Crostini/Pixelbook), and a flatpak build would do wonders for this!

FYI, I've been working on this over the last few days. It's all working to my satisfaction now. It'll take a bit more time to get our build server set up to build flatpaks, but once that's done we'll be posting them to the nightly builds.

Anyone interested in building their own flatpaks can follow the instructions here (start at "Install dependencies"):
https://handbrake.fr/docs/en/latest/developer/flatpak-repo.html

The infrastructure I put in place can also automatically generate the necessary manifest and appstream files for publishing on flathub. So when we get around to doing a 1.2 release, I hope to publish to flathub.

@jstebbins this is awesome! I built it locally to test and have a few comments.

  1. There isn't an OARS policy in the appdata (which is a flathub requirement). It takes a few seconds to add, I'll send a PR later.
  2. I needed to add --device=all on the CLI in order to detect a DVD. You should probably add that permission more generally - or is this not added because you're not shipping libdvdcss (I was testing with an unencrypted DVD). If you don't want to ship that you may wish to define an extension point which would allow a separate extension to add the functionality. (Here's some extension documentation)

I had to use a slightly convoluted way of building this because my system doesn't have dev tools (e.g. I did the generaton inside a temporary container and then used a manual flatpak-builder command outside that to actually build the app) so I may be missing something that your build system does - if so, apologies - although that way is closer to the way flathub would work.

I needed to add --device=all on the CLI in order to detect a DVD

I left out --device=all intentionally. We do not recommend encoding directly from DVD or BD because HandBrake is not a ripper (See "What HandBrake does not do" https://handbrake.fr/docs/en/latest/introduction/about.html). As you noted, we do not ship libdvdcss with HandBrake. And even when you add it yourself, there are still several types of disc protection that the studios use that HandBrake can not handle. So we have always recommended using the right tool for the right job. I.e. use a ripper to pre-rip your discs (e.g. MakeMKV or AnyDVD). Since we get a lot of nuisance support requests about unreadable discs from people who choose not to follow our advice or just don't read documentation, I think leaving out --device=all is the right way to go. Those that require that permission can add it themselves to the 'flatpak run' command line.

Regarding extensions. I have no plan to create an extension for dvdcss (or the equivalent library for BD). And a google search doesn't turn up any pre-existing extensions. Since creating the extension point requires knowing the id of the extension, this can't be done until an extension exists. If someone else created and hosted such an extension, I would consider adding support for it.

I have all the normal tools I use to build HandBrake on Fedora available. But I could probably create minimal list of the tools needed to do a flatpak build using our build system. Off the top of my head, I'm not sure what that would be above a base install + make + flatpak. I'll have to give it a go and see what breaks :grin: Ultimately, when we do a release that we want to post to flathub, I'll run something like:

make pkg.create.flathub HB_URL=https://download.handbrake.fr/releases/1.1.0/HandBrake-1.1.0-source.tar.bz2 HB_SHA256=a02e7c6f8bd8dc28eea4623663deb5971dcbca1ad59da9eb74aceb481d8c40da

This tells make where the HandBrake source tar for the release can be downloaded from and what it's sha is. This will generate the manifest flathub needs and hopefully I haven't missed anything :wink:. E.g.

{
    "app-id": "fr.handbrake.ghb", 
    "modules": [
        {
            "name": "handbrake", 
            "modules": [
                {
                    "sources": [
                        {
                            "url": "http://www.nasm.us/pub/nasm/releasebuilds/2.13.02/nasm-2.13.02.tar.xz", 
                            "sha256": "8ac3235f49a6838ff7a8d7ef7c19a4430d0deecc0c2d3e3e237b5e9f53291757", 
                            "type": "archive"
                        }
                    ], 
                    "cleanup": [
                        "*"
                    ], 
                    "name": "nasm"
                }
            ], 
            "config-opts": [
                "--flatpak", 
                "--disable-gtk-update-checks"
            ], 
            "sources": [
                {
                    "url": "https://download.handbrake.fr/releases/1.1.0/HandBrake-1.1.0-source.tar.bz2", 
                    "sha256": "a02e7c6f8bd8dc28eea4623663deb5971dcbca1ad59da9eb74aceb481d8c40da", 
                    "type": "archive", 
                    "strip-components": 1
                }, 
                {
                    "commands": [
                        "mkdir -p download"
                    ], 
                    "type": "shell"
                }, 
                {
                    "url": "https://download.handbrake.fr/handbrake/contrib/jansson-2.10.tar.bz2", 
                    "sha256": "241125a55f739cd713808c4e0089986b8c3da746da8b384952912ad659fa2f5a", 
                    "type": "file", 
                    "dest-filename": "download/jansson-2.10.tar.bz2"
                }, 
                {
                    "url": "https://download.handbrake.fr/handbrake/contrib/libbluray-1.0.2.tar.bz2", 
                    "sha256": "6d9e7c4e416f664c330d9fa5a05ad79a3fb39b95adfc3fd6910cbed503b7aeff", 
                    "type": "file", 
                    "dest-filename": "download/libbluray-1.0.2.tar.bz2"
                }, 
                {
                    "url": "https://download.handbrake.fr/handbrake/contrib/ffmpeg-4.0.tar.bz2", 
                    "sha256": "318a39d906c9107d49766c63787798dd078d2a36e6670a9dfeda3c55be4573b8", 
                    "type": "file", 
                    "dest-filename": "download/ffmpeg-4.0.tar.bz2"
                }, 
                {
                    "url": "https://download.handbrake.fr/handbrake/contrib/lame-3.100.tar.gz", 
                    "sha256": "ddfe36cab873794038ae2c1210557ad34857a4b6bdc515785d1da9e175b1da1e", 
                    "type": "file", 
                    "dest-filename": "download/lame-3.100.tar.gz"
                }, 
                {
                    "url": "https://download.handbrake.fr/handbrake/contrib/yasm-1.3.0.tar.gz", 
                    "sha256": "3dce6601b495f5b3d45b59f7d2492a340ee7e84b5beca17e48f862502bd5603f", 
                    "type": "file", 
                    "dest-filename": "download/yasm-1.3.0.tar.gz"
                }, 
                {
                    "url": "https://download.handbrake.fr/handbrake/contrib/x264-snapshot-20180525-2245.tar.bz2", 
                    "sha256": "656cb499bc6e6a120fbd1b0e5de086607023e3bfcf62a7178276cb2ec92b39c9", 
                    "type": "file", 
                    "dest-filename": "download/x264-snapshot-20180525-2245.tar.bz2"
                }, 
                {
                    "url": "https://download.handbrake.fr/contrib/x265_2.8.tar.gz", 
                    "sha256": "6e59f9afc0c2b87a46f98e33b5159d56ffb3558a49d8e3d79cb7fdc6b7aaa863", 
                    "type": "file", 
                    "dest-filename": "download/x265_2.8.tar.gz"
                }, 
                {
                    "url": "https://download.handbrake.fr/contrib/libvpx-1.7.0.tar.gz", 
                    "sha256": "1fec931eb5c94279ad219a5b6e0202358e94a93a90cfb1603578c326abfc1238", 
                    "type": "file", 
                    "dest-filename": "download/libvpx-1.7.0.tar.gz"
                }, 
                {
                    "url": "https://download.handbrake.fr/handbrake/contrib/libdvdnav-5.0.3.tar.bz2", 
                    "sha256": "5097023e3d2b36944c763f1df707ee06b19dc639b2b68fb30113a5f2cbf60b6d", 
                    "type": "file", 
                    "dest-filename": "download/libdvdnav-5.0.3.tar.bz2"
                }, 
                {
                    "url": "https://download.handbrake.fr/handbrake/contrib/libass-0.14.0.tar.gz", 
                    "sha256": "8d5a5c920b90b70a108007ffcd2289ac652c0e03fc88e6eecefa37df0f2e7fdf", 
                    "type": "file", 
                    "dest-filename": "download/libass-0.14.0.tar.gz"
                }, 
                {
                    "url": "https://download.handbrake.fr/contrib/opus-1.2.1.tar.gz", 
                    "sha256": "cfafd339ccd9c5ef8d6ab15d7e1a412c054bf4cb4ecbbbcc78c12ef2def70732", 
                    "type": "file", 
                    "dest-filename": "download/opus-1.2.1.tar.gz"
                }, 
                {
                    "url": "https://download.handbrake.fr/handbrake/contrib/freetype-2.8.1.tar.bz2", 
                    "sha256": "e5435f02e02d2b87bb8e4efdcaa14b1f78c9cf3ab1ed80f94b6382fb6acc7d78", 
                    "type": "file", 
                    "dest-filename": "download/freetype-2.8.1.tar.bz2"
                }, 
                {
                    "url": "https://download.handbrake.fr/handbrake/contrib/libdvdread-5.0.3.tar.bz2", 
                    "sha256": "321cdf2dbdc83c96572bc583cd27d8c660ddb540ff16672ecb28607d018ed82b", 
                    "type": "file", 
                    "dest-filename": "download/libdvdread-5.0.3.tar.bz2"
                }, 
                {
                    "url": "https://download.handbrake.fr/handbrake/contrib/fribidi-0.19.7.tar.gz", 
                    "sha256": "3fc96fa9473bd31dcb5500bdf1aa78b337ba13eb8c301e7c28923fea982453a8", 
                    "type": "file", 
                    "dest-filename": "download/fribidi-0.19.7.tar.gz"
                }, 
                {
                    "url": "https://download.handbrake.fr/handbrake/contrib/harfbuzz-1.7.2.tar.bz2", 
                    "sha256": "a790585e35c1a87f0dcc23580c84b7cc2324e6f67a2946178d278c2a36c790cb", 
                    "type": "file", 
                    "dest-filename": "download/harfbuzz-1.7.2.tar.bz2"
                }
            ], 
            "no-autogen": true, 
            "builddir": true
        }
    ], 
    "finish-args": [
        "--share=ipc", 
        "--socket=x11", 
        "--socket=wayland", 
        "--filesystem=xdg-run/dconf", 
        "--filesystem=~/.config/dconf:ro", 
        "--talk-name=ca.desrt.dconf", 
        "--env=DCONF_USER_CONFIG_DIR=.config/dconf", 
        "--filesystem=xdg-videos", 
        "--filesystem=home"
    ], 
    "command": "ghb", 
    "runtime-version": "3.28", 
    "runtime": "org.gnome.Platform", 
    "sdk": "org.gnome.Sdk"
}

While I don't disagree that encoding from SSD/HDD instead of disc is preferable, I'm not feeling as comfortable with the idea of shipping a HandBrake version with differing functionality of this kind. Missing the ability to access discs entirely can also mean modern formats (MP4, MKV, etc.) stored on optical media. I hope this exclusion does not also apply to other external storage devices such as flash drives.

@jstebbins Yes, that example manifest would work perfectly (the one I did earlier just had the dependencies on the local filesystem which wouldn't work) aside from reading 'upside down' compared to most other manifests there's nothing actually wrong with it ;-)

And yes, I was assuming a future libdvdcss extension that doesn't exist. If such a thing is created I'm sure that those parties would open an issue here to let you know :wink:

@bradleysepos 'assuming the right sort of filechooser is being used' (in GTK that's a GTKFileChooserNative) then you can manually pick any file into a flatpak using the portals (and save out as well). But I haven't looked more closely at the way HandBrake works there.

@bradleysepos the permissions can be added to the 'flatpak run' command line. So anyone that doesn't like our default permissions can override them.

@bradleysepos and @nedrichards I had assumed that the gtk filechooser would provide access to removable media filesystems that get mounted under /run/media/$(USER) via the flatpak portals as nedrichards mentions. But I just had a look and it is not working. If I add --filesystem=/run/media to the command line (or manifest) then they can be accessed. Seems like that ought to just work though without adding additional permissions like that.

@nedrichards, any idea why the portal doesn't just make that happen in GTK?

I... don't. That sounds like an issue for https://github.com/flatpak/xdg-desktop-portal/issues (which is the common part underlying the GTK implementation)

I think I found it. You have to use a GtkFileChooserNative in order to get to the portal. GtkFileChooserNative is substantially less flexible than the standard GtkFileChooserDialog (e.g. you can't add extra widgets to it). So to use it I would have to substantially rework source selection. I'll add it to my todo list, but I think for now the solution is going to have to be adding --filesystem=host to the manifest.

Sure, makes sense.

Nightly build flatpak bundles are now available
https://forum.handbrake.fr/viewtopic.php?f=33&t=37882

Hey there, I just wanted to drop by and say thank you for packaging HandBrake as a FlatPak! It's super convenient to install, and works really well for me.
Thanks!

I would also like to say thanks for the Flatpak builds on Flathub, it is really great to get the latest official builds so quickly and working so well, awesome!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

miopad picture miopad  路  6Comments

AlexPasternak picture AlexPasternak  路  5Comments

taxen picture taxen  路  3Comments

a7dfj8aerj picture a7dfj8aerj  路  3Comments

AnotherDimension-Ex picture AnotherDimension-Ex  路  4Comments