BRAW SDK decodeAndProcessJob->Submit() out of mem

Hi,

I'm getting E_OUTOFMEMORY error from decodeAndProcessJob->Submit() command with BRAW SDK 2.0 beta 3 on Linux (Centos 7.7, 128GB RAM), although I'm using CPU decode path and have plenty of free system memory. I don't have multiple decode jobs running in parallel, just one at a time. Problems rise with 12K test files from BMD website from new Ursa 12K camera. I don't get the error right away, but it seems to pop up when I change the processing parameters a few times, for example exposure or tint.

What would be the suggested method to solve the problem or work around it gracefully?

Thanks in advance!

[CaptainHook]

Currently CPU decode for 12K camera files still requires the GPU to do most of the processing as we have not done a fully optimized CPU only decode path yet (still working on it). The SDK handles this in the background when using the CPU decode path so it's likely your GPU is running out of memory. You need a lot of GPU memory with Linux/Windows dealing with these files, Mac with Metal seems to handle it fine by using host memory when needed so even with just a 4GB GPU you won't get out of memory errors, it will just run slower as the system copies memory around.

Currently the options really are only to either upgrade your GPU or decode at lower resolution(s). Also with the 2.0 SDK and especially 12k camera files, make sure you're using the new IBlackmagicRawClipResolutions interface for this.

Our 12K camera introduces a new image format to Blackmagic RAW that has been engineered with performance and scalability in mind. The new format is specifically designed to accelerate down-scaled decodes and support a wider range of cameras. With this new format comes some unique requirements that means a down-scaled decode won't necessarily result in an expected reduction in dimensions, which has led to the addition of the new IBlackmagicRawClipResolutions interface.

The IBlackmagicRawClipResolutions interface (queryable from a clip) is designed to aid in determining the exact processed image sizes based on desired scale values.
The reverse is also true and you're now able to query what scale would be best used to get a processed image resulting in a resolution as close to that specified.
In addition, this interface also provides methods to query all the available resolutions at which an image may be decoded which is useful for lists in GUIs etc.

Hi, thank you for detailed answer! I must see what my gpu mem is doing, I have 2080Ti with 11GB ram so not too shabby.

Already found the downscale size difference, I’m doing a different prototype now, where I need to get exact size of decoded image and pass the info before doing any actual decoding. My Braw player handled subresolutions behind the scenes so I didn’t even notice that decode resolution wasn’t what I’d expect. So somehow the introduction of new interface had evaded me, will look into it!

[CaptainHook]

No problem, FYI there's also a changelog that comes with the SDK that goes into more detail than the read me to alert developers about interface changes etc

Eg. for 2.0 so far:

Code: Select all

What’s new in Blackmagic RAW 2.0 Public Beta 3

• Added support for Blackmagic RAW 2.0 on Linux.
• General performance and stability improvements.
• Added color gamut support for ARRI Alexa Wide Gamut and gamma support for ARRI LogC to improve compatibility with some workflows
• Added gamut compression enable clip processing attribute (GPU only)
• Interface changes:

   - Added:

       - Added item blackmagicRawClipProcessingAttributeGamutCompressionEnable to enum BlackmagicRawClipProcessingAttribute


What’s new in Blackmagic RAW 2.0 Public Beta 2

• Added support for Blackmagic RAW 2.0 on Windows.
• General performance and stability improvements.


Changes in Blackmagic RAW 2.0 Public Beta 1

• Added support for Blackmagic URSA Mini Pro 12K.
• Added support for dual card recording.
• Updated to Blackmagic Color Science Gen 5.
• Note: For this beta when using the manual CPU pipeline for URSA Mini Pro 12K camera images, buffers are recommended to be page aligned for best performance.
• Interface changes:

   - Added:

      - Added interface IBlackmagicRawClipResolutions
      - Added method IBlackmagicRawClipResolutions::GetResolutionCount()
      - Added method IBlackmagicRawClipResolutions::GetResolution()
      - Added method IBlackmagicRawClipResolutions::GetClosestResolutionForScale()
      - Added method IBlackmagicRawClipResolutions::GetClosestScaleForResolution()
      - Added method IBlackmagicRawClipResolutions::~IBlackmagicRawClipResolutions()

A bit of help needed though..

This piece gives me E_NOINTERFACE error from both queries:

Code: Select all

IBlackmagicRawClipResolutions* resolutions;
result = codec->QueryInterface(IID_IBlackmagicRawClipResolutions, (void**)&resolutions);
result = clip->QueryInterface(IID_IBlackmagicRawClipResolutions, (void**)&resolutions);

How do I actually use the interface? For other interfaces there are specific methods that provide interface to supplied pointer or I can use QueryInterface, but I can't find anything specific related to this interface and query fails. I'm creating the factory from v2.0 SDK directory and 12K decode itself works so SDK version is proper.

Sorry if this is something obvious I'm missing, COM interfaces isn't my strong point

[CaptainHook]

Seems strange, your second example should work and does in our test code. Is your clip object definitely a IBlackmagicRawClip ? Can you post more code for context?

Something had went sideways in my system I think, tried today again, first by adding these lines to example code from SDK and then in my own code with exact same clip->QueryInterface(...) and now it works as expected. Clip is the same IBlackmagicRawClip object I use for all other decoder functionality so it definitely is correctly initialized.

It does seem strange that it gave the specific error yesterday. If I can reproduce the error again, I'll try to gather a bit more info about what I did before and what I did in decoder before the call.

[CaptainHook]

Okay, glad its working - thanks for getting back and confirming.

I also investigated my original E_OUTOFMEMORY errors and as usual, it was also my own error. Due to reasons the system spawned multiple decoder instances that eventually ran out of gpu ram. Now I switched to making sure I have just single decoder instance and decoder doing 12K streams doesn't go above 2-3GB of gpu ram usage.

Great news Hendrik ! I was getting worried that 12K decoding would take too much GPU VRAM