Commercial hardware vs software encoders

[cogman]

So, I just got out of a meeting talking about cable tv and broadcasting, and my ears perked when I heard mention of Avail and their current offerings. On of the things the rep said is "Hardware encoders do a much better job then the current software offering of avail"

He mentioned a model number that I didn't jot down (sorry) and said it gave a much better picture quality.

I was just wondering what someone who is more experienced in this field thinks about this, and if they care to refute/confirm it. How does x264 really compare to commercial grade broadcasting hardware.

[Atak_Snajpera]

I was just wondering what someone who is more experienced in this field thinks about this, and if they care to refute/confirm it. How does x264 really compare to commercial grade broadcasting hardware.
at the moment in terms of quality x264 destroys everything :) This "blind test" will prove that http://forum.doom9.org/showthread.php?t=154430

[cogman]

at the moment in terms of quality x264 destroys everything :) This "blind test" will prove that http://forum.doom9.org/showthread.php?t=154430

All those encoders are software encoders (Even the GPU stuff). I'm talking about full blown, broadcasting system encoders. I'm sorry that I don't have any good examples of what I'm talking about, my googling skills aren't up to par (I'm pretty sure Dark knows what I'm talking about as it is his companies direct competitors)

[Dark Shikari]

There are only three types of commercial hardware encoders:

1. Utter garbage, cheap (the kind you can get in USB sticks).
2. Slightly less garbage, expensive (many broadcast encoders).
3. Pretty decent, absurdly expensive (the best broadcast encoders).

Ateme produces some of the best in 3). They're still well behind x264 though. They have some advantages though: significantly better-optimized interlaced compression and an extremely accurate VBV lookahead (they literally just run two encoders, one in front of the other). They also use less power than your standard x86 box.

Overall x264 probably still wins, and given the price it's no wonder that companies like Avail Media pick the cheaper option, but for many cases where price is irrelevant and a company wants a straightforward well-supported box to stick in their rack, such top-end hardware encoders are not a bad option.

Last I recall Ateme's software encoder, on max settings, is designed to give similar results to the hardware encoder, so it should be expected that the results from that encode are representative of the state of the art (in that encoder comparison).

[CruNcher]

Ehh aren't Kyrion HD Hardware Encoders using an entirely different Core Engine optimized for Quality and in the KFE2 Software Encoder it uses one optimized more for Speed ?
Now cogman if you have the money to spare get http://www.ateme.com/products.php5?Arg=71 and tell us the difference :)
I know for sure that Ateme isn't showing everything they got and they don't participate @ the MSU test anymore, so yeah it's hard to keep track of them but i wouldn't trust that their Kyrion Software Encoder is the latest Quality they can provide (i can tell you i guess without braking NDA as all those thinks are released by now that 2 years ago their encoder was far far ahead of x264 (MBAFF,10 bit (started), lookahead, speedcontrol (before the avail patch) where already fully implemented and they experimented with Blu-Ray support, they also had their own CRF mode which rarely someone else had @ that time) now add more years to that and you get the math where they must be ;) )

[Dark Shikari]

by now that 1 year ago their encoder was far far ahead of x264 (MBAFF,10 bit, lookahead, speedcontrol (before the avail patch) where already fully implemented and they experimented with Blu-Ray support, they also had their own CRF mode which rarely someone else had @ that time) now add more years to that and you get the math where they must be now ;) )I tested it back then and it was still quite a bit worse than x264, even on interlaced content. This isn't surprising because they still don't have psy-RD. Furthermore, I have the output of their 2.2 encoder on the parkjoy test and it isn't even competitive with Mainconcept 8.5, let alone x264.

Also, x264 had lookahead a year ago, it had speedcontrol a year ago, and it had CRF mode a year ago.

[CruNcher]

sorry 2008 x264 was in the r85x release stage
They also where ahead with full VBV compliance before x264 slowly got that under control, though i guess their VBV is still more advanced as they designed everything from the ground up on it, x264 as we know implemented it later on with a lot of problems in the way ;).
Yeah Mainconcept got better no doubt but Ateme was much better then them back then also, though Mainconcept never really concentrated on Broadcast as much as Ateme did and does :P

I have the output of their 2.2 encoder on the parkjoy test and it isn't even competitive with Mainconcept 8.5, let alone x264. <- That Encode Result would be from October 2009 we have May 2010 please those are 7 month difference (and who the heck knows how much time it takes before their R&D Encoder becomes the actual product encoder) if @ all test x264 from October 2009 and Mainconcept Encoder in the same timespace against Atemes visual result and not something so far away in Release time :( that's really unfair or at least mention it if you release the test.

I don't think that is a fair compare

Ateme 2.2.2 = October 2009
Mainconcept 8.5 = February 2010
X264 = May 2010

So the least you can do is mention this and maybe also what it means to compare 4-7 month development time away R&D Encoder against each other.

[cogman]

Thanks for the responses thus far.

I have to say, I had a hard time believing that x264 was vastly inferior (in quality) compared to some other encoder, be it hardware or software.

Couple that to the fact that the guy was a hardware vendor, and you'll understand my mistrust over his statement.

[Dark Shikari]

Thanks for the responses thus far.

I have to say, I had a hard time believing that x264 was vastly inferior (in quality) compared to some other encoder, be it hardware or software.

Couple that to the fact that the guy was a hardware vendor, and you'll understand my mistrust over his statement.Never trust the word of anyone who stands to make money over you choosing his product.

Hardware encoders are generally a lot worse simply due to the restrictions they have; they can't implement as efficiently a lot of the kinds of algorithms that one can implement on a CPU, since (at least for FPGA/ASIC solutions) they rely heavily on massively parallel processing to make up for low clock speeds. The other practical problem is that development is vastly slower; obviously you can't just change a few lines of code to update a hardware encoder with a new algorithm.

This doesn't mean they're bad; they just solve a different problem.

[RunningSkittle]

...
I don't think that is a fair compare
... compare 4-7 month development time away R&D Encoder against each other.
then dark_shikari has to compare what x264 will have in 4-7 months ;)

I think its fair to compare whats available now

[jpsdr]

I always find hard to believe the simple fact that a one pass encoding may beat a 2 pass encoding, wich have acces to data of the overall footage, and so have the possibility to optimise to acheave the best qualilty, for a same size final ouput result.
In fact, i'll never believe this...

[Blue_MiSfit]

Indeed. Two different goals. I'm quite impressed with the quality of some high end hardware encoders, but x264 almost always wins, especially in unconstrained VBR.

Not to say that x264's VBV, low latency, CBR, or NAL-HRD are anything less than utterly impressive :)

~MiSfit

[kolak]

Indeed. Two different goals. I'm quite impressed with the quality of some high end hardware encoders, but x264 almost always wins, especially in unconstrained VBR.

Not to say that x264's VBV, low latency, CBR, or NAL-HRD are anything less than utterly impressive :)

~MiSfit

x264 is the most expensive encoder ever created (in some way) :)
If you would count all time spent by all doom9 (and not only) community and all time spent by developers and charge only 1$ per hour it would cost millions $ :)
I'm not surprised that x264 is so good at all.

Andrew

[TEB]

One have to consider that most HW encoders are aimed for the broadcasting marked, READ: RealTime, not offline.
I do look foreward to x264 been able to part of a realtime encoder chain. I belive Keiran is working on a TS muxer aimed for this purpose amongst others..

TE

[Blue_MiSfit]

x264 can already do fantastic realtime encoding for capture / live streaming. A robust ts muxer would be fantastic :)

~MiSfit

[kempodragon]

I'm curious to know if it's possible to make an encoder chip with x264 burned in. Imagine a HD video camera that encodes directly to x264, using just I-frames for later editing and records directly to a hard drive or memory card. The Panasonic HDC-TM700 records full HD at 60p at 28 Mbits with a version of H.264 and I'd love to see how x264 could fare in the same situation. Surely someone has tried to burn a chip, even if it's only a proof of concept?

[Atak_Snajpera]

It would be easy if your camcorder had multi-core x86 cpu with at least 1GB ram and some Linux/Windows on board :)

[LoRd_MuldeR]

I'm curious to know if it's possible to make an encoder chip with x264 burned in. Imagine a HD video camera that encodes directly to x264, using just I-frames for later editing and records directly to a hard drive or memory card. The Panasonic HDC-TM700 records full HD at 60p at 28 Mbits with a version of H.264 and I'd love to see how x264 could fare in the same situation. Surely someone has tried to burn a chip, even if it's only a proof of concept?

x264 is so insanely optimized for CPU's (especially x86/amd64 with SIMD extensions) that it would be hard to port that on a DSP or FPGA chip. Also, those "embedded" encoder chips rely heavily on parallelization (similar to GPU's), so some inherently sequential algorithms simply won't fit. Therefore you'd have to re-write parts of x264, probably sacrificing some (much?) of the quality...

There is a reason why all the "hardware" and "GPU accelerated" encoders suck. At least those that are available to consumers and don't cost $10,000 ;)

It would be easy if your camcorder had multi-core x86 cpu with at least 1GB ram and some Linux/Windows on board :)

...and one hell of a battery that delivers the power you'll need for such a setup :p

[Biggiesized]

Maybe you could build an external tape deck of sorts. You could spit out an HD-SDI signal from your camcorder and do real-time x264 intra-frame encoding.

[Blue_MiSfit]

And then you're a digital rapids box. Hint, it works great already ;)