News for hackers. Stuff that matters.
Re:FFmpeg libav tutorial – from basic to transmuxing, transc... by wwwhizz on Wednesday January 08, 2020 @06:39AM (#21990498)
Define better.

It's more CPU/GPU intensive, is not as widely supported, and there probably are more downsides.

Better quality at the same bitrate? For most use-cases: yes.

Re:FFmpeg libav tutorial – from basic to transmuxing, transc... by raxxorrax on Wednesday January 08, 2020 @06:59AM (#21990599)
Video codecs becoming more CPU intensive was actually a point when many casual users in my circle upgraded their notebooks.

These devices lasted 15 years in some some cases.

But videos not playing correctly was too much. Hardware vendors should develop H266.

Re:FFmpeg libav tutorial – from basic to transmuxing, transc... by bipson on Wednesday January 08, 2020 @08:23AM (#21991171)
h266 would be pointless for your problem.

There is something for you to understand here:

CPU/GPU "intensiveness" of a codec depends, and an increased computational overhead of newer codecs is always to be expected. The more efficient a coded (perceived "quality" per bit), the more complicated the computations of decoding need to be.

That's why most (consumer) CPUs built in the last decade have hardware decoding support (having a dedicated hardware implementation is always more efficient than running on the CPU) - and often even hardware encoding support.

The difference between h26x decoders must not need even that big (depending on the implementation). Widespread use of h264 killed most notebooks because of the missing hardware decoder.

h266 would with 99% guarantee never run more efficient on the same hardware than h265, unless we find some magic to achieve better-then-h264 encoding with MPEG1 complexity, and if this was easy, why was h265 not that.

And then there is AV1, which makes any newer MPEG-LA standard pointless anyway. You just need to wait for the respective widespread use of the hardware en-/decoders (and efficient encoder implementations I guess).

Re:FFmpeg libav tutorial – from basic to transmuxing, transc... by cellularmitosis on Wednesday January 08, 2020 @02:10PM (#21994666)
I parsed his statement the opposite way: “if hardware vendors want to drum up some business, they should develop h265+1, which will trigger the next round of laptop upgrades because it will be too cpu-intensive to work on devices which haven’t been upgraded in 15 years.”
Re:FFmpeg libav tutorial – from basic to transmuxing, transc... by josteink on Wednesday January 08, 2020 @09:17AM (#21991613)
> The more efficient a coded (perceived "quality" per bit), the more complicated the computations of decoding need to be.

That doesn’t have to be true. Only encoding is guaranteed to be more intensive.

What happens when more efficient encodings are developed though is usually not bitrate going down, but instead it is kept on the same rate to provide a higher image-resolution/quality for the resulting video.

And that means more pixels to render, and that means more work on the decoding end.

Re:FFmpeg libav tutorial – from basic to transmuxing, transc... by llampx on Wednesday January 08, 2020 @08:22AM (#21991162)
Try decoding or encoding AV1. You'll want to upgrade to a 64-core Threadripper.
Re:FFmpeg libav tutorial – from basic to transmuxing, transc... by zeotroph on Wednesday January 08, 2020 @07:26AM (#21990764)
The MPEG group has tried to squeeze too much out of their h264 and h265 codecs, so other interested parties developed the totally free (with a patent-MAD clause) AV1 codec. I guess there will be no widely supported h266.
Re:FFmpeg libav tutorial – from basic to transmuxing, transc... by anticensor on Wednesday January 08, 2020 @07:18AM (#21990706)
It has already been developed: Versatile Video Codec.
Re:FFmpeg libav tutorial – from basic to transmuxing, transc... by Hamuko on Wednesday January 08, 2020 @07:59AM (#21990978)
Last I heard, there's also encode times being ass.
Re:FFmpeg libav tutorial – from basic to transmuxing, transc... by dylan604 on Wednesday January 08, 2020 @09:22AM (#21991659)
MPEG2 used to require dedicated PCI-[eX] cards to offload the encoding from the CPU as the CPU couldn't do it fast enough to handle real-time. Now CPUs can do multi-times real speed. H.264 also had add-on cards to enable faster than CPU encodes. Now, CPUs handle. Currently, H.265 pushes CPUs to their limits. Tomorrow? H.265 will be fast, and the next H.2xx will be causing us to wait. Rinse. Lather. Repeat.