Comment on

pory@lemmy.world ⁨23⁩ ⁨hours⁩ ago

• obelisk_complex@piefed.ca ⁨20⁩ ⁨hours⁩ ago

  You know what? I think I can figure out a way to estimate final file size and display it to the user. It’ll only work if “Precision Mode” is off though - that uses “CRF” or “Constant Rate Factor” which basically tells the encoder “be efficient, but make the file as big as it needs to be to look good”. As a result there’s no way to tell how big the file will end up being - the encoder makes the decision on the fly.

  With “Precision Mode” off, HISTV has two gears:

  1. If your file is already small enough (at or below the target bitrate), it uses “CQP” or “Constant Quantisation Parameter” (the QP I/P numbers), which tells the encoder “Use this quality level for every frame, I don’t care how big the file ends up”. It’s fast and consistent - every frame gets the same treatment.
  2. If your file is too big, it switches to VBR (Variable Bit Rate), which tells the encoder “Stay around this target bitrate, spike up to the peak ceiling on complex scenes, but don’t go over”. It’s how the app actually shrinks files. You can estimate the output size with target mbps * seconds / 8 - so a 60-second clip at 4Mbps lands around 30MB. <- This is the maths I’m thinking about doing to display the estimate to the user.

  source
• LiveLM@lemmy.zip ⁨22⁩ ⁨hours⁩ ago

  As an inspiration for this, look into Two-Pass encoding

  source

  • obelisk_complex@piefed.ca ⁨20⁩ ⁨hours⁩ ago

    Fun fact - HISTV actually has two-pass encoding! Though, with enough system RAM you can actually look ahead far enough that you can get the benefits of two-pass in just a single pass. I have a bit about this in the README.md:

    Precision mode

    One checkbox for the best quality the app can produce. It picks the smartest encoding strategy based on how much RAM your system has:

    Your RAM	What it does
    16GB or more	Looks 250 frames ahead to plan bitrate (single pass)
    8-16GB	Looks 120 frames ahead to plan bitrate (single pass)
    Under 8GB	Scans the whole file first, then encodes (two passes)

    Two-pass only happens when precision mode is on AND the system has less than 8GB RAM AND the file would be CRF-encoded. Reason being, Precision Mode normally uses CRF with extended lookahead (120-250 frames depending on RAM). Lookahead buffers live in memory. On low-RAM systems that buffer would be too large, so the app falls back to two-pass instead and stores the analysis run in a tempfile on disk. To break down each one:

    • Pass 1: Runs ffmpeg with -pass 1 writing to a null output. ffmpeg analyses the entire file and writes a statistics log (the passlog file) describing the complexity of every scene. No actual video is produced - this pass is pure analysis.
    • Pass 2: Runs ffmpeg with -pass 2 using the statistics from pass 1. The encoder now knows what’s coming and can distribute bits intelligently across the whole file - spending more on complex scenes, less on simple ones - without needing a large lookahead buffer in RAM. After both passes complete, the passlog temp files are cleaned up.

    I went with this architecture to mitigate the biggest problem with two-pass encoding, when there’s enough system RAM to store the lookahead frames: the speed. The quality of single-pass with a 250-frame lookahead is equal to two-pass; 120-frame lookahead is just as fast, and still close enough in quality that it doesn’t really make a difference.

    source

    • LiveLM@lemmy.zip ⁨16⁩ ⁨hours⁩ ago

      Damn, I had no clue about this single-pass look ahead, all this time I’ve been doing two-pass for nothing 😵‍💫
      Thanks!

      source