Jump to content


Photo

Emby Docker Container (v4.2.1.0) Unnecessary Transcoding

livetv transcoding mpeg2video mpegts h264

Best Answer diego.rivera , 12 November 2019 - 02:39 PM

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

 

Thanks, Luke!!

Go to the full post


  • Please log in to reply
18 replies to this topic

#1 diego.rivera OFFLINE  

diego.rivera

    Advanced Member

  • Members
  • 39 posts
  • Local time: 11:53 AM

Posted 04 November 2019 - 01:46 PM

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, 04 November 2019 - 01:52 PM.


#2 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142523 posts
  • Local time: 12:53 PM

Posted 04 November 2019 - 02:27 PM

Hi there, let's look at an example. Please see how to report a media playback issue. thanks.



#3 diego.rivera OFFLINE  

diego.rivera

    Advanced Member

  • Members
  • 39 posts
  • Local time: 11:53 AM

Posted 04 November 2019 - 03:43 PM

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!

Attached Files


Edited by diego.rivera, 04 November 2019 - 03:46 PM.


#4 diego.rivera OFFLINE  

diego.rivera

    Advanced Member

  • Members
  • 39 posts
  • Local time: 11:53 AM

Posted 04 November 2019 - 04:33 PM

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!

Attached Files


Edited by diego.rivera, 04 November 2019 - 04:35 PM.


#5 diego.rivera OFFLINE  

diego.rivera

    Advanced Member

  • Members
  • 39 posts
  • Local time: 11:53 AM

Posted 04 November 2019 - 04:34 PM

Luke,

 

I've re-posted this topic in the LiveTV forum section as it's probably more appropriate. I've also attached the files there

 

Thanks!



#6 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142523 posts
  • Local time: 12:53 PM

Posted 04 November 2019 - 04:50 PM

Merged topics.


  • diego.rivera likes this

#7 Dan_Austin ONLINE  

Dan_Austin

    Advanced Member

  • Members
  • 61 posts
  • Local time: 09:53 AM

Posted 09 November 2019 - 01:23 PM

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...



#8 davidgfriedman OFFLINE  

davidgfriedman

    Newbie

  • Members
  • 4 posts
  • Local time: 12:53 PM

Posted 09 November 2019 - 01:38 PM

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



#9 diego.rivera OFFLINE  

diego.rivera

    Advanced Member

  • Members
  • 39 posts
  • Local time: 11:53 AM

Posted 09 November 2019 - 01:42 PM

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.



#10 Dan_Austin ONLINE  

Dan_Austin

    Advanced Member

  • Members
  • 61 posts
  • Local time: 09:53 AM

Posted 09 November 2019 - 01:49 PM

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.


  • diego.rivera likes this

#11 diego.rivera OFFLINE  

diego.rivera

    Advanced Member

  • Members
  • 39 posts
  • Local time: 11:53 AM

Posted 09 November 2019 - 01:55 PM

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...



#12 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142523 posts
  • Local time: 12:53 PM

Posted 09 November 2019 - 02:53 PM

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



#13 davidgfriedman OFFLINE  

davidgfriedman

    Newbie

  • Members
  • 4 posts
  • Local time: 12:53 PM

Posted 09 November 2019 - 03:03 PM

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



#14 diego.rivera OFFLINE  

diego.rivera

    Advanced Member

  • Members
  • 39 posts
  • Local time: 11:53 AM

Posted 09 November 2019 - 03:03 PM

Thanks, Luke! Any approximate ETA on that?

#15 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142523 posts
  • Local time: 12:53 PM

Posted 09 November 2019 - 03:04 PM

Soon.



#16 davidgfriedman OFFLINE  

davidgfriedman

    Newbie

  • Members
  • 4 posts
  • Local time: 12:53 PM

Posted 11 November 2019 - 11:23 PM

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?

#17 davidgfriedman OFFLINE  

davidgfriedman

    Newbie

  • Members
  • 4 posts
  • Local time: 12:53 PM

Posted 11 November 2019 - 11:24 PM

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.

Attached Files



#18 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142523 posts
  • Local time: 12:53 PM

Posted 11 November 2019 - 11:35 PM

 

 

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.



#19 diego.rivera OFFLINE  

diego.rivera

    Advanced Member

  • Members
  • 39 posts
  • Local time: 11:53 AM

Posted 12 November 2019 - 02:39 PM   Best Answer

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

 

Thanks, Luke!!


  • Luke likes this





Also tagged with one or more of these keywords: livetv, transcoding, mpeg2video, mpegts, h264

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users