Recherche avancée

Sur d’autres sites (7425)

• Merge commit ’8d07e941b04d63fc4443dd986e3dc7b69cdcca43’

  18 novembre 2016, par Hendrik Leppkes

  Merge commit ’8d07e941b04d63fc4443dd986e3dc7b69cdcca43’
  * commit ’8d07e941b04d63fc4443dd986e3dc7b69cdcca43’ :
  
    FATE : add a test of H.264 SEI recovery in an intra refresh stream
  Our H264 decoder drops 3 frames from the beginning of the stream, but
  
  all frames after those match, hence the difference in the fate test.
  Merged-by : Hendrik Leppkes <h.leppkes@gmail.com>
  

  • [DH] tests/fate/h264.mak
  • [DH] tests/ref/fate/h264-intra-refresh-recovery

• 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