Higher bitrate video always transcoded

[SibrenVasse]

When attempting playback of a large mkv to my Chromecast 2 the media is always transcoded with reason 'ContainerBitrateExceedsLimit'. The file uses working codecs and my network can handle it, because if I disable transcoding altogether the video plays fine.

Server log snippet:

[INF] Bitrate exceeds DirectPlay limit: media bitrate: 12395162, max bitrate: 11000000
[INF] Bitrate exceeds DirectStream limit: media bitrate: 12395162, max bitrate: 11000000

It looks like this limit is hardcoded in app.js:2. I guess this might be suitable for a first generation Chromecast? The Chromecast 2 seems to be able to handle higher rates.

Possible solutions

• Maybe removing the limit entirely (I think that's what plex did)
• Different hard coded limits for the various models (1/2/ultra)
• Server side detection and configuration

[surdu]

I have the same issue.

@SibrenVasse could you please tell me how to disable transcoding as a temporary solution ?

[anthonylavado]

I always thought the limit was on the server side... hrm.

[SibrenVasse]

@surdu I've disallowed video transcoding for my jellyfin user. My entire library is x264, so I don't need this anyway. This way the audio is still transcoded if necessary.

[uchagani]

I'm also having this issue. @SibrenVasse does that setting u mentioned remove the video transcoding?

[SibrenVasse]

Yes it does.

[gabri94]

I think it would be just easier to be able to set the transcode profile from the app, like is done on plex. In this way we could choose manually the quality profile and override these stupids limits

[felschr]

This is happening to me on a Chromecast Ultra. Plex plays those files without transcoding.

[SteveDinn]

Just trying Jellyfin for the first time, and this bug really bit me. My Chromecast ultra is hard-wired and can handle the video I'm playing just fine without transcoding, yet Jellyfin insists on transcoding. Even when I disable the "Allow video playback that requires transcoding" option for my user, it still copies the video & audio streams into another container in the transcoding folder, despite being completely unnecessary.

[surdu]

@SteveDinn Sorry for the slight off-topic, but does Chromecast prioritizes transcoding depending on the power available from the power supply ? Or am I misunderstanding your statement?

[ferferga]

@SteveDinn What's the container of your files?

To everybody: Have you tried the nightly Chromecast version? What happens there?

[SteveDinn]

@SteveDinn Sorry for the slight off-topic, but does Chromecast prioritizes transcoding depending on the power available from the power supply ? Or am I misunderstanding your statement?

I mean, it's connected via Ethernet, not wi-fi. I can play the same files without transcoding and without re-containerizing the video and audio streams through different media servers or directly.

[SteveDinn]

@SteveDinn What's the container of your files?

Mostly MKV, sometimes MP4, video is nearly always h264, audio is AAC 2.0 or AC3 5.1.
I've previously played all of these containers and video/audio combinations natively with the default Chromecast app via pyChromecast through HomeAssistant.

To everybody: Have you tried the nightly Chromecast version? What happens there?

How do I change the android app to use the nightly Chromecast version? I haven't seen this as an option.

[SteveDinn]

How do I change the android app to use the nightly Chromecast version? I haven't seen this as an option.

Never mind, I found it :) It's on the "User Settings / Playback" screen.

[heyhippari]

How do I change the android app to use the nightly Chromecast version? I haven't seen this as an option.

Make sure you have the latest version, then go to User > Playback > Chromecast Version and set it to Unstable. Save the changes, then Force Close the app in the Android settings and restart it (This is currently needed, we hope to fix it at some point, but it's not a change you'll make often anyway).

The "Ready to cast" screen should be very slightly different if you've successfully changed the version.

[SteveDinn]

Well, that setting does not seem to take very firmly. I could only get the version that said "Beta" up once after trying about a dozen times (force-killing the app on the chromecast and my phone each time), and unfortunately, things that previously played with "Direct playing" with the stable app are now "direct streaming" on the beta app, but I did notice that pyChromecast detected that it was playing.

Do you guys have a beta program for the android app? I'd love to get in on that.

[SteveDinn]

I can definitely see a difference in the "GetPostedPlaybackInfo profile" lines in the log.

The old app shows this in the log when I play a file. This clearly matches my file (mkv, h264, ac3).

DirectPlayProfile {
        Container: "mp4,m4v",
        AudioCodec: "ac3,eac3,aac,mp3,opus,flac,vorbis",
        VideoCodec: "h264,vp8",
        Type: Video
},
DirectPlayProfile {
        Container: "mkv",
        AudioCodec: "ac3,eac3,aac,mp3,opus,flac,vorbis",
        VideoCodec: "h264,vp8",
        Type: Video
}

The newer app doesn't seem to produce any entries for MKV at all, and even the MP4 profile isn't very flexible when it comes to audio codecs.

DirectPlayProfile {
        Container: "mp4,m4v",
        AudioCodec: "aac,mp3",
        VideoCodec: "h264",
        Type: Video
}

It wants to transcode my high-bitrate stuff because of this (but it can't play it because I have video transcoding turned off):

MediaBrowser.Api.Playback.MediaInfoService: RemoteClientBitrateLimit: 1000000000, RemoteIp: "10.1.1.51", IsInLocalNetwork: True
MediaBrowser.Api.Playback.MediaInfoService: Bitrate exceeds DirectPlay limit: media bitrate: 11289791, max bitrate: 1000000

10.1.1.51 is my chromecast.

[YouKnowBlom]

mkv support was previously mistaken as supported since all cast devices support webm which is a subset of mkv. As we can't guarantee that all mkvs will play (as some have features not supported in webm) we've disabled it. The low bitrate limits are pretty dumb at the moment however

We may add a toggle to enable experimental mkv support in the future but more discussion is needed.

[SteveDinn]

Is there at least a way to avoid the audio transcoding? I realize that my Chromecast isn't actually decoding it, but my receiver can still take advantage of it.

And +1 for experimental mkv support 👍

I think there should be a "Throw it at the chromecast and see if it works" mode.

[YouKnowBlom]

Audio support should be improved a lot in the future! Several formats are supported via passthrough, we just have to figure out a good way to go about adding "dynamic" support. I'm surprised the old cast app were able to play AC-3 and EAC-3.

[normanu]

Finally found the issue in this topic.
Can I remove the bit rate limit in some file?
As my user plays on many different devices, so I don't want to disable transcoding.

[kevincox]

I tried the nightly chromecast and it "worked" as in the max bitrates were raised, however it now fails to play any media, even stuff that used to play with no transcoding. So I suspect there is an unrelated breakage on nightly.

GetPostedPlaybackInfo profile: {... "MaxStreamingBitrate": 120000000, "MaxStaticBitrate": 100000000, "MusicStreamingTranscodingBitrate": 192000, "MaxStaticMusicBitrate": null, ...}

[OrbitingOcelot]

I have the some problem, would it perhaps be possible to implement a toggle like "limit chromecast bitrate" or something like that? My TV has built-in chromecast and achieves around 200 Mbit thruput via my AC wifi.

[Diak]

I have the same problem, i think, with NVidia Shield TV. Jellyfin is dockerized.
It seems to be an old problem, maybe it would be time to fix it...

[Artiume]

We get it. We hate that there's old problems that last years. But we're also volunteer driven. Please be aware of how you say something because it can do more harm than good.

[Diak]

I don't deny it and i'm aware of the good evolution of Jellyfin for 1 year i use it and switched from Plex.
I'm just surprised that such a problem limiting the capacity of Jellyfin (everybody can't have a powerfull computer to stream) is still open after more than one year. But i'm sure you have other priotities too.
Whatever, my intention wasn't to do any harm so i'm sorry if you felt like this :)

[OrbitingOcelot]

Well, I have ditched the old Chromecast, and now have a similar problem. Whether I try the native Android or the Android TV client, Jellyfin always tries to transcode video, and I cannot figure out why. If I disab.e transcoding on the server for the user account, the video plays fine via direct play. Why is Jellyfin trying so hard to transcode everything, even if it is not necessary? Maybe this could be tuned down to a less aggressive transcode behaviour.
Also, for sure appreciate all the effort and love that went into this - I'm sure given some time this will be the best media solution out there! :)

[neopc10]

#91

[Exist2Resist]

2 years later and this is still an issue and not only on chromecast either, Nvidia Shield TV has the same problem.
Any update on this, maybe a hardware profile setting might be handy?

[StyraxBenzoin]

Just chimining in to say I'm having the same issue too on Fire TV 3rd gen Jellyfin app. Video being transcoded with reason 'ContainerBitrateExceedsLimit'. File is Video: HEVC 4K 10bit HDR 11147kbps, Audio: AAC 7.1 903kbps. If I disable transcoding the video plays directly.

Edit: Oops didn't realise this was the Chromecast specific thread. I'll leave it here anyway in case it's useful to know.

[maxi1134]

Any updates 6 months later?

[hawken93]

Hi, just chiming in about this.

I've happened to have lost interest in the chromecast app after I was stuck against a wall and the chromecast didn't seem to work for me (and therefore for this project..).

The problem when I was coding on this, was that chromecast would be able to play back at fairly high bitrate (we do a bitrate test at connection time to see how good the connection to the server is). However, that was only on direct play with mkv. The HLS streams suffered in a different way. The chromecast seemed to run out of resources after a certain lower bitrate, which would have to be found by experimentation.

What this shows, is that the hardware decoder is fully capable on the chromecast generations, however there was some software bug that caused segmented streams to bottleneck on cpu instead.

The chromecast API really wants segmented streams, and therefore on direct mkv playback there were other issues: A big one is that any seeking worked by the chromecast decoding the whole file, which is not feasible. Therefore workarounds were made in the code to have the server remux to mkv from a seek point, and having the chromecast play from the start of the file, but then there's a mismatch in the chromecast players reference timestamp and the real timestamp. But we want the chromecast api to handle the playlist, so there's no way to work around this to my knowledge, except to continue keeping the playlist outside of the chomecast API and inside of local variables.

So the conclusion was that we depend on google to sort out HLS so that it does not cpu bottleneck (and also so that ac3 streams can work).

It's weird because I believe other chromecast apps are perfectly capable of doing this, but nobody are sharing their secret sauces.

[SteveDinn]

@hawken93 Please tell me you haven't given up! I know what it's like to get burnt out working on a coding problem, but I have been waiting as patiently as possible for that giant PR you have (as well as the one for MKV passthrough) to get merged :) I have such high hopes that this Chromecast client can be great!

I'm a C# developer, so I feel kind of useless when it comes to this project, but let me know if there's anything I can do to help.

[TheDrifter363]

Just wanted to report, I'm having the same issue on the web browser jellyfin site. The video was an 8 bit h264, with aac audio, in a .mp4 container. Should be straight direct streaming, on my local network. Got transcoding instead, with containerbitratelimitexceeded.

Edit: Didn't realize this was for the chromecast repository. Disregard. I'll have to post on the web client repository.

[1337haXXor]

So there's no way to just manually bypass this limit? Or a way to force a significantly higher limit? I got a Chromecast Ultra hoping it would fix my transcoding problems, but the ultra only operates at a bitrate barely higher than a regular, WiFi one.

Alternatively, what would be the best device to watch on? Streaming to the house on a local network. I'd been waiting for a good price on a Shield, though I know it's a bit of overkill, but I've been reading here and other places that those have the same issue as well.

[Sapd]

So there's no way to just manually bypass this limit? Or a way to force a significantly higher limit? I got a Chromecast Ultra hoping it would fix my transcoding problems, but the ultra only operates at a bitrate barely higher than a regular, WiFi one.

There is. I was so annoyed by maxbitrate issues (triggering transcoding), that Ive written a workaround when you use a nginx reverse proxy before jellyfin:

location ~* ^/Items/(.*)/PlaybackInfo {
        if ($args ~ (^|.*)&MaxStreamingBitrate=\d*(.*)) {
            set $args $1&MaxStreamingBitrate=900000000$3;
        }

        # The following options are the same as in the jellyfin wiki for nginx
        proxy_pass http://$jellyfin:8096;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;

        # Disable buffering when the nginx proxy gets very resource heavy upon streaming
        proxy_buffering off;

        # Debug
        add_header X-OVERWRITTENPB 1;
        add_header X-ARGS $args;
        #return 200 $args;
    }

It sets the limit always to around 100 megabyte/s this way (dont set it higher... as jellyfin wont accept higher values).

[1337haXXor]

Um, I'm just using a local server at my house, so no reverse proxy needed. Is there a way I could use that fix for myself? This is why it's so frustrating. I see that there are limitations for remote streaming, which is understandable, but why is it limiting me on my own home network, especially if it's all wired and not wireless anyway?

[kevincox]

This was biting me especially hard for HDR content. This caused an unfortunate series of events.

1. False bitrate limit forced transcoding.
2. Transcoding picked h264. (Not sure why).
3. h264 doesn't support HDR so tone mapping was forced.
4. Resulting video was super washed out. (It also seems that this forced tonemapping doesn't respect the configuration options for some reason.)

Forcing the bitrate limit higher worked around all of these issues as transcoding wasn't required and the chromecast played the original perfectly.

There was one small tweak to the code above. It used $3 but I think it should be $2. The result was this:

if ($args ~ (.*)&MaxStreamingBitrate=\d*(.*)) {
	set $args $1&MaxStreamingBitrate=900000000$2;
}

It would be great if this could be resolved. It provides a pretty bad experience.

[jniewt]

I also ran into this problem with chromecast ultra. Thank you for the workaround, it works! But I don't get why it is so difficult to fix if the workaround is quite simple. It would've been a show stopper for me otherwise, since my media server can't handle transcoding 4k.

[kevincox]

IIUC the problem is that this workaround would break the first-gen chromecast. But I don't know why it is hard to differentiate the different models.

[hawken93]

Hi,
Not to make any promises because I don't currently have the time.

I heard that this pull: #616 might have solved the HLS playback issues.
If this is the case, one can potentially get rid of the direct streaming on chromecast and focus on solving this through HLS.

The fix shouldn't be that far away.