Throttling Not Happening

[Q-Droid 881]

3 hours ago, visproduction said:

MP4 stream 1.3 mbps  --> HLS  720 kbps 380 fps
 

380 frames per second??

Corrupt metadata in the video?

Related: https://stackoverflow.com/questions/13565062/fps-too-high-when-saving-video-in-mp4-container

That's the transcoding rate, not the stream playback fps.

[Q-Droid 881]

On 3/25/2024 at 2:55 AM, Leinad86 said:

Can someone give me some information here?

A we have no idea where the error is is better than no answer.

 

Thanks

Have you considered changing the throttling method to one that's more reliable? Throttling ByStreamBufferSize isn't dependent on the client or media as long as the playback position is known.  This is unless the devs tell us that they plan to remove ByStreamBufferSize as a method.

 

[Leinad86 6]

How do i Change the throttling method? 

[Q-Droid 881]

I think the only way in 4.8.x and later is manually in the encoding.xml file. The buffer size is in seconds, the others you can leave as is. 

  <EnableThrottling>true</EnableThrottling>
  <ThrottleBufferSize>120</ThrottleBufferSize>
  <ThrottleHysteresis>5</ThrottleHysteresis>
  <ThrottlingMethod>ByStreamBufferSize</ThrottlingMethod>
 

[adminExitium 295]

Unfortunately, it's only via the API now. The encoding.xml file is no longer honored.

 

[Q-Droid 881]

4 minutes ago, adminExitium said:

Unfortunately, it's only via the API now. The encoding.xml file is no longer honored.

Crap. I remember that now. We've been trying to get the devs to move the settings from the plugin to the core app but they were "lost in transit" and now we're stuck with having to use an API.

On my server they were set before the upgrade and I assumed the server was still pulling from the xml file.

[Leinad86 6]

I changed the transcoding mod to ByStreamBufferSize.

Unfortunately, initially without success. Here is the log, you professionals may see other problems.

Thanks in advance

09:41:39.290 Too many packets buffered for output stream 1:1.
09:41:39.319 [libmp3lame @ 0x1156180] 3 frames left in the queue on closing
09:41:39.571 Conversion failed!
09:41:39.571 EXIT

emby 4.8.3.0_ByStreamBufferSize.txt

[Q-Droid 881]

Is this consistent for all of your videos when transcoding? What settings did you use?

 

[Leinad86 6]

no, not for all of them, just for some! Everything works on 4.7. Which settings exactly do you mean? Thanks for the help!

[Q-Droid 881]

The settings for throttling, you set ByStreamBufferSize but what are the others?

[Leinad86 6]

response_1711870541555.json

[Q-Droid 881]

I think it's time for the devs to dig in. The error is pretty consistent with different media and throttling options. And if you say this worked in 4.7 but not in 4.8 then even if the media itself has some problems it appears to have handled them better in 4.7.

21:46:27.801 Stream mapping:
21:46:27.801   Stream #0:0 (hevc) -> scale_cuda:default (graph 0)
21:46:27.801   setsar:default (graph 0) -> Stream #0:0 (h264_nvenc)
21:46:27.801   Stream #0:1 -> #0:1 (eac3 (native) -> ac3 (native))
21:46:27.801   Stream #0:3 -> #1:0 (subrip (srt) -> webvtt (native))
21:46:27.801   Stream #0:0 -> #1:1 (copy)                                                     <-- I don't understand the multiple mappings here
21:46:27.801   Stream #0:4 -> #2:0 (subrip (srt) -> webvtt (native))
21:46:27.801   Stream #0:0 -> #2:1 (copy)                                                       <-- and  here
21:46:27.801   Stream #0:5 -> #3:0 (subrip (srt) -> webvtt (native))
21:46:27.801   Stream #0:0 -> #3:1 (copy)                                                        <-- and  here

21:46:45.905 Too many packets buffered for output stream 1:1.
21:46:46.071 Conversion failed!
21:46:46.071 EXIT
 

 

 

[Happy2Play 9444]

@Q-Droidit is the downscaling.

21:46:27.801   Stream #0:0 -> #1:1 (copy)                                                     <-- I don't understand the multiple mappings here

>>>>>>  Video Processing Steps for [0:0]: H.265 (HEVC)
        Step                    HW-Context   Format       SW-Format           Size   Next
        HEVC                 >> CUDA         cuda         nv12           1920x1080 >> scale_cuda
        scale_cuda           >> CUDA         cuda         nv12            1280x720 >> setsar
        setsar               >> CUDA         cuda         nv12            1280x720 >>

But ffmpeg changed from 5.0 to 5.1 between versions so whatever changed has cause issues like this and may other per other post.  But specific conditions are needed to fail as it does not affect all media or servers.

Edited March 31, 2024 by Happy2Play

[Leinad86 6]

So there's nothing I can do about it at the moment? The developers need to patch it?

I'm thinking about setting up a 2 Emby installation. I just don't know if it's worth the effort. It would be nice if a developer could comment on this soon.

But I would like to thank you for your support

[Q-Droid 881]

9 minutes ago, Leinad86 said:

So there's nothing I can do about it at the moment? The developers need to patch it?

I'm thinking about setting up a 2 Emby installation. I just don't know if it's worth the effort. It would be nice if a developer could comment on this soon.

But I would like to thank you for your support

Have you tried converting some of the videos that fail to see what works and what doesn't?

 

[Leinad86 6]

No, I haven't, and to be honest I don't know how to do anything. The content is encoded in H265 using Tdarr. And as I said, I never had any problems with it until 4.8.

I'm just surprised that not many more people have problems with it.

[Happy2Play 9444]

2 minutes ago, Leinad86 said:

No, I haven't, and to be honest I don't know how to do anything. The content is encoded in H265 using Tdarr. And as I said, I never had any problems with it until 4.8.

I'm just surprised that not many more people have problems with it.

And does that not suggest there may be an issue with the method Tdarr is converting the media?  Is this only an issue with Tdarr converted media?

[Leinad86 6]

All of my media was or is encoded with Tdarr. I've been doing this for over 2 years now

[Leinad86 6]

I may have found something, as soon as I activate this (Disable HLS Subtitles) I no longer get any errors in my test episode!

Here is the log 

emby v4.8.3.0_Disable HLS Subtitles.txt

[Happy2Play 9444]

Yep as that correct the issue shown in your test file.  So that gives the devs a specific area to look Subtitles.

Disable HLS Subtitles

Edited March 31, 2024 by Happy2Play

[Luke 40086]

Is it only an issue with that one file?

[Leinad86 6]

No, unfortunately not.

Do you need more examples? It's always the same when the error occurs.

 

08:48:54.359 Too many packets buffered for output stream 1:1.

08:48:54.386 [libmp3lame @ 0x10ce380] 3 frames left in the queue on closing

08:48:54.534 Conversion failed!

08:48:54.534 EXIT

 

Testet episode Die Kaiserin/Staffel 1/die.kaiserin.s01e01.german.1080p.web.x264-wvf.mkv

 

As soon as I activate Disable HLS Subtitles the error no longer occurs

 

 

[Luke 40086]

OK we'll take a look at it. Thanks.

[BlackDub 48]

I have the same problem, NVIDIA and Intel Qsync, with windows and debian, docker too, the only fix is back to 4.7.x.x
 

[Leinad86 6]

@BlackDub

Try activating these two options. You need the Diagnostic plugin for this, you can activate it there. After that everything was working again for me. You have to set these options again after every restart. - Hope it helps you