search

popcornmix / omxplayer

omxplayer
GNU General Public License v2.0
1.02k stars 333 forks source link

OMXPlayer and Raspbian Bullseye - running and compiling #810

Open msedv opened 2 years ago

msedv commented 2 years ago

We have several Pi4 displaying 6-12 RTSP streams from Dahua surveillance cameras. Switching to VLC isn't really a practical solution. Regarding Raspbian Bullseye I made the following observations:

Running:

  1. fresh install of bullseye: no install candidate
  2. fresh install of buster, install omxplayer, dist-upgrade to bullseye: runs like a charm

Compiling: no matter if using method 1 or 2 I'm not able to make omxplayer as soon as on bullseye (make ffmpeg runs fine); I always get a lot of linking errors:

/usr/bin/ld: linux/OMXAlsa.o: in function omxalsasink_worker(void*)': omxplayer/linux/OMXAlsa.cpp:1043: undefined reference tosnd_pcm_open'
/usr/bin/ld: omxplayer/linux/OMXAlsa.cpp:1052: undefined reference to `snd_pcm_hw_params_sizeof'
...

/usr/bin/ld: linux/RBP.o: in function DllBcmHost::bcm_host_init()': /webs/omxplayer/./DllBCM.h:84: undefined reference tobcm_host_init'
...

and so on; full output attached. /opt/vc ist still here. Which libraries are missing? I don't have a clue. :-(

Even if omxplayer isn't maintained and not included in raspbian from bullseye on it would be very helpful if it would be possible to compile a running version by ourself.

omxplayer_compile_output.txt

popcornmix commented 2 years ago

omxplayer binary is still available in bullseye repo, but the openmax libs are not. You can get the libs needed from https://github.com/raspberrypi/firmware/tree/master/opt/vc You also need to not use the kms driver (either comment out or replace with fkms the line dtoverlay=vc4-kms-v3d).

But, be aware this is unsupported and no promises it will continue to work in the future.

nagualcode commented 2 years ago

I believe the community should keep omxplayer alive, VLC will never be a replacement. Specially for the millions of raspberry pi 1, 2 and 3 users out there.

According to vlc contribuitor: The next version of VLC (real soon now) should get you h/w accel where it is supported in most circumstances on 64 and 32 bit. The pathways are always going to be less efficient than those set up by OMXplayer and there are limitations imposed by Linux that mean that some functionality is, at best, hard to achieve so it isn't going to be able to do exactly what OMXplayer did.

popcornmix commented 2 years ago

@nagualcode feel free to fork this repo and provide updates.

But the main issue is the interfaces that omxplayer uses (e.g. openmax) and not available by default on the latest RPiOS (where we have switched to the arm side kms driver for display), so omxplayer won't run by default.

Currently it is possible to run omxplayer on bullseye after disabling the kms driver and installing the openmax libraries, but that may stop applications that target kms from running, so is not something that most users would want to do.

Plainbroke commented 2 years ago

@popcornmix Ok I understand what you are saying, but is there a way for those of us that still want and need omxplayer to install and all its dependencies without breaking bullseye, or without going back to buster and reloading everything??? In my case MagicMirror and approximately 35 modules that rotate using mmm-carousel. 5 of them are differant cameras that use rstp and VLC does not display them correctly at all. Also very bad lag on a pi4 with 8gb ram. using a ssd drive, speed should not be the issue, for the lag.

Jeff

popcornmix commented 2 years ago

Yes, you can run omxplayer under bullseye using fkms driver. You just need to be aware that there be features that are only supported with kms (e.g HDR or HD audio passthrough). And fkms is deprecated so is unlikely to get bug fixes or new features.

Plainbroke commented 2 years ago

I went back to buster and the fkms and everything works as I Want it to now.. I am curious though can I now update to buster and still keep the RTSPStream running on OMXplayer? I read somewhere that it is possible and everything will work the same. I appreciate your quick response. I do not use audio on my Mirror so that is not an issue. I do not understand the depreciated statement. Why are the OS updates not backwards compatible? Seems like it would save a LOT of time fixing problems.. Just my opinion.

Jeff Burdick

From: popcornmix Sent: Saturday, July 30, 2022 12:53 PM To: popcornmix/omxplayer Cc: Jeff; Comment Subject: Re: [popcornmix/omxplayer] OMXPlayer and Raspbian Bullseye - runningand compiling (Issue #810)

Yes, you can run omxplayer under bullseye using fkms driver. You just need to be aware that there be features that are only supported with kms (e.g HDR or HD audio passthrough). And fkms is deprecated so is unlikely to get bug fixes or new features. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

popcornmix commented 2 years ago

I do not understand the depreciated statement. Why are the OS updates not backwards compatible?

kms means all of the code to drive the display is handled on the arm in the kernel fkms means all of the code to drive the display is handled on the gpu in the firmware

The switch to arm side means all the code is open source, and we are using standard linux apis for displays (so you can write code that decodes video and displays it efficiently and the same source code will run on RPiOS on a Pi or Ubuntu on an x86 PC.

This change has many benefits (e.g. new features like HDR and HD audio passthrough are now supported). But it means omxplayer which is explicitly coded to use firmware driver for decode and display cannot possibly work using kms. You can't have both the arm and gpu writing to display hardware registers.

Plainbroke commented 2 years ago

Thanks for the explanation. Makes sense now.

On Mon, Aug 1, 2022, 5:49 AM popcornmix @.***> wrote:

I do not understand the depreciated statement. Why are the OS updates not backwards compatible?

kms means all of the code to drive the display is handled on the arm in the kernel fkms means all of the code to drive the display is handled on the gpu in the firmware

The switch to arm side means all the code is open source, and we are using standard linux apis for displays (so you can write code that decodes video and displays it efficiently and the same source code will run on RPiOS on a Pi or Ubuntu on an x86 PC.

This change has many benefits (e.g. new features like HDR and HD audio passthrough are now supported). But it means omxplayer which is explicitly coded to use firmware driver for decode and display cannot possibly work using kms. You can't have both the arm and gpu writing to display hardware registers.

— Reply to this email directly, view it on GitHub https://github.com/popcornmix/omxplayer/issues/810#issuecomment-1201035260, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMPPR7ONVY4ADOBZ4DJL3STVW6TSBANCNFSM5I5NXCOQ . You are receiving this because you commented.Message ID: @.***>