Opened 18 months ago

Last modified 17 months ago

#11574 new defect

FFmpeg fails to handle symlinks to video devide

Reported by: Martmists Owned by:
Priority: normal Component: ffplay
Version: 7.1 Keywords:
Cc: Martmists Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
On Linux, FFmpeg gives an Invalid argument error trying to playback symlinks to video devices.

How to reproduce:

I have the following udev rule:

SUBSYSTEM=="video4linux", KERNEL=="video*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="0893", ATTRS{serial}=="287A4655", SYMLINK+="webcam"

This creates a symlink /dev/webcam to, in this case, /dev/video0.

$ readlink /dev/webcam
video0

However, FFmpeg fails to play it back:

$ ffplay -v 9 -loglevel 99 /dev/webcam
ffplay version n7.1.1 
  ...
Initialized opengl renderer.
[AVFormatContext @ 0x728098000c80] Opening '/dev/webcam' for reading
[file @ 0x728098001340] Setting default whitelist 'file,crypto,data'
[AVIOContext @ 0x728098011540] Statistics: 0 bytes read, 0 seeks
/dev/webcam: Invalid argument

Using the device it points to works fine, however:

$ ffplay /dev/video0
  ...
  [video playback starts]

FFmpeg version:

ffplay version n7.1.1 Copyright (c) 2003-2025 the FFmpeg developers
built with gcc 14.2.1 (GCC) 20250207
configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libdvdnav --enable-libdvdread --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-vapoursynth --enable-version3 --enable-vulkan
libavutil      59. 39.100 / 59. 39.100
libavcodec     61. 19.101 / 61. 19.101
libavformat    61.  7.100 / 61.  7.100
libavdevice    61.  3.100 / 61.  3.100
libavfilter    10.  4.100 / 10.  4.100
libswscale      8.  3.100 /  8.  3.100
libswresample   5.  3.100 /  5.  3.100
libpostproc    58.  3.100 / 58.  3.100

Change History (2)

comment:1 by Marton Balint, 18 months ago

You could always enforce the used input demuxer/device with -f v4l2. E.g.

ffplay -f v4l2 /dev/webcam

Right now ffmpeg only automatically assumes a v4l2 device if the filename used is /dev/video. Maybe it could probe the filename to determine if it is a valid v4l2 char device instead of relying on the filename itself.

Note: See TracTickets for help on using tickets.