FFmpeg developer. I maintain the Vulkan subsystem, the audio codecs, and the FFT system and its assembly.
FFmpeg開発者。Vulkanサブシステム、音声コーデック、FFTとそのアセンブリを保守。
Alliance for Open Media: worked on the AV1 specification, contributing its segmentation and adaptive quantization system. Now working on OAC, the successor to Opus.
Alliance for Open Media:AV1仕様の策定に参加し、セグメンテーションと適応量子化の仕組みを担当。現在はOpusの後継コーデックOACに取り組んでいる。
Khronos: working on the Vulkan specifications, on compute and video.
Khronos:Vulkan仕様、特にコンピュートとビデオの仕様策定に取り組んでいる。
Member of VideoLAN.
VideoLANのメンバー。
Filmmaker.
映像作家。
2 / why
Why I'm doing this
なぜこれをやっているのか
For my own films.
自分の映画のために。
The tools I needed didn't exist.
必要なツールが存在しなかった。
The ones that did weren't interoperable.
存在するものは互いに相互運用できなかった。
Or were restricted: one operating system, one vendor's hardware.
あるいは制限されていた:ひとつのOS、ひとつのベンダーのハードウェア。
Or prohibitively expensive. And subscription-based.
あるいは法外に高価。しかもサブスクリプション制。
So I wrote them. In the open.
だから自分で書いた。オープンに。
3 / the pipeline
From the camera to the archive
カメラからアーカイブまで
Every stage of a production reads and writes pictures, and every stage is somebody's software. This talk follows them in order.
制作のすべての工程が映像を読み書きし、そのどれもが誰かのソフトウェアだ。この発表はその順に追っていく。
First: decoding.
まずはデコードから。
4 / ffmpeg + vulkan
Vulkan video in FFmpeg, today
FFmpegにおけるVulkanビデオの現在
Vulkan Video engines 固定機能のビデオエンジン
decodeデコード
H.264 · HEVC · AV1
6.1
VP9
8.0
encodeエンコード
H.264 · HEVC
7.1
AV1
8.0
Fixed silicon: 8 to 12 bits, the chroma formats the chip was built for.
固定されたシリコン:8〜12bit、チップが想定したクロマ形式のみ。
Compute shaders コンピュートシェーダー
decodeデコード
FFv1 · ProRes RAW
8.0
ProRes · DPX
8.1
APV
9.0
encodeエンコード
FFv1 8.0 · ProRes 8.1 · APV next
comingこれから
JPEG · PNG · JPEG 2000 decoders, MJPEG encoder
—
Any Vulkan GPU, and whatever the format has: 16-bit, float, Bayer, 4:4:4.
あらゆるVulkan GPUで、フォーマットが持つものすべてに対応:16bit、浮動小数点、Bayer、4:4:4。
9 + 6
Vulkan decoders and encoders upstream, and 20 Vulkan filters Vulkanデコーダー・エンコーダー、Vulkanフィルター20種
1 line
for an API user: hw_device_ctx · CLI: -hwaccel vulkan API利用者は1行で有効化
0 copies
packets are host-mapped and read by DMA パケットはホストマップされ、DMAで直接読まれる
When the device can't, libavcodec drops Vulkan from the list and decodes on the CPU. Automatically.
デバイスが対応できなければ、libavcodecはVulkanを候補から外してCPUでデコードする。自動で。
Release each first shipped in. ProRes decoder by averne, ProRes encoder by IndecisiveTurtle; the other compute codecs are mine.
数字は最初に収録されたリリース。ProResデコーダーはaverne、ProResエンコーダーはIndecisiveTurtle、その他のコンピュートコーデックは私が書いた。
5 / performance
The compute codecs, against the CPU
コンピュートコーデックとCPUの比較
One laptop: an i5-1345U with 12 threads against an RX 6900 XT eGPU, fps, measured 2026-09 to 2026-10. Each side leaves the decoded frame where its next step would use it: in RAM for the CPU, in VRAM for the GPU, so no download over PCIe is counted. The GPU reads each packet from host memory by DMA; PNG's packet was uploaded once and reused. PNG's CPU column is one core: one image is one inflate.
同一のノートPC:i5-1345U(12スレッド)対 RX 6900 XT(外付けGPU)、fps、2026年9〜10月計測。デコード後のフレームは次の工程が使う場所に置いたまま:CPUはRAM、GPUはVRAM。PCIe経由のダウンロードは含まない。GPUは各パケットをDMAでホストメモリから読む(PNGはパケットを一度だけアップロードして再利用)。PNGのCPU値は1コア:1枚の画像は1回のinflate。
6 / no hybrids
Every stage has to stay on the GPU
すべての工程をGPU上に留めなければならない
A hybrid decoder, CPU for the bitstream and GPU for the rest, never wins: the data it moves costs more than the work it saves.
ビットストリームはCPU、残りはGPUというハイブリッドデコーダーは決して勝てない:移動するデータのコストが、節約する処理を上回る。
The official ProRes RAW decoders are hybrids: the entropy decode on the CPU, only the DCT on the GPU, then the picture copied back to the CPU.
公式のProRes RAWデコーダーはハイブリッド:エントロピー復号はCPU、GPUで行うのはDCTだけ、そして画像はまたCPUへコピーされる。
Ours: the packet goes up once, by DMA. The picture never comes back down.
私たちのデコーダー:パケットはDMAで一度だけ送り上げる。画像は二度と戻ってこない。
Not to be confused with running a CPU and a GPU decoder side by side on different frames, as RAWcooked now does: nothing crosses between them mid-frame.
RAWcookedのようにCPUとGPUのデコーダーを別々のフレームで並行に動かすのとは別物:フレームの途中で両者の間をデータが行き来することはない。
7 / png
PNG: Huffman on top of Huffman
PNG:ハフマンの上にハフマン
Still everywhere: the web's lossless image, screenshots, illustration and comics, textures, 16-bit image sequences, DCP subtitles. And one image is decoded by one CPU core: zlib's inflate is serial, end to end.
今も至るところで使われている:Webのロスレス画像、スクリーンショット、イラストや漫画、テクスチャ、16bitの連番画像、DCPの字幕。そして1枚の画像は1つのCPUコアでデコードされる:zlibのinflateは最初から最後まで直列。
Huffman codes whose tables are Huffman coded, in blocks nobody indexes, producing references to earlier output, which is then predicted from itself.
表そのものがハフマン符号化されたハフマン符号が、誰も索引を持たないブロックの中にあり、過去の出力への参照を生み、その出力はさらに自分自身から予測される。
So decoding one DEFLATE stream in parallel was long thought impossible. It isn't.
だから、ひとつのDEFLATEストリームを並列にデコードすることは長い間不可能だと考えられてきた。そうではない。
I'm writing a paper on it.
現在、これについての論文を執筆中。
8 / resynchronization
DEFLATE resynchronizes faster than JPEG
DEFLATEはJPEGより速く自己同期する
Start a decoder at a random bit. On photographs it lands back on a true symbol boundary within about 20 bits half the time, and within 192 bits 99% of the time. The JPEG decoder was built on 256-bit subsequences.
ランダムなビットからデコーダーを開始する。写真では、半分は約20bit以内に、99%は192bit以内に、正しいシンボル境界へ戻ってくる。JPEGデコーダーは256bitのサブシーケンスを前提に作られた。
Why: DEFLATE's only state is the bit position. Two decoders are in sync exactly when they sit on the same bit. JPEG's must also agree on where in the block, and which component, they are.
理由:DEFLATEの状態はビット位置だけ。2つのデコーダーは同じビットに立った瞬間に同期する。JPEGではさらにブロック内の位置と成分まで一致しなければならない。
Screenshots and fractals take longer, so the PNG decoder uses 512-bit subsequences. Noise, which barely resyncs, is pushed through in order and still decodes correctly.
スクリーンショットやフラクタルは時間がかかるため、PNGデコーダーは512bitのサブシーケンスを使う。ほとんど同期しないノイズは順に押し流し、それでも正しくデコードされる。
9 / inflate on the gpu
zlib, entirely on the GPU
zlibを、完全にGPU上で
The piece of this work I'm proudest of. Every serial dependency in DEFLATE gets its own parallel answer.
この仕事の中で、最も誇りに思っているもの。DEFLATEの直列依存のひとつひとつに、それぞれの並列解を。
10 / png results
PNG on the GPU
GPU上のPNG
14×
a 4K RGB photograph, 142 ms → 9.9 ms. With the download over Thunderbolt: 49 ms 4K RGB写真。Thunderbolt経由のダウンロード込みでも49ms
230 / 230
bit-exact with the software decoder. APNG goes to software; corrupt files are rejected by both ソフトウェアデコーダーとビット一致。APNGはソフトウェアへ、破損ファイルは両者とも拒否
A file made only of fixed-Huffman blocks is slower: those blocks still chain one after another.
固定ハフマンブロックだけのファイルは遅い:そうしたブロックは今も1つずつ連鎖する。
RX 6900 XT eGPU vs libavcodec with zlib 1.3.2 on one core of an i5-1345U: one image is one inflate. Packet already on the GPU, median of 3. Corpus: 249 files, FATE, PngSuite, generated and real. Draft PR #24655, building on the JPEG decoder in PR #24652.
RX 6900 XT(外付けGPU)対 i5-1345Uの1コアで動くlibavcodec + zlib 1.3.2:1枚の画像は1回のinflate。パケットはGPU上、3回の中央値。コーパス249ファイル。ドラフトPR #24655、JPEGデコーダー(PR #24652)が土台。
11 / jpeg 2000
JPEG 2000 on the GPU
GPU上のJPEG 2000
Still the format professional cinema is delivered in: every DCP is JPEG 2000. IMF masters and many archives keep it too.
今もプロの映画の納品形式:すべてのDCPはJPEG 2000だ。IMFマスターや多くのアーカイブもこれで保存している。
Decoding it on a CPU has always been too slow. Filmmakers export their film, and then can't watch it: not in real time, not at full resolution.
CPUでのデコードは常に遅すぎた。映像作家は自分の映画を書き出しても、それを観ることができない:リアルタイムでも、フル解像度でも。
The way through: serial inside a codeblock, parallel across the ~26,000 of a 4K frame.
突破口:コードブロック内は直列、4Kフレームの約26,000個のコードブロック間は並列。
DCI 2K, same GPU · the CPU decoder on a laptop's i5-1345U: 28 DCI 2K・同じGPU・ノートPCのi5-1345UでのCPUデコーダーは28fps
18 fps
8K 16-bit RGB 8K・16bit RGB
No reduced-resolution output, on purpose. It's a hack for decoders too slow to show every pixel; at 5× realtime at full resolution it has no reason to exist.
低解像度出力は意図的にサポートしない。全画素を表示できない遅いデコーダーのための苦肉の策であり、フル解像度でリアルタイムの5倍出るなら存在する理由がない。
Laptops too: on a four-year-old laptop's Iris Xe, DCI 2K decodes at 18.8 fps and DCI 4K at 13.5, about twice as fast as before this week's Intel work.
ノートPCでも:4年前のノートPCのIris XeでDCI 2Kは18.8fps、DCI 4Kは13.5fps。今週のIntel向け最適化で約2倍に。
Lossless and integer paths are bit-exact with FFmpeg's software decoder on AMD and Intel; the float 9/7 path is within ±1 LSB on 0.008–0.024% of samples. Test streams: synthetic, OpenJPEG -cinema2K/-cinema4K at 250 Mbit/s. Not merged yet; HTJ2K, multi-tile and multi-layer streams go to the CPU decoder.
ロスレスと整数パスはAMD・IntelともにFFmpegのソフトウェアデコーダーとビット一致。浮動小数点9/7パスは全サンプルの0.008〜0.024%で±1LSB以内。テストストリームは合成(OpenJPEG -cinema2K/-cinema4K、250Mbit/s)。未マージ。HTJ2K・マルチタイル・マルチレイヤーはCPUデコーダーへ。
13 / ffv1
FFv1: the archives' codec, now on any GPU
FFv1:アーカイブのためのコーデックが、あらゆるGPUで
A format archives trust, and more of them every year.
アーカイブが信頼するフォーマット。採用は年々広がっている。
3 PB
the BFI National Archive's DPX film scans, now FFv1 in Matroska, with RAWcooked, since 2019 BFIナショナル・アーカイブのDPXフィルムスキャン。RAWcookedで2019年からFFv1/Matroskaへ
Preferred
Library of Congress: FFv1/Matroska moved up from "Acceptable", December 2023 米国議会図書館:2023年12月、「許容」から「推奨」形式へ
RFC 9043
an IETF standard since 2021: open, patent-free, free to read 2021年からIETF標準:オープン、特許なし、誰でも読める
Also: Österreichische Mediathek, CUNY TV, City of Vancouver Archives, NYPL, Indiana University, Smithsonian Institution Archives, Irish Film Institute, WGBH…
その他:オーストリア・メディアテーク、CUNY TV、バンクーバー市公文書館、ニューヨーク公共図書館、インディアナ大学、スミソニアン協会アーカイブ、アイルランド映画協会、WGBH…
Macs too: Vulkan through KosmicKrisp, so one code base serves every platform. A native Metal port is "not worth the effort, for now". An M4's GPU now encodes 11–17% faster than its CPU.
Macでも:KosmicKrisp経由のVulkanで、ひとつのコードベースが全プラットフォームに対応。Metalへのネイティブ移植は「今のところ労力に見合わない」。M4のGPUはCPUより11〜17%速くエンコードする。
Figures: Jérôme Martinez, MediaArea, "FFV1: a long journey" and "Optimizing FFV1 for Apple Silicon", No Time to Wait 10, October 2026, CC BY.
出典:Jérôme Martinez(MediaArea)、No Time to Wait 10(2026年10月)の発表2件、CC BY。
14 / ffv1 bayer
Compressing uncompressed RAW: FFv1 Bayer
非圧縮RAWを圧縮する:FFv1 Bayer
ARRIRAW is uncompressed: 12-bit photosites, packed, 13-bit on the ALEXA 35. An ALEXA Mini LF at open gate writes about 1.8 TB an hour.
ARRIRAWは非圧縮:12bitのフォトサイトをそのまま詰めたもの(ALEXA 35では13bit)。ALEXA Mini LFのオープンゲートでは1時間あたり約1.8TB。
FFv1 version 4 codes the mosaic itself. Each 2×2 quad becomes a green mean, a green difference, red and blue, decorrelated by a reversible colour transform whose coefficients are searched per slice.
FFv1バージョン4はモザイクをそのまま符号化する。2×2の各クアッドを緑の平均・緑の差分・赤・青に分け、スライスごとに係数を探索する可逆色変換で無相関化する。
Lossless, a CRC per slice, an IETF standard. Software and Vulkan encoders and decoders, merged in 2026, sponsored by the Sovereign Tech Fund.
ロスレス、スライスごとのCRC、IETF標準。ソフトウェアとVulkanのエンコーダー・デコーダーは2026年にマージ済み。Sovereign Tech Fundの支援による。
15 / ffv1 context=2
A new FFv1 context model: smaller and faster
FFv1の新しいコンテキストモデル:より小さく、より速く
-context 2: the two nearest gradients, coarsely quantized: 13 contexts a plane. With 1024 slices, a big context set never gets the data to adapt.
-context 2:最も近い2つの勾配を粗く量子化し、1プレーンあたり13コンテキスト。1024スライスでは、大きなコンテキストセットは適応に足るデータを得られない。
832 B
of probability state per slice, against 23 KB with context 0 and 324 KB with context 1 スライスあたりの確率状態。context 0は23KB、context 1は324KB
0
changes to decoders: the table travels in the extradata, which every FFv1 decoder already reads. Backwards compatible. デコーダーの変更は不要:テーブルはextradataで運ばれ、既存のFFv1デコーダーはすべてそれを読める。後方互換。
Film scan: 6464×4852 16-bit RGB, 1024 slices; decode on an RX 6900 XT, bitstream in VRAM. Stills: measured today, three S1II RW2 frames, FFv1 v4 Bayer, CPU encoder. The default in ffv1_vulkan since September 2026.
フィルムスキャン:6464×4852 16bit RGB、1024スライス、RX 6900 XTでデコード(ビットストリームはVRAM上)。静止画:本日計測、S1IIのRW2 3枚、FFv1 v4 Bayer、CPUエンコーダー。2026年9月からffv1_vulkanの既定値。
16 / the pipeline
From the camera to the archive
カメラからアーカイブまで
Next: developing the RAW.
次:RAWの現像。
17 / the camera
The camera is no longer the problem
もはやカメラは問題ではない
Prosumer cameras already have sensor parity with ARRI's cinema cameras.
プロシューマー向けカメラのセンサーは、すでにARRIのシネマカメラと同等の水準にある。
5.8K
16-bit linear Bayer, ProRes RAW, in the camera · Lumix S1II 16bitリニアBayer、ProRes RAWをカメラ内収録
$50,000
the ARRI its sensor performs like そのセンサーに匹敵するARRIの価格
People shoot on the street with a crew of two. Their sensors are as good as a studio's.
2人のクルーで路上撮影する人たちがいる。そのセンサーはスタジオのものに劣らない。
What matters now is the software.
今、重要なのはソフトウェアだ。
18 / libcraw
libcraw: a library, first and foremost
libcraw:何よりもまずライブラリ
Cinema RAW processing. Camera Bayer data in, scene-linear colour out, on the GPU. Decoding is FFmpeg's job, rendering is libplacebo's; libcraw sits between them.
シネマRAW処理。カメラのBayerデータを受け取り、シーンリニアな色を返す。GPU上で。デコードはFFmpeg、描画はlibplaceboの役目で、libcrawはその間に立つ。
The caller owns the VkDevice, the queues and the command buffers. libcraw records into them and never submits: it drops into anything that already has a Vulkan device.
VkDevice・キュー・コマンドバッファは呼び出し側が所有。libcrawは記録するだけでサブミットしない:Vulkanデバイスを持つものなら何にでも組み込める。
BSD-2-Clause. C23, Vulkan 1.4. Five weeks old.
BSD-2-Clause。C23、Vulkan 1.4。誕生から5週間。
19 / the chain
What libcraw does, and what it costs
libcrawの処理内容と、そのコスト
5760×3040 Lumix S1II ProRes RAW, every stage on, RX 6900 XT, RADV. GPU time per pass, warm, median (DESIGN.md §21.4). Down from 19.6 ms after subgroup streaming and pass fusion. Every stage has a CPU reference implementation the tests hold the shaders to.
5760×3040のLumix S1II ProRes RAW、全ステージ有効、RX 6900 XT、RADV。パスごとのGPU時間(ウォーム、中央値)。サブグループによるストリーミングとパス融合で19.6msから短縮。全ステージにCPUリファレンス実装があり、テストでシェーダーと照合している。
20 / aces 2.0
A full ACES 2.0 pipeline
ACES 2.0パイプラインの全体像
ACES 2.0 folds 1.x's RRT and ODT into one Output Transform per display: a new tone scale, chroma compression, and gamut mapping in a colour appearance model.
ACES 2.0では1.xのRRTとODTが、ディスプレイごとのひとつの出力変換にまとめられた:新しいトーンスケール、クロマ圧縮、色の見えモデルによるガマットマッピング。
21 / where libcraw sits
Where libcraw sits
libcrawの位置づけ
libcraw replaces the vendor SDK and the Input Transform. Sensor to ACES, on the GPU, one library for every camera. And it does what ACES leaves to the vendor: raw denoise, highlight reconstruction, lens correction.
libcrawはベンダーSDKと入力変換を置き換える。センサーからACESまで、GPU上で、全カメラ共通のひとつのライブラリで。さらにACESがベンダー任せにしている処理も行う:RAWノイズ除去、ハイライト復元、レンズ補正。
XYZ → ACES goes through OpenColorIO: OCIO generates the transform as a Vulkan shader, which we compile and embed.
XYZ→ACESはOpenColorIOを通す:OCIOが変換をVulkanシェーダーとして生成し、それをコンパイルして埋め込む。
22 / scene-referred
Or: stay scene-referred
あるいは:シーンリファードのままで
Sensor RAW processing, and nothing else. Grade it later, anywhere.
センサーRAW処理だけ。グレーディングは後で、どこででも。
No tone curve, no gamut mapping, no LUT, no look, no grain. Those sections grey out and come off the display too, so the screen shows what the file holds.
トーンカーブ・ガマットマッピング・LUT・ルック・グレインはすべてなし。これらの項目はグレーアウトし、表示からも外れる。画面はファイルの中身そのもの。
ACES2065-1, ACEScg and XYZ as lossless FFv1 half or single float. ACEScct in any codec of 10 bits or more. A 16-bit ACEScct file decodes back to within 0.009% of ACEScg.
ACES2065-1・ACEScg・XYZはFFv1の半精度/単精度浮動小数点でロスレスに。ACEScctは10bit以上の任意のコーデックで。16bitのACEScctファイルはACEScgに対し0.009%以内で復元する。
23 / vulkan, end to end
Vulkan, from decode to display to encode
デコードから表示、エンコードまでVulkanで
24 / a processing package
A darktable for video, stills and sound
映像・静止画・音声のためのdarktable
Like Darkroom, darktable or RawTherapee: a whole processing package. Except it handles video, images and audio. cineview is the proof that the library holds up.
Darkroom、darktable、RawTherapeeのような、ひとつの完結した現像パッケージ。ただし映像・静止画・音声のすべてを扱う。cineviewは、ライブラリが実用に耐えることの証明。
Video 映像
ProRes RAW, developed by libcrawProRes RAWをlibcrawで現像
V-Log HEVC, H.264, ProRes 422: white balance on a developed pictureV-LogのHEVC・H.264・ProRes 422:現像済みの映像にもWB補正
Retimed to 23.976–60 fps, frame for frame; every other frame, for flickering LED lamps23.976〜60fpsへ1フレームずつリタイム。LEDのちらつきには1フレームおき再生
Lens correction, rotate, cropレンズ補正・回転・クロップ
Stills 静止画
Panasonic RW2 raw stills: a new FFmpeg decoder, bit-exact with LibRaw on 801 files, 3× its speed per threadPanasonic RW2:新しいFFmpegデコーダー。801ファイルでLibRawとビット一致、スレッドあたり3倍速
Cull a card: mark, delete, with the camera's JPEGカードの選別:マークして、カメラのJPEGごと削除
Sound 音声
The audio clock drives playback音声クロックが再生を駆動
Copy, Opus, AAC, FLAC or WAV, cut on a sample boundaryコピー・Opus・AAC・FLAC・WAV。サンプル単位でカット
Four mono tracks in, the camera's stereo pair outモノラル4トラックからカメラのステレオペアを抽出
296 film simulations, film grain by gauge and stock, HDR grading on a colour-managed display, and ten encoder families, six of them on the GPU.
296種のフィルムシミュレーション、ゲージとストックで指定するフィルムグレイン、カラーマネジメントされたディスプレイでのHDRグレーディング、10系統のエンコーダー(うち6系統はGPU)。
25 / the pipeline
From the camera to the archive
カメラからアーカイブまで
Next: into the edit.
次:編集へ。
26 / the field, then the editor
From the field to the editor
ロケ現場から編集ソフトへ
Before any editor: cineview turns a laptop into the whole review station, out on location.
編集ソフトの前に:cineviewはノートPC1台を、ロケ現場でのレビュー環境そのものにする。
37 fps
2 Gbit/s 5.8K ProRes RAW HQ, decoded on a four-year-old laptop's integrated GPU, an Iris Xe: faster than the 29.97 it was shot at 2Gbit/sの5.8K ProRes RAW HQを4年前のノートPCの内蔵GPU(Iris Xe)でデコード:撮影時の29.97fpsより速い
+82%
from this week's Intel work, 20.5 → 37.3 fps, the same bits out. Non-HQ: 50.8 fps 今週のIntel向け最適化で20.5→37.3fps、出力は同一。非HQは50.8fps
On location ロケ現場で
Inspect the RAW, give it a first grade, review it with the director: entirely in the field, with only a laptopRAWの確認、仮グレーディング、監督とのレビュー:すべて現場で、ノートPC1台で
Nothing to send to a lab and wait forラボに送って待つ必要はない
ISO noise ISOノイズ
See on the spot whether a high-ISO shot holds up after decoding, or whether to shoot it again高ISOのショットがデコード後に使えるか、撮り直すべきかをその場で確認
The raw denoise knows the camera's noise, measured from ISO 640 to 12800RAWノイズ除去はカメラのノイズをISO 640〜12800で実測したモデルで把握している
White balance ホワイトバランス
Automatic, from the RAW: a GPU histogram, an estimator on the camera's own locus, a smoother that never jumpsRAWから自動で:GPUヒストグラム、カメラ固有の軌跡上の推定器、決して跳ねないスムーザー
Documentary, a minimal crew, no control over the light: shoot without baking in a white balance, and without lossy, messy conversions laterドキュメンタリーや最小限のクルーで照明を制御できなくても:ホワイトバランスを焼き込まずに撮れ、後で劣化する面倒な変換も要らない
Every GPU codec lives in FFmpeg's own hardware acceleration framework. Anything built on FFmpeg gets them, and falls back to the CPU on its own.
すべてのGPUコーデックはFFmpeg標準のハードウェアアクセラレーション基盤の中にある。FFmpegの上に作られたものは何でもそれを使え、必要なら自動でCPUに切り替わる。
Playing 再生
mpv plays every one of the Vulkan codecs already, automaticallympvは全Vulkanコーデックに自動で対応済み
An API user enables them with one line: hw_device_ctxAPI利用者は1行で有効化できる
Editing 編集
Shotcut, the NLE, uses FFmpeg's hardware decoding and encodingNLEのShotcutはFFmpegのハードウェアデコード・エンコードを利用
Blender: a pull request adds the Vulkan codecs to its video editorBlender:Vulkanコーデックを動画編集機能に加えるプルリクエストあり
Next: RAW 次:RAW現像
libcraw as an FFmpeg filter: everything above develops camera RAW tooFFmpegフィルターとしてのlibcraw:上のすべてがカメラRAWを現像できるようになる
Or embedded: any host with a Vulkan device; libcraw records into its command buffersあるいは直接組み込み:Vulkanデバイスを持つホストなら何でも、そのコマンドバッファに記録する
27 / the pipeline
From the camera to the archive
カメラからアーカイブまで
Next, and still to build: encoding, and mastering.
次、そしてこれから作るもの:エンコードとマスタリング。
28 / next: jpeg 2000 encoding
Next: encoding JPEG 2000 on the GPU
次へ:GPUでJPEG 2000をエンコードする
The decoder was the first step. Every part of it runs backwards: the wavelet, the codeblocks, the MQ coder. Every DCP is a JPEG 2000 encode.
デコーダーは最初の一歩。そのすべてを逆向きに動かせる:ウェーブレット、コードブロック、MQ符号器。そしてすべてのDCPはJPEG 2000のエンコードだ。
250 Mbit/s
DCI's limit, for 2K and 4K alike: about 1.3 MB a frame either way DCIの上限は2Kも4Kも同じ:どちらも1フレーム約1.3MB
4.7 → 1.2
bits a pixel, from 2K to 4K. The higher the resolution, the more the encoder's choices are the picture. 2Kから4Kで1画素あたりのビット数。解像度が上がるほど、エンコーダーの判断がそのまま画質になる。
Consumer GPUs parallelize, and search through solutions, much faster than server CPUs.
民生GPUは、サーバーCPUよりはるかに速く並列化し、解を探索できる。
29 / next: hdr mastering
No one independent is mastering in HDR
インディペンデントでHDRマスタリングをしている人はいない
Most TVs and phones sold today show HDR. YouTube and Vimeo take it.
今売られているテレビやスマートフォンの多くはHDRを表示できる。YouTubeもVimeoも受け付ける。
The cameras capture far more than an SDR master keeps.
カメラは、SDRマスターが残せるよりはるかに多くを捉えている。
The only barrier is the software. Everyone uses Resolve to generate Dolby Vision.
唯一の障壁はソフトウェア。Dolby Visionの生成には、誰もがResolveを使っている。
I'd like to change that. It's what I want to work on next.
それを変えたい。次に取り組みたいのはそれだ。
30 / state
Where things are
現状
Contact: dev@lynne.ee連絡先:dev@lynne.ee
Discussion
質疑応答
Lynne — FFmpeg · dev@lynne.ee
31 / my situation
My situation
私の状況
I'm looking to move to Japan.
日本への移住を考えています。
Most of my professional connections of the past few years are here.
ここ数年の仕事上のつながりの大半は、日本にあります。
To stay, I need a visa.
滞在を続けるには、ビザが必要です。
What I'd hope for: a way to work with IMAGICA, while I keep working on open source, and on my films.
私が望んでいるのは、IMAGICAと協力しながら、オープンソースの仕事と映画制作を続けられる形です。
IMAGICA
The pipeline in this talk, built and tested against a real lab's workこの発表のパイプラインを、実際のラボの仕事で作り、検証する
Open source オープンソース
The internet depends on FFmpeg, and I maintain parts of itインターネットはFFmpegに依存しており、私はその一部を保守しています
Film 映画制作
The reason all of this work existsこの仕事のすべてが存在する理由
32 / together
What we could do together
一緒にできること
Archive: FFv1 for film scans and camera RAW, DPX and JPEG 2000 on the GPU. Your formats are my formats.
アーカイブ:フィルムスキャンとカメラRAWにはFFv1、DPXとJPEG 2000はGPUで。あなた方のフォーマットは、私のフォーマットでもある。
Delivery: fast JPEG 2000 decode for DCP and IMF QC today, a GPU encoder next.
納品:DCP・IMFのQCには今すぐ高速なJPEG 2000デコードを、次はGPUエンコーダーを。
Validation: real lab material and reference masters to hold the open tools to.
検証:オープンなツールを照合するための、ラボの実素材とリファレンスマスター。
Funding: merging the JPEG 2000, JPEG and PNG decoders; building the J2K encoder and an open HDR mastering path.
資金:JPEG 2000・JPEG・PNGデコーダーのマージと、J2KエンコーダーおよびオープンなHDRマスタリング環境の開発。
And a path into the lab for independent filmmakers: open tools on set, IMAGICA for what needs a room.
そしてインディペンデント映像作家がラボへ至る道:現場ではオープンなツールを、部屋が必要な仕事はIMAGICAで。
33 / the obvious question
Our business models look like they're at odds
私たちのビジネスモデルは相反するように見える
IMAGICA
A full laboratory: archival, restoration, mastering完全なラボ:アーカイブ、修復、マスタリング
Graded mastering rooms for picture and sound映像と音響のための、調整されたマスタリングルーム
Me 私
Fully open source, free for anyone完全なオープンソース、誰でも無料
For the people shooting on the street with a minimal crew最小限のクルーで路上撮影する人たちのために
A lab doesn't sell software. It sells calibrated rooms, colourists, mixers, scanners, QC, and decades of custody. Better free tools open-source none of that.
ラボが売っているのはソフトウェアではない。調整された部屋、カラリスト、ミキサー、スキャナー、QC、そして何十年にもわたる保管。無料のツールが良くなっても、そのどれもオープンソースにはならない。
Open tools grow the market: more independent films kept scene-referred and mastered in HDR means more work worth finishing properly. In a room like yours.
オープンなツールは市場を広げる:シーンリファードで保たれHDRでマスタリングされるインディペンデント作品が増えれば、きちんと仕上げる価値のある仕事が増える。あなた方のような部屋で。
The industry already runs on open infrastructure: ACES, OpenEXR, OpenColorIO. Studios and labs fund it because a shared foundation costs everyone less.
業界はすでにオープンな基盤の上で動いている:ACES、OpenEXR、OpenColorIO。共有の土台は皆のコストを下げるから、スタジオやラボがそれに資金を出している。
34 / precedent
An archive has done this before
あるアーカイブが、すでにこれをやっている
2010: the Österreichische Mediathek had to digitize its video collection, losslessly. The products on offer were expensive black boxes: MXF / JPEG 2000 files that could not be opened without the vendor's system.
2010年:オーストリア・メディアテークは映像コレクションをロスレスでデジタル化する必要があった。市販品は高価なブラックボックスで、MXF/JPEG 2000のファイルはベンダーのシステムなしでは開けなかった。
Herman Lewetz, Österreichische Mediathek
“We took our money and we asked the developer Michael Niedermayer directly.”
「私たちは自分たちのお金を持って、開発者のMichael Niedermayerに直接頼んだ。」
Each step needed money and someone's time. “Allocate continuous resources (time or money).” — Peter Bubestinger, 2018
どの段階にもお金と誰かの時間が必要だった。「継続的にリソース(時間かお金)を割り当てよ。」— Peter Bubestinger、2018年
After Jérôme Martinez, "FFV1: a long journey", No Time to Wait 10, October 2026; Scart/PACKED interview with Peter Bubestinger and Herman Lewetz, 2014.
出典:Jérôme Martinez「FFV1: a long journey」(NTTW10、2026年10月)、Peter BubestingerとHerman Lewetzへのインタビュー(2014年)。
