0

Issue: I have an FFmpeg command that I've been running for months now to stream video into the /dev/shm directory. It had been working fine until relatively recently (e.g. within a week), now it throws a permission issue.

The command:

ffmpeg -threads 2 -video_size 640x480 -i /dev/video2 -c:v libx264 -f dash -streaming 1 /dev/shm/manifest.mpd

This is not the exact command (paired down for brevity), however the outcome is the same:

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error:  GLXBadContext
  Request Major code 151 (GLX)
  Request Minor code 6 ()
  Error Serial #57
  Current Serial #56
ffmpeg version n4.3.1 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 7 (Ubuntu 7.5.0-3ubuntu1~18.04)
  configuration: --prefix= --prefix=/usr --disable-debug --disable-doc --disable-static --enable-cuda --enable-cuda-sdk --enable-cuvid --enable-libdrm --enable-ffplay --enable-gnutls --enable-gpl --enable-libass --enable-libfdk-aac --enable-libfontconfig --enable-libfreetype --enable-libmp3lame --enable-libnpp --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopus --enable-libpulse --enable-sdl2 --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libv4l2 --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxvid --enable-nonfree --enable-nvenc --enable-omx --enable-openal --enable-opencl --enable-runtime-cpudetect --enable-shared --enable-vaapi --enable-vdpau --enable-version3 --enable-xlib
  libavutil      56. 51.100 / 56. 51.100
  libavcodec     58. 91.100 / 58. 91.100
  libavformat    58. 45.100 / 58. 45.100
  libavdevice    58. 10.100 / 58. 10.100
  libavfilter     7. 85.100 /  7. 85.100
  libswscale      5.  7.100 /  5.  7.100
  libswresample   3.  7.100 /  3.  7.100
  libpostproc    55.  7.100 / 55.  7.100
Input #0, video4linux2,v4l2, from '/dev/video2':
  Duration: N/A, start: 1900.558740, bitrate: 147456 kb/s
    Stream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 640x480, 147456 kb/s, 30 fps, 30 tbr, 1000k tbn, 1000k tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 0x55b15d8912c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0x55b15d8912c0] profile High 4:2:2, level 3.0, 4:2:2 8-bit
[libx264 @ 0x55b15d8912c0] 264 - core 152 r2854 e9a5903 - H.264/MPEG-4 AVC codec - Copyleft 2003-2017 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
[dash @ 0x55b15d88f600] No bit rate set for stream 0
[dash @ 0x55b15d88f600] Opening '/dev/shm/init-stream0.m4s' for writing
Could not write header for output file #0 (incorrect codec parameters ?): Permission denied
Error initializing output stream 0:0 -- 
Conversion failed!

(tl;dr: Could not write header for output file #0 (incorrect codec parameters ?): Permission denied)

For contrast, this version of the command (writing to the home directory) works fine (/tmp/ also works):

ffmpeg -threads 2 -video_size 640x480 -i /dev/video2 -c:v libx264 -f dash -streaming 1 ~/manifest.mpd

As mentioned above, the strange thing is that I have not (knowingly) changed permissions on anything or altered the application; it seemingly just stopped working (although, not ruling out that I caused it). The last time I remember it working was probably a week ago (~March 20th, 2021).

What I tried:

  • Running ffmpeg as sudo (sudo ffmpeg...)
    • Result: sudo: ffmpeg: command not found. This hasn't been necessary in the past, and it had the same output as before.
  • sudo sysctl fs.protected_regular=0
    • Result: No change.
  • Ran the ffmpeg ... command as su
    • Result: No change
  • chmod +777 /dev/shm
    • Result: No change (ls -tls reveals that the directory is indeed rwxrwxrwt)
  • chown'd both root:root and my username on /dev/shm
    • Result: No change.
  • touch /dev/shm/test.txt and sudo touch /dev/shm/test.txt
    • Result: The file is created without issue.

I've exhausted everything I could think of relating to permissions to get it to work.

The Question What do I need to do to get FFmpeg write files to /dev/shm? Ideally, figuring out why this happened in the first place.

If anyone has any ideas for commands I should run to help diagnose this issue, feel free to add a comment.

System Info:

  • Kernel: 4.19.0-14-amd64
  • Distro: Debian
  • FFmpeg: version n4.3.1 (Was installed using Snapd, if it matters.)

== Solution ==

jsbilling's solution of using snap.<snapname>.* unfortunately did not work, however in the linked forum thread there was a post which basically got around the issue of writing to /dev/shm by mounting a directory in home ~/stmp and writing the ffmpeg output there:

$ mkdir ~/stmp/
$ sudo mount --bind /dev/shm/streaming_front/ ~/stmp/
...
$ ffmpeg -threads 2 -video_size 640x480 -i /dev/video2 -c:v libx264 -f dash -streaming 1  ./stmp/manifest.mpd

Not an ideal solution, but a working one.

1 Answer 1

2

If you are using snaps, this forum post indicates there are specific patterns that are allowed for files in /dev/shm:

/dev/shm/snap.<snapname>.*

Another forum member suggested this hack, although it is basically a security bypass:

$ mkdir /dev/shm/shared
$ mkdir ~/shmdir
$ sudo mount --bind /dev/shm/shared ~/shmdir
$ touch ~/shmdir/foo
$ ls /dev/shm/shared/
foo
2
  • See my edit - I was able to get it working from one of the more 'hacky' solutions in the linked forum pos. If you edit your answer to include that, I'd be wiling to mark your answer as accepted (unless you'd rather not for security-moral reasons :) ). And, while I know that this site discourages this sort of commenting: holy sh*t thank you.
    – schil227
    Mar 27, 2021 at 19:33
  • 1
    @schil227 I added it here, since it does solve the immediate problem despite the security implications, the forum post might be removed/archived/etc.
    – jsbillings
    Mar 27, 2021 at 20:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .