Hardware encoders vs software encoders - best bang for buck?

[zzuser]

Hi everybody! First post :)

I foresee a rather large need to transcode DVB TS streams to MPEG-4 in my future. Thus I have taken an interest in encoders. Currently the question on top of my mind is what equipment to buy for my encoding project.

I notice that a rather implessive list of MPEG-4 codecs has been gathered in http://forum.doom9.org/showthread.php?t=95939
Perhaps a few of you have hands on experience also with some of the hardware encoders.

My question is basically this:
- Does it make sense to invest in hardware encoders from a FPS / monetary unit perspective?

My usage scenario is this:
- Write DVB-T/S TS stream to disk
- Start transcode to MPEG-4 as soon as possible preferrably not having to wait till end of program
- Single pass transcodes with two output files at 1000 kbps and 2000 kbps

Output quality requirements are what a layman would consider good enough for normal TV viewing purposes. At 2000 kbps there is no problem hitting this quality requirement with either single pass Xvid or x264. At 1000 kbps x254 does OK, but Xvid is, although not bad, not quite what I have in mind. For 1000 kbps I'm considering downsampling to 352x288.

I'm doing single pass transcoding due to the fact that I need to move on to the next TS stream as soon as possible. I can always come back later and re-encode or do a second pass at a later time when there is nothing in the queue.

Given that woah! has been hitting 100 FPS with his E6600 rig I expect all hardware encoders being given a run for their money. On a tangential note, I'd love to hear from any Mac Pro owners on their FPS numbers.

Bonus question:
- Can I somehow speed up the generation of multirate encodes?

- Zed

[Pookie]

There are some developers here working on a distributed transcoder model. That means you'll be able to have several machines simultaneously doing the conversion.

So look around for some inexpensive PCs with fast processors, and an ethernet switch to connect them together.

Here are some barebone systems - just add a processor, hard drive, and RAM.

http://www.newegg.com/ProductSort/Category.asp?Category=3

Add another stick of RAM, and you could even get away with 3 of these machines for less than $1000.

http://www.newegg.com/Product/Product.asp?Item=N82E16883103026

[zzuser]

There are some developers here working on a distributed transcoder model. That means you'll be able to have several machines simultaneously doing the conversion.

Yes, I noticed ELDER in particular with interest. However since I'm doing batch conversion of TS streams I figured that I'd get off much easier by setting up one queue per core and let the transcodes run in parallel. Not only is this much easier to set up and manage, it also guarantees 100% CPU usage on all cores as it is not susceptible to the limitations to parallelism. As explained earlier, I do not care how fast a single transcode finishes as long as I manage to squeeze out every last FPS in agregate. Please do correct me if I am wrong in any of my assumptions.

So look around for some inexpensive PCs with fast processors, and an ethernet switch to connect them together.

This is quite the way I had in mind, unless somebody can convince me that a more centralized hardware accelerated solution is more cost efficient.

However, I'm not quite convinced that going by the way of bargain basement systems is the way to go to reach the highest FPS per monetary unit.

I think the situation is similar to the situation ones faces when buying hard disk drives. There is a certain price point under which you may save money in absolute terms, but the price per megabyte starts going up. If you are looking to build a large RAID system, you don't look at the bargain basement drives, but rather at mid to top range drives with a good price per megabyte ratio. You usually end up with something quite recent, but not necessarily with bleeding edge tech where the price per unit starts increasing.

I gather that the sweet spot in CPUs at the moment is somewhere in the Core 2 Duo lineup. Based on test results in this post (http://forum.doom9.org/showthread.php?p=895705#post895705) the E6300 comes out quite strong in the quest for FPS per monetary unit. I do not however know if the tests were performed with single thread encoders or not and how overclocking, should one choose to go that way, would change the picture. Another good question is whether dual CPU systems, such as the Mac Pro, can justify the price premium.

Regardless of your excellent links I was unable to find an apples to apples comparision between the proposed Sempron system and Misfit's nice low cost Core 2 Duo rig (http://forum.doom9.org/showthread.php?p=885305#post885305). So in a roundabout way I concluded that a Sempron 3300+ is roughly as fast as (http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2395&p=5) a Intel Celeron D 345, which in turn is slower than (http://www.ahinc.com/hhchips.htm) a Celeron D 356, which is half the speed (http://www.madshrimps.be/?action=getarticle&number=3&artpage=1805&articID=437) of a Intel Pentium D 805. Thus a AMD Sempron 3300+ system has roughly half the performace of a Intel Pentium D 805 system. Referring back to this (http://forum.doom9.org/showthread.php?p=895705#post895705) one can conclude that a Sempron 3300+ has about a third to a quarter of the performance of a E6300 CPU.

The conclusion is that since the Sempron system costs 55% of a Core 2 Duo system, but only delivers 25-33% of the performace, it is not a cost effective solution from a cost per FPS perspective. In favour of the Core 2 Duo setup are the lower power requirements and the fewer number of nodes to administer for any given performance level.

Please do correct me if my numbers are wrong.

Nevertheless, this comparison, however fascinating, does not bring us closer to the key issue in this thread:

Do software encoders outperform hardware encoders in a cost per FPS comparison?

- Zed

[jared1999]

This is a very interesting question. Having tested MPEG-4 ASP hardware encoders from Envivio and Mayah about a year ago, I would have to say 'No' if you factor in image quality. Quality was at that time worse than Xvid at about the same cpu and memory usage. I have no idea what the maximum fps of the hardware devices was, but they had no problem with SD content at 25/30 fps.

In my experience hardware encoders are (a lot) more expensive per fps, but provide benefits that software solutions rarely have, or simply cannot provide. For instance, hardware encoders have the potential to be more robust, providing better uptime. They also can guarantee you jitter free packet output on the NIC, which software solutions can't do at all. So it all comes down to what your customers wants or demands.
Having said that we've been mostly happy with the performance of our software solution so far, which has cost us approx. one tenth of the price of a hardware solution.

A bit about the pure stream transcoding solution I'm using; VLC receives a UDP multicast MPEG-2 TS stream and transcodes it to a MPEG-4 multicast stream (MPEG-4 ASP in TS in UDP). The reason a hardware transcoder would be preferable in this case is twofold. First of all, VLC has a number of bugs affecting the service, and is relatively unstable in the setup mentioned. Second, jitter-free packet output from the NIC.
If anyone knows a suitable hardware (or different software) encoder for this usage pattern (multicast in -> transcode -> multicast out), feel free to talk about it. :)

Sorry for sidetracking a bit.

[DewAsmara]

As my experience helping my friends in animation industries,
We never thought hardware encoding when talking about quality, just invest in more processor, RAM and of course big hardisk. But Hardware is only for them who don't have time to see the result. Well you have to compromise between time or quality, hope someday someone made processor that have hardware on board to work simultaneously with software. Like this morning, when I need to encode some movies in raw video encoding, my problem is just hardisk capacity, as my processor and RAM can do at any light speed :p But hardware encoding is great idea actually, I also from that kind who's install hardware mpeg card when last time only have 486 processor in my first PC.

[Pookie]

Any of the smaller animation companies are going to spend two years to come up with 90 seconds of final product for the client, in which case a hardware encoder would be overkill. I guess it depends on the company, but even the larger studios treat their multiple projects as though they are separate companies, and very little ever gets shared technology-wise.

As far as transcoding streams that are being served via a VLS or FFserver system, I suppose you'd have to eliminate as many bottlenecks as possible -

1) Pair bonding (or teaming your gigabit ethernet cards) in both the server and the client will ensure your bottleneck isn't coming from the network. That can be done on both Linux and Windows platforms, and you'll need a smart gigabit switch ($400-$500) to support the configuration.

http://www.cyberciti.biz/tips/linux-bond-or-team-multiple-network-interfaces-nic-into-single-interface.html

2) Jumbo Ethernet packets, where your chunk of data is being transmitted/received in 9K frames instead of the old skool 1.5K would also benefit network performance quite a bit. Downside, every machine on the same network segment has to be configured for Jumbo Frames.

3) The problem with bottlenecks is that the target always moves after you've fixed one - Create a huge network pipe with pair bonded Jumbo frame gigabit ethernet and all of a sudden your drive channels can't transfer the data fast enough, or the CPU begins choking. Its always something :)