Publish the clip as a screen share alongside the audio

VIDEO_ENABLED makes the bot publish a second LiveKit track with the
picture. Stoat only grants screen_share in the call token when the bot
has the Video permission and the instance has video enabled, so a refusal
is reported in chat and playback continues with sound alone.

Two constraints shaped the pipeline, both found by testing rather than
assumption:

- Only progressive formats can be streamed. Separate video+audio streams
  make yt-dlp download both in full before muxing a single byte, and
  direct CDN URLs handed to ffmpeg simply hang — YouTube no longer serves
  them to other clients. That caps video at the 360p single file YouTube
  offers, and the format is checked before committing to the video path,
  since audio would otherwise come from the same broken pipeline.
- One ffmpeg with two outputs, paced by -re: an unpaced decode races
  ahead of the sound and eats memory at 1.4 MB per frame.

The same CDN-URL finding removes the audio seek shortcut, which resolved
such a URL and would have hung the same way; seeking now decodes up to
the offset like it already did behind a proxy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

This commit is contained in:

Leonid Pershin

2026-09-09 01:10:11 +03:00

co-authored by

Claude Opus 5

parent 24dfcf9232

commit 49b87dc172

10 changed files with 387 additions and 23 deletions

									
										package.json
									
		+2
		
												View File
												
				@@ -20,7 +20,9 @@

				    "@fastify/cookie": "^11.0.2",

				    "@fastify/static": "^8.1.1",

				    "@fastify/websocket": "^11.0.2",

				    "@livekit/rtc-node": "^0.13.34",

				    "fastify": "^5.2.1",

				    "ffmpeg-static": "^5.3.0",

				    "jose": "^6.0.10",

				    "pino": "^9.6.0",

				    "pino-pretty": "^13.0.0",