HAP Codec

[visulize]

Did we just find a new bump topic??

[malkuth23]

I was straight up mocked by someone encoding the same content next to me for use on VDMX. They finished so much faster it was humiliating. It took them about 2 hours on one Mac trashcan to do what took me all night using 3 servers.

Everything I have read suggests that DXT compression can be done with GPU acceleration. Is this not implemented? It seemed like it was not fully multi-threaded either. The load mostly sat on one core.

Then, after encoding for many hours I find that my content was not a multiple of 4, so I have to bring the content into Adobe Media Encoder to resize and send it back to Windows to encode with the Quicktime encoder (Mac version of plugin still not working right).

It doesn't have to be HAP, but the current coolux codec is incredibly slow. I appreciate the versatility of some of the DDS features, but I am looking for alternative command line encoding procedures now.
http://www.nvidia.com/object/real-time- ... ssion.html
https://www.evl.uic.edu/cavern/fastdxt/

HAP support seems to be the obvious solution, but if that is a long time coming or off the table, any advice about PB DDS and YCoCG formats would be appreciated. I have not tried FastDXT yet, but I plan to begin exploring it when I have time. If anyone else gets to it first please post results.

[florian]

This thread is over a week old, two pages deep and still no feedback from coolux...

Hello?

[mkohler]

*Bump*

[Dennis Kuypers]

Hello?

Hello!

We read through your suggestions and appreciate your feedback. There are currently discussions internally. Daniel will probably let you know when we have something for you.

Regards
Dennis

[Sam Kriemelmeyer]

[Daniel Kaminski]

Hi,

please be patient a little longer.
I can already tell you a few things.

a) we split the codec into 2 codecs. One for mov-files and one for Image Seq. This should make it much more easy to use.
b) encoding of DDS will be much quicker. We were able to reduce the encoding time drastically.

This update should be available after a few final tests and tweaks together with the next 5.7 Bugfix Release.
Do not ask me for a date, I do not know, but it will be rather sooner than later.
We are also looking at all the other options you suggested in this thread, but at this point I have no information or status update on those.

Daniel

[malkuth23]

Hi Daniel,

This sounds great. It is also important that we can have the ability to auto-encode to DDS. 9/10ths of my work these days are installations.

Please consider making DDS part of the inline encoder a high priority.

Thanks!

[florian]

Hi,

It's lovely that the coolux 'DDS' coced is being tweaked to be usable.

I still think that joining the rest of the media playback community and supporting HAP would be a better solution, than insisting on developing this proprietary thing that does the same thing.

Please allocate resources to integrating Hap.

[aquapixs]

Hi,

I totally agree with Florian. Main issue for most ot the content people is that they do not have any option to view a DDS file after encoding. So there is no way to tell if they rendered the right thing or not.
Next downside is the Quicktime Plugin. A lot of people are very frustated to use it as it still does not work well and is still in Beta status. And you always need to explain all steps to them. Hap is much easier to use and most of the content guys know it already.

And final, but most important: DDS quality is way behind HAP.
On the show I did use HAP I did a 1:1 test with a file converted from ProRes 4.2.2 into HAP, DDS and MPEG. And honestly the DDS did not look much better than the mpeg while the HAP was close to ProRes.

best wishes

Patrick

[azman]

Hi All,

Great Post!
I'd also be interested in the outcome of these discussions,
I'll be trialling the Hap codec over the next few weeks & will post any further findings.

Cheers

Az

[Matt Finke]

Sounds interesting to me, would like to try it as well. Any codec making us faster and better looking is highly appreciated from our side. Keep us updated...

all the best

Matt

[Daniel Kaminski]

Hi all,

please keep the feedback coming. All this is good information for us and we are taking all this feedback serious.

A few questions to get a even better Idea what you are dealing with:
* What type of productions do you do?
* What are your normal content dimensions? Mainly HD? 4k? Higher, Lower?
* What is your content amount per production? What is the min, what was the max?
* What is the percentage of MPEG, DDS/YCoCg and Uncompressed (Animation, BMP) Content.
* Do you mainly use Single Files (MPEG, MOV Container) or Images Seq.

Thank you for your feedback.

Daniel

[Markus Zeppenfeld]

Hi guys,

as Daniel already replied, there is progress in the codecs.
Once the installers are built as well, I am happy to share these with you, even prior to a Pandoras Box update.

Let me clarify some things:

1. The coolux codec has been developed to be able to export real image sequences. As HAP is always included into a Quicktime container, you will not be able to exchange/view single images within your file browser.
2. The codec offers even more possibilities for export such as BMP wrapped into SNP or just brings back the BMP export to AfterEffects which was discontinued from Adobe.
3. HAP is using the exact same encoding method as DDS does. Therefore you will not realize any quality differences.
4. DDS files can natively be viewed within Win8.1 and even DDS in MOV-containers can be viewed in Quicktime as soon as the codec is installed.
5. HAP can never act with the same performance as DDS at the moment by just installing the codec. As the decompression is forwarded to the Quicktime Plugin it will not be read natively and has massive downsides at the performance.
6. Development changes can be made easier on our codec than completely implementing HAP for native playback. This does not mean, that we do not look into this, but the performance could be optimized relatively easy compared to implementing something completely new.

We do see that it would be handy to have DDS as well within the Encoder Extension, but the MPEG Encoder Extension is not meant for Image Sequence Export so far.

Cheers
Markus

[florian]

Hi Markus,

I wanted to respond to your assertions 1 at a time:

1. The coolux codec has been developed to be able to export real image sequences. As HAP is always included into a Quicktime container, you will not be able to exchange/view single images within your file browser.

This workflow isn't as useful (to me) in practice as it is in theory. Moving individual files around in large groups puts more strain on network bandwidth than moving a single file. Also, something that is really important when working in the sorts of environments where you're receiving updated frames from content producers, is version tracking. This is often achieved by using version numbers in the file name. Something you can't do when you are just overwriting the old versions in your content directory. Since Pandora has an NLE-style timeline where asset containers can be arranged and composed, I think that rendering out a 2-3frame video and putting it on another layer is a perfectly acceptable way to deal with content patches.

2. The codec offers even more possibilities for export such as BMP wrapped into SNP or just brings back the BMP export to AfterEffects which was discontinued from Adobe.

It's cool that we have additional features, provided gratis (thanks!), to the AE user community, but again, a quick deliverable with a third party reference standard is more useful in most of the workflows that I find myself living at the end of.

3. HAP is using the exact same encoding method as DDS does. Therefore you will not realize any quality differences.

So the only issues we have are workflow related.

4. DDS files can natively be viewed within Win8.1 and even DDS in MOV-containers can be viewed in Quicktime as soon as the codec is installed.

The same is true for Hap. Once the Hap codec is installed you can preview Hap films in regular Quicktime 7 Player. If you are QC-ing a large stack of imagery and you need to look at frame #x, I'd say it's easier to open it in quicktime and jump to that frame than it would be to dig through a folder of several thousand files looking for a particular numbered frame.

5. HAP can never act with the same performance as DDS at the moment by just installing the codec. As the decompression is forwarded to the Quicktime Plugin it will not be read natively and has massive downsides at the performance.

This is why I would love to see support for this codec implemented natively in Pandora. The strategy for doing this is well documented, but obviously requires coolux developer/testing hours.

6. Development changes can be made easier on our codec than completely implementing HAP for native playback. This does not mean, that we do not look into this, but the performance could be optimized relatively easy compared to implementing something completely new.

As of this point, in this list, I still do not understand why I am better off as a user for having you invest all this development time into making something behave *as good* as another solution that does the exact same thing.

The performance issues are manifold. One of the biggest problems with the codec plugin (besides the insanely long render times) is that it simply has too many buttons and checkboxes. I have to personally walk animators through how to set up their export presets. If I don't, invariably, they either left 'image seq' checked, or forgot to pick the alpha dropdown, or some other setting in the rather odd little dialog that also occasionally crashes AE. Hap has thee codec profiles, that have essentially no options for editors to mismanage.

Also, Adobe has become rather fond of dicking around with the media-export pipeline in their apps lately. Most AE users don't like having to queue crap in Media Encoder instead of just having all the options the AE render queue, but complaining about Adobe is like complaining about weather, since, in the end, everyone grumbles and accepts that it is what it is. It does however mean that coolux will likely have to manage to keep the codec integration with AE and other apps working in the face of now yearly updates. This seems like a whole lot of time that you guys could be investing in working on other stuff. I don't see how outsourcing your codec integration support to some people who are already doing it anyway is anything but a windfall.

One of the biggest issues as I see it now is that deciding not to implement this will essentially make Pandora the odd-platform-out. Content producers have caught wind of Hap as a codec solution that works with 'Media Servers'. This is to say that they already expect it in some cases, since just about every other platform supports this. A render pipeline that already has Hap integrated could produce hi-quality content for Pandora. Convincing these studios to instead install yet another codec, trying to annotate the settings and how to find them, and then possibly discovering new and interesting integration problems is a whole lot of problems that I just don't think we need.

As open as coolux is to integrating various DMX-over-ethernet 'standards' (ArtNet1/2,MaNet1/2,champsys, streamingACN, etc...) it's a bit odd to decide to ignore an actual standard for media when it finally comes along.