5 ms·

Simply beyond ridiculous (H265 proposal testing)

90 points by chadaustin 16y ago

Splines 16y ago
Just curious - did the same shenanigans get pulled with H.264?
- DarkShikari 16y ago
  Not to this extreme, as far as I can tell, though I wasn't in the industry during the period that got standardized. You can actually go and try out some of the proposals; one, for example, was called Nokia MVC (not to be confused with the much later H.264 MVC); see http://wiki.multimedia.cx/index.php?title=Nokia_MVC http://wiki.multimedia.cx/index.php?title=Nokia_MVC for more information. While it certainly was a kitchen-sink of "interesting" features (affine motion compensation, KLT, etc), it was not so slow as to be impossible to use. But I can't say for sure that there weren't some totally insane encoders put forward by those involved. What I suspect is going on is a case of exponents. That is, you have an algorithm that tries every possible A, an algorithm that tries every possible B, and an algorithm that tries every possible C. You optimize them independently, and then in the final encoder you submit, you run them all at the same time, optimizing every possible A, for every possible B, for every possible C, sending runtime sky-high. I'd read the code, but it's nearly-undocumented C++, written by the kind of people who reimplemented their own option parser using C strings (in C++) in Visual Studio.
chmike 16y ago
I had the impression that decoding is the time critical operation. Encoding is done once and decoding many time. Sure, it is better with fast encoding, but we won't get better compression for free. The author didn't consider the use of GPU to perform the encoding. Kind of fishy. For my application (not video encoding) I managed to reduce the computation time from 5h to 15s (600x faster!) by using a GTX280 GPU card.
- DarkShikari 16y ago
  If you get a 600x speed increase, you did something wrong in your CPU application; there simply isn't 600x as much processing power on a GPU. Typical increases are about 5-10x, a bit more in applications with heavy floating-point math. More importantly, regardless of how important you think encoding is, if I can't encode a 5 second test sequence in less than a day, I'm not going to be able to do much experimentation with the software. Sure, you can port it to a GPU, but right now it isn't on a GPU, and right now, I'd like to experiment with it.
  - scott_s 16y ago
    I am unfamiliar with the memory patterns in the application, but: 600x improvement in performance does not have to come from increase in processing power. If the algorithms have a lot of data reuse in their matrix computations, I can see achieving 600x improvement when compared to a hardware cache based architecture. If the CPU implementation doesn't do tiling (http://en.wikipedia.org/wiki/Loop_tiling http://en.wikipedia.org/wiki/Loop_tiling) effectively (or it can't) then it's going to shuttle a lot of data back and forth from cache to RAM. The accepted term for this effect is super-linear speedup.
- hristov 16y ago
  You are right. Also computer power tends to increase pretty fast and get cheaper all the time. Also the software at this stage is likely not optimised for encoding speed. Also, that software was likely to have a lot of debugging flags, etc.
  - Kovensky 16y ago
    > Also computer power tends to increase pretty fast and get cheaper all the time. The spec is being written now. The encoder needs to be tested and evaluated now. There's no point in doing it now if we'll have to wait 10 years until CPUs can be used for testing whatever you make. > Also, that software was likely to have a lot of debugging flags, etc. It was released in source form, so those are easily disabled / removed.
- 16y ago
MikeCapone 16y ago
> so I decided to try out the proposal that appeared the most interesting: the Samsung+BBC proposal (A124), which claims compression improvements of around 40%. At first I read this and couldn't believe it. A 40% improvement! Wow! But reading the rest of the article, it's disappointing to see that it's not a practical %40... Makes me wonder if GPUs could be used to do the encode and speed it up enough to make it practical (maybe within a few generations of GPUs..). After all, you have to aim for where computers will be by the time this becomes a standard, not where they are now.
alanh 16y ago
I would like to see more information before reaching a conclusion. Does using a GPU really help as much as chmike suggests? What do the encoder's authors have to say?
Create 16y ago
It is a form of content protection: accessibility to hw to deal with it will be much further down the road for consumers than monopolies. Old format will be "good enough" for home video until the inevitable comes. Would GOOG fast-track vp8 as an ISO standard, like MS did with OOXML? After all, it is ubiquitous in flash video, just as Word is -- a de facto standard needing rubber stamping.
- ZeroGravitas 16y ago
  I've also wondered if the needed hardware for H.264 was a form of dongle (http://en.wikipedia.org/wiki/Dongle#Copy_protection http://en.wikipedia.org/wiki/Dongle#Copy_protection for youngsters who don't remember this early form of DRM) but have concluded it's just because they come from the hollywood and hardware world rather than being internet and software guys. Also note that Microsoft only got to fast-track OOXML as an ISO standard because it had already been passed as a standard by ECMA, not because of anything inherent in OOXML (which wasn't even a de facto standard, the binary .doc was).
- Kovensky 16y ago
  VP8 is NOT ubiquitous in flash video, nor it could ever be. It was never released. Only VP6 is supported, but how many relevant people do you still see using VP6?

90 points by chadaustin 16y ago

Splines 16y ago

Just curious - did the same shenanigans get pulled with H.264?

DarkShikari 16y ago
Not to this extreme, as far as I can tell, though I wasn't in the industry during the period that got standardized. You can actually go and try out some of the proposals; one, for example, was called Nokia MVC (not to be confused with the much later H.264 MVC); see http://wiki.multimedia.cx/index.php?title=Nokia_MVC http://wiki.multimedia.cx/index.php?title=Nokia_MVC for more information. While it certainly was a kitchen-sink of "interesting" features (affine motion compensation, KLT, etc), it was not so slow as to be impossible to use. But I can't say for sure that there weren't some totally insane encoders put forward by those involved. What I suspect is going on is a case of exponents. That is, you have an algorithm that tries every possible A, an algorithm that tries every possible B, and an algorithm that tries every possible C. You optimize them independently, and then in the final encoder you submit, you run them all at the same time, optimizing every possible A, for every possible B, for every possible C, sending runtime sky-high. I'd read the code, but it's nearly-undocumented C++, written by the kind of people who reimplemented their own option parser using C strings (in C++) in Visual Studio.

chmike 16y ago

I had the impression that decoding is the time critical operation. Encoding is done once and decoding many time. Sure, it is better with fast encoding, but we won't get better compression for free. The author didn't consider the use of GPU to perform the encoding. Kind of fishy. For my application (not video encoding) I managed to reduce the computation time from 5h to 15s (600x faster!) by using a GTX280 GPU card.

DarkShikari 16y ago
If you get a 600x speed increase, you did something wrong in your CPU application; there simply isn't 600x as much processing power on a GPU. Typical increases are about 5-10x, a bit more in applications with heavy floating-point math. More importantly, regardless of how important you think encoding is, if I can't encode a 5 second test sequence in less than a day, I'm not going to be able to do much experimentation with the software. Sure, you can port it to a GPU, but right now it isn't on a GPU, and right now, I'd like to experiment with it.
- scott_s 16y ago
  I am unfamiliar with the memory patterns in the application, but: 600x improvement in performance does not have to come from increase in processing power. If the algorithms have a lot of data reuse in their matrix computations, I can see achieving 600x improvement when compared to a hardware cache based architecture. If the CPU implementation doesn't do tiling (http://en.wikipedia.org/wiki/Loop_tiling http://en.wikipedia.org/wiki/Loop_tiling) effectively (or it can't) then it's going to shuttle a lot of data back and forth from cache to RAM. The accepted term for this effect is super-linear speedup.
hristov 16y ago
You are right. Also computer power tends to increase pretty fast and get cheaper all the time. Also the software at this stage is likely not optimised for encoding speed. Also, that software was likely to have a lot of debugging flags, etc.
- Kovensky 16y ago
  > Also computer power tends to increase pretty fast and get cheaper all the time. The spec is being written now. The encoder needs to be tested and evaluated now. There's no point in doing it now if we'll have to wait 10 years until CPUs can be used for testing whatever you make. > Also, that software was likely to have a lot of debugging flags, etc. It was released in source form, so those are easily disabled / removed.
16y ago

MikeCapone 16y ago

> so I decided to try out the proposal that appeared the most interesting: the Samsung+BBC proposal (A124), which claims compression improvements of around 40%. At first I read this and couldn't believe it. A 40% improvement! Wow! But reading the rest of the article, it's disappointing to see that it's not a practical %40... Makes me wonder if GPUs could be used to do the encode and speed it up enough to make it practical (maybe within a few generations of GPUs..). After all, you have to aim for where computers will be by the time this becomes a standard, not where they are now.

alanh 16y ago

I would like to see more information before reaching a conclusion. Does using a GPU really help as much as chmike suggests? What do the encoder's authors have to say?

Create 16y ago

It is a form of content protection: accessibility to hw to deal with it will be much further down the road for consumers than monopolies. Old format will be "good enough" for home video until the inevitable comes. Would GOOG fast-track vp8 as an ISO standard, like MS did with OOXML? After all, it is ubiquitous in flash video, just as Word is -- a de facto standard needing rubber stamping.

ZeroGravitas 16y ago
I've also wondered if the needed hardware for H.264 was a form of dongle (http://en.wikipedia.org/wiki/Dongle#Copy_protection http://en.wikipedia.org/wiki/Dongle#Copy_protection for youngsters who don't remember this early form of DRM) but have concluded it's just because they come from the hollywood and hardware world rather than being internet and software guys. Also note that Microsoft only got to fast-track OOXML as an ISO standard because it had already been passed as a standard by ECMA, not because of anything inherent in OOXML (which wasn't even a de facto standard, the binary .doc was).
Kovensky 16y ago
VP8 is NOT ubiquitous in flash video, nor it could ever be. It was never released. Only VP6 is supported, but how many relevant people do you still see using VP6?