Recherche avancée

Sur d’autres sites (5264)

• Video editing multi customer host in server instances

  1er août 2020, par General Omosco

  I created a multi conference live stream web app using rtc and ffmpeg C api for media stream, videos/images/texts files mixed up together in realtime sending the output to rtmp multiple destinations, but unfortunately my server could not handle more than 2 conference room smoothly.

  


  The server which couldn't handle more than two conference room running ffmpeg api

  


  It is Comfort plan in OVH
Type : vps,
Processor : 4 vCore,
Ram : 8gb

  


  Usage
CPU : 100% //playing smoothly or not.
Ram : 3%

  


  My question here is that. Is it possible to be creating self isolated instance on fly and automatically deploy the app in the instance for each customer ? And the host provider that can accept that.

  


• How to extract motion vectors from h264 without a full decode on the CPU

  25 septembre 2020, par Adrian May

  I'm trying to use my nose as a pointing device. The plan is to encode the video stream from a webcam pointed at my face as h264 or the like, get the motion vectors, cook the numbers a bit and chuck them into /dev/uinput to make the mouse pointer move about. The uinput bit was easy.

  


  This has to work with zero discernable latency. This, for instance :

  


  #!/bin/bash
[ -p pipe.mkv ] || mkfifo pipe.mkv
ffmpeg -y -rtbufsize 1M -s 640x360 -vcodec mjpeg -i /dev/video0 -c h264_nvenc pipe.mkv &
ffplay -flags2 +export_mvs -vf codecview=mv=pf+bf+bb pipe.mkv


  


  shows that the vectors are there but with a latency of several seconds which is unusable in a mouse. I know that the first ffmpeg step is working very fast by using the GPU, so either the pipe or the h264 decode in the second step is introducing the latency.

  


  I tried MV Tractus (same as mpegflow I think) in a similar pipe arrangement and it was also very slow. They do a full h264 decode on the CPU and I think that's the problem cos I can see them imposing a lot of load on one CPU. If the pipe had caused the delay by buffering badly then the CPU wouldn't have been loaded. I guess ffplay also did the decoding on the CPU and I couldn't persuade it not to, but it only wants to draw arrows which are no use to me.

  


  I think there are several approaches, and I'd like advice on which would be best, or if there's something even better I don't know about. I could :

  


  

  • Decode in hardware and get the motion vectors. So far this has failed. I tried combining ffmpeg's extract_mvs.c and hw_decode.c samples but no motion vectors turn up. vdpau is the only decoder I got working on my linux box. I have a nvidia gpu.

  


  • Do a minimal parse of the h264 to fish out the motion vectors only, ignoring all the other data. I think this would mean putting some kind of "motion only" option in libav's parser, but I'm not at all familiar with that code.

  


  • Find some other h264 parsing library that has said option and also unpacks the container.

  


  • Forget about hardware accelerated encoding and use a stripped down encoder to make only the motion vectors on either CPU or GPU. I suspect this would be slow cos I think calculating the motion vectors is the hardest part of the algorithm.

  


  


  I'm tending towards the second option but I need some help figuring out where in the libav code to do it.

  


• Attempting to compile FFmpeg 4.2.3 statically for Windows 10 (x86_64), but binaries asks for missing DLLs

  29 mai 2020, par Expectator

  I am using Msys MinGW (x86_64) and pulled a snapshot of the latest major release of FFmpeg off of their website. Here is my ./configure options. I plan to use the binaries on both the computer that I compiled it on, and other Windows computers that I own.

  



  ./configure --enable-libaom --enable-avisynth --enable-chromaprint --enable-libdav1d --enable-libdavs2 --enable-libgme --enable-libmfx --enable-libkvazaar --enable-libmp3lame --enable-libilbc --enable-libvpx --enable-libmodplug --enable-version3 --enable-nonfree --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-libfdk-aac --enable-libopenh264 --enable-libopenjpeg --enable-nvenc --enable-nvdec --enable-cuda --enable-cuvid --enable-libtwolame --enable-vapoursynth --enable-libwavpack --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxavs2 --enable-gpl --enable-static --disable-shared


  



  Output of configure script (pastebin)

  



  Output of uname -a (in Msys)

  



  MINGW64_NT-10.0-18362 <scrubbed> 3.1.4-340.x86_64 2020-05-22 08:28 UTC x86_64 Msys&#xA;</scrubbed>

  



  The issue that I'm facing is that despite passing the options --enable-static and --disable-shared, the executables generated still require libchromaprint.dll, libfdk-aac-2.dll, and libgme.dll to run. What I expected was that FFmpeg would execute independently of any DLL files since I passed those options to ./configure.