Recherche avancée

Sur d’autres sites (7463)

• Merge commit ’4a27a52a1f74016095b7aee1b4a422cf62217ade’

  29 mai 2013, par Michael Niedermayer

  Merge commit ’4a27a52a1f74016095b7aee1b4a422cf62217ade’
  * commit ’4a27a52a1f74016095b7aee1b4a422cf62217ade’ :
  
    fate : Don’t use files from SRC_PATH in the actual tests
  
    indeo4 : reuse context block VLC for band instead of defaulting
  Conflicts :
  
  	tests/Makefile
  Merged-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/indeo4.c
  • [DH] tests/Makefile
  • [DH] tests/fate/filter-audio.mak
  • [DH] tests/fate/filter-video.mak

• avcodec/h264_mp4toannexb : Prepend SPS/PPS to buffering period SEI

  1er août 2024, par Josh Allmann

  avcodec/h264_mp4toannexb : Prepend SPS/PPS to buffering period SEI
  Encoders may emit a buffering period SEI without a corresponding
  
  SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
  During Annex B conversion, this may result in the SPS/PPS being
  
  inserted *after* the buffering period SEI but before the IDR NAL.
  Since the buffering period SEI references the SPS, the SPS/PPS
  
  needs to come first.
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DH] libavcodec/bsf/h264_mp4toannexb.c
  • [DH] tests/ref/fate/h264-bsf-mp4toannexb
  • [DH] tests/ref/fate/h264_mp4toannexb_ticket2991
  • [DH] tests/ref/fate/segment-mp4-to-ts

• lavfi/delogo : use weighted interpolation

  26 juin 2013, par Jean Delvare

  lavfi/delogo : use weighted interpolation
  The original delogo algorithm interpolates both horizontally and
  
  vertically and uses the average to compute the resulting sample. This
  
  works reasonably well when the logo area is almost square. However
  
  when the logo area is significantly larger than high or higher than
  
  large, the result is largely suboptimal.
  The issue can be clearly seen by testing the delogo filter with a fake
  
  logo area that is 200 pixels large and 2 pixels high. Vertical
  
  interpolation gives a very good result in that case, horizontal
  
  interpolation gives a very bad result, and the overall result is poor,
  
  because both are given the same weight.
  Even when the logo is roughly square, the current algorithm gives poor
  
  results on the borders of the logo area, because it always gives
  
  horizontal and vertical interpolations an equal weight, and this is
  
  suboptimal on borders. For example, in the middle of the left hand
  
  side border of the logo, you want to trust the left known point much
  
  more than the right known point (which the current algorithm already
  
  does) but also much more than the top and bottom known points (which
  
  the current algorithm doesn’t do.)
  By properly weighting each known point when computing the value of
  
  each interpolated pixel, the visual result is much better, especially
  
  on borders and/or for high or large logo areas.
  The algorithm I implemented guarantees that the weight of each of the
  
  4 known points directly depends on its distance to the interpolated
  
  point. It is largely inspired from the original algorithm, the key
  
  difference being that it computes the relative weights globally
  
  instead of separating the vertical and horizontal interpolations and
  
  combining them afterward.
  Signed-off-by : Jean Delvare <khali@linux-fr.org>
  
  Signed-off-by : Stefano Sabatini <stefasab@gmail.com>
  

  • [DH] libavfilter/vf_delogo.c
  • [DH] tests/ref/fate/filter-delogo