react-native-skia-webgpu-video 0.1.0-beta.2 → 0.1.0-beta.4

package/android/src/main/java/com/azzapp/rnskv/VideoEncoder.java

@@ -109,6 +109,9 @@ public class VideoEncoder {
 
   private Surface inputSurface;
 
+  // Only for CPU readback frames, created on the first one: the GPU export
+  // presents to inputSurface through WebGPU instead, and a window has one
+  // producer at a time.
   private EGLResourcesHolder eglResourcesHolder;
 
   private TextureRenderer textureRenderer;
@@ -120,6 +123,7 @@ public class VideoEncoder {
   private long lastPresentationTimeUs = -1;
   private long submittedFrames;
   private long writtenFrames;
+  private long windowFrames;
   private static final int MAX_IN_FLIGHT_FRAMES = 4;
   private static final long MAX_PENDING_SAMPLE_BYTES = 16L * 1024 * 1024;
   private long pendingSampleBytes;
@@ -211,14 +215,6 @@ public class VideoEncoder {
     encoder.configure(format, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE);
 
     inputSurface = encoder.createInputSurface();
-    eglResourcesHolder = EGLResourcesHolder.createWithWindowedSurface(EGL10.EGL_NO_CONTEXT, inputSurface);
-    eglResourcesHolder.runWithContextCurrent(() -> {
-      textureRenderer = new TextureRenderer();
-      int[] textures = new int[1];
-      GLES20.glGenTextures(1, textures, 0);
-      uploadTexture = textures[0];
-      EGLUtils.configureTexture(GLES20.GL_TEXTURE_2D, uploadTexture);
-    });
     encoder.start();
 
     try {
@@ -264,8 +260,59 @@ public class VideoEncoder {
     }
   }
 
-  public void makeGLContextCurrent() {
-    eglResourcesHolder.makeCurrent();
+  /** The codec's input Surface, for the GPU export to present to. */
+  public Surface getInputSurface() {
+    if (inputSurface == null) {
+      throw new IllegalStateException("Encoder has not been prepared");
+    }
+    return inputSurface;
+  }
+
+  /**
+   * Before the GPU export presents a frame to the input Surface: waits for
+   * room in the bounded queue and returns the frame's presentation time in
+   * microseconds, which the caller sets on the window for the buffer it
+   * queues next.
+   */
+  public long beginWindowFrame(double time) {
+    if (!Double.isFinite(time) || time < 0) {
+      throw new IllegalArgumentException("Invalid encoder timestamp");
+    }
+    if (encoder == null) {
+      throw new IllegalStateException("Encoder has not been prepared");
+    }
+    if (eglResourcesHolder != null) {
+      throw new IllegalStateException("The encoder's input Surface is already drawn by EGL");
+    }
+    awaitEncoderCapacity();
+    if (audioException != null) {
+      throw new RuntimeException("Could not encode composition audio", audioException);
+    }
+    long timeUS = TimeHelpers.secToUs(time);
+    if (timeUS <= lastPresentationTimeUs) {
+      throw new IllegalArgumentException("Encoder presentation timestamps must increase");
+    }
+    return timeUS;
+  }
+
+  /** Once the frame of beginWindowFrame was presented. */
+  public void endWindowFrame(long timeUS) {
+    lastPresentationTimeUs = timeUS;
+    submittedFrames++;
+    windowFrames++;
+    drainEncoder(false);
+  }
+
+  private void ensureGLContext() {
+    if (eglResourcesHolder != null) return;
+    eglResourcesHolder = EGLResourcesHolder.createWithWindowedSurface(EGL10.EGL_NO_CONTEXT, inputSurface);
+    eglResourcesHolder.runWithContextCurrent(() -> {
+      textureRenderer = new TextureRenderer();
+      int[] textures = new int[1];
+      GLES20.glGenTextures(1, textures, 0);
+      uploadTexture = textures[0];
+      EGLUtils.configureTexture(GLES20.GL_TEXTURE_2D, uploadTexture);
+    });
   }
 
   /** Uploads owned pixels into this encoder's private context, without retaining the input buffer. */
@@ -275,9 +322,13 @@ public class VideoEncoder {
     if (rgba == null || rgba.remaining() < required || !Double.isFinite(time) || time < 0) {
       throw new IllegalArgumentException("Invalid encoder RGBA frame or timestamp");
     }
-    if (encoder == null || eglResourcesHolder == null) {
+    if (encoder == null) {
       throw new IllegalStateException("Encoder has not been prepared");
     }
+    if (windowFrames > 0) {
+      throw new IllegalStateException("The encoder's input Surface is already drawn by WebGPU");
+    }
+    ensureGLContext();
     awaitEncoderCapacity();
     ByteBuffer source = rgba.duplicate();
     if (bytesPerRow != RgbaLayout.bytesPerRow(sourceWidth)) {
@@ -314,23 +365,6 @@ public class VideoEncoder {
     });
   }
 
-  /**
-   * Encodes a GL_TEXTURE_2D of this encoder's context: a hardware buffer the
-   * export rendered into through WebGPU, imported as an EGLImage natively.
-   * The caller waited for the renderer's fence and keeps the buffer until the
-   * reads this draw queues are complete.
-   */
-  public void encodeTexture(int texture, double time) {
-    if (texture <= 0 || !Double.isFinite(time) || time < 0) {
-      throw new IllegalArgumentException("Invalid encoder texture or timestamp");
-    }
-    if (encoder == null || eglResourcesHolder == null) {
-      throw new IllegalStateException("Encoder has not been prepared");
-    }
-    awaitEncoderCapacity();
-    eglResourcesHolder.runWithContextCurrent(() -> encodeTextureCurrent(texture, time));
-  }
-
   private void awaitEncoderCapacity() {
     drainEncoder(false);
     long deadline = SystemClock.uptimeMillis() + 15_000;
@@ -370,6 +404,12 @@ public class VideoEncoder {
 
   public void finishWriting() {
     drainEncoder(true);
+    // A canvas context drops a frame it could not acquire a window buffer
+    // for, without an error: every presented frame must have come out.
+    if (windowFrames > 0 && writtenFrames != submittedFrames) {
+      throw new IllegalStateException("The encoder wrote " + writtenFrames + " of the "
+        + submittedFrames + " frames presented to its input Surface");
+    }
     if (audioThread != null) {
       try {
         audioThread.join(30_000);

package/docs/FRAME_PIXEL_FORMAT.md

@@ -0,0 +1,124 @@
+# YUV ou RGBA : le format des frames décodées
+
+Mesures du 21 octobre 2026 sur **iPhone 15 Pro** (iOS 27.0.1) et **Pixel 8a** (Android 17), builds Release, Skia 3.7.1 / WebGPU 0.17.0. Ce document explique l'option `framePixelFormat`, ce que chaque format coûte et rend, et les pièges trouvés en la mesurant. Le détail des runs est dans le [rapport de vérification beta.3](VERIFICATION_0.1.0-beta.3.md).
+
+## En bref
+
+- **`auto` vaut `yuv` sur les deux plateformes** ; `rgba` reste disponible.
+- **Android** décode en YUV depuis le début (`ImageReader`), et c'est nettement le meilleur choix. Forcer `rgba` (la passe OpenGL) divise par deux à trois la vitesse des exports 4K, et fait perdre près des deux tiers des frames d'une preview 4K 60 fps.
+- **iOS** décodait jusqu'ici en BGRA (VideoToolbox convertit chaque frame). En NV12, une frame 4K pèse **12,4 Mo au lieu de 33,2 Mo**. Le décodeur garde cinq frames d'avance au lieu d'une ou deux, la preview 4K perd moins de frames, et les cas qui dépassaient le budget mémoire passent. Seul coût mesuré : **environ 2 à 4 ms de plus par frame à l'export**, visible sur les exports longs ou à petite sortie.
+- **Le rendu est le même** pour la vidéo de caméra (Rec.709 ou HLG). Un fichier étiqueté Display P3 ou avec la fonction de transfert sRGB est converti en Rec.709 par `rgba`, pas par `yuv`.
+
+## L'option
+
+```ts
+const composition = { duration, items, framePixelFormat: 'yuv' }; // 'auto' | 'yuv' | 'rgba'
+```
+
+| | iOS | Android |
+| --- | --- | --- |
+| `yuv` | AVAssetReader sort le NV12 du décodeur. La preview l'importe comme texture externe à chaque frame et le convertit en RGB dans une passe de rendu ; l'export le convertit dans une texture par clip | `ImageReader` (pistes 8 bits SDR, à toute taille de frame, plafonnée ou explicite comprise ; les autres restent en `rgba`), converti en RGB et mis à la taille de la frame par la même passe |
+| `rgba` | VideoToolbox convertit en BGRA ; l'export GPU échantillonne l'IOSurface en place, sans copie | Passe OpenGL vers un `AHardwareBuffer` RGBA |
+| `auto` (défaut) | `yuv` | `yuv` |
+
+L'option ne concerne que les compositions (preview et export) : le lecteur d'un clip seul, `useVideoPlayer`, reste en BGRA sur iOS.
+
+La conversion YUV → RGB applique la matrice YCbCr et la plage de chaque buffer, sans convertir la fonction de transfert ni les primaires : c'est ce qui évite d'éclaircir les tons moyens à chaque export (voir `yuvBlit.ts`). Le HDR est d'abord ramené en SDR Rec.709 par la plateforme, dans les deux formats.
+
+## Mesures
+
+### Décodeur seul (iOS)
+
+XCTest `DecodeThroughputTests` : AVAssetReader lit les 360 frames d'un clip HEVC 4K 60 fps, sans React Native ni GPU, en alternant les formats sur trois tours. Téléphone en état thermique *serious*.
+
+| Format | Débit | CPU par frame | Taille d'une frame |
+| --- | --- | --- | --- |
+| BGRA + propriétés Rec.709 | 105–127 fps | 0,42–0,47 ms | 33,2 Mo |
+| NV12 + propriétés Rec.709 | 93–139 fps | 0,45–0,55 ms | 12,4 Mo |
+| NV12 brut | 120–137 fps | 0,47–0,62 ms | 12,4 Mo |
+
+La conversion BGRA est faite par le matériel et ne coûte presque rien en débit. La différence est la **mémoire**, et ce qu'elle permet : la file du décodeur de la preview est plafonnée à 64 Mo, soit une ou deux frames d'avance en BGRA 4K, cinq en NV12.
+
+### Preview
+
+Profil `sync` : chaque frame porte son numéro, lu à chaque vsync. « Exact » : part des vsyncs qui montrent la frame due ; « frames » : frames distinctes affichées.
+
+**Pixel 8a**, 60 Hz, état thermique *nominal* :
+
+| Cas | `yuv` | `rgba` |
+| --- | --- | --- |
+| HEVC 4K 60 fps | **96,9 % exact**, 344/360 frames | 18,4 %, 132/360 |
+| HEVC 4K 30 fps | **100 %**, 179/180 | 38,1 %, 123/180 |
+| H.264 4K 30 fps | **98,8 %**, 177/180 | 38,4 %, 128/180 |
+| Vraie vidéo 4K 60 fps (fleurs, 60 Mbit/s) | **335/360** | 145/360 |
+| HEVC 1080p 60 fps | 99,4 % | 92,7 % |
+| 30 fps, 24 fps, coupe | 99,7–100 % | 99,7–100 % |
+
+**iPhone 15 Pro**, 120 Hz, quatre runs alternés `rgba` / `yuv` / `rgba` / `yuv`, tous en état *serious* (le téléphone n'a pas refroidi entre les runs ; l'alternance répartit cette chaleur sur les deux formats). Deux valeurs par format :
+
+| Cas | `yuv` | `rgba` |
+| --- | --- | --- |
+| HEVC 4K 60 fps (frames, sans lecture du numéro) | **311, 294** /360 | 241, 261 |
+| HEVC 4K 60 fps (exact, une frame sur quatre lue) | **77 %, 90 %** | 46 %, 48 % |
+| Vraie vidéo 4K 60 fps (frames) | **270, 327** /360 | 234, 284 |
+| HEVC 4K 30 fps du benchmark (frames) | **235, 239** /240 | 223, 224 |
+| Vraie vidéo 4K 30 fps (frames) | 173, 178 /180 | 173, 169 |
+| 30, 60 fps et HEVC 1080p 60 fps (exact) | 73–95 % | 71–91 % |
+
+En 1080p et en 30 fps, les écarts entre formats restent dans la dispersion d'un run à l'autre, très forte sur un téléphone chaud.
+
+### Export
+
+Chaque frame exportée a été relue : la bonne frame source dans tous les cas, dans les deux formats, sur les deux téléphones.
+
+| Cas | Pixel `yuv` | Pixel `rgba` | iPhone `yuv` | iPhone `rgba` |
+| --- | --- | --- | --- | --- |
+| 4K 60 → 4K 60 | **5,0 s** | 15,6 s | 4,2–4,3 s | 4,1–4,5 s |
+| 4K 30 → 4K 30 | **3,2 s** | 8,7 s | 2,3 s | 2,4–2,7 s |
+| 4K 60 → 1080p 30 | **2,4–2,9 s** | 8,0–8,2 s | 1,4–2,2 s | 1,7 s |
+| HEVC 1080p 60 → 640×360 | 4,1 s | 8,9 s | 0,9–1,4 s | **0,5 s** |
+| Montage de 120 clips (suite `full`) | **63,5 s** | 95,9 s | 18,1 s | **14,0 s** |
+
+Sur iOS, l'export en `yuv` importe chaque frame NV12 et la convertit dans une texture, là où le BGRA est lu en place. Ce surcoût d'environ 2 à 4 ms par frame est invisible en 4K, où le décodage domine, mais pèse sur les sorties petites ou les exports longs. Pour un export iOS où la vitesse prime sur la mémoire, `framePixelFormat: 'rgba'` reste le plus rapide.
+
+### Mémoire
+
+Pics de la suite `full` (une répétition par format). Pixel : PSS ; iPhone : empreinte physique.
+
+| Cas | Pixel `yuv` | Pixel `rgba` | iPhone `yuv` | iPhone `rgba` |
+| --- | --- | --- | --- | --- |
+| Lecture continue 4K | **438–458 Mio** | 554–602 | **336–343 Mio** | 400–405 |
+| Clip seul 4K | 698–707 | 795–830 | **601–639** | 657–677 |
+| 8 clips 4K, paresseux | **766–785** | 1 020–1 037 | **571–573** | 670–683 |
+| 3 clips 4K simultanés | 1 507 | 1 314 | **734, passe** | arrêté par le budget |
+| 8 clips 4K, eager | 1 562, passe | arrêté par le budget | 1 089, passe | arrêté par le budget |
+
+Les cas « eager » qui s'arrêtaient sur le budget en `rgba` vont jusqu'au bout en `yuv`, d'où une mémoire plus haute sur ceux-là.
+
+## Rendu
+
+Trois contrôles, la même frame décodée dans chaque format :
+
+- **Mire SMPTE** (H.264 et HEVC 1080p, étiquetées Rec.709) comparée à ffmpeg : écart maximal de **0 niveau en `yuv`, 1 en `rgba`**, sur les deux téléphones.
+- **Vraie vidéo** : trois clips tirés de photos d'appareil (panoramique, grain, débits de téléphone, étiquetés Rec.709) comparés à ffmpeg sur 24 points à trois instants. Écart moyen de **0,07 à 0,16 en `yuv`** sur les deux téléphones (max 1). En `rgba` : 0,15 à 0,48 sur le Pixel, 0,5 à 0,8 sur l'iPhone (max 5).
+- **Fixtures du benchmark** (rotations, HDR HLG 10 bits, portrait, 638×358, slow motion) : `yuv` contre `rgba`, écart moyen de 0 à 0,8 niveau. Les maxima de 5 à 17 niveaux sont ponctuels, sur des bords nets entre aplats saturés, où VideoToolbox (ou la passe OpenGL) et la passe GPU n'interpolent pas la chrominance de la même façon.
+
+## Pièges trouvés
+
+**VideoToolbox réétiquette sans convertir.** Avec une sortie NV12, demander les propriétés Rec.709 fait étiqueter le buffer en BT.709 sans convertir les échantillons. Pour une vidéo SD sans étiquette, codée en BT.601, le GPU appliquait alors la mauvaise matrice : le bleu d'un jaune décalé de 11 niveaux, 4,7 en moyenne sur un clip 320×240. Le XCTest `ColorMatrixDiagnosticsTests` le montre : le BGRA de VideoToolbox correspond au NV12 converti en BT.601 (écart 0,4), pas en BT.709 (6,3). Correction : en NV12, seules les pistes HDR ou BT.2020 reçoivent ces propriétés (pour le tone mapping) ; les autres gardent l'étiquette réelle du décodeur, que le GPU applique. Écart après correction : max 1 (638×358) et 3 (320×240), moyenne 0,15 à 0,32.
+
+**Les étiquettes Display P3 et sRGB.** `rgba` convertit vers Rec.709 ce que le fichier déclare (primaires P3, fonction de transfert sRGB) : VideoToolbox sur iOS, la passe OpenGL sur Android. `yuv` n'applique que la matrice et la plage. Sur un clip étiqueté P3 (fixture `tagged-p3-flowers`), `yuv` reste à 0,2 niveau de ffmpeg (qui ignore aussi les primaires), `rgba` s'en écarte de 5,8 en moyenne sur l'iPhone (max 26) et de 1,3 sur le Pixel (max 16). La vidéo de caméra n'est pas concernée ; certains enregistrements d'écran ou exports d'éditeurs le sont.
+
+**Les fixtures héritaient des étiquettes des photos.** ffmpeg recopiait dans les clips de test les primaires P3, la fonction de transfert sRGB ou le profil ICC des photos sources, malgré `-color_primaries bt709`. Le script force désormais les étiquettes avec `setparams` et retire le profil ICC, puis les vérifie avec `ffprobe`.
+
+**La file de décodage iOS tournait en priorité *utility*.** Sur un iPhone chaud, iOS la reléguait sur les cœurs basse consommation : des gels de 300 à 500 ms. Elle tourne désormais en *user-interactive* ; le même run passe de 56 à 244 frames sur 360 en 4K 60 fps.
+
+## Recommandation
+
+Garder `auto` (`yuv`). Choisir `rgba` sur iOS seulement pour :
+- un export où la vitesse compte plus que la mémoire ;
+- des fichiers étiquetés Display P3 ou sRGB dont on veut la conversion colorimétrique.
+
+Pistes pour la suite :
+- réduire le coût de l'import NV12 à l'export sur iOS, par exemple en réutilisant les imports d'un même IOSurface ;
+- mesurer à froid, sur plusieurs répétitions, les écarts 1080p de l'iPhone qui restent dans le bruit.

package/docs/MIGRATION.md

@@ -67,7 +67,7 @@ Audio is implemented on both native platforms, but the device runs so far (3.0.6
 
 Set `configureVideoMemory({ maxBytes })` before allocating sessions. The budget covers tracked resources only; codecs and drivers can retain additional memory. A budget rejection does not silently reduce export dimensions.
 
-On Android with the AHardwareBuffer interop (API 29+, 8-bit SDR H.264/HEVC at the encoded size), the codec writes into an `ImageReader`; WebGPU converts, crops and rotates each YUV buffer, imported once, into an independent Graphite snapshot after a checked GPU fence. Exports skip that snapshot: each clip's frame is converted into a texture of its own and sampled in place, as on iOS. Other sources render through the decoder's private EGL context into an RGBA AHardwareBuffer, or, without the interop, read owned RGBA pixels on the CPU and upload them. All of these avoid Skia's image-count raster-upload cache. CPU Java/JSI backing buffers remain accounted until their aliases and ART/Hermes owners are collected. See the [upstream cache notes](UPSTREAM_NOTES.md#android--éviter-le-cache-dimages-raster-du-provider) and the [3.6.1 verification](../migration/skia-3.6.1/verification.md).
+On Android with the AHardwareBuffer interop (API 29+, 8-bit SDR H.264/HEVC), the codec writes into an `ImageReader`; WebGPU converts, crops, rotates and scales each YUV buffer, imported once, to the frame's size (a `maxLongSide` cap or an explicit `resolution` included) in an independent Graphite snapshot after a checked GPU fence. Exports skip that snapshot: each clip's frame is converted into a texture of its own and sampled in place, as on iOS. Other sources render through the decoder's private EGL context into an RGBA AHardwareBuffer, or, without the interop, read owned RGBA pixels on the CPU and upload them. All of these avoid Skia's image-count raster-upload cache. CPU Java/JSI backing buffers remain accounted until their aliases and ART/Hermes owners are collected. See the [upstream cache notes](UPSTREAM_NOTES.md#android--éviter-le-cache-dimages-raster-du-provider) and the [3.6.1 verification](../migration/skia-3.6.1/verification.md).
 
 The optional `createFrameProcessor` export factory creates a processor once per export. Its asynchronous `prepareFrame` runs at the requested composition timestamp and its `dispose` must finish all frame readers. Drive animated effects from that timestamp, not an independent display animation loop.
 

package/docs/UPSTREAM_NOTES.md

@@ -1,5 +1,7 @@
 # Points amont à revoir lors d'une mise à jour Skia
 
+**Mise à jour du 23 octobre 2026 :** **`react-native-skia@3.7.4`** et **`react-native-webgpu@0.19.0`**, toujours sur Dawn/Graphite 157.0.0. Le patch local passe de 7 fichiers et 62 éditions à 3 fichiers et 8 éditions. `canvas.dispose()` disparaît : en amont, la surface possède son canvas ([#4278](https://github.com/wcandillon/react-native-skia/pull/4278)) et `surface.dispose()` le détache. Le correctif d'`ImageProvider::Make()` est entré en amont par [#4277](https://github.com/wcandillon/react-native-skia/pull/4277). Restent les soumissions vérifiées, réécrites sur le nouveau `DawnContext::submitRecording(recorder, …)`, et `__rnskvTrimRecorderCache`, réduit à un appel de `trimThreadRecorders`. L'export Android rend désormais directement dans la `Surface` d'entrée du codec par `MakeWebGPUCanvasContextFromNativeWindow` ([WebGPU #588](https://github.com/wcandillon/react-native-webgpu/pull/588)), sans EGL. Voir l'[audit](../migration/skia-3.7.4/upstream-audit.md) et la [vérification](../migration/skia-3.7.4/verification.md).
+
 **Mise à jour du 20 octobre 2026 :** **`react-native-skia@3.7.1`**, toujours avec `react-native-webgpu@0.17.0` et Dawn/Graphite 157.0.0. La 3.7.1 ne contient qu'une correction iOS ([#4273](https://github.com/wcandillon/react-native-skia/pull/4273)) : `SkiaView.mm` présente désormais à la pleine fréquence de l'écran sur les appareils ProMotion. Les sept fichiers modifiés par le patch local sont identiques octet pour octet à ceux de la 3.7.0 : le patch s'applique tel quel, seuls sa version et son nom changent. Nos PR amont [#4274](https://github.com/wcandillon/react-native-skia/pull/4274), [#4275](https://github.com/wcandillon/react-native-skia/pull/4275) et [#4276](https://github.com/wcandillon/react-native-skia/pull/4276) sont encore ouvertes : le patch ne rétrécit pas. Vérifié le 20 octobre sur appareils, en Release : iPhone 15 Pro, tests natifs 50/50 et profil smoke 15/15 (l'app déclare Skia 3.7.1, écran à 120 Hz) ; Pixel 8a, contrôle `interop` 10/10 (erreur maximale par canal de 1, comme en 3.7.0, chemins GPU et readback d'accord à l'export) et smoke 15/15. Les mesures d'export de la 3.7.0 restent la référence : le code d'export ne change pas.
 
 **Migration du 19 octobre 2026 :** le code et les dépendances déclarées ciblent désormais **`react-native-skia@3.7.0` / `react-native-webgpu@0.17.0`**, sur Graphite **157.0.0** et **`react-native-webgpu-dawn@157.0.0`** (Skia `chrome/m157`). Les deux paquets doivent monter ensemble : Gradle et le podspec refusent deux Dawn différents. Le patch local garde 61 de ses 62 éditions ; seule tombe l'include `<stdexcept>`, désormais présent en amont. Le Dawn 157 demande trois images FIFO à la swapchain Android, ce qui supprime l'attente du thread principal dans `dequeueBuffer` sur Android 10 ; il garde aussi la robustesse des shaders sur Android, nos WGSL compris. L'[audit](../migration/skia-3.7.0/upstream-audit.md) détaille ces changements ; la [vérification](../migration/skia-3.7.0/verification.md) donne les mesures sur iPhone 15 Pro et Pixel 8a. Après une mise à jour, supprimer le bundle JS généré par Gradle avant de construire un APK de qualification : sa tâche ne voit pas le `node_modules` racine.
@@ -97,6 +99,8 @@ Cette architecture pourrait éviter la lecture CPU de la **sortie composée**. E
 
 ## Patch distinct : durée de vie et soumissions vérifiées
 
+**Depuis 3.7.4**, seules les soumissions vérifiées et la réduction du cache du runtime d'export restent dans le patch : la durée de vie du canvas et la factory d'`ImageProvider` sont corrigées en amont (voir la mise à jour du 23 octobre). La suite décrit l'historique du patch.
+
 Ces quatre protections restent nécessaires en **3.4.4**, puis en **3.6.1**, dont les fichiers patchés sont identiques à ceux de 3.4.4 : l'amont n'a ajouté ni `dispose()` de canvas, ni contrôle d'`insertRecording`, ni garde du snapshot nul, et sa factory d'`ImageProvider` n'a pas changé. Le `dispose()` rebasé remet la surface au `Dispatcher` de son thread créateur, comme le fait désormais le destructeur amont du canvas. Le reste de cette section décrit le patch d'origine.
 
 Dans Skia 3.0.3 et encore dans les sources 3.0.6, le wrapper `JsiSkCanvas` peut garder une référence propriétaire à la surface dont il provient. Disposer uniquement le wrapper `SkSurface` ne ferme donc pas cette référence tant que le canvas est encore détenu ; attendre le GC pour les surfaces temporaires est insuffisant pour une fermeture déterministe.
@@ -113,7 +117,7 @@ La [source Skia de ce build](https://chromium.googlesource.com/skia/+/2466dcf393
 
 Fichiers inspectables :
 
-- [`patches/react-native-skia+3.6.1.patch`](../patches/react-native-skia+3.6.1.patch) : diff du correctif courant, identique à celui de 3.4.4 ; ceux de 3.4.4 et 3.0.6 sont conservés comme historique.
+- [`patches/react-native-skia+3.7.4.patch`](../patches/react-native-skia+3.7.4.patch) : diff du correctif courant ; ceux des versions précédentes sont conservés comme historique.
 - [`scripts/skia-canvas-patch.json`](../scripts/skia-canvas-patch.json) : version, empreintes avant/après et substitutions attendues.
 - [`scripts/apply-skia-canvas-patch.mjs`](../scripts/apply-skia-canvas-patch.mjs) : vérifie tout avant toute écriture, accepte un patch déjà appliqué, refuse un paquet différent.
 
@@ -179,6 +183,15 @@ Le patch ajoute également une méthode privée `__rnskvTrimRecorderCache` : ell
 
 Lors d'une mise à jour amont, vérifier séparément la correction de la factory, l'affinité de thread du Recorder, les erreurs de soumission et une éventuelle API officielle de nettoyage. Ne pas remplacer cette politique limitée par une purge globale à chaque frame.
 
+## Piste testée : Graphite échantillonne le YUV du décodeur — 24 octobre 2026
+
+Sur Android, l'export convertit chaque buffer YUV de l'`ImageReader` en RGBA (une passe WebGPU par frame), puis Skia échantillonne cette texture. Le Skia Graphite précompilé sait échantillonner un `OpaqueYCbCrAndroid` directement, à travers un sampler YCbCr Vulkan (`DawnTextureInfo::fYcbcrVkDescriptor`, `DawnDescriptorToImmutableSamplerInfo`). Un prototype l'a fait marcher sur le Pixel 8a :
+- RN Skia demande `YCbCrVulkanSamplers` et `StaticSamplers` au device, en plus d'`OpaqueYCbCrAndroidForExternalTexture` ;
+- une méthode `Skia.Image.MakeImageFromYCbCrTexture(texture, hardwareBuffer)` lit le descripteur avec `wgpu::Device::GetAHardwareBufferProperties` et enveloppe la texture de `importSharedTextureMemory` ;
+- l'export ouvre l'accès du buffer à l'import et le ferme quand la frame est libérée ; la frame porte le recadrage et la rotation du buffer, comme une frame `direct`.
+
+La passe de conversion disparaît (attente GPU d'une frame 8×4K → 1080 : 2,7 → 1,2 ms), mais la durée des exports ne change pas : une fois l'attente GPU différée et les indices ADPF en place, le bloc codec (décodage 4K et encodage) limite le débit. Les octets exportés changent aussi (reconstruction de la chrominance par le sampler), ce qui demanderait une qualification d'image. Le prototype n'a donc pas été gardé ; il reste à reprendre si un cas devient limité par le GPU (plusieurs couches 4K, GPU plus modeste). Mesures : [vérification 3.7.4](../migration/skia-3.7.4/verification.md#améliorations-du-24-octobre).
+
 ## Référence fournie : `enzomanuelmangano/demos`
 
 Le [dépôt de démos](https://github.com/enzomanuelmangano/demos) est utile pour choisir des scènes visuelles : transitions, reflets de shader et interactions pilotées par des valeurs partagées. Le [manifest consulté](https://github.com/enzomanuelmangano/demos/blob/main/package.json) fixe encore Skia 2.6.2 et WebGPU 0.5.14 ; ses patches de compatibilité ne sont donc pas une preuve de compatibilité avec le couple désormais ciblé 3.0.6/0.12.1, ni avec le couple mesuré 3.0.3/0.11.0.
@@ -187,4 +200,4 @@ Les idées retenues pour les futurs adaptateurs sont une transition à progressi
 
 ## Procédure de mise à jour
 
-Pour chaque nouvelle version Skia : relever le couple Dawn/WebGPU et les versions RN/Reanimated/Worklets compatibles, relire les imports/sorties de buffers, les soumissions vérifiées, la fermeture canvas/snapshot et les budgets/caches Graphite, revoir les empreintes, compiler les deux plateformes, exécuter les tests de pixels/timestamps puis les **65 workloads du catalogue `2026-10-07.1`** (59 historiques, trois lectures continues `copy` et leurs trois équivalents `direct`) et les sessions longues. La configuration iPhone déjà compilée pour la référence 3.0.3 utilise RN 0.86.2, Reanimated 4.5.3 et Worklets 0.11.3 ; ces versions sont conservées pour la migration 3.0.6. Ne pas laisser une plage ouverte sélectionner une autre version sans refaire l'installation native. Documenter la version et le transport effectif dans les résultats. La présence d'un cas dans le catalogue ne signifie pas qu'il a été exécuté sur toutes les cibles. Une correction amont ou des tests de l'hôte verts seuls ne justifient pas de supprimer un garde-fou mémoire.
+Pour chaque nouvelle version Skia : relever le couple Dawn/WebGPU et les versions RN/Reanimated/Worklets compatibles, relire les imports/sorties de buffers, les soumissions vérifiées, la fermeture canvas/snapshot et les budgets/caches Graphite, revoir les empreintes, compiler les deux plateformes, exécuter les tests de pixels/timestamps puis les **67 workloads du catalogue `2026-10-07.1`** (59 historiques, trois lectures continues `copy` et leurs trois équivalents `direct`, plus les deux exports 4K → 4K ajoutés le 24 octobre 2026 sans changer les autres) et les sessions longues. La configuration iPhone déjà compilée pour la référence 3.0.3 utilise RN 0.86.2, Reanimated 4.5.3 et Worklets 0.11.3 ; ces versions sont conservées pour la migration 3.0.6. Ne pas laisser une plage ouverte sélectionner une autre version sans refaire l'installation native. Documenter la version et le transport effectif dans les résultats. La présence d'un cas dans le catalogue ne signifie pas qu'il a été exécuté sur toutes les cibles. Une correction amont ou des tests de l'hôte verts seuls ne justifient pas de supprimer un garde-fou mémoire.

package/docs/VERIFICATION_0.1.0-beta.3.md

@@ -0,0 +1,147 @@
+# Vérification de la 0.1.0-beta.3 — 21 octobre 2026
+
+Ce document liste ce qui a **réellement** été exécuté pour cette version :
+- sur l'hôte ;
+- sur **iPhone 15 Pro** (iOS 27.0.1) ;
+- sur **Pixel 8a** (Android 17).
+
+Tous les builds sont en Release, sur Skia 3.7.1 / WebGPU 0.17.0, inchangés depuis la beta.2. L'analyse du format des frames est dans [FRAME_PIXEL_FORMAT.md](FRAME_PIXEL_FORMAT.md).
+
+## Ce qui change
+
+- **Horloge de `drawFrame`** (iOS, Android) : `currentTime` vaut l'heure à laquelle les frames dessinées ont été choisies. Lue plus tard, elle avançait jusqu'à une frame sur la vidéo à 60 fps, et les overlays calculés d'après elle étaient décalés d'autant.
+- **`splitImportAndDraw`** ne perd plus une frame sur deux quand une nouvelle frame arrive à chaque vsync.
+- **Android 15+** : une preview en lecture demande à l'écran sa fréquence maximale. Le Pixel ne descend plus à 30 Hz, et monte à 120 Hz quand le réglage de l'utilisateur le permet.
+- **iOS** : la file de décodage de la preview tourne en priorité *user-interactive* au lieu d'*utility*.
+- **`framePixelFormat`** (`'auto' | 'yuv' | 'rgba'`) : `auto` vaut `yuv` sur les deux plateformes. Sur iOS, le décodeur sort désormais du NV12 (12,4 Mo par frame 4K au lieu de 33,2 Mo de BGRA). `rgba` reste disponible.
+- **Diagnostic** : `getResourceStats()` donne sur iOS les refus de l'anneau de frames, les files de décodage vides et les ticks de décodage lents.
+- **App de test** : profil `sync` (exactitude des frames, seeks, exports, couleurs, rendu de vrais médias), option `--frame-pixel-format` des lanceurs, `--case` pour iOS, clé `CADisableMinimumFrameDurationOnPhone` (120 Hz sur ProMotion).
+
+## Hôte
+
+| Contrôle | Résultat |
+| --- | --- |
+| Jest | **237/237 tests, 11 suites** (dont les chemins NV12 de la preview et de l'export) |
+| `tsc --noEmit`, `test:package`, `benchmark:test` | OK, 5/5, 122/122 |
+| `test:native` (C++ hôte, validation native, syntaxe des 50 assertions iOS historiques) | OK |
+| Tests JVM | 27/27 |
+| `test-skia-patch-syntax.mjs`, `test-skia-provider-ownership.mjs` | OK |
+| `npm run build`, `check-package` (publint strict) | OK |
+
+## Exactitude de la lecture (profil `sync`)
+
+Chaque frame des fixtures porte son numéro en code-barres, lu à chaque vsync dans `drawFrame` et comparé à l'horloge du player. « Exact » : part des vsyncs qui montrent la frame due. « Irr » : part des changements de frame décalés de plus de 3/4 de vsync. Écran à 60 Hz.
+
+| Cas | Pixel, avant | Pixel, beta.3 | iPhone, avant | iPhone, beta.3 |
+| --- | --- | --- | --- | --- |
+| 30 fps | 93 % · irr 1,8 % | **99,4 %** · irr 1,8 % | 100 % | 100 % |
+| 30 fps, `splitImportAndDraw` | 79 % · irr 81 % · 75 frames sautées | **99 %** · irr 0 % · 2 | 100 % | 100 % |
+| 24 fps | 85 % · irr 21 % | **100 %** · irr 4,6 % | 100 % | 100 % |
+| 60 fps | 51 % · 166 sautées | **99,4 %** · 2 | 80 % · 9 sautées | **100 %** |
+| HEVC 1080p 60 fps | 66 % | **98,8 %** | 99,7 % (0,3 % au premier run) | **100 %** |
+
+« Avant » : le code de `main` avec le seul profil `sync` ajouté. Les 2 à 9 frames sautées restantes tombent au démarrage d'une lecture.
+
+**4K, `yuv` (défaut) contre `rgba`** :
+
+| Cas | Pixel `rgba` | Pixel `yuv` | iPhone `rgba` | iPhone `yuv` |
+| --- | --- | --- | --- | --- |
+| HEVC 4K 60 fps | 18 % · irr 65 % · 205 sautées | **97 % · irr 0,3 %** · 9 | 66 % · irr 6,5 % · 64 | **97 % · irr 1,3 %** · 9 |
+| HEVC 4K 30 fps | 38 % · irr 52 % | **100 %** · irr 0 % | 97 % · irr 1,9 % | **100 %** · irr 0 % |
+| H.264 4K 30 fps | 38 % · irr 48 % | **99 %** · irr 0,6 % | 96 % · irr 6,9 % | **100 %** · irr 1,2 % |
+| Vraie vidéo 4K 60 fps, 60 Mbit/s (frames distinctes) | 145/360 | **335/360** | 268/360 | 267/360 |
+
+Le Pixel est resté à l'état thermique *nominal*. Les deux runs iPhone de ce tableau ont tourné téléphone chaud, *fair* pour `rgba` et *serious* pour `yuv`. Quatre runs alternés `rgba` / `yuv` / `rgba` / `yuv`, tous en *serious*, confirment l'avantage du `yuv` en 4K : en HEVC 4K 60 fps, 294–311 frames sur 360 contre 241–261, et 77–90 % d'exact contre 46–48 % en lisant une frame sur quatre. En 1080p et en 30 fps, les écarts restent dans la dispersion entre runs (73 à 95 % d'exact dans les deux formats). Détail dans [FRAME_PIXEL_FORMAT.md](FRAME_PIXEL_FORMAT.md#preview).
+
+Les **seeks** tombent juste sur les deux plateformes : 22/22 sur chaque téléphone, y compris à ±0,5 ms d'une limite de frame. Sur Android, un seek en pause montre les frames intermédiaires décodées depuis la keyframe avant la bonne ; l'iPhone garde l'image précédente. Ce comportement n'a pas changé.
+
+## Exports
+
+Chaque frame exportée porte son numéro de sortie sous le code-barres source, et est relue après l'export. **Tous les exports sont exacts sur les deux téléphones et dans les deux formats** (30→30, 60→30, 30→60, 24→30, HEVC 60→60, coupe, 4K→4K en 30 et 60 fps, 4K→1080p) : la bonne frame source, aucune frame perdue ou dupliquée, et le décodeur du système compte le bon nombre de frames dans chaque fichier.
+
+| Pixel 8a | `yuv` | `rgba` |
+| --- | --- | --- |
+| 4K 60 → 4K 60 | **5,0 s** | 15,6 s |
+| 4K 30 → 4K 30 | **3,2 s** | 8,7 s |
+| 4K 60 → 1080p 30 | **2,4–2,9 s** | 8,0–8,2 s |
+
+| iPhone 15 Pro, runs alternés en *serious* | `yuv` | `rgba` |
+| --- | --- | --- |
+| 4K 60 → 4K 60 | 4,2–4,3 s | 4,1–4,5 s |
+| 4K 30 → 4K 30 | 2,3 s | 2,4–2,7 s |
+| HEVC 1080p 60 → 640×360 | 0,9–1,4 s | **0,5 s** |
+| Montage de 120 clips (suite `full`) | 18,1 s | **14,0 s** |
+
+Sur iOS, l'export `yuv` importe et convertit chaque frame NV12 au lieu de lire le BGRA en place : environ 2 à 4 ms de plus par frame, sensibles sur les exports longs ou à petite sortie.
+
+## Rendu et couleurs
+
+- **Mire SMPTE** (H.264 et HEVC 1080p, Rec.709) comparée à ffmpeg : écart maximal de 0 niveau en `yuv`, 1 en `rgba`, sur les deux téléphones.
+- **Vraie vidéo** (trois clips tirés de photos d'appareil, étiquetés Rec.709) comparée à ffmpeg sur 24 points à trois instants : écart moyen de 0,07 à 0,16 en `yuv` sur les deux téléphones (max 1). En `rgba` : 0,15 à 0,48 sur le Pixel, 0,5 à 0,8 sur l'iPhone (max 5).
+- **Clip étiqueté Display P3** : `yuv` reste à 0,2 de ffmpeg ; `rgba` convertit le gamut (iPhone : moyenne 5,8, max 26 ; Pixel : 1,3, max 16).
+- **Fixtures du benchmark** (rotations, HDR HLG, portrait, SD, slow motion), `yuv` contre `rgba` : écart moyen de 0 à 0,8 niveau. Les maxima ponctuels de 5 à 17 sont sur des bords nets.
+- **Pixel, `interop`** : décodage GPU contre CPU **10/10**, écarts maximaux 1,1,0,0,1,1,0,0,1,1, identiques à la 3.7.0. Export GPU contre readback : écart 0 sur la mire et sur la vidéo.
+
+Correction faite pendant la vérification : en NV12, VideoToolbox réétiquetait en BT.709 une vidéo SD codée en BT.601 sans convertir ses échantillons (le bleu d'un jaune décalé de 11 niveaux). Seules les pistes HDR ou BT.2020 reçoivent désormais les propriétés de conversion. Voir [FRAME_PIXEL_FORMAT.md](FRAME_PIXEL_FORMAT.md#pièges-trouvés).
+
+## Suite `full` (65 cas, 1 répétition par format)
+
+| | Réussis | Échecs | Arrêtés par le budget | Non exécutés |
+| --- | --- | --- | --- | --- |
+| Pixel `rgba` (26 min, nominal) | 57 | 4 | — | 4 |
+| Pixel `yuv` (24 min, nominal) | **58** | 3 | — | 4 |
+| iPhone `rgba` (17 min, *fair* puis *serious*) | 58 | — | 3 | 4 |
+| iPhone `yuv` (20 min, *nominal* à *serious*) | **61** | — | — | 4 |
+
+Les 4 cas non exécutés sont les extensions LUT, compute, Three.js et Core ML, non branchées dans l'app.
+
+**Pixel.** Les trois échecs communs aux deux formats existaient déjà dans la beta.2 : le build de `main` (`1eeaa3b`) échoue aux mêmes cas, 2 répétitions sur 2, avec les mêmes symptômes.
+
+| Cas | Symptôme, `main` comme beta.3 |
+| --- | --- |
+| `seek-while-playing` | Après un seek en lecture dans une séquence 4K, l'horloge reste vers 4,0 s pendant 4 s |
+| `long-montage-120-clips` | Après un seek en pause dans un montage paresseux de 120 clips, la frame du clip 83 n'arrive pas |
+| `missing-file` | Android 17 répond « Failed to instantiate extractor », que le harness ne reconnaît pas comme une erreur de fichier manquant |
+
+Le quatrième échec en `rgba`, `4k-x8-eager`, dépasse le budget mémoire ; il passe en `yuv`.
+
+| Pixel, `rgba` → `yuv` | Export | Mémoire max (PSS) |
+| --- | --- | --- |
+| 8 clips 4K, paresseux | 29,0 → **12,9 s** | 1 020 → **766 Mio** |
+| Montage en fondu, eager | 27,3 → **14,4 s** | 1 468 → **1 029 Mio** |
+| 3 clips 4K simultanés | 23,2 → **7,3 s** | 1 314 → 1 507 Mio |
+| Exports simples (`encode-*`) | 2,4–2,6 → **1,7–1,9 s** | ≈ égal |
+| Lecture continue 4K | — | 554–602 → **438–458 Mio** |
+
+**iPhone.** En `rgba`, trois cas s'arrêtent sur le budget de la file du décodeur : `montage-all-crossfade-eager`, `4k-x8-eager` et `4k-x3-simultaneous` (problème connu des versions précédentes). **En `yuv`, les trois passent**, et aucun cas n'échoue.
+
+| iPhone, `rgba` → `yuv` | Mémoire physique max | Export |
+| --- | --- | --- |
+| Lecture continue 4K | 400–405 → **336–343 Mio** | — |
+| 8 clips 4K, paresseux | 670–683 → **571–573 Mio** | 4,4–4,5 → 4,5–4,9 s |
+| 3 clips 4K simultanés | budget dépassé → **734 Mio, passe** | — |
+| Montage en fondu, paresseux | 650 → **585 Mio** | 4,3 → 3,6 s |
+| 20 clips courts | ≈ | 3,3 → **2,5 s** |
+| Montage de 120 clips | ≈ | **14,0** → 18,1 s |
+
+## Tests natifs
+
+- **iPhone, XCTest** : **56/58**, les deux autres étant des diagnostics qui ne tournent qu'à la demande. Six nouveaux tests : chaque frame d'un clip et d'un montage lues en NV12, le format annoncé par chaque frame, et la lecture de `framePixelFormat` (`auto` et `yuv` en NV12, `rgba` en BGRA, valeur inconnue refusée). Les deux diagnostics ont été lancés à part (débit du décodeur par format, étiquettes de couleur des clips sans étiquette).
+- **Pixel, tests instrumentés** : **126/127** dans la suite complète. L'échec, `BigMontageTest.aLazyPreviewOfEight4KClipsPlaysThrough`, figure dans la référence connue (il échouait déjà sur `main` dans la suite complète). Lancée seule juste après, sur un Pixel aux cœurs à 85 °C après des heures de 4K, la classe échoue 2 fois sur 5 : le seuil de 150 frames à l'heure en 4K, et un `OutOfMemoryError` du tas Java après l'export eager de 8 clips 4K. Ces tests pilotent le décodeur Java sans `Looper`, chemin que cette version ne modifie pas. Ils n'ont pas été relancés à froid avant la release : l'attribution à la chaleur n'est pas confirmée.
+
+## Runs écartés
+
+- `iphone-full-rgba-interrupted-call` : appel téléphonique pendant le run.
+- `iphone-full-yuv-interrupted-phone-in-use` : téléphone utilisé pendant le run.
+- Les runs `sync` iPhone antérieurs à la correction des couleurs SD et à l'étiquetage forcé des clips photo ne servent pas pour le rendu.
+
+Les résultats sont dans `benchmark/results/*.local.json`, fichiers locaux non versionnés.
+
+## Toujours non qualifié
+
+- Mémoire sur de longues sessions (dernière mesure en 3.0.6).
+- HDR au-delà de la conversion HLG → SDR, son audible et synchronisation audio/vidéo.
+- Les trois bugs Android de la suite `full` ci-dessus, et le seek dans une composition 4K paresseuse sur Pixel.
+- Vraie vidéo 4K 60 fps à 60 Mbit/s sur iPhone chaud : 65 à 91 % des frames affichées selon les runs.
+- Export iOS en `yuv` : environ 2 à 4 ms de plus par frame qu'en `rgba` (à optimiser).
+- Aucune mesure iPhone à l'état thermique *nominal* pour la comparaison des formats : le téléphone est resté chaud toute la journée.

package/ios/NativeResourceStats.h

@@ -24,6 +24,15 @@ struct NativeResourceStats {
   inline static ResourceCounter encoderSubmittingBuffers;
   inline static ResourceCounter encoderSubmittingBytes;
 };
+// Composition preview diagnostics, counted since launch: an acquire refused
+// while the frame ring is full, an acquire that found no decoded frame queued
+// (the decoder not ahead), the decode ticks run, and those over 16 ms.
+struct PreviewStats {
+  inline static std::atomic<uint64_t> ringRefusals{0};
+  inline static std::atomic<uint64_t> emptyQueues{0};
+  inline static std::atomic<uint64_t> decodeTicks{0};
+  inline static std::atomic<uint64_t> slowDecodeTicks{0};
+};
 inline size_t pixelBufferBytes(CVPixelBufferRef buffer) {
   size_t bytes = CVPixelBufferGetDataSize(buffer);
   return bytes ? bytes : CVPixelBufferGetBytesPerRow(buffer) *

package/ios/RNSVColorSpace.h

@@ -16,10 +16,10 @@ namespace RNSkiaVideo {
  * contrast. Asking AVFoundation for these properties makes it tone-map to
  * SDR on the way out, on its own fast path.
  *
- * Applied unconditionally rather than only to HDR sources: a source already
- * in Rec.709 costs nothing, and a BT.601 one gets the conversion it always
- * needed. It also spares the decoders an inspection of the track's transfer
- * function before its format descriptions are even loaded.
+ * Applied to every BGRA output rather than only to HDR sources: a source
+ * already in Rec.709 costs nothing, and a BT.601 one gets the conversion it
+ * always needed. NV12 output takes them only for HDR, see
+ * TrackNeedsSDRConversion.
  */
 static inline NSDictionary* SDRColorProperties() {
   return @{
@@ -29,6 +29,37 @@ static inline NSDictionary* SDRColorProperties() {
   };
 }
 
+/**
+ * Whether a track needs AVFoundation's conversion to Rec.709 even when its
+ * frames are decoded to NV12: an HDR transfer function (HLG, PQ) or BT.2020
+ * primaries, which only a tone mapping brings to SDR.
+ *
+ * An SDR track decoded to NV12 is left as it is: its buffers carry their own
+ * YCbCr matrix, which the GPU applies when it converts them. Asked for Rec.709
+ * properties, VideoToolbox relabels an SD clip's BT.601 samples as BT.709
+ * without converting them, and its saturated colors shift (a yellow's blue
+ * by 11 levels), where its BGRA output does convert.
+ */
+static inline bool TrackNeedsSDRConversion(AVAssetTrack* track) {
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wdeprecated-declarations"
+  NSArray* descriptions = track.formatDescriptions;
+#pragma clang diagnostic pop
+  for (id description in descriptions) {
+    auto format = (__bridge CMFormatDescriptionRef)description;
+    CFTypeRef transfer = CMFormatDescriptionGetExtension(
+        format, kCMFormatDescriptionExtension_TransferFunction);
+    CFTypeRef primaries = CMFormatDescriptionGetExtension(
+        format, kCMFormatDescriptionExtension_ColorPrimaries);
+    if (transfer && (CFEqual(transfer, kCVImageBufferTransferFunction_ITU_R_2100_HLG) ||
+                     CFEqual(transfer, kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ)))
+      return true;
+    if (primaries && CFEqual(primaries, kCVImageBufferColorPrimaries_ITU_R_2020))
+      return true;
+  }
+  return false;
+}
+
 /**
  * Stamps Rec.709 onto a buffer handed to AVAssetWriter. The writer's own
  * output settings already declare it, but a buffer carrying no color

package/ios/ReactNativeSkiaVideo.mm

@@ -276,6 +276,10 @@ RCT_EXPORT_BLOCKING_SYNCHRONOUS_METHOD(install) {
             add("encoders", NativeResourceStats::encoders);
             add("encoderSubmittingBuffers", NativeResourceStats::encoderSubmittingBuffers);
             add("encoderSubmittingBytes", NativeResourceStats::encoderSubmittingBytes);
+            result.setProperty(rt, "previewRingRefusals", static_cast<double>(PreviewStats::ringRefusals.load()));
+            result.setProperty(rt, "previewEmptyQueues", static_cast<double>(PreviewStats::emptyQueues.load()));
+            result.setProperty(rt, "previewDecodeTicks", static_cast<double>(PreviewStats::decodeTicks.load()));
+            result.setProperty(rt, "previewSlowDecodeTicks", static_cast<double>(PreviewStats::slowDecodeTicks.load()));
             return jsi::Value(std::move(result));
           }));
   RNSVModule.setProperty(runtime, "getBackendInfo",

package/ios/VideoComposition.h

@@ -31,6 +31,11 @@ public:
    * default) does. iOS only.
    */
   bool directTexture = false;
+  /**
+   * The composition's `framePixelFormat: 'yuv'`: frames decoded to NV12, the
+   * decoder's own format, rather than BGRA. See setupReader.
+   */
+  bool yuvFrames = false;
   bool isVideo = true;
   bool audioEnabled = false;
   double audioVolume = 1.0;
@@ -61,6 +66,20 @@ public:
       auto lazyProp = jsComposition.getProperty(runtime, "lazyDecoders");
       composition->lazyDecoders = lazyProp.isBool() && lazyProp.getBool();
     }
+    // 'auto' is NV12 on iOS, as on Android: a third of BGRA's memory, and the
+    // same picture for camera footage (docs/FRAME_PIXEL_FORMAT.md).
+    bool yuvFrames = true;
+    if (jsComposition.hasProperty(runtime, "framePixelFormat")) {
+      auto formatProp = jsComposition.getProperty(runtime, "framePixelFormat");
+      if (formatProp.isString()) {
+        auto format = formatProp.asString(runtime).utf8(runtime);
+        if (format != "auto" && format != "yuv" && format != "rgba")
+          throw jsi::JSError(runtime, "framePixelFormat must be 'auto', 'yuv' or 'rgba'");
+        yuvFrames = format != "rgba";
+      } else if (!formatProp.isUndefined()) {
+        throw jsi::JSError(runtime, "framePixelFormat must be 'auto', 'yuv' or 'rgba'");
+      }
+    }
     auto jsItems = jsComposition.getProperty(runtime, "items")
                        .asObject(runtime)
                        .asArray(runtime);
@@ -81,6 +100,7 @@ public:
       item->duration = checkedMediaSeconds(jsItem.getProperty(runtime, "duration").asNumber());
       checkedMediaSeconds(item->startTime + item->duration);
       checkedMediaSeconds(item->compositionStartTime + item->duration);
+      item->yuvFrames = yuvFrames;
       item->resolution = CGSize();
       if (jsItem.hasProperty(runtime, "resolution")) {
         auto resProp = jsItem.getProperty(runtime, "resolution");

package/ios/VideoCompositionFramesExtractorHostObject.h

@@ -71,6 +71,10 @@ private:
   RNSVDisplayLinkWrapper* displayLink;
   NSDate* startDate;
   CMTime pausePosition = kCMTimeZero;
+  // The clock decodeCompositionFrames last picked the frames at, and when
+  // (CACurrentMediaTime); invalid once play, pause or a seek moves the clock.
+  CMTime framesTime = kCMTimeInvalid;
+  CFTimeInterval framesTimeHost = 0;
   bool playWhenReady = false;
   bool isPlaying = false;
   bool isLooping = false;
@@ -91,6 +95,7 @@ private:
   void pause();
   void seekTo(CMTime time);
   CMTime getCurrentTime();
+  CMTime getPresentedTime();
   void release();
   bool opensAt(const std::shared_ptr<VideoCompositionItem>& item,
                double position) const;