FFmpeg libav tutorial – from basic to transmuxing, transcoding and more(github.com)
github.com
FFmpeg libav tutorial – from basic to transmuxing, transcoding and more
https://github.com/leandromoreira/ffmpeg-libav-tutorial#chapter-3---transcoding
36 comments
import encoder
encoder(stuff)
How do I invest in your startup!?!?
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?
First, both H.264 and H.265 are standards only. They are not encoders. And their reference encoder are not meant to be used for anything other than testing Encoding Models, which is different to AV1.
So you need to talk about their respective encoder ( e.g x264 and x265 ) and bitrate. For example, if you are doing 2K to 4K encoding in Sub 3Mbps. x265 will win hands down. Especially for Anime.
Things started to get blurry once you are doing doing Higher Bitrate per Pixel. For Example. 4Mbps for 720 or 1080P, a year ago ( or may be closer to 2 years now ) there are titles that x264 will still win against x265. The same goes for 10+Mbps range for 4K. But x265 has improved a lot, so I am not sure if that is still the case.
And Beamr 5 [1] is a H.265 encoder that does wonder at low bitrate. In short, encoder matter.
[1] https://beamr.com/vanguard-by-beamr-content-adaptive-hevc-co...
So you need to talk about their respective encoder ( e.g x264 and x265 ) and bitrate. For example, if you are doing 2K to 4K encoding in Sub 3Mbps. x265 will win hands down. Especially for Anime.
Things started to get blurry once you are doing doing Higher Bitrate per Pixel. For Example. 4Mbps for 720 or 1080P, a year ago ( or may be closer to 2 years now ) there are titles that x264 will still win against x265. The same goes for 10+Mbps range for 4K. But x265 has improved a lot, so I am not sure if that is still the case.
And Beamr 5 [1] is a H.265 encoder that does wonder at low bitrate. In short, encoder matter.
[1] https://beamr.com/vanguard-by-beamr-content-adaptive-hevc-co...
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.
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.
Last I heard, there's also encode times being ass.
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.
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.
These devices lasted 15 years in some some cases.
But videos not playing correctly was too much. Hardware vendors should develop H266.
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).
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).
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.”
> 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.
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.
Try decoding or encoding AV1. You'll want to upgrade to a 64-core Threadripper.
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.
It has already been developed: Versatile Video Codec.
it will be better the day it is supported in most browsers. We are SO FAR away from that.
https://caniuse.com/#feat=hevc
https://caniuse.com/#feat=hevc
See also the open/royalty-free AV1:
* https://caniuse.com/#search=av1
* https://en.wikipedia.org/wiki/AV1
There also seems to be VVC?
* https://en.wikipedia.org/wiki/Versatile_Video_Coding
* https://caniuse.com/#search=av1
* https://en.wikipedia.org/wiki/AV1
There also seems to be VVC?
* https://en.wikipedia.org/wiki/Versatile_Video_Coding
If you haven't switched yet, maybe just wait for AV1.
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?
Sure, done now.
You can get quicker responses on this by emailing us at [email protected]. We don't come close to seeing everything posted to HN, and I only saw this randomly now.
You can get quicker responses on this by emailing us at [email protected]. We don't come close to seeing everything posted to HN, and I only saw this randomly now.
Not sure why you are being downvoted.
I too assumed this was some minimalist from scratch C-project, not a guide to using ffmpeg.
I too assumed this was some minimalist from scratch C-project, not a guide to using ffmpeg.
Agreed "A minimalist encoder with libav" would be better
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.
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.
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.
That's exactly what I expected. Now I'm really curious whether this is possible.
Monsieur Bellard to the rescue please!
Monsieur Bellard to the rescue please!
For reference, just in case the title is changed, it is currently: "A Minimalist Encoder, Written in C, to Convert H264 to H265"
char* convert(char* str, char find, char replace){
convert("H264", "4", "5")
char *current_pos = strchr(str,find);
while (current_pos){
*current_pos = replace;
current_pos = strchr(current_pos,find);
}
return str;
convert("H264", "4", "5")
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.
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.
No it didn't and it doesn't :)
Great to see it here, simple and educative.
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.
This is a fair point, making it a great example, and further supports the change in title to underscore that its using libav