Emby remuxing or transcoding unnecessarily

[Nuwanda 1]

Yesterday I was having buffering issues watching a large media file (~40 Mbps) using the Emby client on a Roku TV. No remuxing or transcoding should be necessary because both the video codec (HEVC) and the audio codec (AAC) are supported by the Roku TV. The media played just fine using the Roku Media Player served by Emby over DLNA. Both the PC running the Emby server and the Roku TV are wired to the router via Ethernet.

I did some tests today, and it seems that the Emby server is remuxing or transcoding the media even if it's not necessary. If I enable "Allow video playback that requires conversion without re-encoding", then files are written to the transcoding-temp folder during playback. However, if I disable that setting, then no files are written to the transcoding-temp folder. In both cases, the video and audio play just fine. Logs attached.

On a somewhat related note, it would be great to have the feature of using RAM for temporary remuxed or transcoded files instead of the hard drive. There would need to be a setting for the size of the window (either in seconds or MB), but even at e.g. 150 Mbps, a full minute window would need ~1 GB, which is perfectly fine on many recent PCs.

Thanks!!

Conversion enabled.zip Conversion disabled.zip

[ebr 16185]

Hi.  It is transcoding due to the bitrate of the media being higher than the setting in the app.  Try raising the video quality setting in the app.

FYI - both the server dashboard and the stats for nerds display in the app can tell you the reason something is being converted.

Thanks.

[Nuwanda 1]

The Video Quality in the app was set to "Auto". I expected it to not cause any transcoding due to resolution or bitrate.

I changed it to "2160p 110 Mbps" (the maximum arbitrary one), and now there's no transcoding. Thanks!

Still, I think it's not ideal because it's an arbitrary value. If I ever want to play a video over 110 Mbps, it will enable transcoding (and yes, it happens, the 4K 60 fps videos from my cell phone are 120 Mbps).

I'd like to request a new setting "As source" to avoid any transcoding due to resolution or bitrate whatsoever.

Also, I believe the names should be changed to "Up to 2160p 110 Mbps", etc., to avoid any confusion. I had selected "Auto" because I thought "2160p 110 Mbps" was going to make the server upscale lower resolutions or bitrates.

Thank you for your help!

[Nuwanda 1]

By the way, I don't know if this is related to the previous issue, but I can't play the file at all if I enable Audio transcoding and disable remuxing on the server, and leave Video Quality to "Auto". The client shows the spinning wheel forever. The client should abort and show an error message if it can't play the file with the current settings. Logs attached.

It works fine if Video Quality is set to "2160p 110 Mbps".

Audio transcoding enabled, conversion disabled.zip

[Nuwanda 1]

Quote

It is transcoding due to the bitrate of the media being higher than the setting in the app.  Try raising the video quality setting in the app.

I just realized... I had disabled both Video and Audio transcoding on the server. Are you saying that the app overrides those settings?

[Luke 42080]

No it doesn't, but I would suggest reenabling them for the reasons explained in the help text underneath the options.

[ebr 16185]

59 minutes ago, Nuwanda said:

Still, I think it's not ideal because it's an arbitrary value. If I ever want to play a video over 110 Mbps, it will enable transcoding (and yes, it happens, the 4K 60 fps videos from my cell phone are 120 Mbps).

No Roku device claims to support bitrates that high which is why we don't have such a setting.  In fact, the highest bitrate they claim to support is 40 and that is only in HEVC.  I think you can probably get higher ones to play if all circumstances are correct but that is the official spec from Roku.

You have seen what can happen if we try to force the Roku to play something it doesn't support.  Sometimes it just hangs up and doesn't even give us an error.

[Nuwanda 1]

1 hour ago, Luke said:

No it doesn't, but I would suggest reenabling them for the reasons explained in the help text underneath the options.

That text says: "Restricting access to transcoding will disable quality selection and may cause playback failures in Emby apps due to unsupported media formats or insufficient network bandwidth." That makes perfect sense, but it doesn't seem to be what's actually happening.

My settings in the server were: audio encoding disabled, video encoding disabled, remuxing enabled (that's what "video playback that requires conversion without re-encoding" means, right?). Therefore, the video quality setting in the app should have no effect, since you can't change the resolution or bitrate without re-encoding, but it did have an effect, which is writing a huge amount of data (several GBs in just seconds) to the transcoding-temp folder, which may have been the cause of the buffer underruns.

[Nuwanda 1]

46 minutes ago, ebr said:

No Roku device claims to support bitrates that high which is why we don't have such a setting.  In fact, the highest bitrate they claim to support is 40 and that is only in HEVC.  I think you can probably get higher ones to play if all circumstances are correct but that is the official spec from Roku.

You have seen what can happen if we try to force the Roku to play something it doesn't support.  Sometimes it just hangs up and doesn't even give us an error.

The argument to not add settings over 110 Mbps because of the Roku spec is a good point (for now, though they might support it in future devices). However, in this specific case, the Roku device clearly supports the file (which is actually 39.1 Mbps for the whole file, video + audio), I can play it fine with the Roku Media Player over DLNA, but not with the Emby app with the video quality set to "Auto".

My CPU is not fast enough for on-the-fly video transcoding. In my case, the best option is to leave the video quality on 4K 110 Mbps (since there's no "as source"), and if I notice any lag, I'll transcode manually.

Thank you very much for your help!

[ebr 16185]

23 hours ago, Nuwanda said:

That makes perfect sense, but it doesn't seem to be what's actually happening.

But it is what was happening.  You were experiencing a playback failure due to an incompatibility of a particular format on the device.  The key point in that text is that if you disable these, it could very well cause playback failures.

23 hours ago, Nuwanda said:

I can play it fine with the Roku Media Player over DLNA, but not with the Emby app with the video quality set to "Auto".

The next release of the app will have the "Auto" setting using 41 as a limit on the local network.  Previous specs for Roku devices had a max of 30Mb but the newer ones now have 40.  Our app currently uses 35 for the Auto number when on the LAN.

[Nuwanda 1]

1 hour ago, ebr said:

But it is what was happening.

My next paragraph was the reason why I said it's not what was happening: Video transcoding was disabled on the server, but it still performed video transcoding when the video quality was set to "Auto" on the app. The video quality setting on the app should be greyed out (or at least, ignored) if video transcoding is disabled on the server.

Quote

You were experiencing a playback failure due to an incompatibility of a particular format on the device.  The key point in that text is that if you disable these, it could very well cause playback failures.

What incompatibility? As you said, Roku supports HEVC up to 40 Mbps, and I had said that the video codec is HEVC and that the bitrate of the file (video + audio) is 39.1 Mbps.

Changing the "Auto" setting to 41 Mbps makes perfect sense, thank you!

Edited November 21, 2021 by Nuwanda

[ebr 16185]

10 minutes ago, Nuwanda said:

Video transcoding was disabled on the server, but it still performed video transcoding when the video quality was set to "Auto" on the app.

Not in the example you posted.  With that option disabled, no transcoding occurred (there is no ffmpeg log) but playback failed.

[Nuwanda 1]

9 minutes ago, ebr said:

Not in the example you posted.  With that option disabled, no transcoding occurred (there is no ffmpeg log) but playback failed.

I was referring to my first post (Conversion enabled.zip).

[ebr 16185]

14 minutes ago, Nuwanda said:

I was referring to my first post (Conversion enabled.zip).

That did not transcode either.  You can see in that log that both video and audio were stream copied.

[Nuwanda 1]

12 minutes ago, ebr said:

That did not transcode either.  You can see in that log that both video and audio were stream copied.

What for? Why does the video quality setting in the app make it copy the streams?

[Luke 42080]

Essentially it doesn't direct play due to the quality setting, but then it can't transcode due to the user transcoding permissions you've applied.

This is just a rare corner case that needs to be looked at, e.g., when you've restricted transcoding, but still allowed repackaging into new containers. In this specific case, it would be better for the app to try and just direct play, however, this isn't always the case and that's why we can't just blindly make the change.

Thus, it is a tricky corner case that comes up every once in a while. You're better off restricting all three permissions if you really want to (making sure to read the warning text underneath), or, put them back on and use the app quality setting as we've been suggesting.

[Nuwanda 1]

Yes, I'll do that, thank you very much for your help!