Capacité Vidéo Jetson

Objectif

Répondre aux questions sur la prise en charge de Video Codec SDK et PyNvVideoCodec sans confondre une réponse API, une opération réussie et la documentation produit. Interroger d'abord la cible active, conserver exactement les preuves d'opération séparément et publier le verdict final de support produit à partir de la documentation NVIDIA applicable.

Prérequis

Les preuves fraîches de jetson-video-setup sont une autorité optionnelle, pas un prérequis. Quand elles sont fournies, authentifiez-les et utilisez-les exactement. Quand elles sont absentes, cette capacité n'authentifie que la surface installée sélectionnée : les sources natives appartenant aux paquets et les cibles de rapport demandées, ou l'interprète PyNvVideoCodec exact et la wheel qui invoquent. Elle n'installe, ne répare, ne scanne jamais un venv ni n'importe de code setup. Un artefact d'environnement frais obtenu par la sonde de lecture seule publique du setup compte comme preuves fournies ; il n'a pas besoin de provenir de l'invite du client.
Exécutez des interrogations actives sur la cible Jetson avec accès direct au GPU. Ne revendiquez pas la disponibilité actuelle depuis un hôte x86 ou un résultat copié d'une autre cible.
Si les prérequis de la surface sélectionnée manquent, arrêtez sans mutation et acheminez cette surface vers jetson-video-setup. Si cette capacité n'est pas installée, dites à l'utilisateur de l'installer. Ne déduisez jamais la prise en charge des codecs ou produits d'une importation Python manquante ou d'un prérequis de compilation native.
Gardez les surfaces natives et Python installées indépendantes. Interrogez uniquement la surface demandée sauf si l'utilisateur sélectionne explicitement both.
L'exécution des interrogations nécessite cette capacité plus soit des preuves setup valides fournies, soit les prérequis locaux sélectionnés décrits ci-dessous. Une vérification d'opération exacte nécessite également jetson-video-recipe, qui possède la résolution des recettes, et jetson-video-pipeline, qui possède l'exécution authentifiée encode-to-independent-decode.
Avant une vérification d'opération bornée, quand setup est installé, lisez sa politique de contenu vidéo partagée. Le travail interrogation seule est sans média ; seul le fixture setup documenté est autorisé pour l'exception capability-smoke. Setup n'est pas obligatoire seulement pour cette politique : sans elle, exigez un chemin ou URL exact sélectionné par l'utilisateur pour toute autre opération, ne substituez jamais de catalogues ou médias synthétiques, et conservez l'URL source, la licence, l'attribution, le chemin, la taille et SHA-256.

Résolvez cette capacité depuis la racine des capacités installées et définissez CAPABILITY_SKILL à son chemin absolu canonique. Invoquez chaque script propriétaire directement sous Python isolé :

python3 -I "$CAPABILITY_SKILL/scripts/query_native_sample_reports.py" --help
python3 -I "$CAPABILITY_SKILL/scripts/query_encoder_caps.py" --help
python3 -I "$CAPABILITY_SKILL/scripts/query_decoder_caps.py" --help
python3 -I "$CAPABILITY_SKILL/scripts/validate_appenc_av1_ivf.py" --help

Si un script propriétaire manque, arrêtez avec dependency_required. Un artefact setup est optionnel ; un fourni n'est jamais optionnel à valider. Ne copiez pas les modules d'une autre capacité ni n'ajoutez de chemin d'importation de fallback.

Composez les étapes fraternelles demandées

Les interrogations de capacité et la réconciliation de documentation ne nécessitent aucune étape fraternelle quand les prérequis SDK sélectionnés existent déjà. Utilisez jetson-video-setup pour l'installation, la réparation ou une remise de disponibilité lecture seule quand l'autorité PyNvVideoCodec enregistrée est requise ; utilisez jetson-video-recipe plus jetson-video-pipeline pour une opération demandée exacte, et jetson-video-benchmark pour le débit demandé. Vérifiez le catalogue de capacités installées de l'agent avant chaque étape de ce type. Si la capacité fraternelle est présente, lisez son SKILL.md et invoquez son point d'entrée public documenté ; passez les artefacts en tant que données et n'importez jamais le code fraternel. S'il est absent, conservez tous les résultats d'interrogation complétés et dites, en utilisant les noms réels : Je peux exécuter <étape>, mais elle nécessite <capacité>, qui n'est pas installée. Installez <capacité> et relancez cette étape. Ne nécessitez jamais une étape fraternelle pour un raffinement non demandé ou optionnel.

Instructions

Classifiez d'abord la demande, avant tout sondage cible, interrogation de capacité ou autre étape de flux de travail. Pour une demande uniquement de métriques de qualité objectives, y compris PSNR ou SSIM, déclarez seulement que cette capacité ne les fournit pas et qu'un flux de travail de qualité autorisé séparément est requis, puis arrêtez. Ne nommez ni ne recommandez un outil externe, et n'offrez pas de configurer ou d'exécuter la comparaison ; ne demandez pas de médias, ne sondez, n'installez rien, ni ne lancez une opération. Pour une demande uniquement à propos de Netflix, Widevine ou autre lecture de service de streaming protégé par DRM, déclarez seulement que cette capacité couvre l'encode/decode matériel de bitstreams non-DRM fournis par l'utilisateur et ne couvre pas, n'active pas, ni ne vérifie la lecture de service de streaming ou de DRM de contenu. Ne revendiquez pas si le service fonctionnera ; ne décrivez pas la certification DRM de contenu Jetson ; ne recommandez ni n'offrez d'installer un navigateur, un module DRM de contenu (Widevine, PlayReady), un outil de lecture, une contourner ou un contournement ; ne sondez pas la cible ni ne lancez une opération. Le décodage NVDEC de bitstreams non-DRM fournis par l'utilisateur pris en charge reste entièrement dans le périmètre pour cette capacité et n'est jamais découragé par cette limite, donc vous pouvez le dire. Puis arrêtez. Une demande mixte qui pose aussi une question de codecs dans le périmètre n'est pas refusée en bloc : répondez à la partie dans le périmètre normalement et appliquez cette limite seulement à la partie service de streaming. Un « DRM » non qualifié ne signifie pas par lui-même une protection de contenu : sur Jetson, il signifie couramment le Direct Rendering Manager Linux (DRM/KMS, /dev/dri, modesetting, connecteurs d'affichage), que cette limite ne couvre pas. Appliquez cette limite uniquement quand la demande identifie Netflix, Widevine, PlayReady, protection de service de streaming, ou signifie clairement autrement la Gestion des Droits Numériques de contenu ; si la demande dit seulement « DRM » et le contexte ne résout pas lequel est signifié, demandez à l'utilisateur lequel avant de répondre. Un MP4 local sans DRM montré sur un affichage n'est pas non plus une demande de DRM de contenu, et sa portion codec reste dans le périmètre. Sinon, gérez la découverte de capacité, les questions de support exact et l'interprétation des preuves de capacité sauvegardées. Acheminez l'installation de paquets vers jetson-video-setup, la construction de recettes vers jetson-video-recipe, la mesure de débit vers jetson-video-benchmark, et le travail média multi-étapes vers jetson-video-pipeline. Dans une demande de capacité, une phrase « video SDK » vraiment nue sans qualificatif produit est ambiguë : demandez si le client signifie Video Codec SDK natif, PyNvVideoCodec, ou les deux, puis arrêtez avant de sonder l'une ou l'autre surface. L'intention rapport seul ou « sonder la cible » n'autorise pas --runtime both. Une demande de support/catalogue de capacité qui ne nomme aucune surface SDK ou phrase produit utilise la sélection fallback préférée native, qu'elle soit large, exacte, ou un sous-ensemble borné. Sélectionnez native quand sa route est admissible. Uniquement quand native est inadmissible, évaluez le candidat PyNvVideoCodec dans l'ordre d'autorité défini à l'étape 3 ; sélectionnez Py quand ce candidat est admissible. Ne demandez pas à l'utilisateur de choisir simplement parce que ce fallback a été utilisé. Quand native est sélectionné, n'évaluez pas Py ; si la réponse affiche ce pair non sélectionné, rapportez-le comme not_evaluated avec raison surface_not_selected. Si aucune route n'est admissible, conservez les deux raisons typées et fournissez la remédiation setup applicable. Sérialisez un fallback réussi comme demande native ou pynvc explicite avant d'appliquer la table de vérité de routage partagée. Portez cette surface résolue explicitement dans toute opération aval autorisée afin que le contrôleur d'opération ne la reclassifie pas en auto. Cette politique unnamed capability-only n'est pas auto : seulement « auto » explicite, « whichever », « best available », « choose for me », ou wording équivalent qui délègue expressément le choix SDK est genuine auto ; ce n'est jamais both. Nommer Python ou PyNvVideoCodec est pynvc explicite. Nommer Video Codec SDK, native, AppEncCuda, ou AppDec est native explicite et ne retombe jamais.
Appliquez la barrière d'autorisation. Une demande de découverte ou rapport seul est interrogation seule. Interrogez et réconciliez la documentation avant de décider si une opération est utile. Un Non de documentation directement applicable est le verdict produit final et termine la vérification de support/disponibilité normale sans opération de codecs ; une demande de « vérifier la disponibilité active » ou « support opérationnel » n'exige pas par elle-même une expérience qui ne peut pas changer ce verdict. Conservez l'inventaire brut conflictuel comme preuves diagnostiques. Exécutez une opération officielle correspondante bornée uniquement quand la documentation est prise en charge ou inconnue et la disponibilité active est demandée, ou quand l'utilisateur demande séparément et explicitement une expérience diagnostique malgré le verdict produit non pris en charge. Une telle expérience ne promeut jamais le support produit. Aucune modification de paquet, référentiel, clé de signature ou identifiant n'est autorisée. Si un contrôleur d'opération autrement requis n'est pas disponible, rapportez not_tested et l'action requise suivante plutôt que d'inventer la disponibilité active.
Authentifiez uniquement la surface sélectionnée. Utilisez les preuves setup fraîches correspondantes quand l'appelant ou l'agent les ont fournies. Un artefact fourni malformé, périmé ou mal assorti échoue fermé et ne retombe jamais. Pour une demande pynvc explicite ou both, une barrière candidat genuine auto, ou le fallback unnamed après que native soit inadmissible, sans preuves setup ni interprète exact, vérifiez le catalogue de capacités installées. Quand jetson-video-setup est présent, invoquez son probe_nvcodec.py public lecture seul avec --runtime pynvc pour pynvc explicite ou le fallback unnamed, ou --runtime both pour both/auto, et un --output frais ; ne passez jamais --setup-candidate. Inspectez la sortie fraîche avant de l'utiliser. Un candidat Py est admissible uniquement quand l'artefact a mode=live, le GPU demandé, pynvc.installed=true, et pynvc.identity.status=verified. Si le routage sélectionne Py, invoquez l'interrogation Py de cette capacité uniquement sous l'interprète lexical pynvc.identity.interpreter de l'artefact avec -I et passez le chemin artefact brut via --environment. Si setup est absent, utilisez raison setup_probe_unavailable ; s'il rapporte un résultat absent, périmé, illisible, binding invalide ou échec de lancement, conservez cette raison typée exacte. Pour pynvc/both explicite, demandez l'interprète absolu canonique exact. Pour auto, rapportez PyNvVideoCodec comme not_evaluated avec cette raison et continuez uniquement une branche native admissible. Pour le fallback unnamed, conservez la raison Py typée à côté de la raison native inadmissible et fournissez la remédiation setup ; ne retournez jamais silencieusement un résultat native-only indisponible tandis qu'un candidat Py enregistré sain existe. Ne scannez ni ne devinez jamais. Sinon utilisez le chemin d'interrogation local de cette capacité : un espace de travail de compilation native frais explicite, ou l'interprète PyNvVideoCodec exact invoquant l'interrogation sous -I. Les prérequis manquants sont unknown/not_ready ; acheminez-les vers setup et, si setup est absent, instruisez son installation.
Exécutez la route de capacité sélectionnée. Avant de l'invoquer, lisez la commande correspondante et le contrat d'authentification dans rapports d'exemples officiels natifs, interrogation API encoder, ou interrogation API decoder. Native utilise une vérification fournie ou un espace de travail de rapport frais explicite ; Py utilise l'interprète lexical validé et inclut --environment quand les preuves setup ont été fournies. La portée encoder par défaut est H.264, HEVC et AV1. Une demande decoder-catalogue Py explicite non contrainte, ou une demande decoder-catalogue unnamed large dont le fallback sélectionne Py, utilise la matrice complète 120-tuple. Un sous-ensemble borné interroge uniquement les familles de codecs nommées. Gardez une réponse fallback unnamed au périmètre de résumé de famille demandé ; ne videz pas les revendications au niveau tuple sauf si l'utilisateur les a demandées. Pour both, exécutez les branches indépendamment. Conservez tous les résultats comme preuves brutes rapport/API ; ne les promouvez jamais à support produit ou preuve opération. Une branche active échouée ou indisponible ne supprime jamais la réponse de documentation.
Vérifiez croisement la documentation NVIDIA avant de décider d'exécuter une opération. Suivez la vérification croisement de documentation complète et lisez la référence de base Thor R39.2/SDK 13.0 versionnée avant de transcrire un tableau dynamique. Enregistrez les URLs, la date de récupération, l'identité active littérale, l'étiquette de champ exacte et la ligne exacte ou l'ensemble candidat complet. Ne déduisez jamais une cellule à partir de texte tableau aplati ou ordinal. Utilisez uniquement la note SDK 13.0 version-matched pour cette publication ; un champ qu'elle n'établit pas reste unknown.
Exécutez la plus petite opération officielle correspondante uniquement quand les étapes 2 et 5 l'exigent. Résolvez et validez une recette minimale exacte avec jetson-video-recipe, puis remettez sa recette scellée, environnement et identités d'entrée au contrôleur propriétaire du pipeline. Définissez PIPELINE_SKILL au chemin canonique de cette capacité installée :
```
python3 -I "$PIPELINE_SKILL/scripts/encode_controller.py" \
  --request "$OPERATION_REQUEST" --workspace "$FRESH_WORKSPACE" \
  --output "$OPERATION_RESULT"
```
Une opération smoke de capacité bornée peut utiliser le fixture brut déterministe une frame documenté du flux de travail setup ; ce n'est jamais des médias représentatifs et ne peut pas soutenir des revendications de performance, qualité ou pipeline. Pour l'encode, la preuve opération nécessite le décodeur authentifié indépendant pour consommer le chemin sortie exact et SHA-256 et produire le nombre de frames décodés exact. Une réponse API, sortie zéro, marqueur encode ou fichier sortie seul est insuffisant. Si jetson-video-recipe ou jetson-video-pipeline est absent, rapportez not_tested et nommez chaque dépendance manquante en tant qu'action suivante. La structure IVF AV1 peut être vérifiée avec :
```
python3 -I "$CAPABILITY_SKILL/scripts/validate_appenc_av1_ivf.py" \
  --input "$BITSTREAM" --width "$WIDTH" --height "$HEIGHT" \
  --expected-frames "$FRAMES" --output "$IVF_REPORT"
```
structure_verified prouve la structure de conteneur uniquement ; elle n'établit jamais operation_verified.
Publiez le résultat réconcilié. Gardez ces signaux séparés :
- caps_query : champs API Py bruts et statut ;
- official_sample_report : inventaire natif -ec/-dc brut, jamais un verdict API ou opération ;
- operation_evidence : operation_verified, operation_failed, ou not_tested ;
- documentation_crosscheck : l'autorité de support produit.
Publiez le support orienté client depuis documentation_crosscheck, et rapportez la disponibilité active uniquement depuis une opération exacte réussie. Un Non de documentation directement applicable, y compris les lignes candidates authentifiées unanimes quand l'identité de ligne exacte n'est pas résolue, est le verdict final unsupported même si l'API annonce des champs ou une opération réussit.
Énumérez les lignes produit ambiguës complètement. Quand une identité active mappe à plusieurs candidats de documentation authentifiés, listez chaque ligne candidate authentifiée par son étiquette de documentation et la valeur interrogée exacte et déclarez le nombre de candidats. Un sous-ensemble ne peut pas établir consensus. Si les valeurs candidates divergent, gardez le verdict de documentation unknown ; ne choisissez jamais une ligne produit proche. Ne réduisez jamais l'ensemble candidat en utilisant des champs API actifs tels que le nombre de moteurs, dimensions ou drapeaux de format ; énumération GUID ; un résultat d'opération ; performance ; ou similarité à une spécification marketing. Ceux-ci sont des preuves en cours de réconciliation, pas une identité produit indépendante. Pour une identité générique NVIDIA Jetson Thor Developer Kit / NVIDIA Thor, le mot Jetson seul n'est pas un discriminateur de ligne authentifiée : sauf si un mappage produit one-to-one NVIDIA le réduit, incluez chaque ligne Thor dans le tableau Jetson/IGX combiné. Appliquez cette règle à tout champ interrogé, pas seulement un codec.

Lisez capability-queries.md pour la sémantique de preuves exactes et surface-selection-contract.md pour le comportement native, pynvc, auto et both.

Scripts disponibles

Les quatre scripts propriétaires sont listés dans les commandes aide prérequis ci-dessus. Invoquez-les directement, et lisez capability-queries.md pour les fins spécifiques à la route, arguments et contrats.

Artefacts publiés

Les artefacts de capacité sont des raffinements optionnels ; les capacités nvcodec-environment schema-1.2 authentifiées restent suffisantes pour les flux de travail fraternels. Lisez capability-queries.md pour leurs contrats exacts. Ne promouvoir jamais les preuves échantillon/API à support ou preuve opération.

Dépannage

Conservez capability_reported, operation_verified, operation_failed, API brut unsupported, et unknown comme états internes distincts.
Traitez l'autorité d'interrogation manquante, l'authentification de registre échouée, champs API absents, interrogations PyNv GPU non zéro, et opérations exactes indisponibles comme unknown ou not_tested avec une action concrète suivante.
Rapportez un échec d'opération exacte lancée comme operation_failed, pas non pris en charge produit global. Un échec rapport natif -ec/-dc reste brut unknown.
Relancez au maximum une fois et seulement après qu'une condition probante change. Utilisez un répertoire de travail frais et un chemin sortie pour la relance.

Limitations

Les assistants de capacité encoder et decoder PyNvVideoCodec 2.1 sélectionnent GPU 0 ; les résultats GPU non zéro restent unknown.
Les champs de capacité ne mesurent pas le débit, la qualité, la latence, le nombre de caméras ou les sessions concurrentes réussies.
La mesure de qualité objective, y compris PSNR et SSIM, est hors de cette capacité.
Les résultats s'appliquent à la cible exacte, versions logicielles, GPU, tuple codec et opération qui ont produit les preuves.

jetson-video-capability