Recherche avancée

Sur d’autres sites (5829)

• avfilter/vf_premultiply : use correct premultiplication formula

  22 juillet, par Niklas Haas

  avfilter/vf_premultiply : use correct premultiplication formula
  The previous formula was introduced without justification in 6e713841e8,
  
  and the only thing Paul had to say about it over IRC was that it was copied
  
  from an unspecified source on the internet.
  I decided to do some testing and came to the conclusion that this term not
  
  only produces "illegal" files, but also lowers PSNR score, over the naive
  
  implementation without this extra term.
  Here are the results of a round-trip test, using allrgb/allyuv (respectively)
  
  as the input, and fade=alpha=yes:n=256 to cycle through every possible alpha
  
  value, comparing the round-trip output against the input :
  Before patch :
  
    PSNR r:26.677431 g:26.677431 b:26.677431 a:inf average:27.926818 min:6.012093 max:55.400791
  
    PSNR y:26.677431 u:21.101981 v:21.101981 a:inf average:23.548981 min:9.013835 max:53.182303 (full)
  
    PSNR y:27.348055 u:21.101981 v:21.101981 a:inf average:23.625238 min:9.554991 max:45.652221 (limited)
  After patch :
  
    PSNR r:27.321996 g:27.321996 b:27.321996 a:inf average:28.571384 min:6.012093 max:52.424553
  
    PSNR y:27.321996 u:23.187879 v:23.187879 a:inf average:25.431773 min:9.013835 max:50.199232 (full)
  
    PSNR y:27.868544 u:23.187879 v:23.187879 a:inf average:25.515660 min:9.554991 max:45.078298 (limited)
  It's worth pointing out that previous version sometimes artificially inflates
  
  PSNR by producing values that are too high (i.e. RGB > A), such as for the
  
  input pair (R = 255, A = 2) which should give R = 2, but actually gives R = 3
  
  under the old logic.
  As a second evaluation without this shortcoming, here is a comparison against
  
  the reference value computed with a floating point format :
  Before patch :
  
    PSNR r:53.600599 g:53.957833 b:53.540948 a:inf average:54.945316 min:50.508901 max:inf (premul only)
  
    PSNR r:30.734183 g:30.734183 b:30.734183 a:inf average:31.983570 min:12.058264 max:inf (round-trip)
  After patch :
  
    PSNR r:61.751104 g:65.239091 b:61.339191 a:inf average:63.710714 min:55.441130 max:inf (premul only)
  
    PSNR r:32.611851 g:32.611851 b:32.611851 a:inf average:33.861238 min:12.058264 max:inf (round-trip)
  

  • [DH] libavfilter/vf_premultiply.c

• Mathematical formula to always center text along X and Y axis ffmpeg python ?

  18 février 2023, par Sixtus Anyanwu

  I am trying to center a text horizontally and vertically with ffmpeg python but I can't seem to get it right. The mid point shifts depending on the amount of characters in the text.

  


  How do I always center the text to the centre of the screen no matter the length of the text ?

  


  Here is my code.

  


  
v_width = 1080

v_height = 1633

def create_video():

    overlay1 = ffmpeg.input("sukuna.gif").filter("scale", 1080, -1, height = 1633 / 2)

    overlay2 = ffmpeg.input("akaza_long.mp4").filter("scale", 1080, -1, height = 1633 / 2 )

    (

    ffmpeg.input('letsgo.mp4')

    .overlay(overlay1)

    .overlay(overlay2, x = 0, y = v_height / 2)

    .drawtext(textfile = "char_names.txt", fontfile = "/storage/emulated/0/PyFiles/Helvetica-Bold.ttf", fontcolor = "yellow", bordercolor = "black", escape_text = True, start_number = 0, fontsize = "80", x = (v_width / 2) - 40, y = (v_height / 2) - 40, borderw = 4, line_spacing = 3)

    .output("newVideo.mp4")

    .run()

    )


  


  The - 40 is for adding some extra padding to the text.

  


  How do I go about this ?

  


  I want the below position always no matter how big or amount of characters in the text.
Centred text

  


  Already tried adding a couple of offset to the text but once the text gets longer, it loses its alignment.

  


• Best logical formula to determine perceptual / "experienced" quality of a video, given resolution / fps and bitrate ?

  20 mars 2023, par JamesK

  I am looking for a formula that can provide me with a relatively decent approximation of a Video's playback quality that can be calculated based off of four metrics : width, height, fps, and bitrate (bits/sec). Alternatively, I can also use FFMPEG or similar tools to calculate a Video's playback quality, if any of those tools provide something like what I am looking for here.

  


  An example of what a Video might look like in my problem is as follows :

  


  interface Video {
  /** The width of the Video (in pixels). */
  width: number
  /** The height of the Video (in pixels). */
  height: number
  /** The frame rate of the Video (frames per second). */
  fps: number
  /** The bitrate of the video, in bits per second (e.g. 5_000_000 = 5Mbit/sec) */
  bitrate: number
}


  


  I came up with the following function to compute the average amount of bits available for any given pixel per second :

  


  const computeVideoQualityScalar = (video: Video): number => {
  // The amount of pixels pushed to the display, per frame.
  const pixelsPerFrame = video.width * video.height
  
  // The amount of pixels pushed to the display, per second.
  const pixelsPerSecond = pixelsPerFrame * video.fps
  
  // The average amount of bits used by each pixel, each second,
  // to convey all data relevant to that pixel (e.g. color data, etc)
  const bitsPerPixelPerSecond = video.bitrate / pixelsPerSecond
  
  return bitsPerPixelPerSecond
}


  


  While my formula does do a good job of providing a more-or-less "standardized" assessment of mathematical quality for any given video, it falls short when I try to use it to compare videos of different resolutions to one another. For example, a 1080p60fps video with a bitrate of 10Mbit/sec has a greater visual fidelity (at least, subjectively speaking, to my eyes) than a 720p30fps video with a bitrate of 9Mbit/sec, but my formula would score the 720p30fps video significantly higher than the 1080p60fps video because the 720p video has more bits available per pixel per second than the 1080p video.

  


  I am struggling to come up with ideas as to how to either come up with a different way to calculate the "subjective video quality" for a given video, or extend upon my existing idea here.