Recherche avancée

Sur d’autres sites (13702)

• ffmpeg minterpolate and rubberband - how to stretch audio to fit ?

  5 juin 2023, par bossturbo

  What is the best way to control the length of the audio and pitch shift using rubberband ?

  


  I tried setting 'asetpts=PTS*16' to match the video PTS, but it appears to be ignored. The only thing that seems to determine the length of the audio is rubberband pitch. Even 'tempo=0.0625' does not appear to do anything.

  


  I would like to be able to set the audio length to match the slower video section and set the pitch to whatever I want, like minimum 0.15 and have it stretch the audio length as needed.

  


  ffmpeg -ss 123.978571 -i "original-120fps.MP4" -filter_complex "
[0:v]trim=0:0.375,setpts=PTS-STARTPTS,minterpolate='fps=480',setpts=PTS*16[slowv]; 
[0:a]atrim=0:0.375,asetpts=PTS-STARTPTS,rubberband=pitch=0.08:tempo=0.0625[slowa];"
 -y -r 60 -map [slowv] -map [slowa] -preset veryfast "output.mp4"


  


  Finally, is there a good guide to using lib-rubberband ? FFmpeg docs for rubberband doesn't explain anything.

  


• Extract individual macroblock types and their corresponding motion vectors [closed]

  14 mai 2023, par Prajit Kumar

  I need to make a pair for each macroblock from a frame of a video containing its type and motion vector.

  


  I extracted motion vectors by using the python module of mv-extractor.

  


  For macroblock type I used ffmpeg command : ffmpeg -threads 1 -debug 'mb_type' -i file.h264 -f null -

  


  The info received from ffmpeg command doesn't match with the location of motion vectors extracted (Macroblocks which are divided into smaller blocks of size 8X16 or 16X8 do not match with the info of macroblock size received in motion vector info). Also, the ffmpeg command for extracting macroblock type doesn't work properly on some videos.

  


  Can you please tell a more streamlined way of doing this task.

  


• Different ffmpeg result after saving to png

  28 juillet 2023, par Kalev Maricq

  Saving images to PNG first seems to produce different ffmpeg encodes. Running this test code

  


  from PIL import Image
import cv2
import ffmpeg
import hashlib

ffmpeg.input('test.jpg').output('testff.png').run()
cv2.imwrite('testcv.png',cv2.imread('test.jpg'))
Image.open('test.jpg').save('testpil.png')

hashes=[]
for suf in ['.jpg','ff.png','cv.png','pil.png']:
    dest='test'+suf.replace('.','')+'.mp4'
    ffmpeg.input('test'+suf).output(dest).run()
    hashes.append(hashlib.file_digest(open(dest,'rb'),'md5').hexdigest())
    
print(hashes)


  


  I get
  
['a5b744a8ac0f6de9ec4de43ff737c46e'
  
,'ab62474f2160899e064ba24890047372'
  
,'baa788d5e4ef212ab610b8b5cf7772cb'
  
,'baa788d5e4ef212ab610b8b5cf7772cb']

  


  As you can see, the only two that match are the cv2 and pillow conversions, and none of them match the original. In terms of file size, the results that passed to png first seem to be about 10% smaller than the direct-from-jpg result.

  


  Why is this happening and how can I avoid changing image data until I'm ready to encode ?