Page 2 of 3

Re: DXV profiles

Posted: Tue Feb 12, 2013 02:12
by lbens
Hey, sorry def didn't mean to sound thuggish! Just wanted to be clear about how crucial this issue is for some of us. I actually already use a few different softwares and hop back and forth between them depending on the show - what you read was just frustration at having to switch my current show out of resolume (which is otherwise perfect for it) just to get an acceptable image quality. Probably could have worded it better, plane travel and late night gigs do nothing for my diplomacy..
If AIC playback can be improved that's great news :) and an update to the DXV compression sounds promising too.
Thanks!

Re: DXV profiles

Posted: Tue Feb 12, 2013 15:07
by cvanhoose
Great info. thanks. There is a considerable amount of difference from ProRes to DXV in my animations from AE. I find myself using the "Levels" addition on some of my animations, it reduces the rough gradients.
CVH

Re: DXV profiles

Posted: Wed Feb 27, 2013 02:48
by ReggieUnderground
The VDMX guys released a new codec called Hap today. It's similar to DXV in that it uses GPU acceleration. There are 3 profiles: Flat, Alpha, and High Quality. Scroll down to see a chart comparing Hap to DXV and others. http://vdmx.vidvox.net/blog/hap Will be interesting to try out!

Codec download (Github): https://github.com/Vidvox/hap

Re: DXV profiles

Posted: Tue Mar 05, 2013 14:56
by Rene
ReggieUnderground wrote:The VDMX guys released a new codec called Hap today.
How is it different from DXV (besides Mac only and open source)? Will there be native support for Hap in Resolume (would it make sense?), or a DXV HQ profile, both?

Re: DXV profiles

Posted: Tue Mar 05, 2013 15:12
by Joris
How is it different from DXV (besides Mac only and open source)?
On the technical side, they're pretty much identical. Contrary to what it says on the Vidvox site, CPU use is not higher or lower on the codec decompression itself.

We'd be interested to see some real world comparison between compression artifactsing though.
Will there be native support for Hap in Resolume (would it make sense?)
There will. Having more options for lightning fast playback is great and we'd be silly to not support it.
or a DXV HQ profile, both?
No. We feel that the data rates on that HQ profile are too high to be a good alternative to what's already out there.

Re: DXV profiles

Posted: Tue Mar 05, 2013 15:21
by Rene
thanks for your rapid reply :)

Re: DXV profiles

Posted: Tue Mar 05, 2013 15:25
by Joris
No problem.

And "artifactsing" is now a word.

Re: DXV profiles

Posted: Tue Mar 05, 2013 15:26
by kmifflin
Sound interesting. Looking forward to testing it out

Re: DXV profiles

Posted: Wed Mar 06, 2013 17:47
by bangnoise
goto10 wrote:There will. Having more options for lightning fast playback is great and we'd be silly to not support it.
This is excellent news.
goto10 wrote:Contrary to what it says on the Vidvox site, CPU use is not higher or lower on the codec decompression itself.
Just for the record, CPU use is indeed lower with Hap as it uses a faster secondary-(de)compressor (Snappy). If you/Resolume feel unfairly represented on that page then do get in touch - it's intended to be a fair comparison.
goto10 wrote:We'd be interested to see some real world comparison between compression artifactsing though.
For Hap and Hap Alpha artifactsing (artifactsong?) is very very similar. Below the High quality setting we use the GPU to encode so results will vary between machines - but are generally reasonable and encoding is fast. At High and above results should be extremely similar to DXV.

Hap Q has quality far beyond anything currently in DXV - but then so are its data-rates, as you observe.

Anyway, thanks for your support!

Re: DXV profiles

Posted: Thu Mar 07, 2013 10:22
by Joris
Regarding the CPU thing, it's pretty trivial, so we're not worried about it. As long as the fps's are flying, it's all good ;-)

It's interesting though. As far as we know, the latest internal Resolume build is currently the only software that can actually do an A/B test of both codecs in the same software, and we found CPU usage was identical.

How have you tested the CPU usage? Maybe it's just that VDMX has a lower CPU overhead?