Jump to content
diego.rivera

ANSWERED Emby Docker Container (v4.2.1.0) Unnecessary Transcoding

Recommended Posts

diego.rivera

Hi!

 

I've been running a Dockerized Emby server based on the official Docker image (currently at v4.2.1.0), to be accessed from Roku boxes I have laying about the house, using the BETA Roku app. I also have a TVHeadEnd deployment which is fully functional, which also renders all streams as MPEG-TS container with MPEG2 video and AC3 audio. The Emby server is configured to access TVH using the Emby TVHeadEnd plugin (v1.4.4.0).

 

This has worked flawlessly for months, but now I've noticed that Emby is for some reason transcoding from MPEG2 to H264. While this isn't costing too much, it's not what I want. Plex and other clients are more than happy to play back the MPEG2 video streams without issue.

 

However, Emby is choosing to transcode the stream because "container is not supported". This means that for some reason, Emby - either Roku or Server? - decides it doesn't like the MPEGTS container and requires a "transcoding".  The issue here is that the "transcoding" should limit itself to repackaging, since both the audio and video streams are supported by the Roku device(s).

 

As I said, this used to work perfectly in earlier server versions. Sadly, I don't know exactly when this got "broken" (so to speak). I only noticed this accidentally yesterday while showing a friend of mine the "stats for nerds".

 

Can you help me figure out what's wrong? In my mind, if the container is not supported then Emby can definitely repackage the streams as it sees fit - what it shouldn't be doing is transcoding them as this is wasteful and unnecessary. Like I said before, neither Plex nor Roku's UPNP/DLNA application have any issue in playing back the raw MPEGTS/MPEG2/AC3 streams.

 

I'll be happy to provide more details if required.

 

Cheers!

Edited by diego.rivera

Share this post


Link to post
Share on other sites
diego.rivera

I've submitted two logs from the Roku app a few minutes ago - one before (accidental) and one after reproducing the issue. I'm attaching the Emby log files including the transcode log and hardware detection.

The logs were submitted at about 14:33 on 2019/11/04 (UTC-5), by the emby user "admin". The action was just (successfully) playing back a Live TV stream which ended up being unnecessarily transcoded.

 

Cheers!

embyserver.txt

ffmpeg-transcode-11f0245f-6bc1-4429-be35-dd799e2806ee_1.txt

hardware_detection-63708491906.txt

Edited by diego.rivera

Share this post


Link to post
Share on other sites
diego.rivera

Hi!


 


I've been running a Dockerized Emby server based on the official Docker image (currently at v4.2.1.0), to be accessed from Roku boxes I have laying about the house, using the BETA Roku app. I also have a TVHeadEnd deployment which is fully functional, which also renders all streams as MPEG-TS container with MPEG2 video and AC3 audio. The Emby server is configured to access TVH using the Emby TVHeadEnd plugin (v1.4.4.0).


 


This has worked flawlessly for months, but now I've noticed that Emby is for some reason transcoding from MPEG2 to H264. While this isn't costing too much, it's not what I want. Plex and other clients are more than happy to play back the MPEG2 video streams without issue.


 


However, Emby is choosing to transcode the stream because "container is not supported". This means that for some reason, Emby - either Roku or Server? - decides it doesn't like the MPEGTS container and requires a "transcoding".  The issue here is that the "transcoding" should limit itself to repackaging, since both the audio and video streams are supported by the Roku device(s).


 


As I said, this used to work perfectly in earlier server versions. Sadly, I don't know exactly when this got "broken" (so to speak). I only noticed this accidentally yesterday while showing a friend of mine the "stats for nerds".


 


Can you help me figure out what's wrong? In my mind, if the container is not supported then Emby can definitely repackage the streams as it sees fit - what it shouldn't be doing is transcoding them as this is wasteful and unnecessary. Like I said before, neither Plex nor Roku's UPNP/DLNA application have any issue in playing back the raw MPEGTS/MPEG2/AC3 streams.


 


I've attached the Emby server logs from the time period, and here's the information on the client (Roku Beta App) logs:


 


  • Time of submission: 2019-11-04 @ 14:33 (UTC-5) ... +/- 3 minutes (double submission, by mistake...the "good" one is the 2nd one)
  • User connected: admin
  • Action undertaken: Play back (successfully) a Live TV stream, which was transcoded from MPEGTS/MPEG2/AC3 to MKV/H264/AC3

 


Cheers!


embyserver.txt

ffmpeg-transcode-11f0245f-6bc1-4429-be35-dd799e2806ee_1.txt

hardware_detection-63708491906.txt

Edited by diego.rivera

Share this post


Link to post
Share on other sites
Luke

Merged topics.

  • Like 1

Share this post


Link to post
Share on other sites
Dan_Austin

It is the beta Roku app.  Apparently a number of Roku models are having issues

with MPEG2, so instead of just re-muxing it transcodes to H264.  That change was

made somewhere between 185 and 190.

 

It's got me considering trying a Shield...

Share this post


Link to post
Share on other sites
davidgfriedman

Hi!

 

I've been running a Dockerized Emby server based on the official Docker image (currently at v4.2.1.0), to be accessed from Roku boxes I have laying about the house, using the BETA Roku app. I also have a TVHeadEnd deployment which is fully functional, which also renders all streams as MPEG-TS container with MPEG2 video and AC3 audio. The Emby server is configured to access TVH using the Emby TVHeadEnd plugin (v1.4.4.0).

 

This has worked flawlessly for months, but now I've noticed that Emby is for some reason transcoding from MPEG2 to H264. While this isn't costing too much, it's not what I want. Plex and other clients are more than happy to play back the MPEG2 video streams without issue.

 

However, Emby is choosing to transcode the stream because "container is not supported". This means that for some reason, Emby - either Roku or Server? - decides it doesn't like the MPEGTS container and requires a "transcoding".  The issue here is that the "transcoding" should limit itself to repackaging, since both the audio and video streams are supported by the Roku device(s).

 

As I said, this used to work perfectly in earlier server versions. Sadly, I don't know exactly when this got "broken" (so to speak). I only noticed this accidentally yesterday while showing a friend of mine the "stats for nerds".

 

Can you help me figure out what's wrong? In my mind, if the container is not supported then Emby can definitely repackage the streams as it sees fit - what it shouldn't be doing is transcoding them as this is wasteful and unnecessary. Like I said before, neither Plex nor Roku's UPNP/DLNA application have any issue in playing back the raw MPEGTS/MPEG2/AC3 streams.

 

I'll be happy to provide more details if required.

 

Cheers!

 

So I'm NOT crazy.  I saw it work a month or two ago where I could a) stream liveTV via Emby from my HDHomeRun to my Roku3 without transcoding and B) record to Emby from my HDHomeRun then play it later via Emby to my Roku3 without transcoding.  I was getting ready to move so I cut the cord and moved.  Now, I'm settled in and wanted to watch my recordings now that I have my antenna setup.  Unfortunately, neither my pre-move emby DVR recordings or my post-move emby TV recordings are direct streaming to my roku3's anymore.  The movies still direct play / direct steam, but I made those on my Pc when I digitized about 1/3 of my physically-owned DVDs.

 

Do we know what "fix" in either Emby or Roku could have caused this change?  Is there a way I can obtain the Synology binary for a previous version of Emby to install and test and see if it was broken by Emby or Roku?  I don't have the CPU on my Synology DS218+ to transcode the mpeg2video .ts files live  Or is there a way to schedule all new recordings transcode after midnight so they'll be ready the next day?

 

Thanks for any suggestions,

David

Share this post


Link to post
Share on other sites
diego.rivera

Well, they should be querying the Roku for supported protocols vs. just guessing by model... then again I have no idea if the Roku API/services support that kind of querying.  I'm also considering switching to a Shield, but will wait a little to see if the price goes down somewhat.  Can't get the "older" ones anymore, so it's either the cylinder or the pro one, both fairly pricey.

Share this post


Link to post
Share on other sites
Dan_Austin

The change is also in the recent Roku Emby app update, so we are stuck with

this behavior for now.  If the developers add an option to revert to the previous

settings or can add a list of known problematic devices so the better Roku units

do not suffer the faults of the ones with problems, then and only then can we avoid

unneeded transcoding.

  • Like 1

Share this post


Link to post
Share on other sites
diego.rivera

This was the last thing that I was keeping Emby alive for - it could handle LiveTV quirks & hiccups much more cleanly than Plex. It seems Plex has since improved a lot in that department, so I'll have to see if that logic still applies.

 

If it doesn't, then I'm sad to say that I'll have to bid Emby a very grateful adieu...

Share this post


Link to post
Share on other sites
Luke

We'll be pushing out a Roku update to resolve this. Thanks.

Share this post


Link to post
Share on other sites
davidgfriedman

We'll be pushing out a Roku update to resolve this. Thanks.

If you need testers on the Roku Emby Beta app, let me know and I'll test it against HDHomeRun new/old recordings plus live streaming. i have both installed on 2 of my 5 Rokus currently in use (Roku4k and a Roku3, also have 2 TCL Roku 32" TVs and another Roku3 in use, plus a few more not in use yet since the [house] move the last few weeks).

 

thanks,

David

Share this post


Link to post
Share on other sites
diego.rivera

Thanks, Luke! Any approximate ETA on that?

Share this post


Link to post
Share on other sites
Luke

Soon.

Share this post


Link to post
Share on other sites
davidgfriedman

I saw the beta channel has 3.0.192 so I tried it out. Both the recordings from the HDHomerun and the LiveTV streams are gentler on my Synology DS218+ NAS. The only thing which seems strange to me is the playback type reads: remux. Yet the emby server shows it is direct streaming. I've attached a screen shot of the Roku. It seems like all of the videos I've sampled are doing this. Is that the audio changing from surround sound to simple 2 channel stereo. Or an I reading that incorrectly?

Share this post


Link to post
Share on other sites
davidgfriedman

I saw the beta channel has 3.0.192 so I tried it out. Both the recordings from the HDHomerun and the LiveTV streams are gentler on my Synology DS218+ NAS. The only thing which seems strange to me is the playback type reads: remux. Yet the emby server shows it is direct streaming. I've attached a screen shot of the Roku. It seems like all of the videos I've sampled are doing this. Is that the audio changing from surround sound to simple 2 channel stereo. Or an I reading that incorrectly?

Screen shot "attached" this time.

post-401715-0-93506100-1573529036_thumb.jpg

Share this post


Link to post
Share on other sites
Luke

 

 

Yet the emby server shows it is direct streaming.

They're the same thing, just labeled inconsistently between the two places. We'll take a look at that. Thanks.

Share this post


Link to post
Share on other sites
diego.rivera

I can confirm that 3.0.192 does indeed only remux albeit with the labeling issue that has already been noted.

 

Thanks, Luke!!

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...