Hello all, I’m new here so, you’ll forgive me if I breach any forum etiquette. I could not find a “category” for this that seemed appropriate. I trust a mod will move this to the right spot if this is not it.
When I heard that the Raspberry Pi 3 could run Ubuntu MATE, I no longer had a reason to delay in buying one. Ubuntu MATE has been my primary OS for awhile now. My first experience with linux was Ubuntu 9.10 and so I feel right at home with Ubuntu MATE. It did not take me long to realize that video playback on the Raspberry Pi was a little non-standard. There is only one video application that can take advantage of the RPi’s hardware acceleration and it’s a terminal application.
I am attempting to create a wrapper for omxplayer that behaves more like a standardized video player such as vlc. I know this has been attempted before but I believe I have been able to surpass previous attempts.
@Wimpy has requested that I create this thread and has expressed an interest in including tomxplayer in Ubuntu MATE for the Raspberry Pi. I hope that happens.
Seems great !
I can’t wait to try it !
Just for the record it is possible to read videos in window mode / full screen with a real video player but it need to use the (buggy) fkms display driver which give opengl support and access to hardware video decoding. I did it with MPV and smplayer frontend for MPV using h264_mmal decoding and opengl video output
You have definitely surpassed previous efforts, Tomxplayer is looking fantastic. What language is tomxplayer written in? Are you planning on put the source up on something like GitHub?
I can think of a couple of solutions for prevent the screen lock, such as poking the lock inhibit API. But without seeing code I’m not sure what might be possible.
Great project, would love to see this in Ubuntu MATE
tomxplayer is written in C# in MonoDevelop. I wrote you a private message? Did you get it?
Edit: @Wimpy, I'll assume you did not receive my private message due to filtering or something. So here is a copy.
There is only one reason I don’t feel good about the name tomxplayer, and that’s because there’s another media player which exists named Tomahawk. We should try to prevent “Brand confusion” wherever we can.
I’m going to add some negativity here. I don’t agree with adding this to UM at all.
Presumably you are going to fund the inclusion of this through UM donations? I’m not going to repeat unpleasant arguments about the monetisation of the UM project, but surely the way to make money out of tomxplayer is to add it to something like the app store?
UM should be made up of a small number of programs that are common across all architectures. Not the bloated monster it is becoming. Omxplayer is not the future. Vc4 is the future of raspberry pi. If UM is to fund anything on the pi, it should be to encourage the adoption of the latest technologies that puts it on a par with how other architectures work. So things like using grub2 as the bootloader and standard Ubuntu kernels.
I was unaware of Tomahawk and is tomx somehow short for tomahawk? In my admittedly short google search I could find no instance in which Tomahawk was referred to as “tomx” or “tomxplayer”. Anyways, I’m not particularly fond of the name “tomxplayer”. It was a logical name which came out of a naming convention I adopted in my framework. If anyone has any ideas, I’m game.
It’s the first three letters. I know it sounds dumb af but people might legitimately think tomx is a fork of tomahawk because they can’t drop the T from your name and realize it’s a wrapper for omx.
As for alternatives? Since most things in the MATE space use Spanish names, I was about to suggest peyote but there’s a terminal-based player named that in Sourceforge. Damn.
Recently, I discovered the RPI examples in /opt/vc/src/hello_pi. One in particular that caught my eye was the “hello_font” example which painted text on the screen in a “subtitle” sort of fashion. At first, I could not get it to build but then I discovered that if I add -lGLESv2 to the LDFLAGS in /opt/vc/src/hello_pi/Makefile.include …
I imagine these were originally for Raspbian because not all of them build. Most of them do but not all.
I’ve been meaning to experiment with Mono’s native C lib interoperability and I thought that I could reshape this example to provide OSD functionality for tomxplayer. After a couple of days of tinkering, tomxplayer now has OSD functionality and I have learned quite a bit about how to interop with C native libraries in C#/MonoDevelop.
tomxplayer will:
Show the filename, over the video, when the video begins to play.
Show, over the video, “VOL +”, “VOL -”, “Paused” etc when these actions occur.
Show, over the video, playback position during ff/rewind and slider positioning.
Currently, it is possible for the osd text to go outside the window bounds given the window size and length of displayed text. So, some calculation for sizes are still needed. Something to work on.
Also, currently the osd text is displayed in a static position relative to the render window (bottom left corner) instead of being bottom centered.
@Wimpy, Thanks for the tip about the InhibitAPI. I decided to wrap execution using mate-session-inhibit and alternatively systemd-inhibit (if mate-session-inhibit is not available). This will prevent “idle:sleep:switch-user:logout” while tomxplayer is running. Technically, the inhibition should be lifted if the video is paused but this will suffice until I discover how to get notified of system events like “logout” so I can get rid of the video window.
Hi, I am not a developer. I am a regular ordinary opinionated RPI3 owner running UM 16.01 + patch after patch after patch after patch. its a good thing they make patches and updates. The platform has become much better and usable over the last 1+ years.
Video playback has not been tackled by OMX! It is the most unstable and unfriendly software I have encountered while it can play things that others can not. The RPI3 has 1 GB of Memory. With UM desktop running it planes out at about 20- 25% memory utilization. With FF or chromium on top it goes to 80% + open sessions and a YT video (failed to play). When you go to load the video via OMX, it takes over the desktop and you are going to hit the wall and lockup. I hate OMX! Even if I copy the video URL. Close every other application and run the desktop lean and mean, and then launch OMX manually from the prompt with 15 uncommon parameters, OMX will not run sane. The sd card will only stand up to just so many crashes before it is corrupted beyond repair.
I am not apposed to pay for software but it has got to work properly on the platform. I am not interested in a pretty interface that launches the same old problems. I know you have bunches of time into it but unless you can tame that beast like no other has been able to…
Sorry, did not mean to write a book about it. An angry book!
I tried, but it would not play properly in my browser on RPI3 +FF. The video came through crisp and clear but the audio was like loud static broadcast TV when the rabbit ears where out of alignment. 30-40% of YT videos produce the same result. Half of those will not play under VLC or OMX.
When I saw your message this morning, I clipped the link and dropped it into the OMX Gui . It played but with all the horrors of OMX. If I touch anything, I could be locked out of the screen.
I gather that the reason you kept adjusting and re-positioning the movie was to stress it (great idea). Looks to be very stable. It seemed to react and tolerate far more then OMX would normally.
️