Recherche avancée

Sur d’autres sites (8253)

• Revision 5b1dc1515f : Fix a bunch of TODO from vp9_short_idct32x32_add_neon. - full ASM version, no m

  26 septembre 2013, par Christian Duvivier

  Changed Paths :
   Delete /vp9/common/arm/neon/vp9_idct32x32_neon.c

  
   Modify /vp9/common/arm/neon/vp9_short_idct32x32_add_neon.asm

  
   Modify /vp9/vp9_common.mk

  
  
  Fix a bunch of TODO from vp9_short_idct32x32_add_neon.

   full ASM version, no more C gateway file.
   integrate combine-add with last step of 2nd pass.
   remove a few push/pop pairs.
   some instruction reordering to hide latency.

  Change-Id : Ic9d9933c908b65d1bf7ba8fd47b524cda808c9c6

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

  


• Creating a single video using extracted frames from several video clips without having to write the frames into a folder

  24 décembre 2023, par Athekul

  I have a set of mp4 video clips named : file1.mp4, file2.mp4,..filen.mp4.
I want to write a code for going through the files sequentially and extracting a frame every 10 seconds of the video.
Then I want to combine the frames and make one output video file at 6 fps.

  


  I have the code which does that but it extracts frames and stores them in a subfolder before combining them into a video. I think that is inefficient.
Is there a way whereby I can extract frames from the video clips and output the final video without having to store the frames in a folder ?

  


  This is the code that I have.

  


  #!/bin/bash

# Step 1: Extract frames every 10 seconds
input_folder="/home/aj/Videos/merge"
output_folder="/home/aj/Videos/merge"
subfolder="frames"

# Create subfolder if it doesn't exist
mkdir -p "$output_folder/$subfolder"

# Get the total number of input files
total_files=$(find "$input_folder" -maxdepth 1 -type f -name "*.mp4" | wc -l)
processed_files=0
global_frame_counter=0

# Iterate through mp4 files in the input folder
for file in "$input_folder"/*.mp4; do
  filename=$(basename "$file")
  filename_no_ext="${filename%.mp4}"

  # Extract frames every 10 seconds
  ffmpeg -i "$file" -vf fps=1/10 "$output_folder/$subfolder/output_${global_frame_counter}%02d.png"
  
    # Increment the global frame counter
  ((global_frame_counter ++))

  # Increment the processed files count
  ((processed_files++))

  # Calculate and echo the percentage of files processed
  percentage=$((processed_files * 100 / total_files))
  echo -e "\033[1;32mProcessing: $percentage% complete\033[0m"
done

# Step 2: Combine frames into a single video
cd "$output_folder/$subfolder" || exit

ffmpeg -r 6 -f image2 -s 1920x1080 -i "output_%*.png" -vcodec libx264 -crf 25 -pix_fmt yuv420p "$output_folder/result.mp4"

echo "Frames extracted and video created successfully."