Topic: i7-8700K for new Media Server? (Read 9678 times)

jmone · « **on:** October 12, 2017, 06:18:42 pm »

After playing with UHD BD serving/on the fly transcoding, it looks like my old i7-3770K is struggling to transcode even one H265 stream to DLNA devices without pauses. I've been thinking about upgrading for a while anyway and have been looking at what the most appropriate CPU would be. While the AMD Threadripper looks good with so many cores, it has a pretty modest frequency that will hinder single core processes.

I'm thinking the new i7-8700K with 6cores/12theads with stock 3.7/4.7 frequency looks like it could be a great option for a pretty good price.... or am I overlooking something?

Thanks
Nathan

PS - One downside is that availability seems to be non-existent.

RD James · « **Reply #1 on:** October 12, 2017, 09:23:14 pm »

I did some brief testing with my 3.9GHz R7-1700X (8c/16t), and HEVC streaming to my phone via JRemote results in as much as 75% CPU usage for high bitrate 1080p60 videos - but it doesn't drop frames. Seemed to be around 40-50% for 4K24, though these results varied quite a bit depending on the source.
Since the 8700K has fewer cores (6c/12t) but higher IPC and should clock higher, I'd expect it to be able to handle 1080p60, but perhaps closer to 100% usage.
It might be possible to stream 24 FPS content to two devices at the same time.

Threadrippers are basically two Ryzen CPUs stuck together, and I'd expect it to scale roughly linearly with number of cores.
One thing which may affect your decision is that both Ryzen and Threadripper can support ECC memory, while the 8700K does not.

It would be nice if Media Center supported hardware encoders.

jmone · « **Reply #2 on:** October 12, 2017, 09:41:08 pm »

Thanks RDJ - what GPU do you have in that rig (transcoding also uses the GPU).

RD James · « **Reply #3 on:** October 12, 2017, 10:50:44 pm »

It has a GTX 1070.
I would not have expected CPU usage to be so high if it was doing the transcoding with the hardware encoder/decoder on the card. Local playback of the same file is at 1% CPU usage.

RD James · « **Reply #4 on:** October 18, 2017, 01:59:39 pm »

Now that the Fall Creators Update is out, it's easy to check the video encode/decode engines.
Media Center's transcoding uses GPU-accelerated decoding, but only software encoding.

jmone · « **Reply #5 on:** October 18, 2017, 02:58:14 pm »

OK - I've have FCU for awhile (insider) and had been looking at the GPU as well as CPU Core usage in Task Manager / Resource Montitor, and on this rig neither were hitting 100% so I'm not sure what part was holding it back. Anyway, I've now ordered the i7-8700K and if the supplier is telling the truth I should get my parts next week

tyler69 · « **Reply #6 on:** October 18, 2017, 03:17:11 pm »

I have just built a client with a gtx1050ti and an Intel Xeon E3-1220 v6.
Any particular tests I that you are interested in?

jmone · « **Reply #7 on:** October 18, 2017, 03:20:29 pm »

The main 2 areas my current rig struggles with is:
- DeUHD Ripping : I only get 2MBsec ripping speed as it is single CPU Core bound (so Freq matters), and
- BD UHD Playback (Remotes) : It is not "fast" enough to transcode for realtime playback on Remotes.

tyler69 · « **Reply #8 on:** October 19, 2017, 02:02:00 am »

Hm, that I can not test as I do not have this tool. Would playback of some 4K Youtube videos (or any other freely available 4K videos) be benefitial?

jmone · « **Reply #9 on:** October 19, 2017, 02:10:02 am »

Thanks anyway - I have the parts arriving hopefully for the weekend so I'll know soon enough!

jmone · « **Reply #10 on:** October 20, 2017, 01:44:22 am »

No build this weekend

The i7-8700K arrived but who knows where the rest of the bits have gone too. The courier company certainly doesn't

tyler69 · « **Reply #11 on:** October 20, 2017, 04:54:05 am »

Aah, I feel for you. I‘m in a similar situation, however the hardware is mostly complete, just waiting for a riser. So I have a half built htpc running now 😄

RD James · « **Reply #12 on:** October 20, 2017, 10:46:30 am »

That's always the case with new builds in my experience. Not necessarily parts being lost in shipping, which is a headache, but something being out of stock or delayed that holds up the entire build.
I had to wait more than a month to get the ECC memory for my Ryzen build (2666MT/s ECC UDIMMs are/were rare) so I had to overnight some regular DDR4 as a temporary measure.
System was then down for a week or so recently waiting on an RMA due to the Ryzen segfault issue. (anything older than ~week 30 seems to be affected)

tyler69 · « **Reply #13 on:** October 20, 2017, 10:59:24 am »

I had luck until now. But then again, I buy/order hardware really seldom. I need to wait for 2-3 weeks now for the riser according to "googled" experiences with the shipping service. At least I can use MC

jmone · « **Reply #14 on:** October 21, 2017, 03:48:57 pm »

I ended up buying replacement gear as they work out what happened to the rest....anyway here is the build
- ASUS ROG Maximus X Hero MB
- Corsair H110i CPU Cooler
- G.Skill Trident Z 32GB (4x8GB) PC4-25600 (3200MHz) DDR4, 16-18-18-38-2N, 1.35v, Quad Channel Kit
- Samsung 512GB SSD, 960 PRO Series, m.2 (PCIE), Read up to 3500MB/s, Write up to 2100MB/s, Type 2280

I've posted some jmark in the benchmark thread and in the real world:

1) UHD BD transcode and stream to Remotes: Works fine on normal 23.976fps UHD BD

with the server just keeping ahead of the playback of the remote. Can not keep up with my (one and only) 60fps UHD BD even when OC'ed. I'm wondering if the bottle neck is ffdshow's encoding, the GTX960 or a combo of both

2) DeUHD Ripping: I've gone from about 2MB/Sec to 3.8MB/Sec so that results in a nice reduction in time. This single threaded app really likes extra CPU Freq.

Overclocking: The stock i7-8700K jumps to 4.7mhz on a core out of the box and I'd tend to recommend that it is pretty good as it is without stuffing around with OC (but where would the fun in that be). My OC efforts are as follows and at no point have a run into any issues with heat:
- ASUS OC Profile (Gaming / Video Editing): This OC both the CPU (4.99ghz) and the Memory, but was not stable under load (I think the memory profile causing issues).
- ASUS OC Profile (General): This OCed just the CPU (4.99) and is stable.
- Me randomly changing stuff: I don't know what I'm doing but got the CPU to x52 times and it would boot but not be stable for long under prime95

On my ToDo list is:
- See if I can get a OC Profile that is stable and will transcode and stream that 60fps UHD BD (doubtful)
- Work out if that OC that memory is really an issue or if it is the ASUS preset
- See if I can get the 110i cooler to stop "surging" when the Corsair Link program is running.

Advice or Questions welcome!

RD James · « **Reply #15 on:** October 21, 2017, 04:16:09 pm »

Quote from: jmone on October 21, 2017, 03:48:57 pm

1) UHD BD transcode and stream to Remotes: Works fine on normal 23.976fps UHD BD with the server just keeping ahead of the playback of the remote. Can not keep up with my (one and only) 60fps UHD BD even when OC'ed. I'm wondering if the bottle neck is ffdshow's encoding, the GTX960 or a combo of both

I think it's very unlikely to be the GTX 960 holding you back.
I find that streaming via JRemote seems to transcode in chunks of ~120 seconds and then waits for the buffer to almost empty before transcoding the next chunk.
As with memory playback in MC, it doesn't seem particularly well-optimized for slower connections/hardware, only streaming under ideal conditions.
I don't know why JRiver don't seem to care about this, while simultaneously pushing the idea that MC is for streaming all of your media to all of your devices.

jmone · « **Reply #16 on:** October 21, 2017, 05:01:32 pm »

I think the streaming works well. On my UHD BD, MC is adding to the Temp TS file in about 5sec lumps and it is keeping ahead of my Remote and playback is smooth and works.... just not for the 60fps UHD. The "High" Setting is transocoding to AVC/AAC 1280x720/30fps @ 2mb/s which is pretty OK for Remotes.

Also did some more tweaking, kept the ASUS stock CPU OC and turned on XMP profile manually for the Mem.
- JMARK of just over 7K
- Prime95 pushed all cores at times into the 90's but did not crash (only 30min test)
- While using MC to transcode/stream a UHD BD, DeUHD to rip (3.9MB/s) and doing the normal stuff it is all stable and Temps (even with the fans on Quiet) are mid 30 degrees with the cores that are being hammered by the single core processes jumping between 40-65 degress as I watch.

So all looks good with the exception of the 60fps UHD transcoding/streaming (and there is only one of these UHD discs in existence so far).

jmone · « **Reply #17 on:** October 21, 2017, 05:06:27 pm »

...also in checking the transcoded temp file, it is currently at 10min while the remote is at 6min in playback so plenty of buffering.

Hendrik · « **Reply #18 on:** October 21, 2017, 06:08:08 pm »

Quote from: RD James on October 21, 2017, 04:16:09 pm

I find that streaming via JRemote seems to transcode in chunks of ~120 seconds and then waits for the buffer to almost empty before transcoding the next chunk.

Your "information" is wrong, though. MC will always run the transcoder so that by default 50MB of data are available for streaming, and it won't do that in "chunks", but just keep that buffer filled, one frame at a time, to avoid using up the entire CPU for long periods (after the initial buffering) - this is important for running multiple transcodes for mutliple clients. Only when using HLS encoding its a bit chunkier since it has to process an entire HLS chunk at once, but those are only a couple seconds long, nowhere close to 120 (although depending on the read behavior of a client, it might do a couple more segments at once, as clients tend to "burst" those segments as well, and MC needs to catch up to ensure enough data is available at all times)

JRemote for Android doesn't need HLS encoding though and has a far better behavior due to it. Apple unfortunately is rather dumb when it comes to support for media formats.

RD James · « **Reply #19 on:** October 21, 2017, 06:54:53 pm »

Quote from: Hendrik on October 21, 2017, 06:08:08 pm

Your "information" is wrong, though. MC will always run the transcoder so that by default 50MB of data are available for streaming, and it won't do that in "chunks", but just keep that buffer filled, one frame at a time, to avoid using up the entire CPU for long periods (after the initial buffering) - this is important for running multiple transcodes for mutliple clients. Only when using HLS encoding its a bit chunkier since it has to process an entire HLS chunk at once, but those are only a couple seconds long, nowhere close to 120 (although depending on the read behavior of a client, it might do a couple more segments at once, as clients tend to "burst" those segments as well, and MC needs to catch up to ensure enough data is available at all times)

JRemote for Android doesn't need HLS encoding though and has a far better behavior due to it. Apple unfortunately is rather dumb when it comes to support for media formats.

Sorry if I'm wrong about that, I'm not trying to badmouth the program. It's what I often see when streaming video to my iPhone via JRemote if it needs transcoded.
It's rare that I can seek more than 2 minutes ahead of my current position (which is very frustrating if I want to resume a video I was playing elsewhere) and it often empties to <30 seconds or even plays "live" before the buffer starts to fill back up.
CPU usage on the server displays the same behavior of high load, no load, high load etc.

Hendrik · « **Reply #20 on:** October 22, 2017, 01:42:43 am »

You're not meant to be able to seek into the pre-buffer, its not designed for that. Seeking is handled differently. And like I tried to explain, with HLS it greatly depends on the read pattern of the client, ie. if Apple devices burst-read many segments for caching purposes (which some HLS clients do), then MC also has to burst encode a bunch of them. This entirely depends on the client behavior, which in this case is an Apple component, not JRemote itself.

jmone · « **Reply #21 on:** November 03, 2017, 12:52:35 am »

Swapped out the G.Skill ram for Corsair and it is now running XMP. Also tried a stronger GPU (1070 vs 960) to see if it would help with the transcoding / streaming of the UHD 4K/60fps but no real difference. The CPU core doing the trascoding is only sitting around 50% but it is just not generating enough frames (seems to be about 75% of real time needs)... and this is with me running @5ghz.

Hendrik · « **Reply #22 on:** November 03, 2017, 02:48:43 am »

Windows doesn't really show you proper per-core loads, unfortunately. A single thread running at 100% of one core would not show up like that in Windows.

tyler69 · « **Reply #23 on:** November 03, 2017, 04:21:02 am »

Hm, it shows 100% CPU usage for me when I play a movie to Panel on another client.

RD James · « **Reply #24 on:** November 03, 2017, 11:10:15 am »

Quote from: Hendrik on November 03, 2017, 02:48:43 am

Windows doesn't really show you proper per-core loads, unfortunately. A single thread running at 100% of one core would not show up like that in Windows.

Process Explorer can give you per-thread CPU utilization.
With 16 available cores, 6.25% would mean a core is fully-loaded.
Of course you can't guarantee how threads are distributed, but total CPU usage here was only 45%, streaming a 1080p VC1 movie to my phone, so it's unlikely that a core was fully loaded. (at least Process Explorer's per-core usage never reported anything close)

jmone · « **Reply #25 on:** November 03, 2017, 03:19:32 pm »

I can also see core utilisation in Intel OC App (XTU). Regardless, it looks (at least for now) that no amount of HW can do do real time transcoding of 4K/60fps material using the current streaming profile (or am I wrong).

RD James · « **Reply #26 on:** November 03, 2017, 09:38:17 pm »

Quote from: jmone on November 03, 2017, 03:19:32 pm

I can also see core utilisation in Intel OC App (XTU). Regardless, it looks (at least for now) that no amount of HW can do do real time transcoding of 4K/60fps material using the current streaming profile (or am I wrong).

I haven't run into issues caused by the CPU/encoder on my 1700X system, but CPU load varied quite a bit depending on the source. I'd be very surprised if an i7-8700K can't handle it. Is this a source you can link to?

JRemote often does bug out when streaming long videos after 5-10 minutes of playback and I have to play around with seeking to get it to resume, but that's on JRemote's end and happens no matter the source/resolution. It's nothing to do with the buffer running empty.

jmone · « **Reply #27 on:** November 04, 2017, 11:22:33 pm »

Here is a sample that is similar for my 4K 60fps UHD. Shows the same issue of the transcoding/streaming not being fast enough (it is a 1GB download).

http://4kmedia.org/sony-camping-in-nature-4k-demo/

RD James · « **Reply #28 on:** November 05, 2017, 01:52:17 am »

Quote from: jmone on November 04, 2017, 11:22:33 pm

Here is a sample that is similar for my 4K 60fps UHD. Shows the same issue of the transcoding/streaming not being fast enough (it is a 1GB download).
http://4kmedia.org/sony-camping-in-nature-4k-demo/

Since that's HEVC+AAC, JRemote (iOS) just streams it instead of having the server transcode it.
It does not stream smoothly for me though - it hitches up maybe every 15 seconds or so even when I'm right next to the router on a 5GHz network.
JRemote's video playback has had a lot of problems for me for a while now, but it's not related to transcoding on the server.

jmone · « **Reply #29 on:** November 05, 2017, 02:10:11 am »

Unless I'm a complete NooB- all video is being transcoded (only Audio has a native mode). Have a look in the C:\Users\[USERNAME}\AppData\Roaming\J River\Media Center 23\Temp folder. When playing a video using JRemote you will see a new folder created (eg mine is 12688) and in that is a VideoStream.ts file that is the transcoded file used for streaming. This file is AVC/AAC but at 1280*720@30fps and at a bitrate of about 3MB/Sec (when JRemote quality is set to High for Video). This file is not generated quickly enough to support real time streaming.... so you get pauses etc.

jmone · « **Reply #30 on:** November 05, 2017, 02:23:10 am »

...also double checked in HWiNFO64, during this process you can see one thread jump to around 50% (on my OC 5ghz 8700K).

Hendrik · « **Reply #31 on:** November 05, 2017, 02:29:59 am »

Streaming to JRemote on Android behaves quite differently then to iOS, due to the limitations of the iOS ecosystem. Android should be far more reliable, at least I never have problems with watching streamed/transcoded videos on my tablet.

jmone · « **Reply #32 on:** November 05, 2017, 02:55:49 am »

I'm streaming to Android (JRemote). Hendrik does that test clip stream for you without pauses? I did also try to push my CPU (upped to 5.1 no AVX Offset and while it did help it was still not enough....+ at these freq I'm not stable when stress testing so it is just an academic exercise). I'm at the conclusion that the current library is just not efficient/fast enough to transcode/stream such content.... the good thing is I have only one disc like this!

Daydream · « **Reply #33 on:** November 05, 2017, 12:48:13 pm »

Just offering some data from my end. I can stream the Sony Camp video to an iPad Pro with no transcoding, on a 5GHz AC network. No CPU Load, no temp files, 7-15MB/s feed.

Sony camp is ~79Mbps, HVEC, 60FPS and I have it in mp4.

I tried LG garden demo, which is 125Mbps, H264, 24FPS and I have it remuxed in mkv. MC made quick work of it, with an average ~40% CPU load (spikes 60%) and finished transcoding way ahead of the clip finishing. On a Skylake 6700K. The temporary attached GTX 950 was maxed out during this.

If I try an HVEC file in mkv to force the transcoding - say, LG Colors of Journey HDR UHD 4K Demo - the results are all over the place. The CPU usage is 20%, the GPU usage is 40-60% and the video feed has long pauses, waiting. Why I have no idea (this is on MC22, because, well, reasons).

I'm new to anything remote. Is JRemote platform dependent ref. what it streams vs transcoding (regarding containers & codecs)? Can we have any reasonable expectations to not be anymore, in the future?

INTERACT FORUM

Author Topic: i7-8700K for new Media Server? (Read 9678 times)