Open gunetw opened 5 years ago
popcornmix
commented
5 years ago Note: the VLC In raspberry pi repo does include hardware video decode, so may be worth a try. https://www.raspberrypi.org/blog/raspbian-update-november-2018/
If you are able to record a sample as a file (which shows the problem) we may be able to investigate further with omxplayer.
gunetw
commented
5 years ago Thank you for the hint. Will look at the new version later. I was not aware of it. I recorded a 5 second clip and apped it here. Have fun. failed.tar.gz
popcornmix
commented
5 years ago I tried the sample and it played with omxplayer. Does this file fail for you?
gunetw
commented
5 years ago Seems that I must be missing something entirely. The sample does indeed fail for me, with this log: failed.txt Versions: I don't seem to be getting a new version of Raspbian when I do dist-upgrade, only a few packages get updated. Here is all my version information:
What am I missing?
pi@raspberrypi:~ $ sudo apt-get install vlc Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig vlc ist schon die neueste Version (3.0.3-1-0+deb9u1+rpt1). 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
pi@raspberrypi:~ $ omxplayer -v omxplayer - Commandline multimedia player for the Raspberry Pi Build date: Mon, 05 Nov 2018 15:45:07 +0000 Version : 061425a [master] Repository: https://github.com/popcornmix/omxplayer.git
pi@raspberrypi:~ $ cat /etc/debian_version 9.6 pi@raspberrypi:~ $
popcornmix
commented
5 years ago What is output of:
vcgencmd codec_enabled MPG2
vcgencmd get_mem gpu
vcgencmd versionAre you implying I need to purchase a license? That would mean that ARD/ZDF and the like are using another coding method that Raspi runs on HW for free, and RTL etc. are using something I need to purchase the license for? I am surprised. ARD is an HD stream and runs fine, RTL is only SD quality and doesn't. Don't get me wrong, I am OK buying the license if that is what it takes, but is that really my issue?
pi@raspberrypi:~ $ vcgencmd codec_enabled MPG2
MPG2=disabled
pi@raspberrypi:~ $ vcgencmd get_mem gpu
gpu=64M
pi@raspberrypi:~ $ vcgencmd version
Nov 4 2018 16:31:07
Copyright (c) 2012 Broadcom
version ed5baf9520a3c4ca82ba38594b898f0c0446da66 (clean) (release)
pi@raspberrypi:~ $ The video file is MPEG-2 (as is most broadcast SD video). You need a codec licence to play hardware decoded MPEG-2 (or VC-1). omxplayer only supports hardware decoded video playback (other players like kodi or vlc support software decode)
Broadcast HD video is usually H.264 - the cost of that licence is included with the price of the Pi - but MPEG-2 is both less common and more expensive so we leave that as an optional purchase.
gunetw
commented
5 years ago Thanks a million, after applying the MPEG-2 license it sure enough worked. The aforementioned VLC however, is still giving me trouble. Not sure if it uses HW support, but I guess so. At least it offers "MMAL X11 splitter for Raspberry PI" as an output option. However, as soon as I fire up a video, my HDMI attached screen goes dark, but VLC is running somewhere. (I can see it when connected via a VNC session, I can kill it with Ctrl-Q and my monitor lights up again.) My research on the web did not show anyone matching that problem. Could be a small glitch on my behalf, but I can't spot it. For completeness I should state that the monitor is a DVI-I, connected via HDMI-to-DVI adapter. Audio goes to a set of small speakers, connected to the PI's analog jack. Here is what I am getting from VLC, and from omxplayer for comparison, using the same stream.
pi@raspberrypi:~ $ vlc http://192.168.x.y:49402/pipe/0-0-1-4
VLC media player 3.0.3 Vetinari (revision 3.0.3-1-0-gc2bb759264)
[007a22f8] vlcpulse audio output error: PulseAudio server connection failure: Connection refused
[00742938] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
libEGL warning: DRI2: failed to authenticate
[007f3500] main decoder error: buffer deadlock prevented
QObject::~QObject: Timers cannot be stopped from another thread
pi@raspberrypi:~ $ omxplayer http://192.168.x.y:49402/pipe/0-0-1-4
Video codec omx-mpeg2 width 720 height 576 profile 4 fps 25.000000
Audio codec mp2 channels 2 samplerate 48000 bitspersample 16
Subtitle count: 2, state: off, index: 1, delay: 0
V:PortSettingsChanged: 720x576@25.00 interlace:3 deinterlace:1 anaglyph:0 par:1.42 display:0 layer:0 alpha:255 aspectMode:0
Stopped at: 00:00:22
have a nice day ;)Just tried vlc and it played the sample fine for me. Does the sample you provided work? What is gpu_mem set to?
gunetw
commented
5 years ago I can play the sample (and other files/streams) from RTL as I suspected. I can see that from a VNC session. But I cannot DISPLAY those (and nothing else, for that matter) on my HDMI attached monitor. So VLC does its thing somehow, but the monitor does not get any signal and enters sleep mode. Once the video has finished, my monitor comes back up again. Unfortunately, that way I cannot even tell whether HW acceleration catches on with VLC. gpu_mem was not coded in config.txt, so it defaulted to 64 M. I changed it to 256 M - same behavior. I also refreshed my firmware, because the DRI2 error message seemed to indicate that as a solution - but it wasn't. Before you ask: I also refreshed the symlinks for libEGL and libGLESv2 as described in https://raspberrypi.stackexchange.com/questions/61078/qt-applications-dont-work-due-to-libegl I am out of my wits now. BTW, omxplayer still works like a charm after all these changes. That is some consolation, but given that I am dealing with UPnP sources here, VLC would be a much more user friendly option, especially for spouse approval.
gunetw
commented
5 years ago OK, I have now evidence now for what I had presumed in my previous post. I brought the Raspi back to my TV, and sure enough VLC played the sample perfectly. The messages on the console were the same as before, so they don‘t represent an error as such. It must be to do with the way I am connecting my old DVI monitor with an adapter. Apparently VLC is more picky about that than omxplayer. And I can‘t figure out how to force it to just use HDMI and ignore the different circumstances. Too many options, too little experience on my behalf.
popcornmix
commented
5 years ago I've not really understood how the Pi's are connected to displays in working and not-working cases.
VNC is going to cause problems so I wouldn't expect that to work.
Are you saying one directly connected HDMI display works with both omxplayer and VLC, and a different DVI connected display works with omxplayer but not VLC?
What resolution is each display using (run tvservice -s).
gunetw
commented
5 years ago I guess resolution is key here. When I first moved the PI from the TV (full HD) to the HP monitor (1280x1024) I had to enforce the lower res in config.txt. Apparently omxplayer uses that setting, and VLC seems to ignore it. I was unable to identify a VLC setting to that same effect. Ignore the VNC case, that was just to prove that VLC plays the video at all, not an actual use case.
popcornmix
commented
5 years ago omxplayer directly displays the YUV video frames using the hardware video scaler. VLC works in a desktop window, and needs to resize, convert to RGB, composite with VLC overlays and write to framebuffer (where it finally gets read by hardware video scaler).
So VLC will always be less efficient that omxplayer. I believe VLC will be better when running full screen (especially if VLC Is not displaying overlays). VLC will also be better when window resolution is lower (fewer pixels to process).
This is my setup: My Metz TV set, connected to Unitymedia DVB-C network (Baden-Wuerttemberg, Germany) is acting as a UPnP server, serving both live streams and recorded programs. On my Raspi, attached to the same LAN, I use VLC to detect the UPnP resources (for want of a more elegant method). VLC would be able to play all found resources, if it were not for the well-known performance issues. Therefore I copy&paste the stream URL into a console, thus invoking it with omxplayer. Results are mixed: Streams (and recordings) from public chains (ARD, ZDF, Arte, ...) will play perfectly well, on the other hand, streams by commercial stations (RTL, SAT1, Pro7, ...) fail. In the failing case I am getting this message a few times:
Invalid frame dimensions 0x0.This apparently leads to the stream not being recognized properly (duration and bitrate being displayed are obviously nonsense), omxplayer then stops immediately. I tried playing with 'analyzeduration' and 'probesize' as suggested, but to no avail. There must be something in those streams differing from the 'good ones', that leads omxplayer astray. VLC and the TV itself prove that the streams are not corrupted alltogether.ARD Das Erste - this one worked:
RTL Television - this one failed: