v0.21.0

pixtreme-transport 0.21.0: the core works with pixtreme 2.5, reads Frame pixels through DLPack, and reports an unconfirmed output termination with a stable reason. The core now requires pixtreme>=2.5.0 at build and run time. The native ABI stays 7 and CONFORMANCE_REVISION stays 8.

• pixtreme 2.4 and later: pixtreme removed px.core.Frame.data. The core's Python bindings now import a Frame's pixels through the Frame's own DLPack export on the consumer stream, and the exit serialization reads a Frame's device, dtype and shape from its metadata without exporting pixels. Constructing a TransportFrame from a Frame, replacing its image, and the exit serialization decision work again on pixtreme 2.4 and later; core 0.20.0 fails there with AttributeError. The core keeps the source Frame and the consumed DLPack capsule until its own GPU work finishes, so both pixtreme-allocated and borrowed pixels stay valid under pixtreme 2.4's release rules.
• Conformance suite: the distributed suite reads and writes pixels through cupy.from_dlpack. Its obligations and behaviour are unchanged, so CONFORMANCE_REVISION stays 8.
• Unconfirmed output termination: when an output stop callback fails and the module has not yet proven cancellation with finish_cancel, explicit join and close no longer wait indefinitely. They return a session-fatal failure with the stable reason output-termination-unconfirmed (Design SP-TRANSPORT-327). The session stays open and keeps its workers, unfinished work and callback context; check reports the first fatal. After the module proves termination, a close retry finishes cleanup, closes, and reports the first fatal. A successful asynchronous stop still waits for proof. Final release still waits for proof and cannot be retried.
• Dependency: pixtreme>=2.5.0.
• Wheels: CPython 3.12 and 3.13, manylinux_2_28_x86_64, built with the image pixtreme-transport-wheel:cuda13-manylinux_2_28-334eb1e23e02 from wheel-build/ at this tag (CUDA 13.2). Each wheel ships the shared library libpixtreme_transport.so.7, the public C and C++ headers, the CMake package configuration and the testing package. The GPU code targets sm 86, sm 89 and sm 120, with compute 120 PTX. CUDA's runtime is linked statically; neither the NVIDIA driver library nor pixtreme's shared library is included.
• Verify the assets with sha256sum -c SHA256SUMS.

v0.20.0

pixtreme-transport 0.20.0: the entrance conversion and the exit serialization take their colour definitions from pixtreme, YCbCr Frames carry Cb and Cr centred at 0, the native ABI becomes 7 and CONFORMANCE_REVISION becomes 8. The core now requires pixtreme>=2.2.2 at build and run time.

• Colour definitions: the core resolves colour coefficients (chromaticities, white points, conversion matrices between colorspaces, the YCbCr Kr and Kb, and the mapping between codes and Frame values) through pixtreme's colour C interface at run time, and uses the CUDA device helpers that pixtreme ships for the pixel computations. The core's native library depends on pixtreme's shared library libpixtreme.so.2 and finds it in the installed pixtreme wheel through a relative $ORIGIN RPATH.
• Chroma centre: floating-point YCbCr Frames carry Cb and Cr centred at 0, matching pixtreme 2.2. The entrance writes, and the exit reads, Cb and Cr on that scale. Code-grid quantization is otherwise unchanged.
• Native ABI 7: libpixtreme_transport.so.7. C++ modules that use the core's public native ABI must be rebuilt against the 0.20.0 headers; the ABI check rejects a module built for ABI 6.
• Conformance suite: pixtreme.transport.CONFORMANCE_REVISION is 8. Expected values that depend on the chroma centre follow the 0-centred scale. A module that pins the expected suite revision changes that value to 8 when it moves to this version.
• Dependency: pixtreme>=2.2.2. pixtreme 2.2.1 can deadlock when the exit's native thread calls pixtreme's C interface while a Python thread holding the GIL waits for it (sync-dev-org/pixtreme-dev#231); 2.2.2 fixes this.
• Known limitation: while Python does not call pixtreme and only the core's native threads call pixtreme's C interface, Python owners that pixtreme borrowed stay queued until a later Python call runs pixtreme's owner cleanup (for example px.core.memory_info()). This is tracked by pixtreme (sync-dev-org/pixtreme-dev#233).
• Wheels: CPython 3.12 and 3.13, manylinux_2_28_x86_64, built with the image pixtreme-transport-wheel:cuda13-manylinux_2_28-d4816d03a6ff from wheel-build/ at this tag (CUDA 13.2). Each wheel ships the shared library libpixtreme_transport.so.7, the public C and C++ headers, the CMake package configuration and the testing package. The GPU code targets sm 86, sm 89 and sm 120, with compute 120 PTX. CUDA's runtime is linked statically; neither the NVIDIA driver library nor pixtreme's shared library is included.
• Verify the assets with sha256sum -c SHA256SUMS.

v0.19.2

pixtreme-transport 0.19.2: the conformance suite drops the output case that needs two visible GPUs, and CONFORMANCE_REVISION becomes 7. The public C and C++ headers, the Python API, native ABI 6 and the product behaviour are unchanged; programs and modules built against the 0.17.0 to 0.19.1 public headers keep loading without being rebuilt.

• Conformance suite: ExitConformance.test_a_frame_on_another_device_is_rejected_before_consumption (scene device-boundary) is removed. It ran only on hosts with two visible GPUs and was skipped elsewhere. Outputs still reject a frame allocated on another device; the suite no longer checks it.
• pixtreme.transport.CONFORMANCE_REVISION is 7. A module that pins the expected suite revision changes that value to 7 when it moves to this version. A harness that still declares device-boundary in ConformanceCapabilities.scenes keeps working.
• Wheels: CPython 3.12 and 3.13, manylinux_2_28_x86_64, built with the image pixtreme-transport-wheel:cuda13-manylinux_2_28-1df5c1aac194 from wheel-build/ at this tag (CUDA 13.2). Each wheel ships the shared library libpixtreme_transport.so.6, the public C and C++ headers, the CMake package configuration and the testing package. The GPU code targets sm 86, sm 89 and sm 120, with compute 120 PTX. CUDA's runtime is linked statically; the NVIDIA driver library is not included. The runtime dependencies are unchanged.
• Verify the assets with sha256sum -c SHA256SUMS.

v0.19.1

pixtreme-transport 0.19.1: the release wheels are built with CUDA 13.2. The public C and C++ headers, the Python API, native ABI 6 and CONFORMANCE_REVISION 6 are unchanged; programs and modules built against the 0.17.0 to 0.19.0 public headers keep loading without being rebuilt.

• Wheel build image: wheel-build/ at this tag installs CUDA 13.2.86 (nvcc and the static CUDA runtime) and NASM 2.15.03, each pinned to an exact RPM version. Modules that build their wheels from wheel-build/ at this tag get the image pixtreme-transport-wheel:cuda13-manylinux_2_28-1df5c1aac194.
• Wheels: CPython 3.12 and 3.13, manylinux_2_28_x86_64, built with that image. Each wheel ships the shared library libpixtreme_transport.so.6, the public C and C++ headers, the CMake package configuration and the testing package. The GPU code targets sm 86, sm 89 and sm 120, with compute 120 PTX. CUDA's runtime is linked statically; the NVIDIA driver library is not included. The runtime dependencies are unchanged.
• Development builds and tests take nvcc, CCCL and cuobjdump from NVIDIA's CUDA 13.2 Python wheels in the development environment and no longer need an operating-system CUDA toolkit. This does not change the published wheels.
• Verify the assets with sha256sum -c SHA256SUMS.

v0.19.0

pixtreme-transport 0.19.0: the public C++ header adds pixtreme::transport::session::ExitSettings::from_native. Native ABI 6 and CONFORMANCE_REVISION 6 are unchanged; the C ABI declarations are unchanged, and programs and modules built against the 0.17.0 to 0.18.0 public headers keep loading without being rebuilt.

• Public C++ adapter (issue #174): static ExitSettings ExitSettings::from_native(const pixtreme_transport_exit_settings* value) copies a borrowed C output-settings handle into an independent C++ snapshot. It neither retains nor releases the caller's reference. The snapshot holds every field (frame period, pacing, encoded depth, prefill, the audio policy's enabled flag, accepted formats, output format and target format, and the ancillary kinds), and its strings and vectors stay valid after the C handle is released. A null or unrelated handle throws std::invalid_argument; other native failures use the same exception mapping as the other C++ wrappers. The adapter is an inline header wrapper over the existing C ABI. Module bindings that convert a C output-settings handle to C++ can call it instead of keeping their own conversion. pixtreme::transport::detail::exit_cpp::settings_value remains and forwards to from_native; names under detail carry no compatibility guarantee, so modules should move to from_native.
• Wheels: CPython 3.12 and 3.13, manylinux_2_28_x86_64, built with the image pixtreme-transport-wheel:cuda13-manylinux_2_28-5dfc35d6a2b1 from wheel-build/ at this tag. Each wheel ships the shared library libpixtreme_transport.so.6, the public C and C++ headers, the CMake package configuration and the testing package. CUDA's runtime is linked statically; the NVIDIA driver library is not included.
• Verify the assets with sha256sum -c SHA256SUMS.

v0.18.0

pixtreme-transport 0.18.0: the core now requires pixtreme>=2.0. Native ABI 6 and CONFORMANCE_REVISION 6 are unchanged; the C ABI declarations and the public headers are unchanged, and programs and modules built against the 0.17.0 to 0.17.4 public headers keep loading without being rebuilt.

• Dependency (issue #170): the runtime requirement is now pixtreme>=2.0. In pixtreme 2.0, pixtreme.core.Frame is no longer a pydantic model and reports validation errors as ValueError. The core and the reusable conformance suite in pixtreme.transport.testing only use Frame's keyword constructor, its five properties and isinstance, so their public behaviour is unchanged. Installing this version brings in pixtreme 2.0; projects that call pydantic methods on Frame (model_dump, model_construct, model_copy, model_fields) or catch pydantic.ValidationError from it need to move to the public Frame interface.
• Wheels: CPython 3.12 and 3.13, manylinux_2_28_x86_64, built with the image pixtreme-transport-wheel:cuda13-manylinux_2_28-5dfc35d6a2b1 from wheel-build/ at this tag. Each wheel ships the shared library libpixtreme_transport.so.6, the public C and C++ headers, the CMake package configuration and the testing package. CUDA's runtime is linked statically; the NVIDIA driver library is not included.
• Verify the assets with sha256sum -c SHA256SUMS.

v0.17.4

pixtreme-transport 0.17.4: the output sender sleeps between GPU completion queries while it waits to reclaim loaned output values. Native ABI 6 and CONFORMANCE_REVISION 6 are unchanged; the C ABI declarations and the public headers are unchanged, and programs and modules built against the 0.17.0 to 0.17.3 public headers keep loading and pick up the new behaviour without being rebuilt.

• Output sender wait (issue #155): when the encoded queue of an output session is empty and values the target lent to the encoder are still waiting for their GPU work to complete, the core send thread now polls the completion every 50 µs and sleeps between polls, like the other host waits of the core, instead of yielding in a busy loop. Values are still returned only after their GPU work completes, in the same order, and the order of sending, the handling of a closed queue and the wait when no value is outstanding are unchanged. A new encoded item is picked up at the next poll, so its pickup can be delayed by at most one sleep.
• Wheels: CPython 3.12 and 3.13, manylinux_2_28_x86_64, built with the image pixtreme-transport-wheel:cuda13-manylinux_2_28-5dfc35d6a2b1 from wheel-build/ at this tag. Each wheel ships the shared library libpixtreme_transport.so.6, the public C and C++ headers, the CMake package configuration and the testing package. CUDA's runtime is linked statically; the NVIDIA driver library is not included.
• Verify the assets with sha256sum -c SHA256SUMS.

v0.17.3

pixtreme-transport 0.17.3: releasing the last reference of an open C output session closes it first. Native ABI 6 and CONFORMANCE_REVISION 6 are unchanged; the C ABI declarations and the public headers' declarations are unchanged, and programs and modules built against the 0.17.0, 0.17.1 or 0.17.2 public headers keep loading and pick up the new behaviour without being rebuilt.

• Output final release (issue #165): when the last reference of an output session handle is released while the session is open, the session now runs the same close sequence as an explicit close (stop the target, end the core encode and send threads, join_target, finish core GPU work, return remaining values, close_target) before it releases the callback context_owner. This matches the input session. An unopened output, or one that was explicitly closed and not reopened, does not call target hooks again. The hooks run synchronously on the thread that releases the last reference, so release it on the lifecycle caller, outside core threads and SDK callbacks. A final release consumes its reference even when the close fails and reports the failure (including a saved fatal) through its status; retry a failing close with an explicit close while you still hold a reference. Like an explicit close, a final release can wait indefinitely for hooks, real completions or GPU work, including during interpreter shutdown. The comments in pixtreme/transport/c/exit.h, c/session_entrance.h and session/session.h state the contract.
• Wheels: CPython 3.12 and 3.13, manylinux_2_28_x86_64, built with the image pixtreme-transport-wheel:cuda13-manylinux_2_28-5dfc35d6a2b1 from wheel-build/ at this tag. Each wheel ships the shared library libpixtreme_transport.so.6, the public C and C++ headers, the CMake package configuration and the testing package. CUDA's runtime is linked statically; the NVIDIA driver library is not included.
• Verify the assets with sha256sum -c SHA256SUMS.

v0.17.2

pixtreme-transport 0.17.2: C++ input and output session bodies that live as long as their native session handle. Native ABI 6 and CONFORMANCE_REVISION 6 are unchanged; the C ABI and the shared library are unchanged, and programs and modules built against the 0.17.0 or 0.17.1 public headers keep loading. The new factories are header-only inline code, so a C++ module that wants them must be rebuilt against the 0.17.2 headers.

• Session ownership (issue #164): pixtreme::transport::session::Entrance::create<T>(args...) and Exit::create<T>(args...) build a module's derived input or output body T whose lifetime is tied to the last reference of the C session handle it creates. The C session owns the body through its context_owner; the body borrows the handle. T takes a SessionConstruction token as its first constructor argument and passes it to the new Entrance(SessionConstruction, ...) or Exit(SessionConstruction, ...) base constructor. The returned std::shared_ptr<T> shares ownership of the C handle. After an explicit close and the end of all callbacks, the body is destroyed exactly once, whichever of the original object, an exported capsule or an imported wrapper is released last. A body's destructor must not use its borrowed session; release external resources in the stop, join and close hooks. The comments on create() in pixtreme/transport/session/session.h state the full contract. The existing constructors keep their behaviour.
• Source archive: the sdist includes the new C++ test source, so the standalone C++ tests build from the source archive.
• Wheels: CPython 3.12 and 3.13, manylinux_2_28_x86_64, built with the image pixtreme-transport-wheel:cuda13-manylinux_2_28-5dfc35d6a2b1 from wheel-build/ at this tag. Each wheel ships the shared library libpixtreme_transport.so.6, the public C and C++ headers, the CMake package configuration and the testing package. CUDA's runtime is linked statically; the NVIDIA driver library is not included.
• Verify the assets with sha256sum -c SHA256SUMS.

v0.17.1

pixtreme-transport 0.17.1: fixes for exit settings crossing the C ABI. Native ABI 6 and CONFORMANCE_REVISION 6 are unchanged; programs and modules built against the 0.17.0 public headers keep loading. The fix for C++ Exit::effective_settings() is in header-only inline code, so C++ code that calls it must be rebuilt against the 0.17.1 headers to get the fix.

• Exit settings handles (issue #162): ExitSettings values whose audio policy is still incomplete (audio output enabled, with accepted_formats, output_format or target_format not yet specified) can be exported to a C handle (pixtreme.transport.native.export_handle) and imported back unchanged. Modules can fill in the missing audio policy before creating the exit session. Creating an exit session still rejects an incomplete audio policy with the same error.
• C++ exits built from a C handle (issue #161): Exit::effective_settings() reads the native session's current effective settings on each call. An Exit built from a retained C handle reports the target's effective settings after the session opens, and every Exit sharing one native session reports the new settings after any of them reopens it. Reads that find unchanged settings keep returning the same reference; failed reads keep the previous reference. The declaration in pixtreme/transport/session/session.h states how long a returned reference stays valid and which concurrent uses are supported.
• Documentation: the package README no longer contains a development section.
• Wheels: CPython 3.12 and 3.13, manylinux_2_28_x86_64, built with the image pixtreme-transport-wheel:cuda13-manylinux_2_28-5dfc35d6a2b1 from wheel-build/ at this tag. Each wheel ships the shared library libpixtreme_transport.so.6, the public C and C++ headers, the CMake package configuration and the testing package. CUDA's runtime is linked statically; the NVIDIA driver library is not included.
• Verify the assets with sha256sum -c SHA256SUMS.