Recherche avancée

Sur d’autres sites (12180)

• avutils/hwcontext : When deriving a hwdevice, search for existing device in both direc...

  25 novembre 2021, par Soft Works

  avutils/hwcontext : When deriving a hwdevice, search for existing device in both directions
  The test /libavutil/tests/hwdevice checks that when deriving a device
  
  from a source device and then deriving back to the type of the source
  
  device, the result is matching the original source device, i.e. the
  
  derivation mechanism doesn't create a new device in this case.
  Previously, this test was usually passed, but only due to two different
  
  kind of flaws :
  1. The test covers only a single level of derivation (and back)
  It derives device Y from device X and then Y back to the type of X and
  
  checks whether the result matches X.
  What it doesn't check for, are longer chains of derivation like :
  CUDA1 > OpenCL2 > CUDA3 and then back to OpenCL4
  In that case, the second derivation returns the first device (CUDA3 ==
  
  CUDA1), but when deriving OpenCL4, hwcontext.c was creating a new
  
  OpenCL4 context instead of returning OpenCL2, because there was no link
  
  from CUDA1 to OpenCL2 (only backwards from OpenCL2 to CUDA1)
  If the test would check for two levels of derivation, it would have
  
  failed.
  This patch fixes those (yet untested) cases by introducing forward
  
  references (derived_device) in addition to the existing back references
  
  (source_device).
  2. hwcontext_qsv didn't properly set the source_device
  In case of QSV, hwcontext_qsv creates a source context internally
  
  (vaapi, dxva2 or d3d11va) without calling av_hwdevice_ctx_create_derived
  
  and without setting source_device.
  This way, the hwcontext test ran successful, but what practically
  
  happened, was that - for example - deriving vaapi from qsv didn't return
  
  the original underlying vaapi device and a new one was created instead :
  
  Exactly what the test is intended to detect and prevent. It just
  
  couldn't do so, because the original device was hidden (= not set as the
  
  source_device of the QSV device).
  This patch properly makes these setting and fixes all derivation
  
  scenarios.
  (at a later stage, /libavutil/tests/hwdevice should be extended to check
  
  longer derivation chains as well)
  Reviewed-by : Lynne <dev@lynne.ee>
  
  Reviewed-by : Anton Khirnov <anton@khirnov.net>
  
  Tested-by : Wenbin Chen <wenbin.chen@intel.com>
  
  Signed-off-by : softworkz <softworkz@hotmail.com>
  
  Signed-off-by : Haihao Xiang <haihao.xiang@intel.com>
  

  • [DH] libavutil/hwcontext.c
  • [DH] libavutil/hwcontext.h
  • [DH] libavutil/hwcontext_internal.h
  • [DH] libavutil/hwcontext_qsv.c

• ffmpeg, /dev/video0, -f decklink

  20 mars 2019, par Camille Goudeseune

  I’m trying to capture video from a PCI card, the Blackmagic DeckLink Mini Recorder, via ffmpeg, on a headless host running Ubuntu 18.04.2 LTS, hopefully with a command like

  ffmpeg -f decklink -i /dev/video0 ...

  How can I make that work ? I have two obstacles.

  No /dev/video0

  ffmpeg -i /dev/video0 ... fails : /dev/video0: No such device or address.
  v4l2-ctl --list-devices fails with the same error message.

  I built /dev/video0, and it looks okay :

  mknod /dev/video0 c 81 0
  
  chown root.video /dev/video0
  
  chmod g+rw /dev/video0

  To compare this file with a working one, I ran strace cat /dev/video0 on this host, and on another host (Ubuntu 14) with a working /dev/video0. The outputs began to differ here (good, then bad) :

  fstat(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
  
  open("/dev/video0", O_RDONLY)           = 3  
  
  fstat(3, {st_mode=S_IFCHR|0660, st_rdev=makedev(81, 0), ...}) = 0
  
  fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
  
  ----
  
  
  
  fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
  
  openat(AT_FDCWD, "/dev/video0", O_RDONLY) = -1 ENXIO (No such device or address)

  So /dev/video0 is broken at a level lower than ffmpeg or v4l2 or even cat.

  On Ubuntu 14, man 8 MAKEDEV suggests that the error message means that "the kernel does not have the driver configured or loaded."

  This Ubuntu 18 host lacks that manpage, but it does have a few /snap/core/*/sbin/MAKEDEV, all the same, so I tried

  /snap/core/6350/sbin/MAKEDEV -n -v video

  It would have created over a hundred devices videoXX, radioXX, vtxXX, vbiXX. Those devices didn’t exist yet, so it seemed harmless to try it.

  rm /dev/video0; /snap/core/6350/sbin/MAKEDEV video

  That rebuilt /dev/video0, but "No such device" remains, from cat or ffmpeg.

  No decklink

  ffmpeg -f decklink ... fails with Unknown input format: 'decklink'.

  Neither black nor deck nor link is mentioned by ffmpeg -devices (fbdev, lavfi, oss, v4l2) and ffmpeg -formats (about 350), either for Ubuntu’s own version 3.4.4-0ubuntu0.18.04.1, or for version N-93330-g7ff89574c7 compiled from source on 2019 Mar 13 :

  git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg
  
  cd ffmpeg
  
  ./configure --enable-nonfree --disable-doc --disable-w32threads --enable-pthreads

  (Although ./configure --help mentions --enable-decklink, using that yielded "ERROR : DeckLinkAPI.h not found." updatedb && locate DeckLinkAPI.h finds no file with that name, either.)

  The DeckLink PCI card is recognized by hwinfo and lspci.

  lsmod reports the loaded modules blackmagic and blackmagic_io.

  Maybe the PCI card is installed ok, but ffmpeg just can’t reach it because I can’t configure it for that.

  Edit : Rebooting didn’t fix anything.

• Revision 29747 : On incrémente la version du plugin

  8 juillet 2009, par kent1@… — Log

  On incrémente la version du plugin