BRAWSource (Blackmagic RAW)

[emcodem]

Hi,

as users in the FFAStrans Forum requested support for BRAW Files but not ffmpeg neither avisynth supports it currently, i decided to craft an avisynth plugin for it. I'd prefer ffmpeg support but there is no "plugin mechanism" builtin in ffmpeg that allows users to load new readers/decoders without recompiling, so here we go.

https://github.com/emcodem/avisynth_brawsource/releases

@Users: Please try it out and let me know any shortcomings.

It currently supports:
-) Audio and Video
-) 8, 16 or 32 bit (32 with Alpha) Video output (independent of BRAW input format)
-) Full threading support with SetFilterMTMode and Prefetch
-) BMD SDK DLL files (currently shipped with the release zip) must reside in a folder called brawsource_dlls in same folder where brawsource.dll resides

@Developers:

For the last one, i was not sure, how are source plugins supposed to do the threading these days? E.g. i can't really prefetch frames internally because i never know which frame the user wants next, right?

Also i would be very greatful on help for the following topics:
-) does BMD SDK allow redistribution of source code and dll's using their SDK?
-) can i put GPL or similar license on my code parts even when using BMD SDK? License here
-) more experienced c++ devs might know the idl/midl stuff, the bmd sdk requires building their midl to geht the header files, also they require to import a special header file. I'd love to just add all the generated BMD SDK header files to my project and add them to github so anyone can just clone and build without further thinking but maybe the license does not allow to redistribute parts of the SDK (i really don't know, my english is not good enough for these kind of matters) currently try to #include the bmd sdk files from their install location instead of relative, this forces other dev's to download their own copy of the SDK. How do other projects structure that nicely?

Example usage (mtmode and prefetch are very optional but seem to work and speed up ffmpeg operations a lot):

OPT_AllowFloatAudio = true #prevent avisynth downconverting to 16 bit audio
loadplugin("C:\dev\avs_rawsource\RawSource_2.6x\vs2022\x64\Release\BRawSource.dll")
#SetFilterMTMode ("BrawSource", 1)
BrawSource("C:\temp\Filmplusgear-Helicopter-Ischgl-2019.braw",bits=32)
#Prefetch(8,16)

[qyot27]

I don't know if it's the same SDK, but ffmpeg's DeckLink support section in the FAQ does mention the Blackmagic SDK and widl:
https://ffmpeg.org/ffmpeg-devices.html#decklink

There's a slew of decklink-related sources for the encoder and decoder in the libavdevice tree:
http://git.videolan.org/?p=ffmpeg.gi...490d11;hb=HEAD

My assumption (and from reading the license) is that the headers will have to remain as the install path and redistribution of the headers isn't permitted.

The DeckLink stuff in FFmpeg is still LGPL, but that only covers the code on FFmpeg's side; building that module requires the use of '--enable-nonfree', so the resulting binaries can't be distributed. If this is a problem for the LGPL, it definitely is for the full GPL.

On AviSynth's side, there is some ambiguity because AviSynth includes a GPL linking exception clause so plugins (at least; whether it also applies to clients is unclear) aren't required to be distributed under the GPL even while linking against AviSynth, and as historical precedent goes, there are lots of closed-source AviSynth plugins that are stuck perpetually in the early 00s on a level with version 2.5 because the author moved on and never released the source (*cough* deen *cough*). So could you license your plugin-related code under the LGPL like FFmpeg? Probably, but like FFmpeg, that's almost certainly a license conflict and builds of the plugin would be unredistributable. A different FOSS license might be needed for that instead; my gut feeling is that one of the BSD or MIT style licenses might be a little more able to accommodate the circumstances (bmdtools seems to be multi-licensed, so...), but IANAL.

[Selur]

Any plans for Vapoursynth support?

[FranceBB]

Well, I asked about this all the way back in 2019 https://forum.doom9.org/showthread.php?p=1871656 so this indexer is definitely welcomed!
It totally works as I tested with the samples I got from 2019.

BRawSource("A004_10040638_C001.braw", bits=32)

It works and shows the image in all its 6144x3456 50p glory.
Having the ability to output RGBPS also means that high bit depth is preserved.



however it doesn't seem to be working with the ones from the Ursa camera, also from 2019.



I've sent you the link to those clips privately on Slack.
Still, this looks very promising! Very well done indeed!


EDIT: After a bit of a private debugging session on Slack, he created a new static non-debug build and with that one everything worked like a charm, including the Ursa files.



A-M-A-Z-I-N-G

[emcodem]

Originally Posted by qyot27

I don't know if it's the same SDK, but ffmpeg's DeckLink support section in the FAQ does mention the Blackmagic SDK and widl:
https://ffmpeg.org/ffmpeg-devices.html#decklink

There's a slew of decklink-related sources for the encoder and decoder in the libavdevice tree:
http://git.videolan.org/?p=ffmpeg.gi...490d11;hb=HEAD

My assumption (and from reading the license) is that the headers will have to remain as the install path and redistribution of the headers isn't permitted.

Thanks a lot Steven, i should have had a look into decklink source before i asked but no it's not the same SDK, maybe even other license, who knows.
I'll probably keep the files from the SDK out of the source code and just apply LGPL to my plugin (altough i "prefer no license" but some say thats not good)

@Selur
Sorry no Vapoursynth or linux support planned, i am happy when the stuff works in FFAStrans and we are very much bound to windows there and need avisynth only to feed ffmpeg on the fly (i think thats not really possible with vapoursynth, is it?)

@FranceBB
thanks for your efforts, please keep on testing