Jump to content

Chromebook LiveTV Performance


jlachesk

Recommended Posts

jlachesk

I have a feeling this is a bit of a long shot, but I figured if anyone knows they're probably in this forum.

 

I've got a pretty standard set up:

 

- HTPC running Win7 and ServerWMC

- Server running WHS and MediaBrowser Server

- Cable via InfiniTV tuner and FIOS CableCard (it's an InfiniTV4 in the HTPC, actually)

- Acer C710 Chromebook w/ 6GB RAM

- A variety of devices (Macbook, Fire HD7, iPad, FireTV, etc, etc)

 

My issue is that LiveTV performance on the Chromebook is awful. Even at the lowest quality setting, playback stutters and freezes (worse at higher qualities, but even at the lowest it's frequent enough to make actually watching TV impossible). The odd part is that the problem only exists on LiveTV (well, LiveTV and recordings) on the Chromebook. All other media (even 1080p rips) play perfectly fine on the Chromebook, and LiveTV works fine on the Macbook in Chrome (I haven't tested all of the other devices yet, since the Chromebook is my primary device).

 

I'm wondering if anyone has run into this issue. Is there any difference in how MBS/SWMC handles transcoding (my understanding is it's .wtv to .ts?) vs how SWMC handles transcoding other media types? Is the output of SWMC's transcoding some format that just isn't well handled by ChromeOS (or my particular hardware)? I've tried toggling hardware acceleration in chrome://flags, but I don't see any observable difference one way or another. If this is the root cause, would an HDHR Prime potentially solve this problem via DLNA?

 

I've monitored load (CPU and network) on the HTPC and Server and I haven't seen any observable difference between loads streaming to the Chromebook (poor performance) and Macbook (excellent performance) with LiveTV. I also haven't seen any difference in performance on the Server between LiveTV and other media. In all cases, CPU usage tops out at ~60%, network at ~2%. That's further fueling my suspicion that this comes down to ChromeOS and/or Chromebook hardware.

 

If folks feel there is potential value in reviewing logs, I can work on gathering them up (probably take me a day or so due to work schedule). 

 

So there ya have it. Anyone have any bright ideas? Am I overlooking something trivial? Am I doomed?

 

Edit: Forgot to say thanks to the amazing devs creating and supporting MB and SWMC. Seriously, I can't imagine my media setup with out it. 

Edited by jlachesk
Link to comment
Share on other sites

krustyreturns

Sorry, I can't comment on the performance of a chromebook.  Swmc converts from wtv format to ts format only for live-tv streams - and its not transcoding - its just repackaging the data. MBS however is transcoding this data to whatever your client requires, webm in this case.  So since you say both livetv and recordings are playing poorly, it can't be swmc's conversion to ts that is causing the problem.  I would have though it was a bandwidth issue, but since you got no improvement from decreasing the bandwidth I guess not.  

Link to comment
Share on other sites

jlachesk

Krusty,

 

Thanks so much for the response. Given the differences in how live-tv and recordings are handled, I think that points away from SWMC.

 

If it is something with MBS's transcoding, it's something that only happens on wtv and ts input, not any of the other media formats (mkv, mp4, avi, etc all work fine).

 

With that to go one, I'll spend some time w/ the MBS logs and ffmpeg logs to see if I can find a discernable difference.

 

Thanks again!

Link to comment
Share on other sites

jlachesk

Warning: this turned into a much more verbose posting than I intended. Also, it's all based on the assumption that I'm correctly interpreting ffmpeg's output in the transcode logs correctly (intuitively it makes sense, but I'm not an expert). If I've misinterpreted anything, someone please tell me so I can get out of this rabbit hole!

 

Well, I spent some time looking at the transcode logs for live-tv, recorded-tv, and a sample movie (h264 mkv). 

 

Looking at the input/output for all 3, I didn't see any significant differences (i.e. all were output to webm and used the same sets of flags). What I did notice was a significant difference in the fps values ffmpeg was reporting during transcoding. I've included a couple of snippets from each (stripping out most of various meta, just looking at the ffmpeg transcode output:

 

Live-tv:

 

Input #0, mpegts, from 'file:\\HTPC\Recorded TV\TempSWMC\LiveTV_MediaBrowser^WHS^26_Digital Cable_590_2015_01_30_16_21_32.ts':

Stream #0:2[0x1011]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv), 1920x1080 [sAR 1:1 DAR 16:9], max. 16000 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc

 

frame=    0 fps=0.0 q=0.0 size=       5kB time=00:00:00.00 bitrate=N/A    
frame=    0 fps=0.0 q=0.0 size=       5kB time=00:00:00.09 bitrate= 410.5kbits/s    
frame=    3 fps=1.4 q=0.0 size=      13kB time=00:00:01.30 bitrate=  79.8kbits/s
...
frame=  404 fps= 12 q=0.0 size=    1814kB time=00:00:14.68 bitrate=1012.0kbits/s    
frame=  412 fps= 13 q=0.0 size=    1884kB time=00:00:14.94 bitrate=1032.6kbits/s    
...
frame= 3077 fps= 15 q=0.0 size=   12835kB time=00:01:43.87 bitrate=1012.2kbits/s    
frame= 3084 fps= 15 q=0.0 size=   12850kB time=00:01:44.10 bitrate=1011.2kbits/s    
 
As you can see (unless I'm way off in my interpretation), ffmpeg just never transcodes fast enough to actually provide the WebUI with a constant stream of data. I'm sure with some math we could figure out an expected frequency of pauses/stutters. It's basically buffering, but on the transcoding side. During this period, the CPU in the server never went above ~60% (rarely above 40%), so it doesn't seem to be a hard limit in terms of CPU cycles.

 

Recorded-tv:

 

Input #0, wtv, from 'file:\\WHS\Recorded TV\Worst Cooks in America_FOODHD_2015_01_25_20_58_00.wtv':

Stream #0:1[0xee]: Video: mpeg2video (Main), yuv420p(tv), 1920x1080 [sAR 1:1 DAR 16:9], max. 16000 kb/s, 29.97 fps, 29.97 tbr, 10000k tbn, 59.94 tbc

 

frame=    6 fps=0.0 q=0.0 size=      15kB time=00:00:01.26 bitrate=  94.7kbits/s    
frame=   16 fps= 16 q=0.0 size=      19kB time=00:00:01.60 bitrate=  95.2kbits/s    
frame=   25 fps= 16 q=0.0 size=      77kB time=00:00:01.90 bitrate= 333.5kbits/s    
...
frame=  405 fps= 21 q=0.0 size=    1849kB time=00:00:14.58 bitrate=1039.0kbits/s    
frame=  414 fps= 21 q=0.0 size=    1892kB time=00:00:14.88 bitrate=1041.5kbits/s    
...
frame= 2729 fps= 20 q=0.0 size=   12649kB time=00:01:32.12 bitrate=1124.8kbits/s    
frame= 2738 fps= 20 q=0.0 size=   12674kB time=00:01:32.42 bitrate=1123.3kbits/s   
 
Again, fps never catches up with the actual input fps. It's closer, and based on a subjective measure the playback on this was better than on live-tv. I'm also just realizing that since my Recorded-TV is archived to my server ("WHS"), which is where MBS is running, there's 1 less hop involved. However, based on the results of some later tests, I don't think network performance is the culprit.

 

Movie:

 

Input #0, matroska,webm, from 'file:\\WHS\Movies\Test Content\test.mkv':

Stream #0:0(eng): Video: h264 (High), yuv420p(tv, bt709), 1914x808 [sAR 1:1 DAR 957:404], 23.98 fps, 23.98 tbr, 1k tbn, 2k tbc (default)

 

frame=   32 fps=0.0 q=0.0 size=      26kB time=00:00:01.56 bitrate= 134.9kbits/s    
frame=   72 fps= 71 q=0.0 size=     265kB time=00:00:03.26 bitrate= 665.0kbits/s    
frame=  118 fps= 78 q=0.0 size=     506kB time=00:00:05.19 bitrate= 796.9kbits/s 
...
frame=  404 fps= 72 q=0.0 size=    1939kB time=00:00:17.08 bitrate= 929.8kbits/s    
frame=  430 fps= 71 q=0.0 size=    1999kB time=00:00:18.21 bitrate= 899.4kbits/s    
...
frame= 6710 fps= 79 q=0.0 size=   33059kB time=00:04:40.15 bitrate= 966.7kbits/s    
frame= 6754 fps= 79 q=0.0 size=   33283kB time=00:04:41.97 bitrate= 967.0kbits/s    
 
And here we see ffmpeg easily beating the input fps, >3x for the majority of playback. This content, as expected, plays perfectly.

 

 

Hypothesis:

 

What does all of this (maybe, possibly) mean? My best guess at this point is that the wtv and ts content is generally "harder" for ffmpeg to transcode to webm (and only webm). I'm not sure if this is a factor of the format itself, or that the wtv/ts content is that much higher quality over the wire (this seems to be discredited by the odd observation around m3u8 output seen at the end). In either case, it seems that the cause is inadequate performance from ffmpeg on these content types.

 

Test #1:

 

The most direct way of testing the hypothesis seemed to be manipulation of the "threads" flag. More threads = more performance = more fps = more good. The value set for all of the above samples was 5 (this seems to be MBS's default for transcoding content to webm (I have another observation I'll save until the end)). I was only able to do this testing with the Recorded-tv sample, since I wasn't sure how to change the setting in MBS for when it's handle the on-the-fly request for SWMC ts files. Caveat: this was not a scientific test. I ran each one a couple times to see if there were any major differences, in general they were pretty close. I ran each thread count for ~3 minutes  of input out of impatience more than anything.

 

WHS is running a Phenom II X6 1030T (6 cores). In all tests CPU usage hovered between 40% and 50%.

 

Threads = 0 (this is supposed to be "optimal", but I haven't read enough of the ffmpeg docs to know what that really means, maybe 1 thread per core):

frame= 1968 fps= 22 q=0.0 Lsize=    8696kB time=00:01:06.73 bitrate=1067.5kbits/s

 

Threads = 8

frame= 5412 fps= 23 q=0.0 Lsize=   22409kB time=00:03:01.64 bitrate=1010.6kbits/s

 

Threads = 16

frame= 5503 fps= 46 q=0.0 Lsize=   23494kB time=00:03:04.68 bitrate=1042.1kbits/s

 

Threads = 32

frame= 5443 fps= 55 q=0.0 Lsize=   23373kB time=00:03:02.68 bitrate=1048.1kbits/s

 

Threads = 64

frame= 5476 fps= 45 q=0.0 Lsize=   23425kB time=00:03:03.78 bitrate=1044.1kbits/s

 

I'm not sure if the 64 threads is indicative of diminishing returns, or an anomaly. I think the take away is that between 16 and 32 threads put performance above the fps "threshold". There was no discernible difference in CPU utilization above 16 threads.

 

Conclusion and next steps:

 

All of that to say, I think I can throw more HW (i.e. threads) at the problem on the MBS side and solve the problem. If there is a negligible resource utilization impact at 16 or 32 threads, then I'd just as soon default to that and have overkill on non-wtv/ts content.

 

So my question is, how would I go about doing that? Is there a setting somewhere in MBS that exposes the ffmpeg parameters being used for various content inputs/outputs? I did some searching on the forum and couldn't find anything that addressed this problem. My next steps (without input from devs more familiar with this aspect of things. @@Luke maybe?) is to try toggling some of the exposed Transcoding options to see what affect they have on the backend.

 

One odd observation:

 

As I was looking through transcode logs, I happened to open a recorded-tv transcode that was playing to my Fire HD7, so output was m3u8 (instead of webm). Performance of the transcode looked to be right at the fps threshold (and, if memory serves, playback was acceptable). Interestingly enough, it was using threads=0 instead of the 5 that the webm defaulted to. It also (partially) rules out the content quality being the difference between live/recorded-tv and movies.

 

My guess is that going from wtv -> m3u8 is "easier" than wtv -> webm? I certainly can't say that with any conviction, but my limited empirical data supports the claim. Would love to hear input on this.

 

Output #0, hls, to 'C:\Users\Administrator\AppData\Roaming\MediaBrowser-Server\transcoding-temp\streaming\f7ab97b0f48a5ac5f6ed3a7b0b6689ac.m3u8':

Stream #0:0: Video: h264 (libx264), yuv420p, 1920x1080 [sAR 1:1 DAR 16:9], q=-1--1, max. 3744 kb/s, 29.97 fps, 90k tbn, 29.97 tbc

 

frame=   11 fps=0.0 q=0.0 size=N/A time=00:00:03.05 bitrate=N/A    
frame=   31 fps= 30 q=24.0 size=N/A time=00:00:05.09 bitrate=N/A    
frame=   62 fps= 40 q=31.0 size=N/A time=00:00:06.14 bitrate=N/A    
...
frame= 5678 fps= 61 q=21.0 size=N/A time=00:03:13.45 bitrate=N/A    
frame= 5690 fps= 61 q=-1.0 Lsize=N/A time=00:03:14.39 bitrate=N/A   
Link to comment
Share on other sites

jlachesk

I did a bit more digging on the forum and found this thread/comment:

 

http://mediabrowser.tv/community/index.php?/topic/5213-trouble-playing-1080p-video/?p=163320

 

As suspected, the problem was ffmpeg performance; however, as @@mford noticed, the problem was that power management was holding the CPU speeds at ~1Ghz because of the relatively low load total. By changing the power settings to High Performance, I'm actually getting measurably better performance out of -threads 5 than I was out of 16 or 32. The individual core clock speed has a much bigger impact on ffmpeg performance than the number of threads (there may be a breakeven point, I'm not sure).

 

I don't have time to test actual playback on my Chromebook right now, so I can't be entirely sure this resolves the problem. At the very least, it appears to resolve it on paper. 

 

This still leaves me confused as to why the Macbook seemed to handle things just fine (I'll need to go back and retest to confirm). In the meantime, I may have a more readily available solution via Power Options vs. customizing the number of threads used by MBS (though that may still be a worthwhile addition at some point).

 

Power Option = High Performance, Threads = 5:

frame= 5602 fps= 62 q=0.0 Lsize=   22252kB time=00:03:07.98 bitrate= 969.7kbits/s

 

Edit: Using CoreTemp, I confirmed that even when running ffmpeg the core freq were pegged at the power profile minimum (5%, ~800Mhz) while in "Balanced" mode. Changing the profile to "High Performance" (even with the minimum changed to 5%) sees the cores spin up to 100% speed as soon as ffmpeg is started. 

Edited by jlachesk
Link to comment
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...