Throttling Not Happening

[LAPS0082 16]

On 9/2/2026 at 11:10 PM, FranBeltran said:

Root cause found + working workaround for "Too many packets buffered for output stream 1:1" / "Conversion failed" (and the "throttling not happening" symptom)

After two years with this bug I spent a day reproducing it on my server (Emby 4.9.3 → 4.9.5, ffmpeg 5.1-emby_2023_06_25_p4, GTX 1080, Emby for Android/Android TV, Proxmox LXC). Here is what is actually happening and a server-side workaround that needs no changes to the media files and no Diagnostics-plugin tricks.

1. What ffmpeg is asked to do

For every embedded *text* subtitle track, Emby adds a WebVTT HLS output and copies the full video stream into it, so the segment muxer cuts the .vtt files every 3 s in sync with the video:

-map 0:6 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt ... -segment_format webvtt ... _s6_%d.vtt
-map 0:8 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt ... -segment_format webvtt ... _s8_%d.vtt

Stream mapping in the log:

Stream #0:6 -> #1:0 (subrip (srt) -> webvtt (native))
Stream #0:0 -> #1:1 (copy)

 

2. Why it dies

ffmpeg 5.1 cannot write the header of that output until the WebVTT encoder has received its first cue. Until then every copied video packet is queued in the muxing queue. With a sparse track (in my case "Castellano Forzados (SRT)": 4 cues in 2 h 01, the third at 4:53 and the fourth at 2:02:11) the header is never written, the queue reaches ~10k packets after ~60 s and ffmpeg exits:

09:24:50.323 Too many packets buffered for output stream 1:1.
09:24:50.399 Conversion failed!

Two side effects explain the other symptoms reported in these threads:
- `>> ThrottleBySegmentRequest: ... TranscodingPosition: 00:12:57` stays frozen for the whole session (Emby measures progress on the stalled subtitle output), so throttling never kicks in → ffmpeg races at full speed and fills the queue even faster.
- After ffmpeg dies, every request for a `.vtt` of the sparse track waits 6030 ms before Emby answers with an empty file; with 3 s segments the client plays at half speed and re-buffers every 6 s.

Everything that "helps" in these threads is consistent with this: `-max_muxing_queue_size 100000` just delays the overflow (and costs GBs of RAM because the queued packets are the 4K video), "Disable HLS Subtitles" removes the WebVTT outputs (but forces burn-in, which on a 59 GB remux takes >15 s to start and gets killed by the watchdog: exit code 137 in a loop), removing/stripping subtitle tracks makes the track dense or absent. Most Spanish/other-language remuxes carry a "forced" text track with a handful of cues, so this hits "every file".

Fix suggestion for the devs (@Luke @sa2000): don't copy the 4K video into the WebVTT outputs. A 16x16 @ 1 fps dummy video split off the filter graph gives the same segment cadence with 1 packet/s (hours of headroom before the header), or initialise the WebVTT encoder eagerly so the header is written at start. The first option is exactly what my workaround does and it fixes all three symptoms.

3. Workaround (Linux native install, root)

A small wrapper replaces `/opt/emby-server/bin/ffmpeg` (real binary kept as `ffmpeg.real`) and rewrites only the subtitle outputs:

[0:0]split=2[__m0][__d0];[__d0]fps=1,scale_cuda=w=16:h=16:format=nv12,hwdownload,format=nv12,scale=16:16,format=yuv420p,split=2[__dummy0][__dummy1];[__m0]<Emby's original graph>
-map 0:6 -map [__dummy0] -an -c:v:0 rawvideo -c:s:0 webvtt ...

Verified on my server: no `Too many packets`, throttling works (`ThrottleBuffer 130s`), forced cues at 0:54 and 4:53 render in Emby for Android, 100 segments without a single stall, CUDA and software paths, remux commands too (a GPU decode is added just for the dummy). Survives Emby updates via a systemd path/timer unit. Attached zip with README, wrapper, installer, systemd units and a curl-based HLS client simulator that prints a pass/fail summary from the ffmpeg log.

apt install -y busybox-static          # Emby >= 4.9.5 ships its own glibc; the wrapper needs a static shell
mkdir -p /root/emby-fix && cd /root/emby-fix   # unzip here
chmod +x *.sh && ./install-ffmpeg-wrapper.sh && ./install-autoupdate.sh

Uninstall: `mv /opt/emby-server/bin/ffmpeg.real /opt/emby-server/bin/ffmpeg` and disable the two systemd units.

Not covered: Docker images (would need the same wrapper inside the container), OpenCL/Vulkan filter graphs (passed through untouched). Use at your own risk; it is a shell script, read it before installing.

Happy to provide logs or test a beta build.

-- version --

Causa raíz encontrada + solución funcional para "Too many packets buffered for output stream 1:1" / "Conversion failed" (y el síntoma "throttling not happening")

Tras dos años con este fallo he dedicado un día a reproducirlo en mi servidor (Emby 4.9.3 → 4.9.5, ffmpeg 5.1-emby_2023_06_25_p4, GTX 1080, Emby for Android/Android TV, LXC en Proxmox). Esto es lo que ocurre realmente y una solución en el servidor que no requiere tocar los archivos ni trucos con el plugin Diagnostics.

1. Qué le pide Emby a ffmpeg

Por cada pista de subtítulos de *texto* embebida, Emby añade una salida WebVTT para HLS y copia dentro el stream de vídeo completo, para que el muxer de segmentos corte los .vtt cada 3 s en sincronía con el vídeo:

-map 0:6 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt ... -segment_format webvtt ... _s6_%d.vtt
-map 0:8 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt ... -segment_format webvtt ... _s8_%d.vtt

Mapeo en el log:

Stream #0:6 -> #1:0 (subrip (srt) -> webvtt (native))
Stream #0:0 -> #1:1 (copy)

 

2. Por qué muere

ffmpeg 5.1 no puede escribir la cabecera de esa salida hasta que el codificador WebVTT recibe su primer cue. Hasta entonces, cada paquete de vídeo copiado se acumula en la cola de muxing. Con una pista escasa (en mi caso "Castellano Forzados (SRT)": 4 cues en 2 h 01, el tercero a 4:53 y el cuarto a 2:02:11) la cabecera nunca se escribe, la cola llega a ~10.000 paquetes a los ~60 s y ffmpeg termina:

09:24:50.323 Too many packets buffered for output stream 1:1.
09:24:50.399 Conversion failed!

Dos efectos secundarios explican el resto de síntomas de estos hilos:
- `>> ThrottleBySegmentRequest: ... TranscodingPosition: 00:12:57` se queda congelado toda la sesión (Emby mide el progreso sobre la salida de subtítulos bloqueada), así que el throttling nunca entra → ffmpeg va a máxima velocidad y llena la cola aún antes.
- Cuando ffmpeg muere, cada petición de un `.vtt` de la pista escasa espera 6030 ms antes de que Emby responda con un fichero vacío; con segmentos de 3 s el cliente reproduce a mitad de velocidad y rebufferiza cada 6 s.

Todo lo que "ayuda" en estos hilos encaja: `-max_muxing_queue_size 100000` solo retrasa el desbordamiento (y cuesta GB de RAM porque lo encolado es vídeo 4K), "Disable HLS Subtitles" elimina las salidas WebVTT (pero fuerza el burn-in, que en un remux de 59 GB tarda >15 s en arrancar y el vigilante lo mata: código 137 en bucle), y quitar pistas de subtítulos las hace densas o inexistentes. La mayoría de remuxes en castellano (y otros idiomas) llevan una pista de texto "forzados" con un puñado de líneas, por eso afecta a "todos los archivos".

Propuesta de corrección para los desarrolladores (@Luke @sa2000): no copiar el vídeo 4K en las salidas WebVTT. Un vídeo de relleno de 16×16 a 1 fps sacado del grafo de filtros da la misma cadencia de segmentos con 1 paquete/s (horas de margen antes de la cabecera); o inicializar el codificador WebVTT de forma anticipada para que la cabecera se escriba al inicio. La primera opción es exactamente lo que hace mi solución y corrige los tres síntomas.

3. Solución (instalación nativa en Linux, root)

Un pequeño wrapper sustituye a `/opt/emby-server/bin/ffmpeg` (el binario real se conserva como `ffmpeg.real`) y reescribe solo las salidas de subtítulos:

[0:0]split=2[__m0][__d0];[__d0]fps=1,scale_cuda=w=16:h=16:format=nv12,hwdownload,format=nv12,scale=16:16,format=yuv420p,split=2[__dummy0][__dummy1];[__m0]<grafo original de Emby>
-map 0:6 -map [__dummy0] -an -c:v:0 rawvideo -c:s:0 webvtt ...

Verificado en mi servidor: sin `Too many packets`, throttling operativo (`ThrottleBuffer 130s`), los forzados de 0:54 y 4:53 se pintan en Emby for Android, 100 segmentos sin un solo corte, rutas CUDA y software, y también comandos de remux (se añade una decodificación en GPU solo para el relleno). Sobrevive a las actualizaciones de Emby mediante unidades systemd path/timer. Adjunto zip con README, wrapper, instalador, unidades systemd y un simulador de cliente HLS con curl que imprime un resumen pasa/falla a partir del log de ffmpeg.

apt install -y busybox-static          # Emby >= 4.9.5 incluye su propia glibc; el wrapper necesita un shell estático
mkdir -p /root/emby-fix && cd /root/emby-fix   # descomprimir aquí
chmod +x *.sh && ./install-ffmpeg-wrapper.sh && ./install-autoupdate.sh

Desinstalar: `mv /opt/emby-server/bin/ffmpeg.real /opt/emby-server/bin/ffmpeg` y desactivar las dos unidades systemd.

No cubierto: imágenes Docker (habría que meter el mismo wrapper dentro del contenedor) y grafos OpenCL/Vulkan (se dejan intactos). Úsalo bajo tu responsabilidad; es un script de shell, léelo antes de instalarlo.

Puedo aportar logs o probar una beta.

embyffmpegwrapper.zip 9.54 kB · 5 downloads

Dayum Emby Team.

Hire this man!

At least give him some credit or implement this fix please.

 

LAPS

[chrismallia 13]

Confirming this is still present on 4.11.0.13 beta (Docker emby/embyserver:beta, Intel QuickSync, Emby for Android TV 2.5.03g). I reproduced it today and can confirm @FranBeltran's analysis.

The file is 1080p H.264 at 18.8 Mbps. It has an embedded SRT forced track with 12 cues, the first about 19 minutes in. A remote viewer gets a full transcode because of the bitrate limit.

What happens: the forced output writes 0 segments, and ffmpeg exits with Too many packets buffered for output stream 1:1 405 to 414 s of film after the encoder's start point (about 9,700 to 9,900 frames). I got that range from start positions 0:00, 1:45, 2:36, 3:39 and 4:27, so it depends on the queue, not the position in the file.

Turning subtitles off doesn't stop the crash. The client still requests SubtitleStreamIndexes=2,3,4, so the forced track's output is still created, and the encoder dies the same way.

The stutter depends on the selected track. Same play on the Android TV app, with the encoder already dead:

Subtitles	.vtt request time	Video fetch
Forced	~6,030 ms	0.50x realtime, stutters
Regular English	12 ms or less	1.10x
Off	no requests	1.10x

Chrome also gets the 6 s .vtt waits, but keeps fetching video and doesn't stutter. It seems to be the Android TV app that holds video back for the subtitles.

The remux path doesn't have this problem, which may help the fix. On the same file, same version, with the forced track selected:

Transcode (fails): -map 0:2 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt
Remux (ran past 20 minutes with no error): -map 0:2 -vn -an -c:s:0 webvtt

Could the transcode path use the same -vn subtitle outputs? @sa2000, is there a tracking reference for this, or any update from the dev team? I can provide logs or test a beta build.

[sa2000 881]

6 minutes ago, chrismallia said:

Could the transcode path use the same -vn subtitle outputs? @sa2000, is there a tracking reference for this, or any update from the dev team? I can provide logs or test a beta build

Thank you for the feedback. All I can do is pass on the details to the development team. We do have a new transcoder coming soon - i do not know at this moment if it will resolve this issue