Live TV from ErsatzTV M3U source always transcodes — ContainerBitrateExceedsLimit despite low source bitrate

[me@jackbenda.com 4]

Hi all,

I'm running Emby Server 4.9.3.0 natively on Ubuntu Server 24.04 (Intel i5-12500, UHD 770, QuickSync/VAAPI enabled). I have ErsatzTV feeding Live TV channels into Emby via M3U (http://192.168.8.10:8409/iptv/channels.m3u) and XMLTV. ErsatzTV outputs HLS streams at 1200 kbit/s H.264 AAC 720p.

The problem: Emby always transcodes the Live TV stream rather than direct streaming it, and the transcode runs at barely above 1x real-time speed, causing buffering and stuttering on all clients.

What the transcode log shows:

The media source is flagged as:

"SupportsDirectStream": false
"SupportsDirectPlay": false

The transcode reason is ContainerBitrateExceedsLimit, DirectPlayError. The HLS manifest from ErsatzTV reports variant_bitrate: 0, so Emby probes the stream and estimates ~4 Mbit/s. It then decides this exceeds the client's limit and transcodes — even when the client quality setting is set to 4 Mbit/s, resulting in a pointless transcode of a 1200 kbit/s source.

The ffmpeg transcode command Emby generates:

• Input: ErsatzTV HLS at http://192.168.8.10:8409/iptv/session/1/hls.m3u8
• Decoder: h264_qsv
• Encoder: h264_qsv at 10 Mbit/s (or 3.8 Mbit/s at lower quality settings)
• Speed: starts at ~19x, degrades to ~1.02–1.05x real-time during sustained playback

At 1.02x speed there's almost no headroom, so any brief slowdown causes the client to buffer.

What I've already ruled out:

• Local disk I/O is not the bottleneck (NVMe at <2% utilisation)
• NAS SMB read speed is ~45 MB/s, far above what's needed
• GPU is not throttling (running at ~1417 MHz)
• ErsatzTV's own ffmpeg pipeline is healthy and producing segments on time

I guess the key question is: Is there any way to force Emby to direct stream (copy) an HLS Live TV source from an M3U tuner, rather than transcoding? The source is already H.264 AAC in an MPEG-TS container, which should be universally compatible. Is the SupportsDirectStream: false flag hardcoded for M3U Live TV sources, or is there a way to influence it via a device profile or server setting?

Any help appreciated. A couple of logs attached for your reference.

ffmpeg-transcode-3aa1a334-fdde-419f-a931-cb9380d36de0_1.txt ffmpeg-transcode-2c59b904-f3b8-417a-91db-6111478bb332_1 (1).txt

[Neminem 1607]

Check your client bit rate settings.

ContainerBitrateExceedsLimit = bitrate set to low or set to auto.

[me@jackbenda.com 4]

Cheers for the response. I did look at the client bitrate settings. At the moment it’s set to Auto, but the issue is that Emby is overestimating the bitrate of the stream coming from ErsatzTV.
Because the HLS/TS source doesn’t advertise a proper bitrate, Emby probes it and assumes it’s around 4 Mbps, even though the actual output is only 1.2 Mbps. That’s what triggers the  flag.

If I manually set the client to something like 720p 2 Mbps, Emby will treat everything as capped at 2 Mbps and transcode all content down to that (not just Live TV) which isn’t ideal.
So the problem isn’t really the client setting, it’s that Emby thinks the source bitrate is higher than it actually is. I’m trying to get Emby to direct‑stream the original 1.2 Mbps feed rather than transcoding it unnecessarily.

[Q-Droid 1002]

For starters live-tv, being live, is always 1x. It can't transcode into the future. 

Increase the client bitrate limit. Auto is effectively broken on most if not all platforms. 

 

[me@jackbenda.com 4]

Thanks, I get what you mean about Live TV being stuck at 1× and Auto being unreliable. Does that explain why Emby is overestimating the bitrate of the stream coming from ErsatzTV. Because the source doesn’t advertise a proper bitrate, Emby probes it and assumes it’s around 4 Mbps, even though the actual output is only 1.2 Mbps.

So Auto ends up enforcing a limit that the stream never actually exceeds, it’s just Emby’s estimate that’s too high. If I switch off Auto and pick a fixed bitrate, that becomes a global cap and forces transcoding for everything else I watch, which I’m trying to avoid.

So I’m not sure the client setting alone solves it... the underlying issue is that Emby is misreading the source bitrate and refusing to direct‑stream a feed that should already be compatible. 

Does that make sense?

[me@jackbenda.com 4]

Thanks for the suggestions... I’ve been digging into this a bit more and it looks like the issue isn’t really my client settings after all.

ErsatzTV is advertising a correct BANDWIDTH= value in the HLS manifest, but Emby is still detecting the stream as much higher bitrate than it actually is. For example, a 1.2 Mbps stream is being interpreted as ~4 Mbps, which then triggers ContainerBitrateExceedsLimit even though the real bitrate is well below any reasonable threshold.

This seems to match a known Jellyfin/Eamby issue (ErsatzTV issue #2022) where MPEG‑TS/HLS streams have their bitrates inflated during detection, causing unnecessary transcoding or preventing direct stream. ErsatzTV and Dispatcharr both report the correct bitrate, but Emby’s Live TV pipeline overestimates it. 

So while setting a higher client bitrate can mask the problem, the underlying issue is that Emby is misreading the source bitrate and refusing to direct‑stream a feed that should already be compatible. I guess I'll make a proper bug report... unless this already constitutes one? @Luke?

Edited 1 hour ago by me@jackbenda.com

[Q-Droid 1002]

Is there a reason why you can't set your bitrate cap to a value that covers direct play for all of your media?