Deep color VFW & QT codecs

[shekh]

This thread was about what is possible to do to make cineform working with virtualdub in better than 8 bit modes. Started here http://forum.doom9.org/showthread.ph...98#post1717198

With ffmpeg everything works, no problem there.
The problem with cineform, I would ideally use direct api, but the problem is: it is licensed.
The other option is vfw driver, but it is limited in supported formats. I know it can pass v210, but afaik nothing better than that. If it supported at least something like normal 16bit planar or interleaved yuv I would deal with it, but v210 does not make me excited.

[kolak]

Yes, Cinefrom offers many pixel formats with API.

Does this help?

https://twitter.com/cineformsdk

[shekh]

Originally Posted by kolak

Yes, Cinefrom offers many pixel formats with API.

Does this help?

https://twitter.com/cineformsdk

Yes, I know this. I made some basic sdk integration into input driver. I put source code on sourceforge but removed this capability from compiled version. (If anyone wants to know here is place to look: https://sourceforge.net/p/vdcachingd...e/cineform.cpp)

There is a bunch of non-technical problems.
With trial license cineform sdk is fully functional, but the trial key expires yearly and who knows, will they make another one for 2016? In any case, as there is no terms of use for sdk, I am quite sure it means "dont do that". I asked cineform to clarify but had no reply.

[kolak]

What if you install GoPro Studio app? This gives some free Cineform encoding, maybe it will work.
Other than this- Cineform is not free, so you can't "give it" for everyone for free. As far as I know Cineform checks for "global" license, so you can make some solution which supports it and than it's up to end user to add license. This is how it works with eg. Resolve.

[shekh]

Sure, I have GoPro Studio installed. This is how I have access to "free" codec, played with vfw interface and sdk interface. Btw, found from some of your older messages that it has directshow interface as well. Tried to investigate codecs with graphedit but it does not show format options.

Other than this- Cineform is not free, so you can't "give it" for everyone for free. As far as I know Cineform checks for "global" license, so you can make some solution which supports it and than it's up to end user to add license.

I think licenses are gone since Cineform does not sell anything now on their website. Do you have "global cineform license"? Do you know how to get it? I suspect if Resolve has Cineform integration, that is result of some agreement with GoPro. And this provides no new opportunity for third party.

Meanwhile, checking GrassValley HQX codec. It is handy that ffmpeg can decode it (not as fast as native decoder, but anyway). Image has DCT artifacts. Decoding speed about 1/3 of Cineform. Will see what else it can do.

[kolak]

Resolve won't export Cineform if you don't add "license" (or at least it didn't use to). Integration is there, but codec is not activated. This is what I'm talking about.
Old days you could add native Cineform support to your product. Than if user wanted to use it he had to buy Cineform license and activate it. By doing this license was enabled to your whole machine. Maybe it has changed.
HQX is ok, but not multithreaded. It only works very fast inside Edius (codec itself is single threaded).

I own Cineform license, but don't need it.

[aladdin4d]

According to a post in this thread by David Newman usage of Cineform is now effectively free as long as GoPro Studio is installed and third party tools are the way of the future as far as encoding goes

http://www.dvinfo.net/forum/cineform...nal-users.html

I think that means you can roll your own solution. Whether or not that translates into being able to freely use the SDK is obviously another issue but in theory (understand I'm definitely not a programmer of any sort) as long as the encoder is getting the data in a way it accepts it should work as long as GoPro Studio is installed.

Later on in that thread he mentions the SMPTE VC-5 package comes with reference source code to implement an encoder/decoder pair which again indicates there shouldn't be a problem with an independent solution.

Grass Valley HQX is ok but AFAIK deep color support is limited only for use in Edius and truncated to 8 bit when the codec is accessed by any other app.

[shekh]

After some investigation I confirm that HQX vfw codec can only accept data in 8 bit format.

About SMPTE VC-5, right now I dont think it is useful. AFAIK the specification is based on cineform, but is not specification of cineform. Even if the reference code works, who will optimize it? There is already jpeg2k which is loose reference of what cineform is. The problem is - it is slow. Unfortunately I am not inspired enough to purchase SMPTE subscription to make a closer look

[aladdin4d]

Standardizing through SMPTE is a 2-way street so they are pretty much one and the same now just like DNxHD is VC-3. Avid could have just added to DNxHD but that would've meant no longer being VC-3 compliant so you get DNxHR. It's the same with Cineform, it can change but then it won't be able to claim VC-5 compliance. The only real difference at the moment is VC-5 does not allow for interlaced encoding which is why it's being deprecated by Cineform, to maintain compliance.

If and when I can confirm that this:

http://ieeexplore.ieee.org/xpl/artic...Number:7290349)

really does include the reference code and test materials I'll seriously consider getting it. It's $120.00 US for non IEEE members which isn't too outrageous

[shekh]

Originally Posted by aladdin4d

If and when I can confirm that this really does include the reference code and test materials I'll seriously consider getting it. It's $120.00 US for non IEEE members which isn't too outrageous

But you said you are not a programmer, what would you do with it?
Btw, is it allowed to include such reference code in open source?

[aladdin4d]

Originally Posted by shekh

But you said you are not a programmer, what would you do with it?
Btw, is it allowed to include such reference code in open source?

You're right I'm not a programmer but I can generally get something to compile so I should end up with an encoder/decoder pair and some other simple utilities. On top of that I do know a programmer or two that I might be able to draft into helping me or worst case I eventually pay one.

I believe the license only allows for a binary to be distributed, not the source but that's a question that would be definitively answered by the materials

[shekh]

Originally Posted by aladdin4d

You're right I'm not a programmer but I can generally get something to compile so I should end up with an encoder/decoder pair and some other simple utilities. On top of that I do know a programmer or two that I might be able to draft into helping me or worst case I eventually pay one.

Please share your experience when you make progress with this.

[kolak]

HQX 10bit is supported in MOV through v210. b64a and r4fl pixel formats seams to be also supported.
Another thing- good luck with trying to get access to Grass Valley SDK. It seams to be impossible, even if such a thing does exist.

[aladdin4d]

Originally Posted by kolak

HQX 10bit is supported in MOV through v210. b64a and r4fl pixel formats seams to be also supported.
Another thing- good luck with trying to get access to Grass Valley SDK. It seams to be impossible, even if such a thing does exist.

This is true but all that functionality is limited to Edius only, no third party access and no SDK for third party use.

[kolak]

Originally Posted by aladdin4d

This is true but all that functionality is limited to Edius only, no third party access and no SDK for third party use.

No- it works with Adobe software. You can export HQX at 10bit from Premiere, AE or MediaEncoder. You just have to modify Adobe xml rules file. Any other tool which can push specific pixel format to MOV exporter will also work.

[aladdin4d]

Originally Posted by kolak

No- it works with Adobe software. You can export HQX at 10bit from Premiere, AE or MediaEncoder. You just have to modify Adobe xml rules file. Any other tool which can push specific pixel format to MOV exporter will also work.

If Adobe products can do that then great for you they must have cut a deal with Grass Valley because the codecs alone do not allow that without an active license. They allow reading 10 bit files but you can't encode 10 bit files. I've tested this a few times now by moving my Edius license across three different machines. When Edius is installed and activated then yes third party apps can encode 10 bit files but remove Edius then it's back to 8 bit only.

[benwaggoner]

Originally Posted by kolak

HQX 10bit is supported in MOV through v210. b64a and r4fl pixel formats seams to be also supported.
Another thing- good luck with trying to get access to Grass Valley SDK. It seams to be impossible, even if such a thing does exist.

Several years ago I was quoted a price for licensing the HQX SDK, around $25K IIRC. Never went so far that I had engineers able to review it and determine its capabilities.

It's a very painful codec in so many ways. Lots of in-the-wild files I've seen didn't even have proper field order or aspect ratio metadata! Maybe there are in some sort of bitstream level private metadata or something.

I don't know why anyone would want to make new files in that format given those challenges and its relative inefficiency, but at least ffmpeg now appears to have a good decoder.

[kolak]

Well, it's not that bad from the consumer point of view (not sure about internals). Efficiency is about the same as ProRes or DNxHD. It's about as fast to decode as ProRes. GV uses their own metadata in AVI, so it works fine inside their environment.
The problem is with owner, thought they were persuaded to give it for free. SDK is yet another story
I still prefer Cineform as it's very unique and powerful technology.

[shekh]

Does the same (b64a via quicktime) work with cineform? Just found CFHDCodec.qtx on my machine, so at least the component exist.

[shekh]

Originally Posted by shekh

Does the same (b64a via quicktime) work with cineform? Just found CFHDCodec.qtx on my machine, so at least the component exist.

Still no idea if it works at all, but there is only 32bit component, and it seems the whole quicktime thing is 32bit only. What a mess. (I am complaining about memory addressing/architecture, not pixel format).