4 ms·

I've always thought FPGAs would be perfect to have hardware backed video decoding/encoding that could adapt to new codecs (like vp9) while also being updatable

I've always thought FPGAs would be perfect to have hardware backed video decoding/encoding that could adapt to new codecs (like vp9) while also being updatable for new performance improving discoveries. It also seemed like it would go well with a generic radio subsystem, so you could compile hardware support for new wireless standards that come out after your hardware did (essentially an fpga sdr). It seems like there could be lots of uses for being able to on demand enable hardware acceleration for certain tasks a program might need lots of.

jakeinspace 8y ago
I spent this summer doing exactly that for an internship. I set up a xilinx Zynq chip to run a basic video capture and streaming program (based on gstreamer), with the encoding portion handled by the fpga. This chip has a baked-in encoder supporting AVC and HEVC, but I suppose you could implement or buy your own IP block for other codecs. Xilinx makes multiple boards based off the same chip with support for video codecs and SDR.
mirashii 8y ago
FPGAs are indeed commonly used for SDR as well. Ettus has a range of USRPs with FPGAs on-board, and you can find readily available IP cores for anything from Bluetooth to DVB-S.
- Firerouge 8y ago
  That's partially where I got my inspiration. Seems like it integrated properly it could be a great component in a general purpose PC to future proof it against changing needs and requirements
zymhan 8y ago
Experience seems to show that standardizing on a codec or instruction type is the most likely path. Apple iDevices have had hardware transcoding for video for a couple releases now. You really can't just have an FPGA that you recompile to a different architecture within a split second. They typically require compiling, downloading, and testing the the architecture you're deploying. Until someone comes up with a much faster to deploy FPGA, you'll likely not see enough efficiency gains in having a codec-specific processor given the time it takes to reconfigure the FPGA for each codec.
- Firerouge 8y ago
  But isn't that a one time expense? When a program installs it could compile the hardware acceleration for your platform and test it. Can you not, rather rapidly, directly activate that compiled designs every time you launch the program in the future? In that same vein, one time compilation for a hardware video decoder when a new codecs is released, and simply loading it when you want to play a video, seems infinitely easier than upgrading your desktop GPU or CPU to one that supports hardware acceleration for a new codec.
  - ibeckermayer 8y ago
    You're correct that it's a one time expense, you can quickly load the bit file onto the FPGA (< 2 seconds) once it's been generated.

jakeinspace 8y ago

I spent this summer doing exactly that for an internship. I set up a xilinx Zynq chip to run a basic video capture and streaming program (based on gstreamer), with the encoding portion handled by the fpga. This chip has a baked-in encoder supporting AVC and HEVC, but I suppose you could implement or buy your own IP block for other codecs. Xilinx makes multiple boards based off the same chip with support for video codecs and SDR.

mirashii 8y ago

FPGAs are indeed commonly used for SDR as well. Ettus has a range of USRPs with FPGAs on-board, and you can find readily available IP cores for anything from Bluetooth to DVB-S.

Firerouge 8y ago
That's partially where I got my inspiration. Seems like it integrated properly it could be a great component in a general purpose PC to future proof it against changing needs and requirements

zymhan 8y ago

Experience seems to show that standardizing on a codec or instruction type is the most likely path. Apple iDevices have had hardware transcoding for video for a couple releases now. You really can't just have an FPGA that you recompile to a different architecture within a split second. They typically require compiling, downloading, and testing the the architecture you're deploying. Until someone comes up with a much faster to deploy FPGA, you'll likely not see enough efficiency gains in having a codec-specific processor given the time it takes to reconfigure the FPGA for each codec.

Firerouge 8y ago
But isn't that a one time expense? When a program installs it could compile the hardware acceleration for your platform and test it. Can you not, rather rapidly, directly activate that compiled designs every time you launch the program in the future? In that same vein, one time compilation for a hardware video decoder when a new codecs is released, and simply loading it when you want to play a video, seems infinitely easier than upgrading your desktop GPU or CPU to one that supports hardware acceleration for a new codec.
- ibeckermayer 8y ago
  You're correct that it's a one time expense, you can quickly load the bit file onto the FPGA (< 2 seconds) once it's been generated.