-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trying to make RPi FFmpeg work on Ubuntu - has it been tried? #45
Comments
Actually re-opening...did anyone make this work on Ubuntu-Rpi4b? |
Are you asking if my tree compiles on rpi ubuntu (The 'this' in the issue title is somewhat ambiguous)? I haven't tried. If you can characterise what fails I'll have a quick look. |
HI can change the title when I know more what I'm asking! :) My Setup: Actually after thinking a bit clearer this morning it seems like I'm either missing or the configure script is not finding EGL. It builds fine using this config line, But the out devices are missing your egl one,
I did installed these, Ubuntu comes with, And the raw ffmpeg seems to work as this runs ok: but this does not, since I have an EGL problem: Probably this does not actually have to do with ffmpeg as such it feels more like I've got something missning somewhere. EDIT: I just did
I'm reading in the 'configure' script that,
Maybe Ubuntu Rpi is now also using Wayland as a default and that uses different files for its egl which are not identified by 'configure' ? EDIT2: Sorry scratch that I can also find these,
I'm going to try this now, So I guess maybe the question is, why is 'configure' not finding EGL? |
I'd go though the headers included in libavdevice/egl_vout.c and see what is missing on your system. If none are missing then I've got a config problem. If I had to guess a missing package I'd look at libepoxy-dev (I'm guessing the name) as that's not a default package for most things. (Used by me 'cos it was used by the original author of the code I copied.) |
I looked in egl_vout.c and compared the includes to the ones in the enabled drm_vout.c and the suspect differences were,
so I ran apt on libepoxy-dev but that was already installed and latest version. One other actually was libx11-dev was also already installed as I mentioned earlier. Soo...not sure? |
vout_egl requires xlib & epoxy in configure, xlib appears to require Xvlib.h which is in libxv-dev. Maybe my dependency was a little wide but as I've never had to add that manually myself I didn't notice. If that doesn't help, zip up and send me ffbuild/config.log from whatever your build dir is. |
Thanks for the tip I think I used something like apt-file a while ago but then forgot about it again. Xvlib.h was found here, |
Add --enable-epoxy to your config. It is arguably a bug you need it (and I'll have a go at fixing it) as it should be a dependency not something you have to have set but I think that will fix your problem. Tip: when your custom config fails have a look at what I'm using in pi-util/conf_native.sh as that is what I use to configure stuff. ffmpeg configure is something I'm still confused by. |
I've pushed a new configure script to dev/4.4/rpi_import_1 which shouldn't need the enable-epoxy or enable-libudev flags and should complain if it is missing something it needs for vout_egl. |
Nice one thanks I'll try these steps out tonight! I think it makes sense to fix in the config like you said although for me I was going to write an install script for 'my' users to make it super easy. I'll let you know how it works out with --enable-epoxy or your new config. |
Btw is the dev/4.4/rpi_import_1 your new main branch to use for your rpi-ffmpeg? |
dev/4.4 is used by Kodi and generally maintained in sync with test/4.3.2/rpi_main which is the Pi (debian) distribution. In this case I've just pushed to 4.4 so I can get your feedback before I commit the changes to the other branch. |
Alright that got us a step further so that's great!
both returned empty but I'd have to check on my RaspiOS Bullseye to see if I should expect any of those. I might have to let this simmer a bit and taking a look at libnraries attached on the RaspberryOS version and see if I can find some differences. I my program at least it returns that setting up av codec context was successful. No errors from the below.
FULL ERROR from the run. built with gcc 11 (Ubuntu 11.2.0-7ubuntu2) |
What was your command line? I see no evidence of accelerated decode there and the vout_egl/drm devices are very stupid such that they only accept DRM_PRIME frames (and the error says they aren't getting that). |
I successfully built dev/4.4/rpi_import_1 on the rpi ubuntu 22.04 (jammy) after installing libxv-dev libglfw3-dev libgles2-mesa-dev libdrm-dev libudev-dev . Although, libx11-dev was already installed pkg-config complained about no xlib until I installed the libxv-dev like you mentioned above. For configuring I did The problem I have now is finding a command line that works to confirm that the hardware accelerated decode is working. but that errors with
analogous error if I change that to Not super familiar with ffmpeg or what the the various vout_* arguments mean but perhaps this could be something to do with the fact that Ubuntu is running gnome 3 on wayland? If you're testing on raspian I think they haven't moved to wayland yet. Took a shot in the dark (removed -f vout and changed /dev/null to a mp4 output file) and didn't get too far, but it does appear the h264_v4l2m2m code is starting up before it fails:
so I added -v trace to see if that might help (apologies for the large output, I truncated all the stuff prior to the [h264_v4l2m2m] point:
|
I'll take a look at this again on Sat evening as I'm tied up until then. @doesnotexist |
I built it on the raspberry pi 4 running ubuntu jammy, I probably shouldn't have done -j4 but I was just copy/pasting what was in the pi-utils/BUILD.txt @Fredrum Thanks for catching that missing -f, that was it! So it appears to work now with this: Using vout_egl, displaying the decoded images still requires quite a bit of CPU from what I can tell. All 4 cores go to 100%. This doesn't seem to be the case if I do it with vout_drm from a regular (no X) terminal / tty. So I think that confirms it works at least the h264 part. Haven't tried the stateless hevc decoding that is more specific to this fork. |
@jc-kynesim |
Sorry for the multiple posts. Maybe try adding |
@Fredrum |
|
Now I'm trying with, It's not complaining about a DRM Frame anymore but instead I get this,
I run with -v trace and you can see the full output here, This opens a window with the video playing but is of course not the wanted pipeline, EDIT: EDIT2: |
Well the unexpected timeout thing is almost certainly 'cos the V4L2 stateful driver in the Ubuntu kernel (that is what you are using isn't it?) is somewhat behind the PiOS one. There was a bug in our driver some time ago where it didn't deal with the startup sequence correctly, and I'm pretty sure that what you are seeing here is that. |
Ok yes I was starting to think that maybe there might be some kernel differences. |
I could make educated guesses but you are probably better off asking. I don't know how Ubuntu & Pi deal with patches. |
Hi I just overnight updated my SD card from Raspi Ubuntu 21.04->22.04 and now this command worked! I haven't had time to test the kmsdrm or hevc commands yet as I had to rush but this seems promising! |
Testing more now on my lunch hour! :) h264 -> egl on Desktop worked good. With -v trace I noticed it saying it couldn't open 'dmabufs'. It also reported hevc successfully decoding two frames. So I tried to run the command with 'sudo' and then it worked! hevc jellyfish played on the tty. Anyone's got an idea why that would be different? EDIT: There was errors opening these
EDIT2: Is this one of those things where devices need to be part of certain groups?
The second one is missing my name on the 'user:'. EDIT3:
Somewhat unfortunate that is needed but I don't know how to get that fixed/changed. UPDATE: When I re-did the process with a newly flashed Raspberry Ubuntu 22.04 SD card (as opposed to upgrade Ubuntu in place) I did not have the permissions problems. |
linux,cma is the device that I use for getting dmabufs (I don't know if system needs better perms). It is possible that under unbuntu it has different default perms to PiOS where it has group video rw. |
Maybe what you actually need is "sudo adduser fred video"? |
Thanks! I will try that method instead on my next run! |
Nevermind! User error again! :)
The text was updated successfully, but these errors were encountered: