Thread

Loading the complete thread in the background. This saved snapshot is available now. Refresh

1. antisthenes · 1790691244 · focus · HN ↗

   I'll save everyone the time:

   You gain ~0.7 VMAF score (both above 90) and save 33% bandwidth at the cost of 3.2x longer encoding for (presumably) some set of 1080p clips used in testing.

   1. NooneAtAll3 · 1790695281 · focus · HN ↗

      what about decoding speed?

      just how much worse will it be for my old CPU?

      1. ddorian43 · 1790696455 · focus · HN ↗

         Should be the same?

         1. MaxBarraclough · 1790702913 · focus · HN ↗

            I don't know that much about video codecs, could decoding performance improve, given the reduced input size?

            1. ZeroGravitas · 1790704219 · focus · HN ↗

               Decoding speed can be affected by encoding choices. Meta and others have taken advantage of this to specifically target low end phone software decode.

               I believe it's basically about scoring decode operations on both quality and decode speed impact to optimise both goals at once.

               1. MaxBarraclough · 1790707618 · focus · HN ↗

                  Interesting, thanks.
            2. ddorian43 · 1790704383 · focus · HN ↗

               Doubt. Check your igpu or gpu should have dedicated hardware decoder for h264.
2. dylan604 · 1790693327 · focus · HN ↗

   It's been a long time since I've had to worry about encoding parameters, but even these settings feel like a set it and forget it compared to what we used to do in the past. Comparing encoding for streaming vs shiny round discs is so different. We would do scene by scene encodes with a minimum of 2-passes allowing for even more when necessary. We were strict on controlling the VBV but these formats had more bandwidth than streaming and were not susceptible to congestion and buffering issues. The video was even sent to QA to look for any kind of issues with the encoding. I doubt anybody looks at the best quality of the ladder let alone all of the variations before it reaches the users.
3. netsharc · 1790693564 · focus · HN ↗

   Gotta love an article about video compression where the top image is a blurry downscaled-and-then-upscaled image, that's not even clickable to zoom.

   Yes, if you scroll down the image is there again, still a bit blurry (so much winning), but clickable to embiggen. Your CMS is giving everyone a terrible first impression!

4. IOT_Apprentice · 1790700129 · focus · HN ↗

   Why not use x265?

   1. thunderfork · 1790702622 · focus · HN ↗

      Some clients only take H264, depends on what you're delivering to. Often for web media you end up having to serve [h264, h265, av1], which is a real pain
   2. slimscsi · 1790702807 · focus · HN ↗

      Often the increased encoding cost does pay for the reduced bandwidth cost. And that assumes you can navigate and afford the HEVC license.
   3. Insimwytim · 1790714573 · focus · HN ↗

      Heavier on CPU during playback
5. aand16 · 1790726026 · focus · HN ↗

   I thought VMAF was a bad metric for perceived video quality.

   CVVDP is best and SSIMULACRA2 and Butteraugli pretty good.

Unofficial Hacker News client; not affiliated with Y Combinator.