Jump to content

Podcast plugin vid quality suddenly crappy?


Recommended Posts

Posted

In the last few weeks, I have noticed that all of my podcast videos have gone to crap quality when viewing via Roku and emby beta.  When the podcasts are viewed via the web interface of emby, they all view in HD quality.  But, when viewed with Roku, the quality goes to crap and there is a lot of pixelation and compression artifacts.  Also, most of my podcasts come from the twit network and when viewed with the TWIT roku app, the quality is HD, but when switched to emby to the podcast plugin, back to poor quality.  My home service is a reliable 300 megabit plus, so it is not a lag issue for certain.

 

This was never an issue before and just showed up 2 to 3 weeks ago.  It is consistent and repeatable.

 

Any ideas?

Posted (edited)

What make/model# of roku is this? 

 

Have you tried a setting other than "Auto" and manually setting a maximum video bitrate in the settings of the app? Sometimes Auto can get confused especially with IPTV streams.

Edited by speechles
Posted

It is a Roku Ultra (lastest model).

 

I just tried setting video quality to both 1080P FHD - 60 Mbps and 2160P 4K(UHD) - 30 Mbps, and both were the same low quality as I am getting with the auto setting.

Posted (edited)

In that case, can you provide an ffmpeg log created when it plays? Using this we should be able to see what is happening and why it is under performing.

 

Make sure to try with hardware acceleration for transcoding both on and off.

Edited by speechles
Posted

It seems as though ffmpeg is complaining about a problem in the source stream:
 

https://mcdn.podbean.com/mf/web/h5c4jr/tekthing--0214--huawei-matebook-13-block-sim-card-hacks-fast-router-vpn-aromatherapy.mp4: Invalid data found when processing input
Posted (edited)
VideoCodec=h264,mpeg1video,mpeg2video,hevc&AudioCodec=ac3,aac,mp2,mp3,eac3,flac,opus,vorbis,lpcm

TranscodeReasons=ContainerNotSupported

 

  Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native))

  Stream #0:1 -> #0:1 (aac (native) -> ac3 (native))

 

It is a .ts. The issue is why does it use mpeg2video when the source isn't mpeg2video?

 

I think I answer my own question here:

The source video/audio isn't known as this is not ffprobed in advance. This is an iptv/web stream you can tell it has no information as to what the stream should be. So my guess is with TV it just assumes mpeg2video with ac3? Is this why mpeg2video is chosen instead of just stream copy both the h264 and aac?

 

This might be causing our Roku problem (Roku 2HD/2XD/2XS) with pixelated mpeg2video that is choppy, users complain is it IPTV streams that do this. I think I now see a correlation.

Edited by speechles
Posted

this one is a server-side issue it appears.

Posted (edited)

I gather from you guys' conversation, you are on to something?  I will wait patiently as this is not the end of the world.  Thanks for your efforts!

Edited by gwbaker
Posted

We're looking into it, thanks.

  • 2 weeks later...
Posted

Just FYI,

 

The 4.0.2 update had no effect on this issue...  Not sure it was supposed to?

Posted

No, I haven't had a chance to get to this yet but will try to soon. Thanks.

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