Video-Ingestion

Fügst du einen Videolink in den Chat ein, ruft Tale das Transkript des Videos mit yt-dlp ab. Video-Plattformen — YouTube am aggressivsten — fordern Anfragen von Rechenzentrums- und Server-IPs mit einer „Bist du ein Mensch?"-Abfrage heraus, sodass eine frische, selbst gehostete Bereitstellung auf einer Cloud-VM beim Einlesen scheitern kann, wo ein Laptop an einem Heimanschluss durchkäme. Diese Seite behandelt die drei Ebenen, die Tale mitbringt, um daran vorbeizukommen — von der, die keine Konfiguration braucht, bis zu der, die am meisten verlangt.

Ebene 1 — der PO-Token-Provider (Standard, keine Konfiguration)

Die wirksamste Einzelmaßnahme ist ein Proof-of-Origin-(PO-)Token: ein signierter Wert, der eine Anfrage so aussehen lässt, als käme sie aus einer echten Browser-Session. Tale bringt einen fertig verdrahteten Token-Provider mit — das yt-dlp-Plugin ist ins Image eingebacken, und ein bgutil-provider-Sidecar liefert die Tokens über das interne Netz. Keine Umgebungsvariable ist nötig; ein frisches docker compose up oder tale deploy hat ihn am Laufen.

Du kannst yt-dlp mit VIDEO_INGEST_POT_PROVIDER_URL auf einen Provider auf einem anderen Host verweisen oder mit VIDEO_INGEST_PO_TOKEN ein manuell erstelltes Token übergeben — beides ist in der Umgebungsreferenz dokumentiert. Ein ausgefallenes Sidecar bricht den Stack nie: Das Einlesen fällt auf kein Token zurück, genau so, als gäbe es die Ebene nicht.

Ebene 2 — ein Egress-Proxy

Reicht das Token allein nicht — manche IP-Bereiche sind ohnehin markiert —, leite den Abruf über einen Egress-Proxy auf einer IP, der die Plattform vertraut. Residential- und ISP-gehostete Proxys funktionieren am besten; Rechenzentrums- und kommerzielle Proxys sind oft genauso markiert wie der Server selbst.

Setz VIDEO_INGEST_PROXY_URL auf die Proxy-URL. Ein socks5h://-Schema löst DNS am Proxy auf (die sicherste Wahl); http, https, socks4, socks4a, socks5 und socks5h werden alle akzeptiert. Der Wert darf Zugangsdaten enthalten — Tale entfernt sie aus jeder Log-Zeile.

VIDEO_INGEST_PROXY_URL=socks5h://user:pass@residential.example:1080

Der Proxy gilt für jede Phase eines Abrufs — Metadaten, Untertitel und Audio —, sodass das gesamte Einlesen einen vertrauenswürdigen Ausgangspfad teilt.

Ebene 3 — der vorgewärmte Browser-Session-Pool

Die stärkste Maßnahme präsentiert Cookies aus einer echten Browser-Session, die die Bot-Abfrage bereits bestanden hat. Tale hält einen Pool solcher Sessions, nach Domain geschlüsselt, und gibt jedem Abruf eine davon, sodass die Plattform einen wiederkehrenden Besucher statt eines erstmaligen Servers sieht.

Sessions werden verschlüsselt gespeichert (der Cookie-Jar wird mit dem ENCRYPTION_SECRET_HEX der Bereitstellung versiegelt) und werden nie an vom Agent ausgeführten Code weitergegeben — sie leben nur in der serverseitigen Abruf-Ebene. Eine Session, die blockiert zu werden beginnt, wird automatisch abgekühlt und dann stillgelegt, und abgelaufene Sessions werden planmäßig aufgeräumt.

Den Pool zu füllen ist ein fortgeschrittener, händischer Schritt: Erfasse einen Netscape-Cookie-Jar aus einem Browser, der die Abfrage für die Zielplattform gelöst hat, und importier ihn dann über die interne Action importBrowserSession. Derselbe Pool trägt auch das Web-Fetch-Tool und den Crawler des Agents, sodass eine für eine Domain vorgewärmte Session jedem serverseitigen Zugriff darauf zugutekommt.

Welche Ebene brauche ich?

Eine ehrliche Erwartung

Keine dieser Ebenen kann das Einlesen gegen eine Plattform garantieren, die aktiv daran arbeitet, automatisierten Zugriff von beliebigen IPs zu blockieren. Zusammen bringen sie das Einlesen überall dort zum Erfolg, wo dein Ausgang vertrauenswürdig ist, und jede Bereitstellung hat einen unterstützten Weg zu eskalieren. Blockiert eine Plattform deinen Server hart, lässt sich das Transkript trotzdem von Hand hereinholen — füg es in ein Wissen-Dokument ein.