
FFmpeg libav tutorial – from basic to transmuxing, transcoding and more - dreampeppers99
https://github.com/leandromoreira/ffmpeg-libav-tutorial#chapter-3---transcoding
======
pornel
For a second I hoped it'd be an actual low-encoder that does a clever lossless
transcoding by treating H.264 data as a subset of H.265 data. But this just
feeds frames to ffmpeg.

~~~
legulere
Would be interesting if that would be possible and if you could save some
bytes with that.

------
rasz

        import encoder
         encoder(stuff)
    

look, I wrote Minimalist Encoder!

~~~
asymptotically2
How do I invest in your startup!?!?

------
doppel
Having done something similar to transcode h264 to fragment mp4, there are a
ton of pitfalls, weird settings and flags that need to be set to get a
"correct" output that will play in most players. FFmpeg/libav provides a ton
of functionality, but sometimes it's like reading javadocs, where you get the
interface but have no idea of what to put in.

~~~
paulsutter
This is a fair point, making it a great example, and further supports the
change in title to underscore that its using libav

------
Already__Taken
Has h265 got to the point where it's always in every case better than h264? I
don't need to think about it anymore?

~~~
wwwhizz
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.

~~~
raxxorrax
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.

~~~
bipson
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).

~~~
cellularmitosis
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.”

------
ngcc_hk
It is really good tutorial. Just not aligned when the expectations about
programming depth. Really good.

------
speps
Interesting tutorial on libav for sure but the submission title is definitely
a bit of a stretch given that it's just a libav tutorial and you can probably
do the same with ffmpeg directly quite easily. Can we change the title please?

~~~
bluesign
Agreed "A minimalist encoder with libav" would be better

~~~
ailideex
It quite literally is not an encoder - title should be something like "how to
use libav to convert H264 to H265" \- libav is the only thing doing encoding
here.

~~~
userbinator
I thought it would be about finding a way to losslessly transform a H264
bitstream to a H265 one, and writing a simple application to do it. That would
be a _very_ interesting article if it was possible.

Even the title of the page itself is (currently) "FFmpeg libav tutorial -
learn how media works from basic to transmuxing, transcoding and more" which
is far more accurate.

~~~
leetcrew
ignorant question: are h264 and h265 related in a way that would make this
remotely possible?

~~~
TD-Linux
Basically, no. Basic features like the transforms and loop filters are
different. It would cause the result to rapidly differ after a few frames.

------
manorwar8
Great to see it here, simple and educative.

------
CHsurfer
char* convert(char* str, char find, char replace){

    
    
        char *current_pos = strchr(str,find);
    
        while (current_pos){
    
            *current_pos = replace;
    
            current_pos = strchr(current_pos,find);
    
        }
    
        return str;
    

}

convert("H264", "4", "5")

~~~
skocznymroczny
Here's an optimized version:

char* convert(char* str) { str[3] = "5"; return str; }

I tried it with your testcase and it worked, so it passes 100% of the tests
I've ran.

~~~
ithinkso
No it didn't and it doesn't :)

