Transcode Buffer "Draining"

[Sammy 790]

The Transcode Buffer is not keeping up. I pause playback to build it to 30 seconds and watch it drain to 5 seconds at which point stuttering starts.

Playback is on MiBox s at 40Mbps.

Server is Ryzen 3700x with nVidia GTX 1060 6Gb and 16 Gb RAM.

AndroidTV Log Sent NOW. User name is TVTime.

Had to zip the server log as it was too big.

Sent from my SM-G960U1 using Tapatalk

http://cloud.tapatalk.com/s/5eef6ca3e24bf/ffmpeg-transcode-46815aa7-4c7d-4067-8361-90e1a2f55cd1_1.txt

http://cloud.tapatalk.com/s/5eef6cef1961c/embyserver%20%281%29.zip

 

 

 

 

 

 

Edited June 22, 2020 by Sammy

[Luke 42078]

Can you please attach the log files? Thanks.

[Sammy 790]

 

Can you please attach the log files? Thanks.

I did.. via Tapatalk but here they are again

 

 

 

Sent from my SM-G960U1 using Tapatalk

 

embyserver (1).zip

 

ffmpeg-transcode-46815aa7-4c7d-4067-8361-90e1a2f55cd1_1.txt

 

 

Edited June 21, 2020 by Sammy
Upload logs via web, not Tapatalk

[Sammy 790]

Uploaded again in above post.

[Sammy 790]

I uploaded my logs but I don't see that anybody is downloaded them to look at them. Do I need to test again because probably the AndroidTV log is old or gone.

[Luke 42078]

@softworkz will be taking a look. Thanks.

[Sammy 790]

Awesome! He da man!

 

Thanks @softworkz!

[Sammy 790]

Here's an update..

I decided to change some of the transcode settings.. Playback is fine now and the transcode buffer is throttling and not depleting.

I set the Transcoding thread count to "Max", moved H264 encoding preset from "slow" to "medium" and H264 encoding CRF from "18" to "23". 

Of these settings which has the biggest effect and did I maybe take too far a jump on the Thread Count or CRF?

Maybe a little more guidance on these settings is in order? Maybe they need some sort of a gradient scale that the end user can look out to see the effects of balancing transcoding and quality?

Edited June 22, 2020 by Sammy

[Luke 42078]

23 was the default, so that means you previously customized it.

[Sammy 790]

1 minute ago, Luke said:

23 was the default, so that means you previously customized it.

Yes, in my never-ending quest for quality, maybe I did too much! So what if I just put that at 23 and leave the balance of the settings as they were..

Transcoding thread count: "Auto"

H264 encoding preset: "Slow"

[softworkz 5067]

So, that whole issue was simply: "Transcoding not being fast enough"

PS: "Slow" requires more CPU than "Fast" (for example)

 

 

[pünktchen 1409]

So, that whole issue was simply: "Transcoding not being fast enough"
PS: "Slow" requires more CPU than "Fast" (for example)
 
 

But he is using his Nvidia graphics. At least the screenshot says so and i didn't look at the ffmpeg log. Didn't you say somewhere the transcoding settings have no impact on hwa transcoding? Or does the stats report something wrong and it is software transcoded?

[softworkz 5067]

 

2 minutes ago, pünktchen said:

50 minutes ago, softworkz said:

So, that whole issue was simply: "Transcoding not being fast enough"
PS: "Slow" requires more CPU than "Fast" (for example)
 
 

But he is using his Nvidia graphics. At least the screenshot says so and i didn't look at the ffmpeg log. Didn't you say somewhere the transcoding settings have no impact on hwa transcoding? Or does the stats report something wrong and it is software transcoded?

My reply was solely based on this:

3 hours ago, Sammy said:

I set the Transcoding thread count to "Max", moved H264 encoding preset from "slow" to "medium" and H264 encoding CRF from "18" to "23". 

In case of Nvidia HWA, none of those modifications would have changed anything.

[Sammy 790]

1 hour ago, softworkz said:

 

1 hour ago, softworkz said:

So, that whole issue was simply: "Transcoding not being fast enough"

PS: "Slow" requires more CPU than "Fast" (for example)

 

 

Why would this be an issue here? I have a Ryzen 3700x; it is hardly a wimp.

 

[pünktchen 1409]

6 minutes ago, softworkz said:

In case of Nvidia HWA, none of those modifications would have changed anything.

That's what i thought. But then something is wrong with the Nvidia transcoding.

If you look at the ffmpeg log then you'll see it starts with a speed of over 500x and gets slower every 10 frames down to only 3x.

I guess with some more minutes in the video the transcoding would just stop completely.

[Sammy 790]

12 minutes ago, softworkz said:

 

My reply was solely based on this:

In case of Nvidia HWA, none of those modifications would have changed anything.

If none of these modifications do anything, why did changing them correct the issue.

The GPU is a GTX 1060 6Gb.

[softworkz 5067]

27 minutes ago, pünktchen said:

That's what i thought. But then something is wrong with the Nvidia transcoding.

If you look at the ffmpeg log then you'll see it starts with a speed of over 500x and gets slower every 10 frames down to only 3x.

I guess with some more minutes in the video the transcoding would just stop completely.

No. There's a calculation bug in ffmpeg. It doesn't correctly calculate the speed when transcoding does not start from the beginning (-ss parameter specified)

Better look at the fps= values.

Those indicate that transcoding has been too slow right from the start - like i had already suspected.

[softworkz 5067]

47 minutes ago, Sammy said:

If none of these modifications do anything, why did changing them correct the issue.

I can't say exactly without seeing the ffmpeg log from afterwards.

Probably you have changed something else or simply played without subtitles.

47 minutes ago, Sammy said:

The GPU is a GTX 1060 6Gb.

It's not about GPU. It's about CPU needing to do the subtitle burn-in.

And there we come to the file in your example:

• It seems to be some kind of "home-grown" mkv file
• The MKV includes 40(!) subtitle streams
• Some of them do not even match the duration (like 1h or 1.5h instead of 2h)
• The resolution of the graphical subtitles that are burnt-in in your ffmpeg log example does not match the resolution of the video

Edited June 22, 2020 by softworkz

[pünktchen 1409]

23 minutes ago, softworkz said:

No. There's a calculation bug in ffmpeg. It doesn't correctly calculate the speed when transcoding does not start from the beginning (-ss parameter specified)

Better look at the fps= values.

Those indicate that transcoding has been too slow right from the start - like i had already suspected.

Ah, i see.

And it seems your right with the subtitles. At least the PGS subtitles. I also have a GTX 1060 and don't have any problems with videos that have similar specs, but with external SRT subs.

[Sammy 790]

Guess I'll pass it through mkvToollNix..

Sent from my SM-G960U1 using Tapatalk

[softworkz 5067]

14 minutes ago, pünktchen said:

Ah, i see.

And it seems your right with the subtitles. At least the PGS subtitles. I also have a GTX 1060 and don't have any problems with videos that have similar specs, but with external SRT subs.

 

The new logs make it easy to spot which things are done in sw or hw:

[softworkz 5067]

7 minutes ago, Sammy said:

Guess I'll pass it through mkvToollNix..

I think it has gone through such tools way too often already.

Better get another version...

[pwhodges 2012]

MKVToolnix should do no damage, though.

Paul

[softworkz 5067]

3 minutes ago, pwhodges said:

MKVToolnix should do no damage, though.

Paul

But it can't fix that mess either.

[Sammy 790]

I meant to strip out the extra subtitles..

Sent from my SM-G960U1 using Tapatalk