Newbie looking for advice on how to avoid transcoding with subs

[hgpuke 2]

Hi there!

 

I have been a loyal Plex user for many years, but unfortunately the Plex community does not seem to be able to solve the playback issue with the Android TV client. Believe me, I have been waiting. Soon for one year.

 

So I came across Emby and downloaded it to my Synology NAS DS916+.

So far, everything seems to be working great, except for one small annoyance.

Maybe you can help me with this.

 

Most of my movies are Blu-ray disks that I have ripped using DVDFab (version 10 and 11 for Windows).

Mostly, I have used the default settings, that seem to give me all of the audio-streams and all of the subtitles (VOBSUB) in one mp4 container.

My problem is that when selecting one of those subtitles, the CPU-usage of the NAS goes up to between 90 and 100% which effectively makes it useless for anything else than viewing that movie. If I turn subtitles off, CPU-usage goes down to between 5 and 20% depending on other activities.

I have tried to use the feature to download SRT type subtitles from opensubtitles.org, and while the feature works, the NAS still seem to have to transcode the video-stream to display these subtitles (hence the high CPU usage).

 

I am mostly using an Xiaomi MiBox3 Android TV box connected to my TV.

I have also tried the Android client on my phone (running Android 9), the WebOS client on my second TV (LG) and the Samsung 2014 smartTV client on my daughters bedroom TV. It all yields the same result: High CPU usage when using subtitles.

As most of my movies are english language, and my native language is swedish, subtitles are important to me.

 

Is there any way to get around this problem, either with existing movies, or at least when ripping new ones?

 

Thanks for all help.

 

Hans-Göran Puke

[Luke 37178]

HI, welcome. Our Android TV app hasn't yet implemetned direct play support for this subtitle format, but it's planned for the future.

 

Our mobile app and Samsung TV app already support it though, so there must be another reason for the transcoding. Can we look at an example?

Regarding SRT, these should just about never cause a transcode, so again it must be for another reason. Can we look at an example of that? Thanks !

[hgpuke 2]

Hi Bazinga!

Thanks for your reply!

Sorry, I was wrong. There is no problem with the Android (for my phone) client.

There is no extra taxing on the CPU when using that. I haven't tried the Samsung smarttv client yet, but I am sure you are right there too.

 

However, I noticed a strange behaviour on my NAS when trying the two subtitle formats (VOBSUB and SRT):

 

VOBSUB: The server sends >10MB/s data to the client. Thats MegaBYTES!

SRT: The server sends <10Mb/s data to the client. Thats MegaBITS!

This is the same movie: Jurassic World in 1080P, approximate bitrate 5Mb/s according to the server.

 

So what is happening when I use the VOBSUB subs?

 

I have now also tried out the client for AppleTV and iPAD. Both are working great!

 

In any case, my conclusion at this point are:

 

1. Emby is working much better than Plex in my environment.

2. When ripping a blu-ray movie, I shall make sure to get the subs in the SRT format, not the VOBSUB format.

3. I will become a Premiere subscriber.

 

Thanks!

Edited December 30, 2018 by hgpuke

[Luke 37178]

Thanks for the feedback. To answer the bandwidth question, can you please attach the ffmpeg logs from both sessions? Thanks.

[hgpuke 2]

Thanks for the feedback. To answer the bandwidth question, can you please attach the ffmpeg logs from both sessions? Thanks.

Sure, if you could instruct me how to do this (where to find them and how to send them), please.

[Luke 37178]

Instructions can be found here:

https://emby.media/community/index.php?/topic/739-how-to-report-a-problem/

 

Thanks.

[hgpuke 2]

Thanks.

I re-run the tests, and now I don't see this strange behaviour with a lot of data being transferred.

However, I see a different problem when playing the movie with the VOBSUB subtext, and that is that the player stops for 1s every 5s or so (to re-buffer, I suppose). I did not have this issue earlier today. Very strange!

(I see a little extended CPU usage when using VOBSUB, but not more than 20% max. When running SRT, CPU was as low as a few percent).

 

I have made no changes to any settings since then.

 

Anyway, I am adding the ffmpeg log and embyserverlog to this message if you want to have a look.

 

I should add that my test was performed between 20:27:20 and 20:33:07 approximately.

I first ran with VOBSUB, then with SRT.

ffmpeglog.txt

embyserverlog.txt

Edited December 30, 2018 by hgpuke

[Luke 37178]

Burning in subtitles is a very expensive process, and it looks like your system simply can't do it fast enough. This is the reason for the buffering.

 

Please note, the upcoming 3.6 release will have dramatically improved support for hardware acceleration:

https://emby.media/community/index.php?/topic/64534-36058-hardware-acceleration-settings/

 

And this may help you as well.

 

But in general, avoiding the transcoding altogether will be your best approach i would think.

[hgpuke 2]

OK, thanks!

Tried again just now, and now there is no buffering... So it may have been some other activity interfering with the transcoding.

Anyways, I am looking forward to version 3.6. What is the time-schedule?

 

Also, I will go through my library, and try to use Sub Edit to extract the VOBSUB subtitles and convert them into SRTs. Hope it works. That way I don't need transcoding at all.

[Luke 37178]

Hopefully very soon. Thanks for the feedback.

[hgpuke 2]

Thanks for all the help so far. Just one remaining problem: I can't seem to play Jurassic World at all on my LG TV (WebOS 3).

First, I played a 480P movie, and it worked well.

Then I selected Jurassic World with Swedish SRT subtitles.

The Emby client for LG TV just gave me a black screen. Nothing happened.

After about 15 seconds I pressed the "back" key on the remote. Nothing happened. Still black screen.

After about approximately 1 minute of black screen, I gave up and shut down the TV.

After some more minutes I turned on the TV again, and started Emby. Emby worked OK. I did not try to start Jurassic World again.

 

I am attaching a portion of the emby server log, starting at about where I requested the client to start Jurassic World.

I hope that you can explain what is going on.

 

Hans-Göran

embyserverlog.txt

[Luke 37178]

Can you provide a sample video for testing? Thanks.

@@SamES

[hgpuke 2]

I have sent you a link to the movie. Cannot share it publicly.

[Luke 37178]

You sent it to me? Please include @@SamES on the conversation as well. Thanks.

[hgpuke 2]

I sent it to both of you

[Luke 37178]

Great, thanks.

[hgpuke 2]

 

Please note, the upcoming 3.6 release will have dramatically improved support for hardware acceleration:

https://emby.media/community/index.php?/topic/64534-36058-hardware-acceleration-settings/

 

 

Yes, 4.0 release has more support for hardware assisted decoding and encoding. However, it seems that the graphics hardware included in my Pentium N-series CPU is simply not powerful enough to be really usable here. See my other post "Observations ..."

[Luke 37178]

Yes and that's something we need to do a better job of automatically detecting. Thanks for your feedback.

 

@@softworkz

[solabc16 379]

Hello All

 

For reference and for other readers of the thread, we need to be a little careful here with our wording. If we're referring to VOBSUB, the limiting factor isn't the 'graphics hardware included in the Pentium N-series CPU'.

 

The limiting factor is that this has to be done in s/w and the limitation is the raw processing power of a single core, as the task isn't multi threaded.

 

This isn't an Emby Server specific limitation, but ways to improve upon it are being explored - but it's early days.

 

Best

- James

Edited January 16, 2019 by solabc16