upvote

points

by tgtweak17 hours ago |
comments
upvoteby drmpeg14 hours ago|
next
[-]
Using multiple CPUs for encoding goes way back. The early (1994) C-Cube MPEG-1 and MPEG-2 real-time encoders for DirecTV were built with 8 chips running in parallel (out of necessity since they were only 60 MHz processors) to encode 704x480. Each chip encoded a slice of the image and an auxiliary bus was used to send reconstruction video between chips so that motion vectors could cross chip image boundaries.

Here's a picture of the VME bus development board. It was a two board sandwich to support 10 chips in parallel (only one board pictured).

https://www.w6rz.net/scorpio.jpg

The first real-time HDTV encoders for terrestrial digital television (ATSC) were built by Harris using an IBM encoder chip. It took 6 chips to encode 1920x1080. The IBM chips didn't have an auxiliary bus, so you could see motion vectors limited to chip image boundaries (in this case, 6 tiles arranged like so).

  -------------------------
  |       |       |       |
  |   1   |   2   |   3   |
  |       |       |       |
  -------------------------
  |       |       |       |
  |   4   |   5   |   6   |
  |       |       |       |
  -------------------------
reply
upvoteby tgtweak13 hours ago|
parent|
[-]
Yeah at this time intel was just releasing their quick sync tech and a few vendors were putting 4 intel cpus on a pcie board and using it for video encoding! Matrox also had a considerable piece of this business doing video compression and editing/compositing using bespoke processors and boards.

Despite being more "power efficient" - both nvidia and intel's hardware solutions left a lot to be desired in terms of final quality for the same bitrate, compared to x264 that seemed to just put out substantially better quality video for the same bitrate even at the same h264 profile levels. There are still lots of x264 design elements, some even verbatim ported, into modern av1 and hevc encoders.

reply
upvoteby rufo6 hours ago|
parent|
next
[-]
As someone doing a lot of DVD transcoding at the time, I remember being excited for Quick Sync on my new Sandy Bridge build - only to find that, while fast, it had absolutely _horrendous_ quality. I revisited it on my previous main Plex server build, which I think was a Haswell, and it was still unusable for transcoding compared to x264.

It took Nvidia until the encoder they bundled into 20xx series cards and Intel until the 6th or 7th generation of Quick Sync, but their hardware encoders are _finally_ at a point you can get decent quality at reasonable bitrates. Even so, x264 (and x265!) beat the pants off of them if one can spare the time and electricity; they're still that far ahead.

reply
upvoteby drmpeg8 hours ago|
parent|
prev|
[-]
Today I learned about Intel Quick Sync. Thanks. I retired from video compression in 2011, so I've been out of the loop for a long time.

https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

reply
upvoteby mcoliver16 hours ago|
prev|
[-]
Very cool. Took a similar approach to optimizing openutv by looking at flamegraphs. UTV is a fork of openrv which is an older release of the commercial RV. Like many things it uses ffmpeg and also native readers and writers for certain formats. Allowed me to get it to 8k@60fps buttery smooth playback with hardware acceleration. If you are still in the video/imaging space would love your feedback on UTV. openutv.com
reply