Comercial support token: 6R7X549H-202481111018:8517f9148012534acf6ae04e29b2b28cd5325a8e4a6cd5177b90073e7fc10268
Desktop (please complete the following information):
- OS: Ubuntu Linux 22.04
- Runtime: Matlab R2022b
- Hardware: Radeon RX 6900 XT
- Version: Psychtoolbox 3.0.19
Describe the bug
I am trying to run the VideoRecordingDemo script on a Linux PC but every codec I’ve tried produces an unplayable video. I have tried to run this script with both a USB MR safe camera (MRC systems 12M camera [MRC Systems - MRI compatible video cameras]) and a Logitech webcam. Both cameras can provide a video feed and record videos with no issue using VLC. However with the VideoRecordingDemo script, regardless of the camera used, when I run the script without specifying a codec (i.e. using the Linux system default), the script quits out immediately without displaying a camera feed or saving a video. When I run the script while specifying one of the “good” codecs (i.e. avenc_mpeg4, x264enc, VideoCodec=x264enc speed-preset=1, Keyframe=60 Videobitrate=8192), I get a video feed and a video is saved. However when I try to play back the video I recorded, I get the error message “The playback of the movie requires a ITU H.264 (High 4:2:2 Profile) recorder plugin which is not installed”. Linux then directs me to download GStreamer which I already have downloaded on the system and have already tried updating and reinstalling multiple times as a trouble-shooting measure.
Additional context
I have also tried running this script on two difference Linux PC’s running Ubuntu 20.04 as well as a Linux laptop also running Ubuntu 20.04 and run into the same errors listed above regardless. I also get the same exact issues regardless of using the MRC systems camera or the Logitech camera and both camera’s can successfully record playable video through VLC.
Hm. If I call…
VideoRecordingDemo ('testmovie', 'VideoCodec=x264enc speed-preset=1, Keyframe=60 Videobitrate=8192')
… I get a valid movie that plays back fine on Ubuntu 20.04-LTS.
What happens if you leave the encoding parameters, especially speed-preset which can affect decoding compatibility, out? E.g.,
VideoRecordingDemo ('testmovie', 'VideoCodec=x264enc') or simply VideoRecordingDemo ('testmovie', 'x264enc')
Are the libav GStreamer plugins installed? They are generally needed for playback of H264 encoded movies and other modern movie formats. If not, in a terminal type:
sudo apt install gstreamer1.0-libav
Does our SimpleMovieDemo play the H264 demo movie? If the libav plugins would be missing, that would also fail.
[40 minutes out of 30 paid minutes used up]
Hi Mario,
I’m using Ubuntu 22.04 for this specifically but I don’t know if that makes a huge difference as it hasn’t for any of the other PTB3 functions. We have the libav Gstreamer plugins installed and I have already tried reinstalling them and updating them before we put in a request for support as I said above. The SimpleMovieDemo plays the DualDiscs movie with no issues and also has no problems displaying any of our video stimuli that we’ve tested. It seems to specifically be an issue with the VideoRecording and VideoCapture works with no issues. When I leave out the encoding parameters, I experience the same issue as above where the video will record and save, but when I try to play it back it will claim that I don’t have the plugins installed that I have already checked multiple times that are there.
Thanks for your help!
Ok, if SimpleMovieDemo works to play back our own DualDiscs movie and your movies, then the needed plugins should be installed. And video capture by itself also works. Weird!
Can you put a sample recording file that doesn’t work somewhere for me to download and test here?
What happens if you provide the optional ‘specialFlags1’ parameter in Screen('OpenMovie', ...., specialFlags1) as value 4? This would disable gpu hardware accelerated video decoding by your graphics card, and choose a pure software solution - less efficient, but maybe can deal better with weird files?
[48 minutes out of 30 paid minutes used up]
Hi Mario,
Here’s a dropbox link to a sample video:
Screen(‘OpenMovie’) is not a part of the code for the VideoRecodingDemo file. However when I switch the Screen(‘OpenMovie’) specialFlag to 4 when running a script to play back the video file, all that happens is that the script quits out immediately.
Thank you so much! I really appreciate your help!
Ok, more baffling: I can play your movie file on both Ubuntu 20.04-LTS with Intel graphics chip and Ubuntu 22.04-LTS with AMD graphics without errors - i think. Also worked on a MacBookPro under macOS. It is a 13+ minute video in which almost nothing happens in terms of visual motion?
The weird thing is that it is encoded in H264 High 4:2:2 profile, when regular Main profile encoding should be sufficient for rather low resolution 640x480 30 fps video. On my machines this High Profile causes playback to fall back to software decoding, instead of using the graphics card, but playback seems to work.
All quite puzzling. Can you try deleting the GStreamer registry on the off-chance it somehow got corrupted? Close Matlab, then in a terminal do:
rm ~/.cache/gstreamer-1.0/*
Then retry playback?
Also what’s the output of the terminal command:
gst-inspect-1.0 | grep h264
You mean it aborts with an error? What output do you get?
Hi Mario!
I deleted the Gstreamer registry and now the video recordings play but they are all much longer than they should be. The video I sent you should be less than a minute long, not thirteen minutes, and another video file I recorded as a test that should of been only 5 seconds long had a playback time of an hour and 14 minutes. The motion and the frame rate is also incredibly choppy and lags severely both with the on-screen video feed during recording and when I watch the saved movie file, no matter what encoding parameters I use.
The output of the terminal command gst-inspect-1.0 | grep h264 is as follows:
libav: avdec_h264: libav H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 decoder
libav: avenc_h264_omx: libav OpenMAX IL H.264 video encoder encoder
openh264: openh264dec: OpenH264 video decoder
openh264: openh264enc: OpenH264 video encoder
rtp: rtph264depay: RTP H264 depayloader
rtp: rtph264pay: RTP H264 payloader
typefindfunctions: video/x-h264: h264, x264, 264
uvch264: uvch264deviceprovider (GstDeviceProviderFactory)
uvch264: uvch264mjpgdemux: UVC H264 MJPG Demuxer
uvch264: uvch264src: UVC H264 Source
va: vah264dec: VA-API H.264 Decoder
vaapi: vaapih264dec: VA-API H264 decoder
vaapi: vaapih264enc: VA-API H264 encoder
videoparsersbad: h264parse: H.264 parser
Playback of the video file, through any of the movie demo scripts is working fine now, but again, the videos recorded through VideoRecordingDemo are all about 4 times as long as they should be and lagging terribly.
Thank you so much!
Ok, a corrupted gstreamer registry prevented playback, unlikely and deeply annoying, but at least playback is solved.
Wrt. recording, does this too long movies happen with all your cameras?
Before running the recording demo, do a…
Screen('Preference','Verbosity', 7);
… so I can look at the output for a few seconds of capture. Maybe put it somewhere to look at, it could be too much for the forum.
It’s guessing time: Edit VideoRecordingDemo.m around line196 to add the value 8192 to the withsound variable. This will disable framerate stabilization. One could also replace realmax in line 263 with the expected capture framerate, e.g., 30.
You could also try with the different codec types again, as described in VideoRecordingDemo.m and done in a previous message.
[>> 90 minutes out of 30 paid minutes used up - Paid support exhausted many times over].
Actually, another thing to try before anything else is to manually select the video capture device to use, and enforcing the use of the good old Video4Linux2 video source.
Edit VideoRecordingDemo.m, line 240 from …
grabber = Screen('OpenVideoCapture', win, [],...) to
grabber = Screen('OpenVideoCapture', win, 20000,...)
Then retry. This will select video capture device 20000 as video source. You can look at the available/enumerated video source via d = Screen('Videocapturedevices').
The kicker here is that we want to enforce use of a camera by use of the good old v4l2src video capture plugin on Ubuntu 22.04, not by use of the more recent pipewiresrc plugin, which was likely be chosen by default, but seems to have some problems with video recording with a few cameras.
When I tested video recording here with default settings, it worked with my USB cameras and most webcams of my laptops. But there was one exotic webcam in the Intel MacBookPro 2017, which has other exotic non-standard quirks, and when trying to record video from it, that showed similar problems for video recording as yours, although pure video capture without recording worked just fine. The way I got it to work nicely was to enforce use of the v4l2src capture plugin instead of the new pipewiresrc plugin, by specifying a device index in the 20000 range. E.g., the first such camera on your machine would have index 20000, a potential 2nd connected camera 20001 and so on.
Apparently the new pipewiresrc is not as mature yet and can cause problems with certain cameras at least for recording.
Hi Mario,
Thank you so much! I really appreciate your help!
In terms of cameras, yes this happens with both our Logitech camera and our MR safe camera. I made a document with the verbose matlab readout from both that I’ve linked here:
https://www.dropbox.com/scl/fi/q2pa8zqrtushpkox2li43/cameraOutput.odt?rlkey=up4zlwn9vdyli29cihv4jtj4e&st=e9q1llzc&dl=0
I did also go back and test all the available codecs after fixing the GStreamer registry issue and all the codecs are behaving exactly the same way—changing the codec doesn’t change the playback behavior.
Lastly, the tutorials I’m using that were included as part of the PTB package are read-only files and thus I can’t edit the lines you specified as being potential fixes just yet. We’re currently working that out with IT but I just wanted to make sure I don’t need to download a different version of the toolbox (i.e. from GitHub).
Thanks again!!
You can open the VideoRecordingDemo.m file in Matlab and then save it into a local folder in your home directory, so editing will be possible, and then cd() into that directory to make sure the edited file is used.
Looking at that log output makes things more puzzling. The Logitech C310 webcam is reported as well supported under Linux, and the output suggests it should work at 640x480 at 30 fps. The “Imaging Source DFG/USB2pro” framegrabber for your MR compatible camera is also supposedly well supported under Linux and the company provides quite a bit of documentation and even a GStreamer SDK to make optimal use of their cameras. The output suggests that camera should work at up to 720 x 576 pixels at 25 fps, which is PAL video standard, and that that’s the chosen setting - at which it then doesn’t seem to work.
Hi Mario!
Thank you so much for your help and your instructions!! Once I copied the VideoRecordingDemo file into my home directory, I was able to edit it to specify a device index and enforce use of the v412src capture plugin as you recommended above and it completely solved the issue for both cameras.
I cannot tell you how much I appreciated your support on this issue—I was loosing my mind trying to figure out what was going wrong!! Thank you a million times over!!!
Thanks again!
Isabel
Good it helped. I’ll probably change the enumeration order of video capture devices to prefer v4l2src as default device in future PTB releases.
Case closed.