bcm00re 18 Posted October 26, 2018 Share Posted October 26, 2018 From https://www.techhive.com/article/3249091/streaming-hardware/hdhomerun-plans-a-new-dvr-box.html: SiliconDust is against using HTTP Live Streaming, which other products like Tablo and Plex rely on for Roku support, because it splits the video into chunks that have to load before the video can play. “We like a purist experience where you’re changing channels within a couple seconds,” Head said. “We hit five seconds, we’re pissed off.” So what does Emby use for live streaming? I ask because for me it has always taken what feels like forever. It seems to take well over the 5 seconds referenced above to start tuning to a channel or to change channels. My server is running on dedicated HTPC (with a SSD) powered by an Intel i7-6700 processor, my tuner is an HD Homerun Extend (with hardware encoding set to Mobile), and I use Roku units (a Premiere model using wifi and a 3 model with a wired ethernet connection). In Emby settings I have Hardware Acceleration set to None under Transcoding, but I believe that I should already be getting a Roku compatible mpeg-4 stream from my Extend tuner. I am open to suggestions... Link to comment Share on other sites More sharing options...
Luke 37180 Posted October 26, 2018 Share Posted October 26, 2018 Hi, what we use depends on the platform. Let's look at an example and we'll offer some advice. Please attach the information requested in how to report a media playback issue. thanks ! Link to comment Share on other sites More sharing options...
bcm00re 18 Posted October 26, 2018 Author Share Posted October 26, 2018 (edited) I looked at the logs and did find an issue. It says it is doing the transcode at the "heavy" setting despite the fact the Extend software/firmware is set to "mobile". I have had that setting on "heavy" for awhile now and recently switched it to "mobile". I have changed that setting, within the Extend software, several times in the past and believe I saw it have the intended effect. Perhaps some settings in Emby are somehow overriding the Extend's transcode settings? Fron what I read Plex can do that so I suspect Emby can too. I restarted the Emby server and that didn't correct this issue. Also, my Extend's firmware was on an older 2017 version but I updated to the latest 2018 one, but that did not fix this either. Edited October 26, 2018 by bcm00re Link to comment Share on other sites More sharing options...
bcm00re 18 Posted October 26, 2018 Author Share Posted October 26, 2018 I did confirm under the Emby Live TV settings that I have "Allow hardware transcoding" checked for my Extend tuner. Link to comment Share on other sites More sharing options...
Luke 37180 Posted October 27, 2018 Share Posted October 27, 2018 The way we do it in emby is the server decides in it's own what stream to use, rather than using your hdhr default. Why, because it takes quality values requested by the emby app and then picks the closest hdhr profile to that. Link to comment Share on other sites More sharing options...
bcm00re 18 Posted October 27, 2018 Author Share Posted October 27, 2018 Are there settings within Emby that I can set to tweak what value Emby commands to the Extend (concerning hardware transcoding)? If so, which settings would those be? Link to comment Share on other sites More sharing options...
Luke 37180 Posted October 27, 2018 Share Posted October 27, 2018 What are you looking to do? Link to comment Share on other sites More sharing options...
bcm00re 18 Posted October 28, 2018 Author Share Posted October 28, 2018 I am trying to get my Extend to do the transcoding on the mobile setting because I believe that would mean the stream would not need to be transcoded for the Roku to play it. I was thinking that lack of Emby transcoding would make channel tuning notably faster. Link to comment Share on other sites More sharing options...
Luke 37180 Posted October 28, 2018 Share Posted October 28, 2018 Ok, we don't have any settings to allow you to do this. It's something we could add, but what kind of TV are you playing on? Delivering at lower resolution means you won't be seeing it at original quality. Link to comment Share on other sites More sharing options...
bcm00re 18 Posted October 28, 2018 Author Share Posted October 28, 2018 (edited) I agree the "mobile" setting isn't ideal, but the "heavy" setting doesn't deinterlace 1080i and Roku doesn't accept an interlaced steam. Honestly, depending how "mobile" actually looked it might not be what I really want. I wish the Extend had a setting between those two. I am currently not doing any hardware transcoding on my Emby server PC -- perhaps that could help? Seems like stuff I read about on that feature (in Emby) indicates it is still in development or kind of quirky/fragile. Edited October 28, 2018 by bcm00re Link to comment Share on other sites More sharing options...
bcm00re 18 Posted October 28, 2018 Author Share Posted October 28, 2018 BTW, the "mobile" transcode setting on the extend is still 720p resolution (with a bitrate of about 3mbps). That said, I noticed my recently experiences with watching Live TV have been with Fox, and that channel is already in 720p -- so not sure why Emby is even doing a transcode for my Roku. With the Extend already doing the "heavy" transcode the stream should be 720p with a bitrate of around 9mbps. My Emby app on the Roku does not have any bandwidth restrictions (it's setup to Auto). You asked about my TV; my primary one is a 58" Panasonic and my secondardy one if a 47" Panasonic and both are 3-4 year old. Link to comment Share on other sites More sharing options...
Luke 37180 Posted October 28, 2018 Share Posted October 28, 2018 We can add a setting, that's fine. Thanks. Link to comment Share on other sites More sharing options...
bcm00re 18 Posted October 28, 2018 Author Share Posted October 28, 2018 Before going to that trouble, let me get you some logs so we can fully understand why the transcode is occurring. Link to comment Share on other sites More sharing options...
bcm00re 18 Posted October 28, 2018 Author Share Posted October 28, 2018 (edited) Nothing to see here (double post that I cannot delete). Edited October 30, 2018 by bcm00re Link to comment Share on other sites More sharing options...
bcm00re 18 Posted October 30, 2018 Author Share Posted October 30, 2018 (edited) Attached on some log files. First I viewed some previously recorded X-Files episodes (recorded from Fox) and noticed then were also show "Trans" indicating they were being transcoded. So that appears consistent with what I see with Live TV. Next I tuned to my local Fox channel to get you some data. After watching for 5-7 minutes I got some buffering 2-3 times then the stream seemed solid. This seems to happen quite often when initially tuning. The other night when watching the World Series it was happening A LOT long after tuning. I also brought up the Performance tab of Task Manager while I was watching that Live TV, and surprisingly I found that my CPU and GPUs were all barely doing anything (like 0-9% utilization). So maybe Emby isn't really doing much -- in my case with the Extend tuner doing hardware transcoding -- when it is reporting "Trans". Please let me know your thoughts or if you need some other/more data. Thanks... embyserver_.txt ffmpeg-remux-fda40f14-b3fb-4eb4-b76d-22eb638210a0.txt ffmpeg-remux-ec2ab516-ea50-4651-8589-3c1b00969e73.txt ffmpeg-remux-dec71e19-1cdc-45c7-b4f9-954a2615b17a.txt Edited October 30, 2018 by bcm00re Link to comment Share on other sites More sharing options...
Luke 37180 Posted October 30, 2018 Share Posted October 30, 2018 These are just remuxes and not full transcodes. All they are doing is a container swap, while retaining original video and audio. Link to comment Share on other sites More sharing options...
bcm00re 18 Posted October 30, 2018 Author Share Posted October 30, 2018 (edited) Thanks for taking a look. That explains the lack of processor use! In the server log, do you see any hiccups that would cause the buffering I mentioned? I believe it occurred around 10:37pm tonight. With so little really occurring, I don't understand the buffering (especially what I saw the other night trying to watch the World Series). Edited October 30, 2018 by bcm00re Link to comment Share on other sites More sharing options...
Luke 37180 Posted October 31, 2018 Share Posted October 31, 2018 @@speechles can do some testing on this soon. Thanks. Link to comment Share on other sites More sharing options...
speechles 1921 Posted October 31, 2018 Share Posted October 31, 2018 (edited) Input #0, mpegts, from 'file:E:\TV\The X-Files\Season 11\The X-Files S11E04 The Lost Art of Forehead Sweat.ts': Duration: 01:05:59.67, start: 87087.863767, bitrate: 8848 kb/s Program 3 Stream #0:0[0x31]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [sAR 1:1 DAR 16:9], Closed Captions, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc Stream #0:1[0x34](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 448 kb/s Stream mapping: Stream #0:0 -> #0:0 (copy) Stream #0:1 -> #0:1 (ac3 (native) -> aac (native)) What kind of Roku is this? Now on the Roku 3 I can see the 60fps is going to be an issue as that device is underpowered for anything over 720@60. Combined with the fact the audio is being transcoded from AC3->AAC it might impose some kind of weird sync issue with the timestamps and the Roku just goes "hold up" and pauses for a second or two. Especially if the video and audio streams have errors like some OTA/Satellite streams may have. If you could get equipment to support the Dolby AC3 it might eliminate the problem, or at least remove it as a suspect in the lineup. The other issue at play is the Roku itself can decode AAC. We are at the mercy of the device and issues shine through when it screws up. This means that underlying Roku firmware issues might be exposing themselves to us. That being said, the Premiere should not be suffering the same at all. It has a much better chipset, twice the size and speed of memory, and twice the cores in its CPU. If it is having this same issue it might be network congestion and something is competing with you for resources across the network and eating bandwidth. We are doing the right thing by passing the video stream untouched. But maybe we need to on high latency, congested networks have "a way out". Even if that way out imposes full transcoding as a cost. I do have a Proof-of-Concept in progress for this app that adds a "force transcode" button of sorts onto the OSD. But I am not sure if even that could be a real way out of this situation. Like @@Luke said, I can investigate this soon. I have equipment on order, but have yet to receive it. Once that happens I can try to see if I can replicate any of this. But most of it sounds dependent on the same variables in your network setup and that part might be harder to replicate. In any case, it will get dealt with as any issue with LiveTV is a problem with the core product. And as such, becomes priority so we will continue to follow up on this issue until we find some resolution that is both acceptable to us, and to you. Sorry for your inconvenience. I wish everyone were happy all the time. I know that isn't possible at this time. Apologies. EDIT: One of the logs has the below in it repeated: [h264 @ 0000028831cbce80] SPS unavailable in decode_picture_timing [h264 @ 0000028831cbce80] non-existing PPS 0 referenced [h264 @ 0000028831cbce80] SPS unavailable in decode_picture_timing [h264 @ 0000028831cbce80] non-existing PPS 0 referenced [h264 @ 0000028831cbce80] decode_slice_header error [h264 @ 0000028831cbce80] no frame! [h264 @ 0000028831cbce80] SPS unavailable in decode_picture_timing [h264 @ 0000028831cbce80] non-existing PPS 0 referenced [h264 @ 0000028831cbce80] SPS unavailable in decode_picture_timing [h264 @ 0000028831cbce80] non-existing PPS 0 referenced [h264 @ 0000028831cbce80] decode_slice_header error [h264 @ 0000028831cbce80] no frame! [h264 @ 0000028831cbce80] SPS unavailable in decode_picture_timing [h264 @ 0000028831cbce80] non-existing PPS 0 referenced [h264 @ 0000028831cbce80] SPS unavailable in decode_picture_timing [h264 @ 0000028831cbce80] non-existing PPS 0 referenced [h264 @ 0000028831cbce80] decode_slice_header error Timing issue which would cause the very issue you describe. This is in the last ffmpeg log you provided. Edited October 31, 2018 by speechles Link to comment Share on other sites More sharing options...
bcm00re 18 Posted November 1, 2018 Author Share Posted November 1, 2018 @@speechles That was a Roku Primiere. I changed its HDMI (audio) setting away from Auto and now DD is getting passed to my A/V Rec'r that's in that setup. But I noticed the the info still says Trans -- maybe that's just the wrapper change. I'll try this new setup and see if I have another lots-of-hiccups episode. I still get one shortly after tuning, but I can live with that. My ASUS RT-N66W Dual-Band Wireless-N900 Gigabit Router is less than six feet away so not really thinking that is the issue. Maybe I'll give it a reboot for good measure. You mentioned Roku 3 was underpowered for anything but 720@60, but that is precisely what I was watching. All OTW broadcasts in 1080 are @30 so it should be okay too. And should bitrate come into play here too? Don't forget my setup has the Extend tuner doing hardware transcoding so that will limit the bitrate of typical broadcast streams. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now