Benchmark vidéo Jetson

Objectif

Mesurer le débit (FPS) et les mégapixels/seconde au stade codec sur le Jetson actuel. Utilisez cette compétence pour le débit d'encodage ou de décodage, les comparaisons P4/P5, les comparaisons native-versus-Python, et les tests d'augmentation de capacité worker. Quand le contenu n'est pas disponible, elle peut produire une estimation clairement étiquetée de la documentation du SDK pour une ligne de tableau 1080p exactement supportée et une horloge vidéo maximale cible. Pour une autre résolution demandée, elle peut appliquer l'heuristique de zone de pixels bornée définie dans la référence d'estimation. Ne présentez jamais l'une ou l'autre estimation comme une mesure cible.

Prérequis

• Pour une mesure en direct :
  • Exécutez sur le Jetson cible avec accès GPU direct. Une identité nvcodec-environment fraîche et validée depuis jetson-video-setup est optionnelle ; quand elle est fournie, elle fait autorité et toute identité invalide ou obsolète échoue sans secours local. L'agent peut obtenir cette identité depuis la sonde publique en lecture seule du setup ; elle n'a pas besoin d'être présente dans l'invite du client.
  • Sans cette identité, les routes natives inspectent uniquement le paquet APT nvidia-video-codec-sdk installé et ses sources d'exemples officiels possédées par le paquet. Les routes PyNvVideoCodec nécessitent un environnement setup authentifié ou l'exact pynvc_interpreter absolu du client ; ne scannez jamais pour un venv. Avant de demander ce chemin au client, invoquez la sonde publique du setup quand cette compétence est installée et inspectez son résultat typé. Ces vérifications en lecture seule n'installent, ne réparent, n'enregistrent et ne testent rien. Uniquement quand aucune autorité n'est utilisable, une demande explicite pynvc ou both retourne input_required ; auto local enregistre PyNvVideoCodec comme not_evaluated et peut continuer une branche native éligible.
  • Une route de performance décodage seule PyNvVideoCodec peut utiliser un environnement pynvc-smoke par défaut validé. Une route d'encodage Python ou de comparaison utilise des exemples officiels qui importent Torch et nécessite donc un venv full-samples provisionné séparément ; ne mettez jamais à niveau le venv smoke sur place.
  • Les routes d'encodage en direct, de comparaison et de capacité d'encodage nécessitent un jetson-video-recipe frère et une identité portable exacte pour l'une de ses recettes schema-2 validées. Si son validateur public est absent, préservez dependency_required et son action d'installation et nouvelle tentative. Les routes de décodage ne nécessitent pas la compétence de recette.
  • Quand le setup est installé, lisez sa politique de contenu vidéo partagée avant une mesure en direct. Elle ne s'applique pas au chemin d'estimation séparé documentation seule. Le setup n'est pas requis uniquement pour cette politique : sans lui, nécessitez un chemin ou URL exactement sélectionné par l'utilisateur, ne choisissez jamais de catalogue ou média synthétique, et préservez URL source, licence, attribution, chemin, taille et SHA-256.
  • Appliquez la porte d'entrée d'entrée de cette politique avant de construire une exécution test de benchmark en direct. Ne choisissez jamais de média pour l'utilisateur ni n'utilisez le fixture smoke du setup pour la performance.
• Une réponse documentation peut être produite hors-cible quand la plateforme exacte, la version SDK, les conditions de tableau et les faits d'horloge vidéo maximal configuré sont fournis avec provenance. Une estimation à l'échelle de l'horloge nécessite également une horloge vidéo maximal configuré positive. Elle ne nécessite pas de média, recette, authentification d'exemple ou lancement de codec. Sans cette horloge, rapportez uniquement la ligne de référence non mise à l'échelle comme target_clock_unavailable, pas une estimation mise à l'échelle à la plateforme.

Composez les étapes frères demandées

Les estimations documentation seule et le décodage sans recette en direct ne nécessitent pas une compétence frère. Les routes d'encodage en direct, de comparaison et de capacité d'encodage nécessitent jetson-video-recipe ; l'installation SDK, la réparation, un nouvel environnement Python full-samples ou un handoff en lecture seule quand l'autorité Python enregistrée est requise appartient à jetson-video-setup. Vérifiez le catalogue de compétences installées de l'agent avant l'une ou l'autre étape. Si le frère est présent, 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 frère. S'il est absent, préservez les entrées complétées et les preuves de mesure et dites, utilisant les noms réels : Je peux exécuter <stage>, mais cela nécessite <skill>, qui n'est pas installé. Installez <skill> et relancez cette étape. Ne nécessitez jamais le setup quand l'appelant a déjà fourni des preuves setup authentifiées ou un interpréteur exact qui réussit l'authentification locale, ou une recette pour une demande décodage seule ou documentation seule.

Instructions

1. Appliquez d'abord la limite de portée. Pour une demande uniquement de métriques de qualité objective, incluant PSNR ou SSIM, déclarez uniquement que cette compétence de performance ne les fournit pas et qu'un flux de travail de qualité autorisé séparé 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, n'installez ou ne lancez rien.

2. Classifiez une demande in-scope comme une mesure encode, decode, compare, ou camera_capacity en direct, ou comme une réponse documented_estimate. Résolvez la direction des données de caméra avant de sélectionner une ligne d'encodage ou de décodage. La qualité, le preset, le débit, le contrôle de débit, l'enregistrement ou la formulation de sortie codec demandée est un indice d'encodage ; commencez par NVENC et mentionnez le décodage uniquement comme le cas conditionnel où les caméras émettent déjà le codec compressé nommé. L'entrée IP/RTSP, l'entrée déjà encodée, l'ingestion, la lecture ou la formulation de décodage explicite est un indice de décodage. Le transcodage explicite ou le décodage-puis-encodage utilise des budgets NVDEC et NVENC séparés. Quand aucun indice de direction n'existe, présentez conditionnellement les interprétations d'encodage et de décodage et demandez laquelle s'applique ; ne choisissez jamais silencieusement l'une.

3. Quand le média est absent :

   • Pour une demande explicite de lancer ou benchmarker, ou pour FPS réel, mesuré, en direct, ou sur cette cible, appliquez la porte input_required de la politique partagée et arrêtez avant de sonder, récupérer, authentifier, créer un espace de travail, exécution test, ou lancer. Demandez uniquement l'identité média manquante à cette porte ; ne demandez pas aussi un interpréteur, environnement, recette ou autre champ de stade ultérieur.
   • Pour une question de planification, attendu, indicatif ou FPS réalisable à toute résolution demandée positive, suivez les estimations de performance documentées. Utilisez uniquement une ligne 1080p exactement documentée et une horloge vidéo maximal configurée comme base source. Pour une demande non-1080p, appliquez la formule d'inverse-zone-de-pixels de la référence et divulguez que c'est une heuristique supplémentaire non indiquée par le tableau SDK. Si l'horloge n'est pas disponible, retournez uniquement la ligne de référence 1080p non mise à l'échelle. N'invoquez pas le contrôleur de benchmark et ne réclamez pas une mesure.

4. Quand le média local est fourni, validez et hashé cette entrée exactement sélectionnée. Pour l'entrée URL, préservez l'URL exacte fournie par l'utilisateur et récupérez-la uniquement après les portes cible, autorisation et autorité runtime ; puis validez et hashé les octets récupérés. Préservez l'URL source (ou null pour le média local), licence et attribution. Utilisez le chemin de mesure en direct, pas une estimation documentation.

5. Préservez la surface demandée pour les mesures en direct. Traitez « n'importe lequel », « le meilleur disponible », « choisissez pour moi » et autre formulation de surface non spécifiée comme auto, jamais comme both. Réservez both pour une comparaison dual-surface explicite. Pour auto, zéro surfaces éligibles bloquent, une exécute, et deux retournent selection_required ; n'inspectez jamais les résultats antérieurs, n'inventez pas un SDK préféré, ou ne lancez pas un benchmark pour faire le choix utilisateur manquant. Avec deux surfaces éligibles, demandez exactement native, pynvc, ou both. Après la porte média, utilisez d'abord les preuves setup validées fournies ou un interpréteur exact. Si PyNvVideoCodec peut participer et que l'un ou l'autre ne sont pas fournis, invoquez le jetson-video-setup installé par sa sonde publique en lecture seule probe_nvcodec.py : utilisez --runtime pynvc pour Python explicite ou --runtime both pour both/auto, une --output fraîche, et jamais --setup-candidate. Inspectez l'artefact frais ; uniquement un artefact en direct dont la surface Py sélectionnée est installée et dont pynvc.identity.status est verified est une autorité utilisable. Snapshot cet artefact exact comme l'identité portable environment du contrôleur avec exactement schema_version, kind, path absolu canonique, size_bytes et sha256 minuscule. Si le setup est absent ou rapporte n'importe quel non-prêt, illisible, obsolète, binding ou échec de lancement, demandez l'interpréteur exact pour pynvc/both explicite ; pour auto local, rapportez Python comme not_evaluated et continuez uniquement une surface native éligible. Ne passez jamais une sonde bloquée comme autorité, ne scannez pour un venv ou ne cachez un pair non évalué.

6. Exécutez d'abord une dry_run, revisitez chaque argument planifié, puis exécutez execute dans un espace de travail privé frais. Invoquez directement le contrôleur de cette compétence :

   python3 -I {baseDir}/scripts/benchmark_controller.py \
     --request request.json --workspace fresh-workspace \
     --output result.json

7. Pour l'encodage native, authentifiez AppEncPerf, inspectez -h et -A, et utilisez uniquement les options annoncées. Ne passez jamais -loop. Le décodage native utilise AppDecPerf authentifié ; PyNvVideoCodec utilise les exemples de performance appartenant au wheel sous l'interpréteur evidencé par le setup ou l'exact pynvc_interpreter absolu sélectionné par l'appelant.

8. Retenez un échauffement de processus complet et au moins trois processus mesurés séparés par variante et surface. Chaque phase de commande mesurée est measure.

9. Pour une mesure en direct, listez le FPS et MP/s de chaque répétition, puis la moyenne, minimum et maximum des deux métriques. Le décodage PyNvVideoCodec omet MP/s car son exemple de performance authentifié ne rapporte pas les dimensions ; rapportez cette raison au lieu de dériver MP/s à partir des métadonnées de l'appelant. Pour une comparaison native/Python, divulguez les différences de projection exactes et si elles ont changé l'intention demandée. Pour une comparaison de preset en direct, rapportez uniquement les différences de débit mesurées ; ne déclarez ni n'impliquez un ordre de qualité, efficacité de compression ou stockage à partir des noms de preset ou débit. Déclarez que la qualité n'a pas été mesurée quand cette distinction a de l'importance. Pour une estimation documentée, rapportez la ligne source, provenance de l'horloge, résolution demandée, formule, hypothèses et chaque étiquette d'inférence requise par la référence d'estimation, plus measurement_performed: false ; n'inventez jamais de répétitions ou statistiques mesurées.

10. Étiquetez les résultats de concurrence mesurée comme des bornes de capacité de stade codec. Pour une question de planification sans média, une estimation mise à l'échelle en résolution peut produire en outre une documented_theoretical_capacity_estimate quand le FPS par flux et une marge de sécurité explicite ou clairement définie par défaut sont disponibles. Maintenez les budgets d'encodage et de décodage séparés ; pour les charges de travail mixtes, additionnez la charge fractionnaire de chaque flux contre un budget partagé au lieu d'accorder à chaque résolution le budget complet. Appelez le résultat une limite théorique de flux codec, jamais un nombre de caméras vérifié : elle exclut la capture, ISP, transport, IA, affichage, contention mémoire et latence de bout en bout. Les scénarios 30-fps et 60-fps divulgués peuvent remplacer un débit non déclaré, mais ils ne remplacent pas la question : la réponse finale doit toujours demander explicitement chaque entrée omise qu'elle a supposée ou énumérée, nommant la direction codec (encoder les images capturées, décoder les flux déjà compressés, ou les deux), preset exact, FPS par flux, et mélange de flux ou décompte. Terminez en demandant le contenu exactement représentatif et un balayage worker strictement croissant mesuré pour vérifier la capacité. Utilisez une calculatrice en lecture seule pour chaque FPS documenté et calcul de décompte de flux, préservez la précision complète jusqu'à l'arrondi final ou d'affichage, et appliquez la vérification de décompte maximal bilatérale de la référence ; ne vous fiez jamais à l'arithmétique mentale pour une capacité rapportée.

Références

• Flux de travail benchmark définit les routes, la préparation et l'exécution.
• Contrat de sortie benchmark définit les états de résultat, répétitions, comptage des images et statistiques.
• Estimations de performance documentées définit le tableau SDK 13.0 sans média, l'horloge et la mise à l'échelle de zone de pixels, la budgétisation de flux théorique et le contrat de rapport.

Scripts disponibles

Inspectez directement le CLI public du contrôleur :

python3 -I {baseDir}/scripts/benchmark_controller.py --help

Limitations

• Les résultats s'appliquent uniquement à la cible et la charge de travail evidencées ; ce ne sont pas un plafond produit portable.
• Les valeurs dérivées de documentation et mises à l'échelle en résolution sont des estimations de planification par moteur indicatif, pas du FPS réalisé, de la capacité concurrence vérifiée, ou un substitut pour tester le contenu représentatif.
• N'interpolez pas de presets non documentés ni ne mettez à l'échelle entre formats, profondeurs de bits, chroma, codecs, modes de contrôle de débit ou tuning. Mettez à l'échelle uniquement la résolution par l'heuristique de zone de pixels explicitement étiquetée. Ne multipliez pas par un décompte moteur sauf si ce décompte cible exact est indépendamment authentifié, l'utilisateur demande explicitement une planification agrégée multi-session, et la réponse reste une limite théorique multi-session étiquetée séparément.
• La mesure de qualité objective, incluant PSNR et SSIM, est en dehors de cette compétence de performance.
• Le helper de performance d'encodage PyNvVideoCodec 2.1 publié plafonne chaque worker à 1 000 images. Suivez le contrat de sortie plutôt que de comparer silencieusement des décomptes de frames inégaux.
• Les codecs externes et le temps wall du wrapper ne peuvent pas substituer au débit rapporté par l'exemple officiel.

Dépannage

• Préservez input_required, selection_required, blocked, partial et failed au lieu de les promouvoir à l'achèvement.
• Rejetez les sorties obsolètes, la dérive d'identité d'entrée ou environnement, les métriques malformées ou non finies, les mauvais décomptes de frames traités, les options d'exemple non supportées et les marqueurs positifs manquants.
• Retenez une surface réussie quand son pair échoue, mais ne mettez jamais en commun ou ne substituez leurs résultats.