jetson-video-recipe

Par nvidia · skills

Utiliser pour transformer un cas d'usage d'encodeur Jetson en une recette validée, neutre vis-à-vis de la surface, avec des projections natives et PyNvVideoCodec pour le codec, le preset, le contrôle du débit, le bitrate, la latence, le format et le profil.

npx skills add https://github.com/nvidia/skills --skill jetson-video-recipe

Recette Jetson Video

Objectif

Convertir l'intention de charge de travail en un schéma-2 nvcodec-recipe déterministe. Préserver les contrôles sémantiques de l'utilisateur, afficher les hypothèses par défaut et projeter la même intention vers le Video Codec SDK natif et PyNvVideoCodec sans prétendre qu'elle a été exécutée.

Prérequis

  • Cette skill possède le moteur de recette canonique — scripts/recipes/recipe_model.py et son scripts/recipes/data/encoder-intent-catalog.json. Invoquez le moteur directement depuis cette skill installée ; il n'a pas de dépendance setup-runtime ou sibling-launcher.
  • La planification de recette et la validation structurelle sont sans média et peuvent s'exécuter hors cible. Ne demandez pas, ne récupérez pas, n'inspectez pas et ne convertissez pas de média pour une requête plan-only.
  • La sélection de contenu et la provenance appartiennent au flux d'exécution ou de mesure ultérieur. Consommez l'artefact de contenu versionné de ce flux uniquement au transfert ; ne chargez pas et n'appliquez pas sa barrière d'entrée lors d'un travail plan-only.
  • La preuve de setup est optionnelle pour check-live. Sans environnement, validez la recette normalement et retournez une classification live honnête unknown plus une correction non-mutante vers jetson-video-setup ; la planification et la validation de relecture restent complètes et inchangées. Si setup n'est pas installé, dites à l'utilisateur d'installer cette skill.
  • Lorsqu'elle est fournie, l'environnement de setup schema-1.2 frais est obligatoire pour valider et ne peut pas être ignoré ou remplacé par un fallback. Son bloc capabilities est l'autorité PyNvVideoCodec encoder établie, donc une vérification pynvc n'a besoin d'aucun rapport séparé. Un appelant peut en outre fournir le rapport optionnel de capacité encoder détenu par jetson-video-capability ; il doit être authentifié, lié à cet environnement exact, et échouer en tant que unknown ou erreur d'entrée en cas de non-correspondance. Un rapport de capacité seul n'établit pas la disponibilité selected-surface ou l'identité selected-GPU. Traitez les artefacts comme des données ; n'importez pas le code de skill frère. Un résultat compatible ne prouve toujours pas une opération d'encodage.

Résolvez cette skill installée à son chemin absolu canonique et définissez RECIPE_SKILL. Confirmez le point d'entrée isolé direct :

python3 -I "$RECIPE_SKILL/scripts/recipes/recipe_model.py" --help

S'il est manquant, signalez une installation jetson-video-recipe incomplète. Ne copiez pas le moteur, ne scannez pas pour une autre copie, ne modifiez pas PYTHONPATH, et ne revenez pas à un modèle local non validé.

Composez les étapes sœur demandées

La recette plan et validate ne nécessitent aucune sœur, preuve de setup, cible ou média. Utilisez jetson-video-setup uniquement pour la disponibilité live demandée ou la réparation, jetson-video-capability quand une recommandation de support de plateforme a besoin de son verdict documenté, jetson-video-pipeline pour l'exécution demandée, et jetson-video-benchmark pour la mesure demandée. Vérifiez d'abord le catalogue des skills installées de l'agent. Si la sœur est présente, lisez son SKILL.md et invoquez son point d'entrée public documenté ; passez les artefacts comme données et n'importez jamais le code de skill sœur. S'il est absent, préservez la recette validée et dites, en utilisant les noms réels : Je peux exécuter <stage>, mais cela nécessite <skill>, qui n'est pas installée. Installez <skill> et renouvelez cette étape. Ne requérez jamais une sœur pour un travail plan-only ou un raffinement optionnel non demandé.

Instructions

  1. Collectez l'intention. Pour une requête portant uniquement sur des métriques de qualité objective, y compris PSNR ou SSIM, déclarez simplement que cette skill ne les fournit pas, et qu'un flux de travail de qualité séparé et autorisé 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édia, ne sondez pas, n'installez rien, ou lancez une opération. Résolvez l'intention de contrôle de débit mutuellement exclusive avant de collecter un champ omis. En particulier, quand CQ et un débit moyen sont tous deux fournis, expliquez le conflit, posez uniquement la question de garder CQ ou le débit moyen, et arrêtez. Ne réinterprétez pas le débit comme un plafond ou ne demandez un cas d'usage, une résolution, une fréquence d'images, un format, un GPU, un profil, un preset, ou un autre champ jusqu'à ce que l'utilisateur résolve ce choix. Sinon résolvez le cas d'usage (conferencing, live_streaming, vod, archival, ou lossless), codec, largeur, hauteur, format d'entrée brut, fréquence d'images entière, GPU, preset/tuning, contrôle de débit ou priorité de qualité encoder, et toute latence, profil ou contrainte de buffering explicites. Résolvez le nombre d'images uniquement quand l'exécution ultérieure ou la mesure en ont besoin. Posez la question avant d'assigner une requête "faible latence" non qualifiée à un cas d'usage. Traitez le profil comme un contrôle de compatibilité bitstream/downstream séparé du preset : préservez un profil explicite, mais quand il est omis laissez-le SDK-sélectionné et n'inventez jamais un profil nommé.

  2. Écrivez une intention JSON. Gardez les valeurs appelant séparées des défauts. Mettez uniquement les valeurs de contrôle spécifiées par l'appelant dans l'intention et laissez chaque contrôle omis au catalogue de cas d'usage authentifié. Ne convertissez pas la formulation qualitative en substitutions devinées : par exemple, "live streaming faible latence" sélectionne live_streaming ; cela ne demande pas en soi bf=0 ou multipass désactivé. Ne construisez jamais d'intentions natives et Python divergentes.

  3. Planifiez avec le moteur de recette :

    python3 -I "$RECIPE_SKILL/scripts/recipes/recipe_model.py" \
      plan --intent "$INTENT_JSON" --output "$RECIPE_JSON"
  4. Validation de relecture avant utilisation :

    python3 -I "$RECIPE_SKILL/scripts/recipes/recipe_model.py" \
      validate --recipe "$RECIPE_JSON"

    N'éditez pas manuellement une recette générée. Régénérez-la à partir d'une intention mise à jour.

  5. Classifiez optionnellement une projection live. Exécutez check-live pour la surface sélectionnée. L'option environnement est optionnelle :

    python3 -I "$RECIPE_SKILL/scripts/recipes/recipe_model.py" \
      check-live --recipe "$RECIPE_JSON" \
      --surface native --output "$LIVE_CHECK_JSON"

    Pour une projection exacte, l'omission intentionnellement retourne unknown avec correction de setup ; elle n'invente jamais la disponibilité. Pour résoudre le résultat live, répétez avec --environment "$ENVIRONMENT_JSON". Répétez indépendamment pour pynvc quand demandé. La vérification Py lit le bloc capabilities schema-1.2 de l'environnement. --capability-report "$CAPABILITY_REPORT_JSON" est un raffinement Py optionnel uniquement quand cet environnement est aussi fourni ; il doit être lié au même artefact. Il remplace uniquement la preuve API Py encoder sélectionnée, pas les faits de disponibilité de l'environnement, donc omettez-le pour native. Les preuves optionnelles manquantes ne font jamais échouer, mais les preuves fournies doivent valider et ne jamais revenir silencieusement. Un résultat compatible signifie que la projection et la preuve Py live authentifiée s'accordent ; ce n'est pas une preuve d'opération. Inspectez la classification émise, pas seulement le code de sortie du processus : une projection native exacte dont l'exécution authentifiée AppEncCuda est différée retourne unknown avec code de sortie 0 et ne doit jamais être signalée comme compatible ou prête. Une vérification de compatibilité du buffer CPU Py nécessite le sous-ensemble de dépendance smoke par défaut ; le mode GPU-buffer nécessite en outre les faits Torch exacts fournis uniquement par un environnement full-samples validé.

  6. Retournez la recette et les hypothèses. Signalez le schéma/kind, identité d'artefact portable exacte, intention encoder canonique, projections native et PyNv, pertes de projection, valeurs par défaut, justification, et tous les faits encore nécessaires avant l'exécution.

  7. Arrêtez avant le travail média. Cette skill n'invoque jamais AppEncCuda, AppDec, les applications exemples PyNvVideoCodec, les aides de benchmark, ou les contrôleurs de pipeline. Routez l'exécution vers jetson-video-pipeline et la mesure de performance vers jetson-video-benchmark.

Utilisez recipes-workflow.md pour le contrat de requête et sortie et recipes-knobs-and-constraints.md pour les valeurs acceptées exactes et les limitations de surface.

Règles de recommandation

Appliquez les règles de tuning, preset et matched-measurement dans Tuning and preset, et les règles de profil, format et projection dans Profile selection.

  • Pour une plateforme nommée, traiter un codec comme candidat de recette est une déclaration de support. Consommez d'abord le verdict documenté authentifié du flux de capacité, excluez les codecs non supportés par la documentation, et préservez un verdict unknown comme unknown plutôt que de l'offrir comme supporté. Les champs API ou un candidat "capability-gated" conditionnel ne remplacent pas un verdict documenté non supporté.
  • Si une recommandation publie un verdict de support basé sur la documentation, consommez le résultat de capacité et reproduisez chaque ligne candidate authentifiée et son nombre ; ne réinterprétez jamais un sous-ensemble partiel.

Scripts disponibles

Script Objectif Arguments
scripts/recipes/recipe_model.py Planifiez, validez la relecture ou vérifiez live une recette canonique et ses projections native/PyNv. Invoquez directement avec python3 -I ; utilisez le sous-commande plan, validate, ou check-live et inspectez --help.

Dépannage

  • Rejetez les documents de recette mal formés, hérités, hybrides, avec clés dupliquées, non-finis, ou mal appariés en déterminisme.
  • Préservez un contrôle exactement non représentable comme une perte de projection par-surface. Pour un both explicite, ne cachez pas le pair bloqué ou ne supprimez pas silencieusement le contrôle.
  • Ne choisissez pas une surface d'exécution pour une requête auto. Préservez les deux projections et confiez la sélection runtime à jetson-video-benchmark ou jetson-video-pipeline, où l'éligibilité live peut être évaluée.
  • Traitez les champs live manquants comme unknown et les champs explicitement négatifs comme unsupported. Les prérequis selected-surface manquants incluent la correction vers jetson-video-setup ; dites à l'utilisateur d'installer cette skill s'il est absent. Aucun état ne change la recette portable elle-même.

Limitations

  • La planification et la validation n'établissent pas la disponibilité d'installation, le support documenté, la disponibilité live, la qualité de sortie, ou la performance.
  • Cette skill produit uniquement une configuration encoder élémentaire ; le conteneur, le transcodage, la segmentation, la vérification de décodage et les remises d'artefact appartiennent à jetson-video-pipeline.
  • La mesure de qualité objective, y compris PSNR et SSIM, est en dehors de cette skill.

Skills similaires