Fast video codec

[Cyan]

Hello


I've been looking around for a fast video encoder, written in C (preferably) or C++.
The encoder should be able to handle real-time high-resolution video, such as 1920x1080 at 30FPS.
Another requirement is that it should accept input in 32-bits RGBA, and output in 32-bits RGBA, to minimize format transformation costs & distortions.

On the other hand, compression ratio doesn't need to be high. 15:1 is acceptable, which is a quite easy to achieve for Video.
Lossy transformation is autorised, but it must remain small.

So, the question is : does such a beast exist ?

I've started to look at VP8 for example, in fast mode. I like the licensing policy of Google.
But i'm nonetheless wondering if there are better alternative out there for such use case .


Regards

[m^2]

I wanted to write one, but didn't get a grant.

[Bloax]

The only ones that come to mind is Lagarith and UT Video, but neither seem to reach the 1:15 ratio.

[xooyoozoo]

Are you sure VP8 doesn't do internal conversations into and out of YUV?

x264's predictive lossless mode (--qp 0) should provide better compression than Lagarith or UT Video even on its fastest setting. On an average system, you should also be able to achieve realtime somewhere between the ultrafast and normal presets. It has flexible colorspace input and output BUT it always internally handles data as YUV.

[Cyan]

Yeah, i think "lossless" is quite likely incompatible with such scenario.
So lossy transformation is autorised.
Let's just say that, in term of quality, it better be "good".

So the real requirement here is speed :
1920 x 1080, 32 bits RGBA, 30 FPS => 250 MB/s !!!
It looks almost impossible. I guess multi-threading is a pre-requisite. Or, maybe, GPU compression ?


> Are you sure VP8 doesn't do internal conversations into and out of YUV?

In fact i don't really mind, as long as input and output from the "overall" coding-decoding chain operates in RGBA32.
I'm just worried that such transformation may cost some precious CPU cycles, as well as add some losses (rouding errors mostly).
Hopefully, I'm wrong.


> x264

I looked into x264 too. I'm just a little worried about license. Isn't that patented by MPEG-LA ?

[Bulat Ziganshin]

many modern cpus/gpus include dedicated video encoding hardware such as intel quicksync

[Cyan]

many modern cpus/gpus include dedicated video encoding hardware such as intel quicksync

Thanks for the hint Bulat, it looks promising.
I understand this feature is relatively new (introduced with the Sandy Bridge CPU microarchitecture on 9 January 2011),
and therefore not available for older processors (and i guess, neither for AMD ones).
That might prove an issue.


As a related news, i've been informed that the video scene to be compressed is built inside the GPU (in an OpenGL frame).
That might come handy, since it means part of the compression job could be done directly into the GPU, lessening CPU usage.

Still, i've only read a few articles about GPU video compression so far....

[Bulat Ziganshin]

http://techreport.com/review/23324/a...ding-on-the-pc :

AMD slapped a similar encoding block, dubbed Video Codec Engine (or VCE), into the Radeon HD 7000 series graphics processors earlier this year. Nvidia was the last to jump on the bandwagon with NVENC, yet another similar bit of hardware that premiered in the company's Kepler-based GeForce 600-series GPUs this spring.

[Cyan]

Thanks for the link, very interesting read.
So it finally seems to come from all fronts. This is good news for the future.

I'm afraid i will not be able to "wait for" the future, but that's nonetheless interesting to keep in mind.
The article stresses the importance of OpenCL for these new generation algorithms.

[Bulat Ziganshin]

these are completely independent: quicvsync/vce/nvenc is a special fixed-function hardware, while opencl/cuda is a gpgpu computation

[thorfdbg]

Yeah, i think "lossless" is quite likely incompatible with such scenario. > x264 I looked into x264 too. I'm just a little worried about license. Isn't that patented by MPEG-LA ?

Basically. However, you cannot patent an implementation, only an algorithm, and the patent holders are the developing companies, which however licence their IPRs through MPEG-LA. However, H.264 aka MPEG AVC licences are royalty free for internet applications. IOW, pay it or leave it.

[cbloom]

The only ones that come to mind is Lagarith and UT Video, but neither seem to reach the 1:15 ratio.

Not really the OP's question, but Lagarith is horribly slow. I've been meaning to do a fast lossless video codec for a long time but never get around to it.

There's an older one, HuffYUV or something that can do RGB, but it's pretty broken.

x264 -qp0 can't do lossless RGB that I know of because they assume YUV. (I think they can do non-subsampled and full range (0-255 instead of 16-235) but you have to set the right flags).

[cbloom]

I've been looking around for a fast video encoder, written in C (preferably) or C++.
The encoder should be able to handle real-time high-resolution video, such as 1920x1080 at 30FPS.

x264 realtime encoding modes can do that speed on a good enough system. Needs a few cores.

The slow part of encoding is mainly movec search. GPGPU for mocomp search can easily get you a video codec that does that speed. Needs a machine with a modern GPU.

[Cyan]

@cbloom : Thanks for the hints