Recherche avancée

Sur d’autres sites (7836)

• FFmpeg tile crop paging when full

  19 janvier 2021, par Jimmy

  I've been trying to tile images from a video into a 10x10 image,it works but when the image is filled 10x10 it won't create another image and fill, it just stopped,

  


  This is what I ended up with :
ffmpeg -i video.mp4 -frames 1 -vf "select=not(mod(n,10)),scale=80:45,tile=10x10" out%03d.png

  


  What I wanted :

  


  

  • a tile with 10x10

  


  • when the image is filled, create another image and fill and so on, the outcome will be out1.png, out2.png... until it's done

  


  


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

  


• Combine MPEG-DASH segments (ex, init.mp4 + segments.m4s) back to a full source.mp4 ?

  20 octobre 2016, par Drake

  GPAC, http://gpac.wp.mines-telecom.fr/, can be used to do video segmentation along with MPEG-DASH spec. One type of results is a combination of init files (ex, init.mp4) and several roughly fixed-duration segments (ex, segment-%d.m4s). What if I just got those results and I like to reverse/combine them back to one full source.mp4 file ? Can I use GPAC or ffmpeg for this ?