[FFmpeg-user] [Discussion] FPGA vs GPU for Live Transcoding

[Dennis Mungai]

On Sun, 1 Mar 2020, 17:46 Christian David, <davidchristia at gmail.com> wrote:

> Em dom, 1 de mar de 2020 10:37, Mark Filipak <
> markfilipak.windows+ffmpeg at gmail.com> escreveu:
>
> > On 03/01/2020 06:24 AM, Christian David wrote:
> > > Em dom., 1 de mar. de 2020 às 06:45, Mark Filipak <
> > > markfilipak.windows+ffmpeg at gmail.com> escreveu:
> > >
> > >> On 03/01/2020 04:29 AM, Carl Eugen Hoyos wrote:
> > >>>> Am 01.03.2020 um 07:47 schrieb Christian David <
> > davidchristia at gmail.com
> > >>> :
> > >>>>
> > >>>> Hi everyone, i was reading about FPGA solutions against traditional
> > >>>> solutions with GPUs (Nvidia at most times) for live video
> > transcoding..
> > >>>
> > >>> I was under the impression that all GPU encoding happens on FPGA: Am
> I
> > >> wrong?
> > >>
> > >> FPGA? Field programmable gate array?
> > >
> > > Yes,  for example for nvidia hardware acceleration we use one of GPU
> > cards
> > > from nvidia to do all the job (encoding/decoding), so we can also use
> CPU
> > > solutions with an accelerator card (FPGA)...
> >
> > Ah! Okay, I get it. You're calling the Alveo U200 board an FPGA because
> > it has an XCU200 FPGA mounted on it. That's technically incorrect, and
> > it will confuse hardware geeks like me, but I can live with it.
> >
> So give-me a light about this, your opinion.
>

Here's a bit of a primer on the same:

FPGA's and their runtimes are *very* proprietary in nature. It will take
years, at the very least, months, to see vendors such as Xilinx push
patches to a project such as FFmpeg for FPGA off-load, and even these that
do tend to frequently violate licensing terms (Amazon wins the big ticket
here). Adopting them for use as general purpose GPUs have evolved over the
same time will be a considerable effort.

Both hardware accelerated encoding solutions impemented on GPUs and FPGA
solutions alike are strikingly similar in design (as Carl pointed out) as
they do require (an implementation of a bitstream or it's equivalent) on a
DSP block. And that black box model of DSPs will also involve a lot of
vendor cooperation with projects such as FFmpeg to better utilize encoder
specific parameters and their tunability. Look around and you'll see how
Intel, as an example, has multiple employees pushing code to FFmpeg which
has vastly improved both QuickSync and VAAPI subsystems in just under two
years. Then you'll realize that if you're after. With that said, can you
rely on a FPGA vendor to put in the same kind of dedication and resources
to such enablement? If so, then FPGAs may stand a chance against the likes
of NVIDIA and Intel in that respect.

So far, what we've seen FPGA vendors do (specifically NGCodec) is to fuel
the flames of vendor locking to specific cloud technologies, ie AWS where
that product is openly touted and well supported without an obvious way of
doing it on premise (unless you enter into some sort of NDA with AWS and
NGCodec).

Either way, when it comes to these hardware accelerated implementations,
there's always a compromise to be made, and that falls on you, the client,
to decide on what works for you: A self hosted implementation (using
supported commodity or prosumer GPUs on infrastructure you have control
over) OR cloud based services such as NGCodec on AWS (subject to terms of
provision by third parties and recurrent licensing fees, etc).

Take a pick.