You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Are there any roadmap to implement Camera raws like Braw, R3d, etc for filmcraft. #383
I was able to open an MXF - but it was slow processing a directory of files to get info on them. Application would hang while processing each file for info (frame rate, etc). Opening file directly was pretty fast, but slower than other types on my machine. Filmcraft 0.5.0 was version I was using.
MXF File I tested with:
`Format : MXF
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
File size : 122 MiB
Duration : 6 s 506 ms
Overall bit rate : 157 Mb/s
Encoded date : 2018-05-23 18:22:42.000
Writing application : CANON XF400 1.00
Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings : 2 Ref Frames
Format settings, CABAC : No
Format settings, Reference frames : 2 frames
Format settings, GOP : M=3, N=12
Format settings, wrapping mode : Frame
Codec ID : 0D01030102106001-0401020201314001
Duration : 6 s 506 ms
Bit rate : 152 Mb/s
Maximum bit rate : 150 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.766
Stream size : 118 MiB (97%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709`
Question for the maintainers (@echelon, @bflatastic), so contributors know which way to go on camera RAW:
CinemaDNG has a public spec (Adobe DNG 1.x / TIFF-EP, lossless JPEG per ITU-T T.81). I'm starting a clean-room, pure-Rust CinemaDNG decoder now (separate issue + PR), since it needs no SDK.
R3D (RED) and BRAW (Blackmagic, BRAW Support #290), and ProRes RAW (ProRes RAW decode #345), have no public format spec; the only routes are the vendors' proprietary C/C++ SDKs. Under the pure-Rust / no-unsafe / clean-room rules a native decoder isn't possible without reverse engineering, which I won't do. Would you accept an optional SDK bridge for these, confined to crates/platform (the one crate already allowed unsafe for OS media FFI), loaded only if the user has installed the vendor's SDK/runtime themselves, off by default, never bundled — with FilmCraft's own decoders and transcoding as the fallback? Or should camera RAW stay out of scope apart from public-spec formats?
Adding to @vangel76's question above (@echelon, @bflatastic): we've taken exactly that route for BRAW, and it is now a concrete pull request to look at (#1954) rather than a hypothetical.
What it looks like in practice:
The bridge lives in crates/platform/src/braw, i.e. the crate that already allows unsafe for OS media FFI; it is the only new #[allow(unsafe_code)] module, and its declarations are transcribed from the vendor's published headers (which carry the Boost Software License 1.0).
The runtime (libBlackmagicRawAPI.so / BlackmagicRawAPI.dll / BlackmagicRawAPI.framework, Blackmagic RAW 6.0+) is loaded at run time, only when the first .braw file opens, and never bundled. Without it, a .braw file fails to open with a message saying what to install; nothing is loaded at startup.
Nothing else changes: FilmCraft's own decoders, the import fallbacks and transcoding are untouched, and the tests skip themselves when no runtime is installed, so the suite (and CI) stays green without it.
The interface is used only after QueryInterface confirms its ids — the SDK's vtables changed between versions, so an older runtime is refused instead of called at the wrong slots — and the decoder's callbacks never unwind into the API and never take FilmCraft's lock.
It is tested on Linux (SDK sample clips and 6K camera clips), on Windows 11 and on macOS 15.8 (the latter two in virtual machines with the official runtime): the same clips decode to the same numbers on all three.
If the answer here is "optional vendor SDK bridges are fine, as long as they are never bundled and nothing else depends on them", then the BRAW PR is ready to review, and R3D / ARRIRAW / Sony RAW / Canon RAW (also vendor-SDK-only) become possible the same way. If the answer is "no", the PR can simply be closed and nothing else in the tree is affected — the ADR 0001 addendum is marked proposed precisely because this is your call.
A concrete proposal for R3D is now up as a draft: #3016. It decodes Nikon ZR R3D NE through RED's SDK as an opt-in feature (off by default, SDK supplied by the user, never bundled), runs the SDK in a separate helper process, and proposes the rules it needs as ADR 0002 and an AGENTS.md paragraph, both marked as proposed. It takes a different shape from #1954 and the PR explains why; happy to follow whichever pattern you prefer for vendor SDKs.
Activity
ccmj-js commentedon Oct 10, 2026
I was able to open an MXF - but it was slow processing a directory of files to get info on them. Application would hang while processing each file for info (frame rate, etc). Opening file directly was pretty fast, but slower than other types on my machine. Filmcraft 0.5.0 was version I was using.
MXF File I tested with:
`Format : MXF
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
File size : 122 MiB
Duration : 6 s 506 ms
Overall bit rate : 157 Mb/s
Encoded date : 2018-05-23 18:22:42.000
Writing application : CANON XF400 1.00
Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings : 2 Ref Frames
Format settings, CABAC : No
Format settings, Reference frames : 2 frames
Format settings, GOP : M=3, N=12
Format settings, wrapping mode : Frame
Codec ID : 0D01030102106001-0401020201314001
Duration : 6 s 506 ms
Bit rate : 152 Mb/s
Maximum bit rate : 150 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.766
Stream size : 118 MiB (97%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709`
vangel76 commentedon Oct 11, 2026
Question for the maintainers (@echelon, @bflatastic), so contributors know which way to go on camera RAW:
unsafe/ clean-room rules a native decoder isn't possible without reverse engineering, which I won't do. Would you accept an optional SDK bridge for these, confined tocrates/platform(the one crate already allowedunsafefor OS media FFI), loaded only if the user has installed the vendor's SDK/runtime themselves, off by default, never bundled — with FilmCraft's own decoders and transcoding as the fallback? Or should camera RAW stay out of scope apart from public-spec formats?I won't start on R3D/BRAW until you've decided.
#1065: clean-room DNG / CinemaDNG decoder crate
txiki739 commentedon Oct 14, 2026
Adding to @vangel76's question above (@echelon, @bflatastic): we've taken exactly that route for BRAW, and it is now a concrete pull request to look at (#1954) rather than a hypothetical.
What it looks like in practice:
crates/platform/src/braw, i.e. the crate that already allowsunsafefor OS media FFI; it is the only new#[allow(unsafe_code)]module, and its declarations are transcribed from the vendor's published headers (which carry the Boost Software License 1.0).libBlackmagicRawAPI.so/BlackmagicRawAPI.dll/BlackmagicRawAPI.framework, Blackmagic RAW 6.0+) is loaded at run time, only when the first.brawfile opens, and never bundled. Without it, a.brawfile fails to open with a message saying what to install; nothing is loaded at startup.QueryInterfaceconfirms its ids — the SDK's vtables changed between versions, so an older runtime is refused instead of called at the wrong slots — and the decoder's callbacks never unwind into the API and never take FilmCraft's lock.It is tested on Linux (SDK sample clips and 6K camera clips), on Windows 11 and on macOS 15.8 (the latter two in virtual machines with the official runtime): the same clips decode to the same numbers on all three.
If the answer here is "optional vendor SDK bridges are fine, as long as they are never bundled and nothing else depends on them", then the BRAW PR is ready to review, and R3D / ARRIRAW / Sony RAW / Canon RAW (also vendor-SDK-only) become possible the same way. If the answer is "no", the PR can simply be closed and nothing else in the tree is affected — the ADR 0001 addendum is marked proposed precisely because this is your call.
admbe commentedon Oct 23, 2026
A concrete proposal for R3D is now up as a draft: #3016. It decodes Nikon ZR R3D NE through RED's SDK as an opt-in feature (off by default, SDK supplied by the user, never bundled), runs the SDK in a separate helper process, and proposes the rules it needs as ADR 0002 and an AGENTS.md paragraph, both marked as proposed. It takes a different shape from #1954 and the PR explains why; happy to follow whichever pattern you prefer for vendor SDKs.