VSS Video Embedding (RT-Embed)

Utilisez cette skill pour le microservice d'embedding vidéo RT-Embed, y compris le chemin de déploiement standard Cosmos-Embed1 et les travaux de modèles d'embedding personnalisés/BYOM.

Phrases de déclenchement : vss-deploy-video-embedding, RT-Embed, rtvi-embed, video embedding service, Cosmos-Embed1, embed live stream, embed video file, generate video embeddings, text embedding for video search, RT-Embed BYOM, VideoPrism embed, custom embed model, MODEL_IMPLEMENTATION_PATH, MODEL_REPOSITORY_SCRIPT_PATH, bring your own embedding model.

N'utilisez pas cette skill pour RT-CV, RT-VLM, VSS Agent, ou les travaux de déploiement VSS généraux sauf si la demande déploie, exploite, intègre ou personnalise RT-Embed.

Service Snapshot

• Skill : vss-deploy-video-embedding.
• Nom legacy 3.1 : RT-Embed.
• Service Compose : rtvi-embed.
• Nom du conteneur : vss-rtvi-embed.
• Image : ghcr.io/nvidia-ai-blueprints/vss/vss-rt-embed (remplacer avec VSS_RT_EMBED_IMAGE).
• Tag par défaut : develop-latest (remplacer avec VSS_RT_EMBED_TAG ; utiliser develop-latest-sbsa pour un host SBSA/DGX Spark).
• Profil : rtvi-embed.
• Port du conteneur : 8000 (côté host ${RTVI_EMBED_PORT}).
• Modèle par défaut : cosmos-embed1-448p depuis nvidia/Cosmos-Embed1-448p.
• Variables du loader BYOM : MODEL_PATH, MODEL_IMPLEMENTATION_PATH, MODEL_REPOSITORY_SCRIPT_PATH.
• Endpoint de santé : GET /v1/ready.
• Délai de grâce du healthcheck au démarrage : 1200s (20 minutes) au premier boot.

Route First

Choisissez un chemin primaire avant d'agir. Chargez la référence liée et suivez-la ; ne dupliques pas les workflows complets depuis ce fichier top-level.

Règles de sélection :

• Si on vous demande quelle skill gère le déploiement RT-Embed Cosmos-Embed1 par défaut, répondez : utilisez vss-deploy-video-embedding ; c'est le chemin de déploiement par défaut, pas le chemin BYOM/modèle personnalisé.
• Pour un déploiement RT-Embed ou Cosmos-Embed1 normal, utilisez la référence de déploiement. Dans la réponse, dites explicitement que c'est le chemin de déploiement RT-Embed par défaut. Distinguez aussi explicitement BYOM/intégration de modèle personnalisé : BYOM est uniquement pour ajouter ou valider des backends d'embedding personnalisés non-défaut comme VideoPrism, et n'est pas nécessaire pour le modèle Cosmos-Embed1 par défaut.
• Pour BYOM, modèles d'embedding personnalisés, exemples VideoPrism, ou questions sur les chemins d'implémentation de modèle, utilisez d'abord la référence BYOM, puis les références de déploiement/API seulement si nécessaire.
• Pour les appels d'endpoint directs, utilisez la référence API et réutilisez le contexte de déploiement seulement quand le service n'est pas déjà en cours d'exécution.
• L'IPC de frame décodée requiert un producteur RTVI CV compatible sur le même host, un répertoire de socket partagé accessible aux UID/GID 1001, et une camera ID correspondante. Le consommateur utilise le contrat de socket fixe /run/rtvi-ipc/nvds_ipc_{camera_id}.sock. Les IDs de camera, capteur et flux IPC doivent être non-vides et contenir uniquement des lettres ASCII, des chiffres, ., _ et - ; les UUIDs standards sont valides. S'applique seulement au traitement RTSP en direct.
• Si la demande mélange déploiement et BYOM, chargez BYOM en premier pour établir les exigences du chemin de modèle, puis utilisez la référence de déploiement pour exécuter le service.

Operating Rules

• Ne déployez pas un profil VSS complet pour RT-Embed autonome. Travaillez depuis deploy/docker/services/rtvi/rtvi-embed sauf si l'utilisateur demande explicitement un déploiement de profil.
• Ne laissez jamais sudo demander interactivement. Préférez plain docker ; sinon utilisez sudo -n docker et arrêtez-vous avec la commande manuelle exacte si sudo sans mot de passe est indisponible.
• N'exposez pas les valeurs complètes de NGC_API_KEY, HF_TOKEN, bearer tokens, ou identifiants de dépôt de modèles dans les prompts, logs ou réponses finales.
• Ne réduisez pas start_period: 1200s du healthcheck pendant le premier boot. Le téléchargement du modèle Cosmos et la génération du dépôt de modèles Triton peuvent prendre jusqu'à 20 minutes.
• En mode autonome, désactivez les pairs manquants avec MESSAGE_BUS=, ERROR_BUS=, et ENABLE_REDIS_ERROR_MESSAGES=false sauf si le service Kafka ou Redis correspondant est démarré et accessible.
• Pour les modèles BYOM qui sont vidéo uniquement, exigez une décision explicite d'endpoint texte : soit un encodeur texte compatible dans le même espace d'embedding, soit une réponse 4xx claire pour /v1/generate_text_embeddings.

Quick Reference

• Détails de déploiement : image, GPU, stockage, démarrage, disponibilité, mise à niveau et démantèlement vivent dans references/deploy-vss-deploy-video-embedding.md.
• Détails API : upload de fichier, embeddings texte/vidéo, contrôle de flux en direct, modèles, santé, métadonnées et métriques vivent dans references/rest-api.md.
• Détails d'intégration : entrées/sorties, Redis/Kafka/OTel, auth, networking, et snippets Compose vivent dans references/integrate-vss-deploy-video-embedding.md.
• Matrice d'environnement : renommages host-to-container, volumes optionnels, et variables sensibles aux secrets vivent dans references/environment.md.
• Détails BYOM : contrat de modèle personnalisé, remplacements Docker/Helm, variables de chemin de modèle, et validation d'exemple VideoPrism vivent dans references/byom-custom-model.md.
• Détails de dépannage : démarrage courant, cache, permission, bus et défaillances API vivent dans references/troubleshooting.md.

References