Recherche avancée

Sur d’autres sites (4667)

• How to averagely extract frames from a video using ffmpeg by specifying "fps"

  14 juin 2021, par alanzzz

  I have a job of using ffmpeg to extract the frames averagely from a video, with different fps. I use this command for it.

  


  ffmpeg -i input.mp4 -r specified_fps -q:v 2 image %4d.png

  


  And I have 3 questions about this task.

  


  

  1. what I expect is that if I double the fps, the number of extracted frames will also get doubled. However, that's not the case. Take one of the input videos as an example.

  


  


  video info

  


  

  • Duration : 1min18s

  


  • Total number of frames : 2340

  


  • Frame rate mode : constant (CFR)

  


  • Frame rate : 30.0 FPS

  


  


  Config setting & results

  


  

  • FPS=1 => number of frames=80

  


  • FPS=2 => number of frames=158 (2x80-2)

  


  • FPS=3 => number of frames=236 (3x80-4)

  


  • FPS=5 => number of frames=392 (5x80-8)

  


  


  Is it possible for me to get the exact doubled number of frames when fps get doubled ? In such case, number of frames is 160 for FPS=2, 240 for FPS=3, 400 for FPS=5.

  


  


  2. I check for the output images, the extracted frames in different fps are totally different from each other. In other words, for example, the 1st image for fps=1 is not the same as the 1st image for fps=2. Is that legitimate ? And is it possible for me the get some identical images for different fps ?

     


  


  3. The last problem is that for some videos I use, the difference between the 1st and 2nd image is different from the difference between the 2nd and 3rd. While for the remaining images, the differences become average. To be specific, there is only a slight change from 1st to 2nd frame, while for 2nd to 3rd, 3rd to 4th, and so on, the changes are the same, which is normally distributed according to the specified FPS. I am wondering why such a case happens ? Does it related to the I-frame, B-frame, P-frame, GOP or IDR ?

     


  


  


  I am new to this field and cannot find some useful info from other places. I've tried my best to describe my questions clearly. Feel free to leave some comments. Any help would do me a great favor. Thanks in advance !

  


• No such file or directory FFMpeg Error on MAC

  20 novembre 2014, par Nitesh

  I am trying to build a ffmpeg binary using the following link

  http://ffmpegmac.net/HowTo/

  I was successful in creating the binary.
  I could convert video files easily
  This is the code i run in the terminal

  ffmpeg -i Test.mp4 -b:v 64k -bufsize 64k test2.flv

  This works fine totally
  But when i run

  ./ffmpeg -re -i  test2.flv  -acodec libfaac -ar 44100 -ab 96k -c: v libx264  -level 41 -      profile baseline -bufsize 20000k -maxrate 25000k -g 250 -r 20 -s 480x270 -flags  -global_header -map 0 -f segment -segment_time 4 -segment_list test.m3u8 -segment_format mpegts stream%05d.ts 

  I get a "test2.flv : No such file or directory error" even though the test2.flv exists in the folder. Can you tell me where i might be going wrong.
  I am doing the above operation to stream the video to my iPhone over air.

  (Note- The command to build the ffmpeg binary i am using is as follows-
  ./configure —prefix=$TARGET —enable-nonfree —enable-gpl —enable-pthreads —enable-version3 —enable-libspeex —enable-libvpx —disable-decoder=libvpx —enable-libfaac —enable-libmp3lame —enable-libtheora —enable-libvorbis —enable-libx264 —enable-avfilter —enable-libopencore_amrwb —enable-libopencore_amrnb —enable-filters —arch=x86_64 —enable-runtime-cpudetect && make -j 4 && make install
  )

  Thanks in advance for your help
  Regards

• Revision c70cea97ac : Remove mi_grid_* structures. mi_grid_* are arrays of pointer to pointer. They s

  12 septembre 2014, par hkuang

  Changed Paths :
   Modify /vp9/common/vp9_alloccommon.c

  
   Modify /vp9/common/vp9_blockd.c

  
   Modify /vp9/common/vp9_blockd.h

  
   Modify /vp9/common/vp9_debugmodes.c

  
   Modify /vp9/common/vp9_entropy.h

  
   Modify /vp9/common/vp9_loopfilter.c

  
   Modify /vp9/common/vp9_loopfilter.h

  
   Modify /vp9/common/vp9_mvref_common.c

  
   Modify /vp9/common/vp9_onyxc_int.h

  
   Modify /vp9/common/vp9_pred_common.c

  
   Modify /vp9/common/vp9_pred_common.h

  
   Modify /vp9/common/vp9_reconinter.c

  
   Modify /vp9/decoder/vp9_decodeframe.c

  
   Modify /vp9/decoder/vp9_decodemv.c

  
   Modify /vp9/decoder/vp9_detokenize.c

  
   Modify /vp9/decoder/vp9_dthread.c

  
   Modify /vp9/encoder/vp9_bitstream.c

  
   Modify /vp9/encoder/vp9_denoiser.c

  
   Modify /vp9/encoder/vp9_encodeframe.c

  
   Modify /vp9/encoder/vp9_encodemb.c

  
   Modify /vp9/encoder/vp9_encodemv.c

  
   Modify /vp9/encoder/vp9_encoder.c

  
   Modify /vp9/encoder/vp9_firstpass.c

  
   Modify /vp9/encoder/vp9_mbgraph.c

  
   Modify /vp9/encoder/vp9_pickmode.c

  
   Modify /vp9/encoder/vp9_quantize.c

  
   Modify /vp9/encoder/vp9_rd.c

  
   Modify /vp9/encoder/vp9_rdopt.c

  
   Modify /vp9/encoder/vp9_segmentation.c

  
   Modify /vp9/encoder/vp9_temporal_filter.c

  
   Modify /vp9/encoder/vp9_tokenize.c

  
  
  Remove mi_grid_* structures.

  mi_grid_* are arrays of pointer to pointer. They save the pointers that point
  to the MIs in cm->mi. But they are unnecessary and complicated. The original
  goal was to remove MODE_INFO_t copy. But with an extra MODE_INFO_t pointer
  inside MODE_INFO_t, same goal could be achieved.

  This commit totally removes the mi_grid_* structures. But there are still
  many dummy MODE_INFO_t inside cm->mi which are a waste of memory. Next commit
  will do on-demand MODE_INFO_t allocation in order to save these memories.

  Change-Id : I3a05cf1610679fed26e0b2eadd315a9ae91afdd6