11 ms·

FFmpeg libav tutorial – from basic to transmuxing, transcoding and more

142 points by dreampeppers99 7y ago

ngcc_hk 7y ago
It is really good tutorial. Just not aligned when the expectations about programming depth. Really good.
speps 7y ago
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?
- josteink 7y ago
  Not sure why you are being downvoted. I too assumed this was some minimalist from scratch C-project, not a guide to using ffmpeg.
- bluesign 7y ago
  Agreed "A minimalist encoder with libav" would be better
  - ailideex 7y ago
    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 7y ago
      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.
      - fps_doug 7y ago
        That's exactly what I expected. Now I'm really curious whether this is possible. Monsieur Bellard to the rescue please!
      - leetcrew 7y ago
        ignorant question: are h264 and h265 related in a way that would make this remotely possible?
        TD-Linux 7y ago
        Basically, no. Basic features like the transforms and loop filters are different. It would cause the result to rapidly differ after a few frames.
- spuz 7y ago
  For reference, just in case the title is changed, it is currently: "A Minimalist Encoder, Written in C, to Convert H264 to H265"
- dang 7y ago
  Sure, done now. You can get quicker responses on this by emailing us at hn@ycombinator.com. We don't come close to seeing everything posted to HN, and I only saw this randomly now.
manorwar8 7y ago
Great to see it here, simple and educative.
Already__Taken 7y ago
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 7y ago
  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 7y ago
    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.
    - anticensor 7y ago
      It has already been developed: Versatile Video Codec.
    - zeotroph 7y ago
      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.
    - llampx 7y ago
      Try decoding or encoding AV1. You'll want to upgrade to a 64-core Threadripper.
    - bipson 7y ago
      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).
doppel 7y ago
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 7y ago
  This is a fair point, making it a great example, and further supports the change in title to underscore that its using libav
CHsurfer 7y ago
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 7y ago
  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 7y ago
    No it didn't and it doesn't :)
pornel 7y ago
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 7y ago
  Would be interesting if that would be possible and if you could save some bytes with that.
rasz 7y ago
import encoder encoder(stuff) look, I wrote Minimalist Encoder!
- asymptotically2 7y ago
  How do I invest in your startup!?!?

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

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?

josteink 7y ago
Not sure why you are being downvoted. I too assumed this was some minimalist from scratch C-project, not a guide to using ffmpeg.
bluesign 7y ago
Agreed "A minimalist encoder with libav" would be better
- ailideex 7y ago
  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 7y ago
    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.
    - fps_doug 7y ago
      That's exactly what I expected. Now I'm really curious whether this is possible. Monsieur Bellard to the rescue please!
    - leetcrew 7y ago
      ignorant question: are h264 and h265 related in a way that would make this remotely possible?
      - TD-Linux 7y ago
        Basically, no. Basic features like the transforms and loop filters are different. It would cause the result to rapidly differ after a few frames.
spuz 7y ago
For reference, just in case the title is changed, it is currently: "A Minimalist Encoder, Written in C, to Convert H264 to H265"
dang 7y ago
Sure, done now. You can get quicker responses on this by emailing us at hn@ycombinator.com. We don't come close to seeing everything posted to HN, and I only saw this randomly now.

manorwar8 7y ago

Great to see it here, simple and educative.

Already__Taken 7y ago

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 7y ago
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 7y ago
  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.
  - anticensor 7y ago
    It has already been developed: Versatile Video Codec.
  - zeotroph 7y ago
    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.
  - llampx 7y ago
    Try decoding or encoding AV1. You'll want to upgrade to a 64-core Threadripper.
  - bipson 7y ago
    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).

doppel 7y ago

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 7y ago
This is a fair point, making it a great example, and further supports the change in title to underscore that its using libav

CHsurfer 7y ago

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 7y ago
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 7y ago
  No it didn't and it doesn't :)

pornel 7y ago

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 7y ago
Would be interesting if that would be possible and if you could save some bytes with that.

rasz 7y ago

import encoder encoder(stuff) look, I wrote Minimalist Encoder!

asymptotically2 7y ago
How do I invest in your startup!?!?