Recherche avancée

Sur d’autres sites (4401)

• Unable to load FFProbe - Ubuntu - Laravel 5.5

  6 décembre 2018, par Shreeraj

  I know there are already many questions asked over this issue. Been searching for the solution since last 2 days. I have found several forums :

  Ubuntu - Laravel 5.6 - Unable to load ffprobe (using php-ffmpeg)

  Unable to load FFProbe in laravel app

  getting error Unable to load FFprobe

  Laravel unable to load FFProbe ?

  Unable to load FFProbe driver for FFmpeg

  I have already tried all of the above suitable solutions but none worked.
  Also tried installing the below given packages.

  composer require sormagec/laravel-ffmpeg

  composer require pbmedia/laravel-ffmpeg (Didn’t work because of laravel version, I guess)

  I have set the binary paths correctly :

  return [
  
  'default_disk' => 'local',
  
  
  
  'ffmpeg.binaries' => '/usr/bin/ffmpeg',
  
  'ffmpeg.threads'  => 12,
  
  
  
  'ffprobe.binaries' => '/usr/bin/ffprobe',
  
  
  
  'timeout' => 3600,
  
  ];

  I am using Laravel 5.5 version

  I am not sure what else is missing or where am I lacking. I have installed ffmpeg in my ubuntu. And other required packages in my Laravel application. Please help me out if anything else is missing.

• OUTPUT webcam video over rtp

  20 août 2013, par Manjinder Singh Sekhon

  I'm currently trying to stream webcam video from beagleboard black to my laptop and am using this line of code :

  avconv -f video4linux2 -i /dev/video0 -debug -vcodec mpeg2video -r 25 -pix_fmt yuv420p -me_method epzs -b 2600k -bt 256k -f rtp rtp ://192.168.1.12:5004

  the program starts working, but after a while it doesn't really do anything.
  debug log :

  avconv version v0.8.4, Copyright (c) 2000-2012 the Libav developers
  
    built on May 20 2013 13:00:42 with gcc 4.7.3 20130205 (prerelease)
  
    configuration: --enable-shared --enable-pthreads --enable-gpl --enable-postproc --enable-avfilter --cross-prefix=arm-angstrom-linux-gnueabi- --prefix=/usr --enable-avserver --enable-avplay --enable-x11grab --enable-libtheora --enable-libvorbis --enable-libx264 --arch=arm --target-os=linux --enable-cross-compile --extra-cflags=' -fexpensive-optimizations -fomit-frame-pointer -O4 -ffast-math -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/sysroots/beaglebone' --extra-ldflags='-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed' --sysroot=/build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/sysroots/beaglebone --enable-hardcoded-tables --cpu=cortex-a8
  
    libavutil    51. 22. 1 / 51. 22. 1
  
    libavcodec   53. 35. 0 / 53. 35. 0
  
    libavformat  53. 21. 0 / 53. 21. 0
  
    libavdevice  53.  2. 0 / 53.  2. 0
  
    libavfilter   2. 15. 0 /  2. 15. 0
  
    libswscale    2.  1. 0 /  2.  1. 0
  
    libpostproc  52.  0. 0 / 52.  0. 0
  
  [video4linux2 @ 0x2dae0] [3]Capabilities: 84000001
  
  [video4linux2 @ 0x2dae0] Querying the device for the current frame size
  
  [video4linux2 @ 0x2dae0] Setting frame size to 640x480
  
  [video4linux2 @ 0x2dae0] The V4L2 driver changed the pixel format from 0x32315559 to 0x56595559
  
      Last message repeated 1 times
  
  [video4linux2 @ 0x2dae0] The V4L2 driver changed the pixel format from 0x50323234 to 0x56595559
  
  [video4linux2 @ 0x2dae0] The V4L2 driver set input_id: 0, input: Camera 1

  from what I can see, the program stops because it can't get any input from webcam. The webcam works when I use a opencv program.(so /dev/video0 definitly works.) Any ideas. I've also tried using ffmpeg, but i get message that I should use avconv.

• avcodec : disallow hwaccel with frame threads

  23 octobre 2015, par Hendrik Leppkes

  avcodec : disallow hwaccel with frame threads
  HWAccels with frame threads are fundamentally flawed in avcodecs current
  
  design, and there are several known problems ranging from image corruption
  
  to driver crashes.
  These problems come down to two design problems in the interaction of
  
  threads and HWAccel decoding :
  (1)
  
  While avcodec prevents parallel decoding and as such simultaneous access
  
  to the hardware accelerator from the decoding threads, it cannot account
  
  for the user code and its access to the hardware surfaces and the hardware
  
  itself.
  This can result in image corruption or even driver crashes if the
  
  user code locks image surfaces while they are being used by the decoder
  
  threads as reference frames.
  The current HWAccel API does not offer any way to ensure exclusive access
  
  to the hardware or the surfaces if frame threading is used.
  (2)
  
  Initialization of the HWAccel with frame threads is non-trivial, and many
  
  decoders had and still have issues that cause excess calls to the
  
  get_format callback.
  This will potentially cause duplicate HWAccel initialization, which in
  
  extreme cases can even lead to driver crashes if the HWAccel is
  
  re-initialized while the user code is actively accessing the hardware
  
  surfaces associated with it, or lead to image corruption due to lost
  
  reference frames.
  While both of these issues are solvable, fixing (1) would at least require
  
  a huge API redesign which would move a lot of complexity into the user
  
  code.
  The only reason the combination of frame threads and HWAccel was
  
  considered useful is to allow a seamless fallback to multi-threaded
  
  software decoding if the HWAccel is not available, however the issues
  
  outlined above far outweigh this.
  The proper solution for a fallback is to re-open the AVCodecContext with
  
  threading enabled if the HWAccel failed, which is a practice commonly used
  
  by various user applications using avcodec today already.
  Reviewed-by : Gwenole Beauchesne <gb.devel@gmail.com>
  
  Reviewed-by : wm4 <nfxjfg@googlemail.com>
  
  Signed-off-by : Hendrik Leppkes <h.leppkes@gmail.com>
  

  • [DH] libavcodec/utils.c