Recherche avancée

Sur d’autres sites (6300)

• How to set frame offset for source and reference video for calculating using FFMpeg commandline ?

  1er septembre 2018, par Souvik Das

  I have a scenario where I am streaming a reference video on a server machine and receiving it at a client machine with exact same codec, using FFMpeg via UDP/RTP.

  So, I have a reference.avi file and a recording.ts file with me. Now, due to a network side issue and FFMpeg discarding old frames, often the recording.ts lacks exactly 12 FRAMES from the beginning. Sometimes, it may lack more frames in-between but that’d due to general network traffic and packet loss reason and I don’t plan to account for that. Anyways, due to those 12 frames, when I calculate the PSNR, it drops down to 13, even though remaining frames may/may not be affected.

  So, my aim is to discard first 12 frames from reference.ts and then compare. For that, I would also need to adjust the frames from recording.ts.

  Consider the following scenario :

  reference.ts has 1500 frames. So naturally I am going to cut-short it 1488. Then we have the following cases :

  1. recording.ts has 1500 frames. This is not affected. Still I will remove 12 frames to match the count. So frame 1 would then represent frame 13.
  2. recording.ts has 1496 frames. This is not affected. Still I will remove 12 frames even though it’d get to 1484 count assuming that frame 1 would then represent frame 13.
  3. recording.ts has 1488 frames. This is affected. No need to remove frames.
  4. recording.ts has 1480 frames. This is affected. No need to remove frames.

  Once that is done, then I will calcualte the PSNR. So, my FFMpeg should be able to do all this, hopefully in a single command on bash.

  A better alternative would be for FFMpeg to find the where the 13th frame is in recording.ts and then cut-short from the beginning. That’d be more preferred and even more if there is no cut-shorting required, i.e. if offset could be set in-line to command and no additional video output is generated for use in PSNR comparison.

  Current I am using the following command to calculate the PSNR.

  ffmpeg -i 'recording.ts' -vf "movie='reference.avi', psnr=stats_file='psnr.txt'" -f rawvideo -y /dev/null

  It’d be great if somebody could help me in this regard. Thanks.

• ffmpeg - prop flicker removal works but ffmpeg insists on changing framerate [closed]

  28 avril 2023, par Mutley Eugenius

  I have been researching how to use FFmpeg to do some fantastic wizardry on my cockpit videos to remove the dramatically distracting propeller, but after many hours now I cannot seem to find a way to get the program to stop stripping more than half the frames. The source video file is 1920 x 1080 @ 60fps and I believe I have my offset right (1/60= 0.0166) but the output video is always coming out at 25 fps. Can't see what element in the code is telling it to do that, or how to change it.

  


  Here's my file :

  


  https://drive.google.com/file/d/1VPttH4PHgUr0uzmsbl4Bcyg5_gAixblA/view?usp=sharing

  


  Here's my code :

  


  ffmpeg -i G:\PropFlicker.mp4 -itsoffset 0.01666 -i G:\PropFlicker.mp4 -filter_complex color=0x202020:s=1920x1080:d=24[mask];[mask][0][1]maskedmax=[out] -map [out] -crf 10 G:\PropNoFlicker.mp4


  


  I have tried adding -r 60 which gives me a 60 fps output file, but the video is still being processed at 25 and it just adds in duplicated frames after processing to pad it out to 60. The rendering shows more dropped frames than rendered frames by about a 3 to 2 ratio which matches frame drops from 60 to 25. I lose my shot fluidity and I get flickery artifacts

  


  What am I missing to get the flicker removal processing done at 60 fps and the output file rendered at 60 fps with the original smoothness ?

  


  I'm also not sure what the :d=24 is doing. I tried d=60, but it made no difference.

  


  I copied original code that I found in this link :

  


  text

  


• avcodec/omx : Fix handling of fragmented buffers

  17 janvier 2019, par Dave Stevenson

  avcodec/omx : Fix handling of fragmented buffers
  See https://trac.ffmpeg.org/ticket/7687
  If an encoded frame is returned split over two or more
  
  IL buffers due to the size, then there is a race between
  
  whether get_buffer will fail, return NULL, and a truncated
  
  frame is passed on, or IL will return the remaining part
  
  of the encoded frame.
  
  If get_buffer returns NULL, part of the frame is left behind
  
  in the codec, and will be collected on the next call. That
  
  then leaves a frame stuck in the codec. Repeat enough times
  
  and the codec FIFO is full, and the pipeline stalls.
  A performance improvement in the Raspberry Pi firmware means
  
  that the timing has changed, and now frequently drops into the
  
  case where get_buffer returns NULL.
  Add code such that should a buffer be received without
  
  OMX_BUFFERFLAG_ENDOFFRAME that get_buffer is called with wait
  
  set, so we wait for the remainder of the frame.
  
  This code has been made conditional on the Pi build in case
  
  other IL implementations don't handle ENDOFFRAME correctly.
  Signed-off-by : Dave Stevenson <dave.stevenson@raspberrypi.org>
  
  Signed-off-by : Aman Gupta <aman@tmm1.net>
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/omx.c