Recherche avancée

Sur d’autres sites (5546)

• Dynamic Location Offsetting while Desktop Video Capture in FFPMEG

  18 février 2024, par Zen Of Kursat

  is there a way to dynamically change offsets during screen capture ?

  


  but this offset values are static (eg. 66 and 77) and we cannot change these values during video recording. simply I am trying to record screen with according to mouse coordinates which are ofsure changing while video recording starts.

  


  eg.

  


  ffmpeg -f gdigrab -framerate 30 -offset_x 77 -offset_y 66 -video_size 1920x1080 -i desktop output.mp4


  


• 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.

  


• How do I access the ipod-library for decoding ffmpeg ?

  16 janvier 2014, par M_On

  Thank you to look at my question.

  There is a problem with too slow to access the music file using ffmpeg.

  Get the URL of the music that is in the ipod-library by using the 'valueForProperty:MPMediaItemPropertyAssetURL' method.

  Use the (AVAssetExportSession Class) TSLibraryImport.m, extract the music files from ipod-library.

  However, I took the extraction time is too long. (4 seconds of the 3GS iPhone, iPhone 5 is 1 second)

  It was not possible to be decoded using FFmpeg If you do not the Export.

  In order to use FFmpeg, it's AVPlayer can not be used.

  I will never forget the grace if you can answer if you folded to know how other maybe.