Generated banner for Jetson Video Pipeline
Generated logo for Jetson Video Pipeline

Jetson Video Pipeline

NVIDIAOfficialCreated by Vinit BansalDistributed by NVIDIA

  • Skill
  • Workflow
  • Software development
  • Apache-2.0
  • Medium risk

From the author

Use when planning, executing, and independently validating Jetson Video Codec SDK or PyNvVideoCodec encode/decode, transcode, segmentation, container decode, AV1, or concise acceptance workflows.
— the description by Vinit Bansal

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The Jetson Video Pipeline skill provides a structured framework for managing video encode, decode, and transcode operations on NVIDIA Jetson hardware. It focuses on using official Jetson Video Codec SDK and PyNvVideoCodec samples to perform codec tasks while ensuring each stage of the pipeline is independently verified. The skill enforces strict evidence-based reporting, requiring that every consumer validates the output bytes produced by its preceding stage. It is designed for developers needing to perform codec triage, AV1 verification, or acceptance testing, while maintaining clear boundaries regarding what constitutes proven performance or interoperability.

What it does

  • Plans and executes video codec workflows including encode, decode, and transcode.
  • Validates pipeline stages by re-hashing and re-authenticating artifacts between producers and consumers.
  • Provides structured acceptance reports for codec readiness and capability.
  • Supports container triage and AV1 verification using official NVIDIA sample contracts.
  • Enforces strict filesystem-based artifact sharing and synchronization protocols.
  • Manages dry-run planning for codec architecture and route verification.

When to use it

  • When you need to verify the correctness of a video codec pipeline on Jetson hardware.
  • When performing acceptance testing for encode/decode performance or functionality.
  • When you need to triage containerized video streams using official SDK tools.
  • When you require a reproducible, evidence-based report of codec pipeline execution.

Advantages

  • Ensures data integrity by requiring independent verification of every pipeline stage.
  • Provides a standardized, reproducible approach to codec testing.
  • Strictly adheres to official NVIDIA sample contracts and API usage patterns.
  • Clear separation between planning, execution, and validation phases.

Usage examples

“Plan an encode-decode pipeline for a 1080p H.264 file.”
The agent will outline the required stages, identify the necessary sample tools, and state the assumptions for execution without launching any processes.
“Execute an AV1 verification workflow for /data/input.ivf.”
The agent will authenticate the media, run the appropriate AV1 sample, verify the output frame count, and provide a report with checksums.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/nvidia/jetson-video-pipeline/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip jetson-video-pipeline.zip -d .agents/skills

Documentation by Vinit Bansal

Jetson Video Pipeline

Purpose

Build and run direct NVIDIA sample commands, then prove each consumer used the exact bytes produced by the preceding stage. This skill owns codec workflow and evidence policy; it does not own environment installation or product-support claims.

Terminal gates

Apply these before inspecting the target, another skill, or a command:

  1. For a PSNR/SSIM-only request, state that objective quality measurement is outside this skill and requires a separately authorized workflow, return not_evaluated with reason out_of_scope, then stop. Do not name a tool or request media. Do the same for a request limited to capture, transport, AI, display, or glass-to-glass latency. For a mixed codec-plus-quality request, continue only the codec portion and report the quality portion as not_evaluated with reason out_of_scope rather than silently omitting it.

  2. Classify every other request before applying the media gate:

    • Return planned for architecture and route questions; they need no media. State assumptions and what execution would verify, then stop before target inspection, retrieval, authentication, recipe dispatch, or workspace creation.

    • A dry run with concrete commands needs a user-named path or placeholder and the metadata required by those commands. The media need not exist. Obtain recipe options through jetson-video-recipe, report planned, and do not inspect, authenticate, or launch anything.

    • Execution, verification, and performance require one exact target-local media path or one user-supplied HTTP(S) URL. Without it, return input_required, identify the intended route briefly using only stages expressible by this skill's allowlisted samples, ask for that one item, and stop before target inspection, retrieval, authentication, recipe dispatch, or workspace creation. Label every other requested transform as unresolved rather than inventing an executable route.

    Never choose catalog or synthetic media. The deterministic setup smoke fixture is allowed only for a bounded capability operation and is never representative pipeline or performance evidence.

Select and authenticate the execution surface

Steps 3–4 apply to execution; step 5 also applies to recipe-bearing dry runs. For other planning, preserve an explicit surface without claiming live eligibility; delegated surface-specific dry runs return selection_required without ranking the choices.

  1. Preserve explicit native, pynvc, and both. Map “whichever”, “best available”, “choose for me”, or otherwise delegated selection to auto, not both. For auto: zero eligible surfaces is blocked, one runs, and two is selection_required; do not rank them or consult old results.

  2. Obtain a fresh read-only readiness result from jetson-video-setup through public skill dispatch. For Python, pass any exact user-supplied or current-conversation interpreter. Otherwise select the profile before dispatch: decode-performance may use pynvc-smoke; encode, segmentation, advanced/decode.py, pipeline, and encode-benchmark work require full-samples. Setup checks that profile's conventional path; never scan for a venv. If only the smoke profile is ready for full-samples work, return dependency_required before workspace creation and direct the user to provision a separate full-samples venv; never upgrade the smoke venv in place. Native eligibility requires one installed, package-verified SDK and one package-owned Samples root. Python eligibility requires that exact interpreter, an importable PyNvVideoCodec distribution loaded from its environment, and a clean pip check. The result must match the requested Jetson and GPU. Preserve the setup reason when a candidate is ineligible. The requested pipeline supplies its own operation proof.

  3. Recipe-bearing encode and transcode work requires jetson-video-recipe; an acceptance request containing a performance stage also requires jetson-video-benchmark. Invoke either through public skill dispatch and pass its result as data. If a needed sibling is absent, preserve completed stages and say: I can run <stage>, but it requires <skill>, which is not installed. Install <skill> and retry this stage.

    “Preserve” means retain each completed stage's status and current path/size/SHA-256 identities in the user-facing partial result; it does not create hidden resumable state. On retry in the same request, reopen and rehash those artifacts and skip only unchanged complete stages. With a changed/missing identity, or a later request that does not supply the prior evidence, use a new workspace and rerun the stage.

Execute

  1. Choose the smallest route: encode_decode, native_transcode, pynvc_segments, container_triage, av1_verify, or acceptance.

  2. Read pipeline-workflow.md for stage order, content handling, retry policy, and reporting. Read official-sample-contract.md completely once; it covers sample allowlists, direct arguments, marker grammar, and frame-layout checks. Read buffer-sharing-and-synchronization.md completely once for filesystem boundaries. For a custom in-process CUVID/CUDA/NVENC graph, also read in-process-codec-boundaries.md completely once.

  3. For execution, canonicalize the exact media, record its provenance and identity, and use a new mode-0700 workspace with fresh outputs. For a dry run, use only the supplied identity and metadata, state assumptions, and show planned commands and handoffs without opening the media or authenticating launchers.

  4. For execution, authenticate each selected native sample or wheel member, launch its literal argument list directly, and retain unedited logs. Require the reference's exit, marker, count, error, freshness, and layout checks.

  5. Reopen and rehash every producer output before and after its independent consumer. Preserve successful branches, report a failed peer as partial, and apply the reference's single-retry rule.

  6. Emit the applicable io_contract directly in every plan, result, and producer/consumer boundary. Do not depend on a contract module or infer external sharing from a device-memory mode.

Route requirements

RouteRequired proof
encode_decodeOne validated recipe; direct AppEncCuda→AppDec or wheel-owned basic encode→advanced decode; exact raw and decoded byte counts.
native_transcodeH.264 input, exact HEVC native projection, AppTrans output, exactly one accepted transcode marker, then AppDec over the same hash; require the AppTrans and AppDec frame counts to be equal and positive, and to equal the known input count when available.
pynvc_segmentsWheel-owned schedule/config; every declared segment is fresh and nonempty; decode and rehash every segment independently.
container_triageEligible Jetson, exact local/retrieved container, intrinsic libavformat demux in AppDec or wheel-owned advanced decode, fresh decoded output.
av1_verifyExact AV1 native recipe; host and video-memory modes; AppDec consumes each exact IVF output and reports the expected frame count.
acceptanceA concise reproducible report covering requested readiness, capability, recipe, codec, and benchmark stages with per-stage status and identities.

Report

Use the statuses and concise report defined in pipeline-workflow.md. Include the selected runtime, exact media and recipe identities, literal commands, producer and consumer results, decoded layout/size validation, logs, limitations, and retry reason. Add compact JSON or a checksum manifest when useful or requested.

Limitations

  • Codec work does not prove capture, transport, inference, display, quality, or end-to-end latency.

  • API fields and inventory are not operation proof or product support.

  • Container demux is allowed only inside an authenticated released NVIDIA sample.

  • Apply every deterministic acceptance check in the references.

  • Codec/API capability and benchmark results do not prove buffer interoperability, zero copy, or synchronization compatibility.

Files

references/official-sample-contract.md

Official sample and validation contract

The lists below define route selection. Before each operation, bind every selected native file to the installed nvidia-video-codec-sdk package and every selected Python file to the exact interpreter and PyNvVideoCodec distribution reported by the fresh setup readiness check. Reject a changed or unowned file, a stub/missing library, or a different loaded extension.

Exact pipeline allowlist

Native paths are relative to the authenticated SDK build/source roots.

SampleExecutableSourceCMake fileRequired runtime libraries
AppEncCudaAppEncode/AppEncCuda/AppEncCudaSamples/AppEncode/AppEncCuda/AppEncCuda.cppSamples/AppEncode/AppEncCuda/CMakeLists.txtlibcuda.so.1, libnvidia-encode.so.1
AppDecAppDecode/AppDec/AppDecSamples/AppDecode/AppDec/AppDec.cppSamples/AppDecode/AppDec/CMakeLists.txtlibcuda.so.1, libnvcuvid.so.1
AppTransAppTranscode/AppTrans/AppTransSamples/AppTranscode/AppTrans/AppTrans.cppSamples/AppTranscode/AppTrans/CMakeLists.txtlibcuda.so.1, libnvcuvid.so.1, libnvidia-encode.so.1

PyNvVideoCodec wheel members:

SampleAdditional required RECORD members
samples/basic/encode.pysamples/utils/__init__.py, samples/utils/Utils.py, samples/utils/encode_parser.py, samples/utils/frame_utils.py
samples/advanced/decode.pysamples/utils/__init__.py, samples/utils/Utils.py, samples/utils/decode_parser.py
samples/basic/create_video_segments.pysamples/utils/__init__.py, samples/utils/transcode_parser.py, samples/basic/segments.txt, samples/basic/transcode_config.json

The allowlist in this reference owns route selection. The fresh probe supplies the SDK root, package, tools, interpreter, extension, and dependency evidence; the agent authenticates the selected source or wheel members immediately before use. Do not run another sample merely because it exists in a source tree or wheel.

Build package-owned native samples

Build the selected target directly. First require /usr/bin/dpkg-query -W and -L to identify one installed public nvidia-video-codec-sdk 13.0.x package and its single owned SDK/Samples tree. Require /usr/bin/dpkg --verify nvidia-video-codec-sdk to exit zero with no output. Reject a symlinked/unowned source, multiple candidate roots, or any package/source identity change.

The package name and single-root rule are exact. If the package is absent, renamed, or resolves to zero or multiple complete 13.0.x roots, return dependency_required and route repair to setup; never guess a package or choose one candidate by path order.

Resolve CMAKE, CXX, NVCC, PKG_CONFIG, GENERATOR, and GENERATOR_NAME with standard system commands. Take SDK_ROOT from the package-owned Samples path and CUDA_ROOT from the resolved nvcc; record canonical paths and versions. Select only AppEncCuda, AppDec, or AppTrans from the table above as TARGET, create a fresh mode-0700 BUILD_ROOT outside SDK_ROOT, and invoke these exact argument arrays:

"$CMAKE" -S "$SDK_ROOT/Samples" -B "$BUILD_ROOT" \
  -G "$GENERATOR_NAME" \
  "-DCMAKE_MAKE_PROGRAM=$GENERATOR" \
  -DCMAKE_BUILD_TYPE=Release \
  "-DCMAKE_CXX_COMPILER=$CXX" \
  "-DCUDAToolkit_ROOT=$CUDA_ROOT" \
  "-DCUDAToolkit_NVCC_EXECUTABLE=$NVCC" \
  "-DCMAKE_CUDA_COMPILER=$NVCC" \
  "-DPKG_CONFIG_EXECUTABLE=$PKG_CONFIG"
"$CMAKE" --build "$BUILD_ROOT" --target "$TARGET" --parallel 2

The resulting launchers under BUILD_ROOT are exactly AppEncode/AppEncCuda/AppEncCuda, AppDecode/AppDec/AppDec, and AppTranscode/AppTrans/AppTrans. Require the selected binary to remain inside BUILD_ROOT, hash it, and use ldd to prove every library in its table row resolves to a real non-stub file. Recheck package, sources, tools, binary, and libraries after execution. A failed target does not erase a separately successful target; a nonzero configure or build exit fails that target, returns failed with the exact command and captured output, and never launches or substitutes another binary.

Direct argument templates

Treat each placeholder as one argument. NATIVE_RECIPE_ARGS is the validated recipe's exact native projection; CONFIG is the wheel/config artifact bound to the same recipe.

"$APPENC" -i "$RAW" -o "$BITSTREAM" "${NATIVE_RECIPE_ARGS[@]}"
"$APPDEC" -i "$BITSTREAM" -o "$DECODED" -gpu "$GPU"

"$PYTHON" -I "$BASIC_ENCODE" \
  -i "$RAW" -o "$BITSTREAM" -s "${WIDTH}x${HEIGHT}" \
  -m "$BUFFER_MODE" -if "$FORMAT" -f "$FRAMES" -g "$GPU" \
  -c "$CODEC" -json "$CONFIG"
"$PYTHON" -I "$ADVANCED_DECODE" \
  -i "$BITSTREAM" -o "$DECODED" -g "$GPU" -d 0 -f "$FRAMES"

"$APPTRANS" -i "$INPUT" -o "$OUTPUT" -gpu "$GPU" \
  "${TRANSCODE_RECIPE_ARGS[@]}"
"$PYTHON" -I "$CREATE_SEGMENTS" \
  -i "$INPUT" -s "$SEGMENTS" -c "$TRANSCODE_CONFIG" \
  -o "$OUTPUT_TEMPLATE" -g "$GPU"

For AppTrans, copy the exact native recipe projection except raw-only -s, -if, and -gpu; add the selected -gpu once. Never use string evaluation or silent option aliases.

Observable completion

Match anchored lines and require the expected count/path exactly:

  • Native encode: ^Total frames encoded: ([0-9]+)$.

  • Native decode count: ^Total frame decoded: ([0-9]+)$.

  • Encode/decode saved output: ^Saved in file (.+) in (NV12|P016|YUV444|YUV444P16|NV16|P216) format$.

  • Transcode saved output: ^Saved in file (.+) of (8|10) bit depth$.

  • Py encode: ^Completed encoding ([0-9]+) frames using (CPU|GPU) buffers$, one ^ENCODING COMPLETE$, and the requested output path exactly twice as ^Output file: (.+)$.

  • Py full decoder: exactly one of ^Successfully decoded all ([0-9]+) frames to (.+)$ or ^Successfully decoded requested ([0-9]+) frames to (.+)$.

  • Py smoke decoder: exactly one log line ending in Successfully decoded requested ([0-9]+) frames and exactly one ^Total frames decoded: ([0-9]+)$. Its threaded log may prefix the first marker and does not report a decoded output path.

  • Native transcode: exactly one total across legacy \(#totFrames=([0-9]+)\) and current ^Total frame transcoded: ([0-9]+)$; reject duplicates or mixed forms.

  • Segments: ordered ^✓ Created: (.+)$ lines exactly matching the validated schedule outputs, plus ^Summary: ([0-9]+) segments created successfully$.

In all cases reject an explicit error/fatal/failed/failure/CUDA/NVENC/FFmpeg failure line, even when the process exits zero. Require fresh nonempty output, then independent consumption of the same path/size/SHA-256.

Frame and layout check

Apply this check to the actual raw source and to every decoded output, and retain the result. It is a mandatory acceptance step, not optional guidance. Width, height, and frame count must be positive integers. Formats with subsampling enforce their geometry parity before byte arithmetic.

Frame-layout rule.

A raw source file must satisfy the byte-size rule below. A decoded output must also satisfy the independent decoder checks:

  1. size_bytes == width * height * frames * numerator / denominator for the declared pixel format, using the table below. The product must divide exactly -- a non-integral result is a failure, never a rounding case.

  2. The package-owned decoder's reported frame count equals frames, and its reported layout equals the table's decoded layout name.

Fact 1 authenticates raw frame boundaries. For decoded output, both facts are required; raw encoder input has no decoder marker of its own.

Pixel formatnumerator/denominatorWidthHeightDecoded layout name
NV123/2evenevenNV12
YUV4203/2evenevenNV12
P0103/1evenevenP016
NV162/1evenanyNV16
P2104/1evenanyP216
YUV4443/1anyanyYUV444
YUV444_16BIT6/1anyanyYUV444P16
ARGB4/1anyanynot a decoded layout
ABGR4/1anyanynot a decoded layout

Reject any pixel format not in this table rather than guessing a size. Enforce the width/height parity column; an odd dimension for a subsampled format is a failure. When reporting a decoded artifact, use the decoded layout name from the last column -- ARGB/ABGR are input/packed formats only and must not be reported as a decoder output layout.

Report the resolved path, pixel format, width, height, frames, expected bytes, and observed bytes. For a decoded artifact also report the decoder's frame count and layout. Never infer the frame count from a filename.

Worked example: 302 frames at 1920x1080 NV12 -> 1920 * 1080 * 302 * 3 / 2 = 939,340,800 bytes, and AppDec must report 302 decoded frames.

AppEncCuda AV1 output

Do not create or run a separate IVF parser. Prove the artifact the same way as every other output: independently decode the exact produced path with the package-owned decoder and require a positive frame count equal to the requested frame count. Report the output path, size, SHA-256, and decoder frame count.

Evidence classifications

  • api_query_helper: an API returned fields; never operation proof.

  • official_sample_report: an authenticated sample's report mode.

  • official_sample_operation: an authenticated sample was launched and passed the observable checks above.

  • documentation_reference: product-support authority for the exact tuple; never live readiness by itself.

  • absent_release_sample: absent from the authenticated release payload.

  • source_tree_candidate: present in source but not an authenticated runnable route.

Changing an allowlist requires matching direct-command instructions and focused identity, option, marker, stale-output, and handoff tests.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Vinit Bansal
Publisher
NVIDIA (Official)
Distributed by
NVIDIA
Source
NVIDIA/skills · skills/jetson-video-pipeline · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Vinit Bansal or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download jetson-video-pipeline.zip