Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mattkhan]

I run a dual core haswell cpu in my jriver machine. As I understand it, streaming a BD to gizmo is a CPU only operation for the transcoding. The cpu profile I see is that of x seconds at 98-99% cpu utilisation then y seconds at 1-2%, the values of x and y seem to vary according to the quality option on the gizmo device. For example, it's about 35 and 20 on high quality & 10-15 and ~40 on low quality. This looks like jriver is periodically writing a buffer that then gets streamed down to the client & I imagine these are the seg*.ts files that get written to the temp dir.

My question has a few aspects which are all driven by thoughts around provisioning a single box that can be used by multiple clients simultaneously & whether I should

1) what is driving this load? it behaves something like "when buffer size < x then fill buffer to y (where y > x)"
2) if I have put more cores in this box (e.g. switch to a core i7) then will I just get shorter spikes of a similar intensity? i.e. the box will still periodically crank up to 100% cpu
3) is there any way to place limits around the resources consumed by certain activities? for example, can you put the media network bit in a separate resource pool to that used by the media player? (no idea if this is possible in windows 8.1 anyway, thinking in terms of a docker/lxc style container). Alternatively is jriver meant to be doing this itself (e.g. is it telling the OS these jobs are a lower priority and it just looks like jriver is caning the CPU because I'm not doing anything else at the same time)

[mwillems]

You are correct; it's transcoding a buffer and then streaming until it needs to transcode some more.   You can demonstrate something similar by using JRiver to convert the format of a video file triggering "pure" transcoding without streaming.  Under those circs IME the processor usage just goes to 100% and stays there until the job is done.  I have an i7 and I get max CPU utilization whenever transcoding is happening (whether periodically while streaming, or steady state while converting videos); it just takes less time to do it than it does on my i5.

In my experience JRiver is generally pretty "smart" about the loading, in that if other things are going on simultaneously JRiver doesn't seem to "steal" CPU priority from other processes (it's "nice" in the Linux sense).  It just seems to use whatever it can get it's hands on when it needs it.  For example, I often use convert format for transcoding while doing other things on the computer and listening to music at the same time.  The CPU will be completely pegged, but music playback and web browsing will be just fine.  I haven't tried running it up against other processor intensive tasks, but regular music playback (with convolution) and general web browsing type activity seem unaffected (at least on my i7, I don't use my i5 as a workstation).

What I haven't tested is what happens when multiple Gizmo clients try to make demands at the same time (i.e. how well does JR prioritize multiple transcoding requests).  I have no idea how to control/dock resource availability on a windows box, but am interested if anyone here does.

[mattkhan]

OK thanks for the info. It sounds like switching to a beefier CPU will be a sensible upgrade if I want to stick everything on windows. The other option I was thinking of was sticking jriver linux in a VM on my server and then using that for streaming duties (assuming that is now supported on linux given that it has video?)

[mwillems]

OK thanks for the info. It sounds like switching to a beefier CPU will be a sensible upgrade if I want to stick everything on windows. The other option I was thinking of was sticking jriver linux in a VM on my server and then using that for streaming duties (assuming that is now supported on linux given that it has video?)

To my knowledge transcoding is not supported on Linux yet; it can only currently serve video content "as is."  That may change soon, but I have no sense of where that is in the pipeline.  You could probably apply the same method to windows though (put windows in a VM and fence it's resources).

The rule of thumb I've seen is that a PC needs a passmark CPU benchmark in the 2000-3000 range to transcode a single 1080p stream in real time.  So if you were creating a server device that will do nothing else, you'd want to have a benchmark in the range of 2500 * the number of clients you plan to serve at any one time plus a little overhead.  I don't use my server for transcoding much (most of my clients are instances of JRiver), so my server box is currently an i5 with a benchmark in the middle 3000's which is enough for occasional streaming to a single tablet with some horsepower to spare.  Almost any modern i7 (other than U or Y series chips) will get you into 7000's easily, and over 10k for a bit more.