@pictor-sdk/video-android 0.1.4 → 0.1.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pictor-sdk/video-android",
-  "version": "0.1.4",
+  "version": "0.1.6",
   "description": "Optional Android video playback and export adapter for Pictor. Requires Android API 29+.",
   "license": "MIT",
   "main": "./dist/index.js",
@@ -29,7 +29,7 @@
     "react": ">=18.0.0",
     "@expo/config-plugins": ">=54.0.0",
     "react-native-reanimated": ">=3.16.0",
-    "@pictor-sdk/video-core": "^0.1.1"
+    "@pictor-sdk/video-core": "^0.1.2"
   },
   "devDependencies": {
     "react-native": "^0.81.0",
@@ -40,7 +40,7 @@
     "@types/react": "^19.0.0",
     "@expo/config-plugins": "^54.0.5",
     "react-native-reanimated": "^4.1.0",
-    "@pictor-sdk/video-core": "0.1.1"
+    "@pictor-sdk/video-core": "0.1.2"
   },
   "codegenConfig": {
     "name": "PictorVideoSpec",

package/src/compositionSpike.ts

@@ -106,6 +106,16 @@ export interface CompositionSpikeState {
   releases?: number
   readinessTimeouts?: number
   readinessFailure?: string | null
+  /**
+   * How many resumes had to be re-primed because no frame could satisfy them.
+   *
+   * A resume whose target sits past the newest frame cannot be released on
+   * anything that exists, so playback seeks to the frame on screen to make the
+   * decoder produce one. Counted because it is a recovery, not a normal path:
+   * a number that climbs steadily is the renderer falling behind the transport
+   * more often than it should.
+   */
+  primedResumes?: number
   /** How long the last hold lasted before playback was released. */
   holdMs?: number
   /**

package/src/useCompositionPlayback.ts

@@ -1,4 +1,5 @@
 import { useCallback, useEffect, useMemo, useRef, useState } from 'react'
+import { AppState } from 'react-native'
 import {
   playIntent,
   playlistOf,
@@ -104,6 +105,19 @@ export interface CompositionPlaybackState {
   width: number
   height: number
   error: string | null
+  /**
+   * Why the transport refused to start, or null.
+   *
+   * Playback is released on a frame that shows the position asked for, and if
+   * no such frame arrives the hold times out and the transport stays stopped
+   * rather than starting on an unverified picture. That used to be invisible:
+   * the control stayed enabled, the press was accepted, and nothing happened,
+   * with no way for a host to tell that apart from a person who had not pressed
+   * it yet. Pressing play again clears it and tries afresh.
+   *
+   * @experimental
+   */
+  readinessFailure: string | null
 }
 
 function composedState(snapshot: CompositionSpikeState): CompositionPlaybackState {
@@ -129,6 +143,7 @@ function composedState(snapshot: CompositionSpikeState): CompositionPlaybackStat
     width: 0,
     height: 0,
     error: snapshot.error ?? null,
+    readinessFailure: snapshot.readinessFailure ?? null,
   }
 }
 
@@ -213,13 +228,66 @@ export function useCompositionPlayback(
     setUnsupported(
       refused.map((reason) => ({ clipId: reason.split(':')[0] ?? '', reason }) as UnsupportedSource),
     )
-    if (spec.items.length === 0) return
+    /*
+      A project with nothing in it is a reconciliation too.
+
+      This used to return here, and returning is not nothing: the player is a
+      process-wide singleton that goes on playing whatever it last loaded. So
+      removing the only clip *while it was playing* left the removed clip
+      audible until it reached its own end — measured on a Pixel 7 as roughly
+      four more seconds of a six-second clip, three times out of three — with
+      the picture already cleared and the clock already reading 0:00.000,
+      because those follow the document and only the player does not.
+
+      Pausing is the whole fix. The composition is deliberately **not**
+      released: emptying a timeline is usually a step on the way to putting
+      something else in it, and `loaded.current` is left alone so that undoing
+      the removal reuses the composition already loaded instead of rebuilding
+      one that has not changed. Releasing is what `PlaybackLifecycle` does when
+      the *screen* goes, which is a different question from what the document
+      currently holds.
+
+      Nothing here touches the document. Playback stopping says nothing about
+      where the playhead should be.
+    */
+    if (spec.items.length === 0) {
+      spikePause()
+      return
+    }
     const started = spikeStart(spec) as { ok?: boolean }
     // A refusal is not a load. Recording it as one is what left an editor
     // waiting for an edit the person had already made.
     if (started.ok === true) loaded.current = signature
   }, [enabled, signature, surfaceGeneration, project, mix])
 
+  /*
+    Backgrounding pauses; returning re-arms.
+
+    The same wiring `useMedia3Playback` has, and its absence here was the same
+    bug `PlaybackLifecycle` was written to fix, reintroduced by a newer playback
+    path that never got it. `useVideoSurface` already retires the presentation
+    surface when the app leaves, so the picture stopped and the sound carried
+    on — measured on a Pixel 7 as a composition still reporting `playing` with
+    its position advancing from 1.3 s to 4.4 s across a press of Home.
+
+    Suspend rather than teardown: the picker comes up over the editor as a
+    background transition, and rebuilding a player the screen never lost would
+    be a stall nobody asked for. The document is not touched either way.
+  */
+  useEffect(() => {
+    const subscription = AppState.addEventListener('change', (next) => {
+      if (next === 'active') {
+        lifecycle.resume()
+        setLifecycleEpoch(lifecycle.epoch)
+        return
+      }
+      lifecycle.suspend('background')
+      setLifecycleEpoch(lifecycle.epoch)
+      setPlaying(false)
+    })
+    return () => subscription.remove()
+  }, [lifecycle])
+
   useEffect(() => {
     return () => {
       lifecycle.teardown('unmount')