View Full Version : Which video-encoder do you use most?
Forteen88
11th February 2020, 14:54
Which video-codec do you use most?
OBS! Your vote-choice is public.
Update: Oh, darn, I forgot to make an "Other"-option. But I don't think that people uses so many other video-codecs. And maybe I should've rather asked: "Which video-codec do you prefer?".
ChaosKing
11th February 2020, 15:25
I think you mean video codec and not encoder?
For me:
h265 = codec
x265 = encoder
Forteen88
11th February 2020, 15:54
I think you mean video codec and not encoder?
For me:
h265 = codec
x265 = encoderOh, yeah, I meant codec.
Thanks for correction.
Sharc
11th February 2020, 16:49
It would be informative to see figures for Hardware (GPU) and Software (CPU) codec usage:
H.264 (AVC) HW
H.264 (AVC) SW
H.265 (HEVC) HW
H.265 (HEVC) SW
Forteen88
11th February 2020, 17:03
It would be informative to see figures for Hardware (GPU) and Software (CPU) codec usage....True, that'd be interesting. I should've done that :P
Someone else, or I, have to do such a poll soon.
And I forgot to include AV1 codec.
StainlessS
11th February 2020, 18:30
Pretty much always H.264(SW)
feisty2
11th February 2020, 18:51
uncompressed fp32 binary
FranceBB
11th February 2020, 23:57
I voted for x265 but that's only based on my personal encodes I do at home for fun.
At work I mainly use:
- x262/ffmpeg MPEG-2 to encode files in SD at 50 Mbit/s 4:2:2 yv16 planar 8bit interlaced TFF 25i (IMX50)
- x264 to encode files in AVC-Intra 100 for HD/FULL HD 25i interlaced 4:2:2 10bit 100 Mbit/s or XAVC Intra Class 300 (500 Mbit/s 4:2:2 50fps progressive 10bit UHD files) or for official HD/FHD BD releases.
- x265 to encode official UHD BD releases.
- MJPEG2000 to encode DCP for official cinema releases (4:4:4 XYZ 12bit).
- DNxHQX 700 Mbit/s 12bit 4:2:2 UHD files as mezzanine.
I can't really say which one I use most other than saying that I don't often encode in Motion JPEG 2000 'cause we receive more external productions than what we can internally produce.
As a side note, I noticed that nobody voted for x262/MPEG-2, but please note that many TVs actually ask us to send them our files in XDCAM50, which basically is an MPEG-2 4:2:2 8bit 25i interlaced TFF FULL HD file 'cause many old video servers they use for playout actually support it. Unfortunately, even in 2020, MPEG-2 is still very much alive in broadcast...
kolak
12th February 2020, 12:50
Yep, a lot of broadcasters use XDCAM50. I think it's time to move on, but no one wants a change as it costs money. Broadcast is heavily outdated, its core still lives in 90s.
IPV TV is coming.
Blue_MiSfit
13th February 2020, 05:22
50 Mbps is quite tolerable for storage and NAS / SAN etc. The quality of XDCAM HD422 is quite good. It's VERY light on the CPU relative to anything else commonly in use, and the MXF container (as overly complex as it may be) allows for lots of nice things like a 436M VANC track to store synchronized metadata like captions / subtitles.
All of this means that a video server won't break a sweat recording, playing, or seeking, and have quality that's significantly better than what's finally going to air. You can stack many tracks in an NLE and not tax your storage or CPUs.
The vagaries of linear playout are truly a dreadful thing, especially dealing with older equipment and (most importantly) crufty software stacks that have been around for decades.
I'm astonished you're still making 576i IMX50, @FranceBB :D
FranceBB
13th February 2020, 05:48
I'm astonished you're still making 576i IMX50, @FranceBB :D
I know, the only reason is that we have two locations for out playout, one is main, the other one is for backup, which is also called "failover geo-backup". Whenever we air from the main location, everything is fine and the FULL HD file gets compressed and aired in FULL HD but also downscaled and converted to BT601 live by our encoders for our SD channels, however on the old rarely used geo-backup location there's pretty much everything that time has forgotten (i.e SD video servers for SD channels), so we're kinda forced to do that; we're probably never going to use that unless something catastrophic happens, but it's a "just in case".
Luckily relatively few years ago we finally managed to scrap the BetaCAM backup that some dinosaur- uhm I mean boss was still asking (he retired).
50 Mbps is quite tolerable for storage and NAS / SAN etc. The quality of XDCAM HD422 is quite good. It's VERY light on the CPU relative to anything else commonly in use, and the MXF container (as overly complex as it may be) allows for lots of nice things like a 436M VANC track to store synchronized metadata like captions / subtitles.
All of this means that a video server won't break a sweat recording, playing, or seeking, and have quality that's significantly better than what's finally going to air. You can stack many tracks in an NLE and not tax your storage or CPUs.
That's true; unfortunately linear channels - although most of the time they are encoded in H.264 10-14 Mbit/s - they are encoded "live" which means with a very short delay (something from 1 to 4 seconds) which leads to a not so good compression by the encoder and compared to the XDCAM50 original masterfile, they are still far worse. Of course live encoders can be tweaked to encode with maximum complexity and still retain the standard compatibility with our decoders, but that would lead to a 20 seconds delay caused by the encoder plus the whole physical air time to the satellite and back to Earth where viewers homes are which is not acceptable.
By the way, in the case of XDCAM, when I tested it against metrics (SSIM/PSNR) the thing it hit me (hard) the most when I encoded in H.264 for our on demand catalogue (offline / not-live encoding) was going from yv16 to yv12...
WorBry
14th February 2020, 07:46
The Canon XF-300, which records MPEG-2 4:2:2 (50Mbps) in MXF format, was, and still is, a very popular pro-line HD camcorder despite being 10 years old. B&H still stocks it:
https://www.bhphotovideo.com/c/product/684199-REG/Canon_4457B001_XF300_Professional_Camcorder.html
Forteen88
25th February 2020, 09:55
I must say that I'm surprised that so many members here uses AVC instead of HEVC.
Is it because AVC is better at retaining grain than HEVC is?
UPDATE: OK, thanks for the answers.
wonkey_monkey
25th February 2020, 10:53
Is it not more likely to be down to compatibility (my 10+ year old TV and my 5+ year old bluray player will only play h.264) and/or h.265 still being relatively new? It's still behind h.264 when it comes to general usage.
StainlessS
25th February 2020, 11:01
For myself, I dont use x265 simply because 'MX Player' [the best player] on Android, cannot seek in x265.
If I stop half way through a movie, and then try restart and seek to where I left off, it simply jumps back to beginning.
I dont like having to start back at beginning and watch first half again, just so as I can continue from there.
Not really an x265 problem, is still a Player problem, just checked a few days back when MX Player updated,
there are a lot of codec hardware/software options in MX-Player, it could be that I just aint tried the one that works.
EDIT: Like what Wonkey said.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.