Recherche avancée

Sur d’autres sites (5847)

• FFMPEG spoils the extreme pixels when converting and cropping images [closed]

  20 décembre 2024, par Jacob

  I have a side image processing task in my work.
I am using the following command to translate a spherical panorama into a cubemap :

  


  Path/ffmpeg.exe -i "Path/PanoImageInput.png" -vf v360=equirect:c6x1:fin_pad=64:out_frot=002200,scale=-1:2048:flags=neighbor "Path/CubemapOutput.png"

  


  And then I slice it into separate images, 1 face for example :

  


  Path/ffmpeg.exe -i "Path/CubemapOutput.png" -vf crop=2048:2048:0:0 -sws_flags neighbor "Path/face_1.png"

  


  I get artifacts on both cubemap and images of this kind that really bother me :

  


  Cubemap image junction
The junction and part of the edge of the cubemap image

  


  The pixels at the junctions of the 6 images in cubemap and the outermost pixels of any images change their color slightly. This eventually leads to the appearance of visible seams in the scene assembled from the images.

  


  Is there any way I can get rid of them ?

  


  I have tried different interpolation methods in both functions : fast, bicubric, gauss, etc. It doesn't seem to have any effect.

  


  I also tried to crop a couple of pixels less, something like : crop=2040:2040:4:4

  


  I thought it was all because of cubemap and its distortions. Anyway, at the edges of the image, the extreme pixels change their hue.

  


  I also hoped that with the help of pad, during the conversion, I could somehow control the area where the pixels deteriorate, but it absolutely does not matter what I put there - fin_pad, fout_pad and any numbers for them, remove scale, set scale - neither the final image size changes, nor any extra fields appear. Most likely, I just don't understand what this function is really supposed to mean.

  


• avcodec/pthread_frame, decode : allow errors to happen on draining

  28 avril 2017, par Muhammad Faiz

  avcodec/pthread_frame, decode : allow errors to happen on draining
  So, all frames and errors are correctly reported in order.
  
  Also limit the numbers of error during draining to prevent infinite loop.
  This fix fate failure with THREADS>=4 :
  
    make fate-h264-attachment-631 THREADS=4
  
  This also reverts a755b725ec1d657609c8bd726ce37e7cf193d03f.
  Suggested-by : wm4, Ronald S. Bultje, Marton Balint
  
  Reviewed-by : w4 <nfxjfg@googlemail.com>
  
  Reviewed-by : Ronald S. Bultje <rsbultje@gmail.com>
  
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Muhammad Faiz <mfcc64@gmail.com>
  

  • [DH] libavcodec/decode.c
  • [DH] libavcodec/internal.h
  • [DH] libavcodec/pthread_frame.c

• fftools/ffmpeg : disable and deprecate -qphist

  28 mars 2023, par Anton Khirnov

  fftools/ffmpeg : disable and deprecate -qphist
  This option adds a long string of numbers to the progress line, where
  
  i-th number contains the base-2 logarithm of the number of times a frame
  
  with this QP value was seen by print_report().
  There are multiple problems with this feature :
  
  * despite this existing since 2005, web search shows no indication
  
    that it was ever useful for any meaningful purpose ;
  
  * the format of what is printed is entirely undocumented, one has to
  
    find it out from the source code ;
  
  * QP values above 31 are silently ignored ;
  
  * it only works with one video stream ;
  
  * as it relies on global state, it is in conflict with ongoing
  
    architectural changes.
  It then seems that the nontrivial cost of maintaining this option is not
  
  worth its negligible (or possibly negative - since it pollutes the
  
  already large option space) value.
  
  Users who really need similar functionality can also implement it
  
  themselves using -vstats.
  

  • [DH] doc/ffmpeg.texi
  • [DH] fftools/ffmpeg.c
  • [DH] fftools/ffmpeg.h
  • [DH] fftools/ffmpeg_opt.c