RPi-Distro / vlc

GNU General Public License v2.0
41 stars 4 forks source link

libpolkit or rpi-eeprom update broke video rendering #57

Closed barjonas closed 2 years ago

barjonas commented 2 years ago

Several months ago I set up a system which showed two RTSP feeds from local IP cameras on at TV plugged into a PI 4. Essentially the script consists of:

screen -d -m cvlc -vv --crop=720x720+70+0 --mmal-vout-window 570x720+0+0 --no-audio --mmal-layer 30 'rtsp://lanipaddress:554/Streaming/Channels/102'
screen -d -m cvlc -vv --mmal-vout-window 1280x720+640+0 --no-audio --mmal-layer 40 --mmal-vout-transparent 'rtsp://username:password@lanipaddress:554/cam/realmonitor?channel=1&subtype=0'

This worked great for several months. One day I had to shutdown the machine to change a fan. I probably did a apt get update/upgrade/install at the same time. It has not worked from that day, even after trying everything I can thing of:

  1. Downgrading firmware to the version mentioned in #48.
  2. Simplifying the command line, step by step.
  3. Trying the command directly on the machine (no SSH/screen).

I don't know how to check whether the VLC package version updated, or how to manually revert for testing.

The verbose log (attached) output appears to say everything is working fine, although I don't have a "before" log to compare to. When I run the full script (which uses 2x screen instances), I see the output video dip to back for a couple of seconds before going back to the console output.

Hardware and software version info:

Hardware        : BCM2711
Revision        : b03114
Model           : Raspberry Pi 4 Model B Rev 1.4
Package: vlc
Version: 3.0.12-0+deb10u1+rpt3
$vcgencmd version
Feb  4 2022 12:05:40
Copyright (c) 2012 Broadcom
version a26faf97e3bf76bcc23949d7cdab2f96f399a0c3 (clean) (release) (start)
$ uname -a
Linux redacted 5.15.18-v7l+ #1520 SMP Fri Feb 4 12:01:36 GMT 2022 armv7l GNU/Linux
XECDesign commented 2 years ago

You can check /var/log/apt/history.log to see which packages have been updated. VLC on Buster hasn't been touched for a while. If you could check which packages were updated just before it broke, maybe that would be helpful.

I don't know much about rtsp or all the mmal options, so if you have simple instructions to reproduce the issue, that would also help.

barjonas commented 2 years ago

Thanks for the prompt. I ended up looking in /var/log/dpkg.log, which confirmed that nothing has changed with the VLC installation since 2021-12-08.

It looks like the offending update must have come on 2022-01-31. Here's a list of packages which updated on that day:

upgrade policykit-1:armhf 0.105-25+rpt1 0.105-25+rpt1+deb10u1
upgrade libpolkit-agent-1-0:armhf 0.105-25+rpt1 0.105-25+rpt1+deb10u1
upgrade libpolkit-backend-1-0:armhf 0.105-25+rpt1 0.105-25+rpt1+deb10u1
upgrade libpolkit-gobject-1-0:armhf 0.105-25+rpt1 0.105-25+rpt1+deb10u1
upgrade rpi-eeprom:armhf 13.3-1~buster 13.5-1~buster

I'm happy to hear any suggestions for what I should downgrade and how. I've read too many different instructions about manually changing EEPROM image versions to feel 100% sure that I've done it correctly.

In an attempt to make this more reproducible, I tried the same machine with a local mp4 file. Here are the commands:

wget -O BBB.mp4 https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/720/Big_Buck_Bunny_720_10s_5MB.mp4
vlc -vv BBB.mp4 &> bbb.log

Here's the log. I can confirm that no video ever appeared on the screen. I'll try to rename this issue since it now appears that it's neither a regression nor specific to RTSP.

XECDesign commented 2 years ago

Neither of those packages really has the ability to break vlc.

AFAIK, that eeprom update doesn't actually automatically flash anything to the eeprom by default (right @timg236?).

The policykit update was a fix for CVE-2021-4034, and isn't involved in any way.

I've just flashed the latest legacy image and it's able to play BBB without any issues, so I haven't been able to reproduce it.

timg236 commented 2 years ago

2021-12-08.

No, I can't see any connection, but it's easy enough to bisect through the EEPROM releases in under /lib/firmware if you really suspect that's issue. I think that that is exceptionally unlikely because the bootloader is replaced in memory when start.elf runs and has absolutely no code related to video decode.