problem with transcoding or transmission

[hearingaid1970 0]

I have been having issues with emby freezing while playing back tv shows.  I am including the log files and i hope someone on here can help me figure out what is going on and how to fix..

I have tried reducing bitrate, increasing bitrate, disable hardware transcode, enable hardware encode.  I have no idea what else to do.

Anyone who has knowledge, please look and give a hand.

 

Thank you.

embyserver.txt ffmpeg-transcode-01f763a9-dc23-4181-b9d2-f38f1724f556_1.txt

[ebr 16561]

Hi.  Is it possible your transcoding temp location is running out of space?

12:16:28.750 Too many packets buffered for output stream 1:1.
12:16:28.827 Conversion failed!
12:16:28.827 EXIT

 

[speechles 2107]

Quote

12:16:28.750 Too many packets buffered for output stream 1:1.

Quote

12:15:55.729   Stream #0:2 -> #1:0 (subrip (srt) -> webvtt (native))
12:15:55.729   Stream #0:0 -> #1:1 (copy)

The output steam 1:1 is the subtitles.

 

Quote

12:15:55.840     Side data:
12:15:55.840       cpb: bitrate max/min/avg: 4232000/0/4232000 buffer size: 8464000 vbv_delay: N/A

8.464MB buffer. There are 3 subtitles muxing into this space from your log. If each takes up the maximum it would equal 12 which exceeds the buffer. Not sure if that is what this means the buffer size is for all the subtitles combined or just the 1. But the issue comes down to the subtitles sidedata being too large. If you remove some of those subtitles that will never get used it might make it easier to play that item.

ffmpeg allows the flag -max_muxing_queue_size to change the queue size larger. But that is at the cost of memory leaking. The main reason that error comes up is to prevent memory leaks so ffmpeg crashes rather than continue out of bounds. This is happening for a reason.

Maybe @softworkzknows best?

 

Edited yesterday at 06:07 PM by speechles

[softworkz 5330]

12 hours ago, speechles said:

8.464MB buffer. There are 3 subtitles muxing into this space from your log. If each takes up the maximum it would equal 12 which exceeds the buffer. Not sure if that is what this means the buffer size is for all the subtitles combined or just the 1

This bufsize parameter is for something different. It is a parameter for the video encoder and indicates the (fictional) size of the input buffer which the decoder will have available.Input buffer of the decoder means memory where video data is stored when it is read or arrives from the network before the decoder decodes it. When this buffer is rather small, the encoder must avoid rapid changes of the bitrate because this can lead to buffer overflow and underflow when ther buffer is no longer able to erqualize the input data flow with its buffer.

So, effectively, this value puts constraints on the way how the encoder is allowed to modulate the bitrate of the encoded video stream.

The values is in bits, so in this case it's roughly 1 MB

 

12 hours ago, speechles said:

But the issue comes down to the subtitles sidedata being too large.

Side data is an  FFmpeg concept which serves lots of different purposes, but afaik, there's no subtitle format in FFmpeg for which any kind of side-data is being used.

 

12 hours ago, speechles said:

ffmpeg allows the flag -max_muxing_queue_size to change the queue size larger. But that is at the cost of memory leaking. The main reason that error comes up is to prevent memory leaks so ffmpeg crashes rather than continue out of bounds. This is happening for a reason.

Now it's getting hot - right into the the bulls-eye! But then it gets slightly wrong again.A memory leak is only called cases where memory does not get freed at the end of an operation. High memory usage itself is not a leak. When you set max_muxing_queue_size to a value high enough that the whole video stream gets queued up in the muxing queue (which could be many GB) and the memory gets freed at the end (assuming FFmpeg would not exit immediately), then that's not a leak. But yes, such cases are meant to be avoided, not only for memory consumption but more naturally for the simple reason that when so many packets are getting queued up, it's a strong indicator that something is wrong and the intention is to rather error out in those cases than let it running. 

BTW: Our command lines do not include  max_muxing_queue_size but our FFmpeg has higher defaults already.

[softworkz 5330]

Now for the actual Issue

In order to get webvtt subtitle segments at regular intervals, in-sync with the video segments, we are pairing each subtitle stream with a copy of video stream. The video streams are never encoded for these, they just provide a continuous packet flow inside ffmpeg and are eventually dropped. Without this, ffmpeg would wait until the subtitle stream has some content, so when there's no subtitle for 60s, it would not create any output segment during those 60s and then instead create a single subtitle segment with a length of 63s. That's bad, because at this time, we have already told the client that there are 21 segments to download, each with a length of 3s. From then on, everything would go wrong...

And there's another problem: When muxing and filtering, FFmpeg waits until it has seen a packet from each stream before it even starts. In our FFmpeg, we're addressing this by sending empty subtitle packets when needed, to ensure proper flow of all streams. This can be seen in the logs as "subtitle kickoff".

In this log, we see this working for all subtitle streams except the first one. I can't say for sure but my best guess is that this subtitle stream might have some invalid packets or packets with incorrect of unusual timing. Something like this might stop the kickoff mechanism - probably.
The result is that no subtitle packets are flowing for the first subtitle output stream, which means that the video packets (which are to be dropped later) are filling up the muxing queue, eventually causing FFmpeg to stop.

[hearingaid1970 0]

All this info is nice, but I am not that knowledgeable.

What do I need to do to fix this?

 

Please help

[hearingaid1970 0]

I have removed all subtitles that were unnecessary.

now I think we are down to the 3 English subtitles only.

We tried to play again, and same problem.

[Luke 42826]

1 hour ago, hearingaid1970 said:

I have removed all subtitles that were unnecessary.

now I think we are down to the 3 English subtitles only.

We tried to play again, and same problem.

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[softworkz 5330]

2 hours ago, hearingaid1970 said:

I have removed all subtitles that were unnecessary.

now I think we are down to the 3 English subtitles only.

We tried to play again, and same problem.

Ît was never about the number of subtitle streams. It's about the first one: "English forced" which seems have some issue.

[hearingaid1970 0]

this issue occurs with every one of the shows.

I will remove the forced subtitle on all the shows and see what happens

[softworkz 5330]

24 minutes ago, hearingaid1970 said:

I will remove the forced subtitle on all the shows and see what happens

Maybe try with a single one first?