Need some computer hardware advice

Welcome to our community

Be a part of something great, join today!

It will only be running one piece of software

Unless it's a piece of software that has all the hardware device drivers needed to run on bare hardware, you still need an OS like Linux or Windows.

The OS provides access to the hard drives, user interface, network, etc.

I don't know how long your typical conversion process takes. If it is taking 3 minutes on an I7 6700 class CPU, it would likely take 30 minutes on an atom.

If the time doesn't matter and the price does, you can find ~$150-$200 priced NUC (similar 6x6x3.5" sized) systems with celeron, atom, etc.

6x6x3.5 is about the size of an apple magic trackpad. Smaller than a mouse pad (mat). Similar in size to Apple TV, Roku device, etc.
 
Amazon product ASIN B01K1IO3QW
Click on the image anyway, even if it's generic :)

upload_2017-1-11_15-15-32.png

$350, decent i3 cpu, small amount of RAM. You can open it up and upgrade to more RAM if you need it.
 
Amazon product ASIN B01K1IO3QW
Click on the image anyway, even if it's generic :)

View attachment 11816

$350, decent i3 cpu, small amount of RAM. You can open it up and upgrade to more RAM if you need it.

My uncle has a laptop very similar to that if not the same model, upgrading the ram and the HD to SSD was ridiculously difficult. If he wants to upgrade anything on that I strongly suggest getting something different. I've upgraded many laptops over the years, that was just stupid.
 
Unless it's a piece of software that has all the hardware device drivers needed to run on bare hardware, you still need an OS like Linux or Windows.

The OS provides access to the hard drives, user interface, network, etc.

I don't know how long your typical conversion process takes. If it is taking 3 minutes on an I7 6700 class CPU, it would likely take 30 minutes on an atom.

If the time doesn't matter and the price does, you can find ~$150-$200 priced NUC (similar 6x6x3.5" sized) systems with celeron, atom, etc.

6x6x3.5 is about the size of an apple magic trackpad. Smaller than a mouse pad (mat). Similar in size to Apple TV, Roku device, etc.

It's a live encoder for broadcasting
 
6"x6"x3.5"

If you don't need the power of an i7 6700, you an use ANY skylake 6th gen processor with 65 watts TDP or less.

That's what I'm trying to figure out...how much do I need. I have a piece of software I can test in a system but I'm trying to avoid testing every atom chip to see if it works.
 
I get that it's a live encoder.

Unless there's hardware support, an atom isn't going to encode a live stream very well.

The quality of the stream, resolution (e.g. 720p, 1080p, etc.), frame rate (60hz, 30hz, etc.), bitrate (2mb/sec, 10mb/sec, etc.). and the actual encoder type (h.264, AAC, etc.) determine the CPU needed.

This is from adobe's README about their Flash Media Live Encoder 3.2

http://www.adobe.com/support/documentation/en/flashmediaencoder/3/FMLE_3.2_Win_Read_Me.pdf

upload_2017-1-11_15-27-46.png

That should give you an idea.

If you want to do 720p, you need a fairly beefy CPU.

This link:

https://obsproject.com/forum/threads/best-pc-setup-for-1080p-60fps.28986/

upload_2017-1-11_15-32-19.png
 
I get that it's a live encoder.

Unless there's hardware support, an atom isn't going to encode a live stream very well.

The quality of the stream, resolution (e.g. 720p, 1080p, etc.), frame rate (60hz, 30hz, etc.), bitrate (2mb/sec, 10mb/sec, etc.). and the actual encoder type (h.264, AAC, etc.) determine the CPU needed.

This is from adobe's README about their Flash Media Live Encoder 3.2

http://www.adobe.com/support/documentation/en/flashmediaencoder/3/FMLE_3.2_Win_Read_Me.pdf

View attachment 11817

That should give you an idea.

If you want to do 720p, you need a fairly beefy CPU.

This link:

https://obsproject.com/forum/threads/best-pc-setup-for-1080p-60fps.28986/

View attachment 11818

Denny you know any hardware specialists? This actually runs at 720 on an iPhone but have been told it's not optimized for ARM processors. I know it will run on an i3 but haven't been able to nail down exactly how much processor is needed.
 
Denny you know any hardware specialists? This actually runs at 720 on an iPhone but have been told it's not optimized for ARM processors. I know it will run on an i3 but haven't been able to nail down exactly how much processor is needed.

720 at what bitrate?

What bitrate do you want it to be?

Here's an example of 720p @ 2mbit, 23fps:



I think it's just OK. Not very detailed, blurry, especially if the camera is moving/panning.

I don't know what your videos are of. If you're pointed at the beach, then low bandwidth, low framerate is ok.

If it's for a security camera, they do incredibly low framerate, like 4/sec.
 
720 at what bitrate?

What bitrate do you want it to be?

Here's an example of 720p @ 2mbit, 23fps:



I think it's just OK. Not very detailed, blurry, especially if the camera is moving/panning.

I don't know what your videos are of. If you're pointed at the beach, then low bandwidth, low framerate is ok.

If it's for a security camera, they do incredibly low framerate, like 4/sec.


I'm looking for 1080 60fps. It is for a new ip video compression that is very low latency. It compresses very well, much better then h.264
 
Unless you have some sort of hardware acceleration (custom chips, plugin board, etc.), the CPU has to do the encoding. The slower the CPU, the longer the encoding takes. If you're trying to encode a live stream at 1080p/60Hz/2mbit (which is worse than the above youtube video), and the CPU can only handle 1080p/60hz/1mbit, it's not going to work.

For video purposes, developers of the codecs are interested in fast decoding and are willing to encode something like a movie or youtube video on a workstation for as long as it takes. Real-time means you don't have the luxury of encoding for as long as it takes.

Ripping a 200 minute movie DVD, at best quality the ripper will do, on my iMac takes about 20 minutes. Or about 10x realtime. The CPU is 10000 PassMark. If you have a 1,000 passmark CPU, you can do it in realtime. 20 minutes x 10 = 200 minutes (original movie length). The encoding is m4v, and the quality isn't the greatest.

The CPU in the iMac is a quad core with hyperthreading, so it gets about 30% performance boost over just 4 cores. It can do up to 8 things in parallel, which may do even better for encoding video.

I don't think you want to be using 100% of the CPU 100% of the time to encode. You will certainly get glitches in the stream if the OS needs to do anything else (and it does).

The Intel Atom Z3735F @1.33GZ has a CPU mark of 908. Not good enough.

The Intel Atom D525 @1.80GHz has a CPU mark of 702. Even worse, though the GHz/clock rate is higher.

Here's a calculator you can use to figure out your hardware requirements:

http://www.luxriot.com/support/hardware-calculator/

Not sure if I trust it though.
 
Unless you have some sort of hardware acceleration (custom chips, plugin board, etc.), the CPU has to do the encoding. The slower the CPU, the longer the encoding takes. If you're trying to encode a live stream at 1080p/60Hz/2mbit (which is worse than the above youtube video), and the CPU can only handle 1080p/60hz/1mbit, it's not going to work.

For video purposes, developers of the codecs are interested in fast decoding and are willing to encode something like a movie or youtube video on a workstation for as long as it takes. Real-time means you don't have the luxury of encoding for as long as it takes.

Ripping a 200 minute movie DVD, at best quality the ripper will do, on my iMac takes about 20 minutes. Or about 10x realtime. The CPU is 10000 PassMark. If you have a 1,000 passmark CPU, you can do it in realtime. 20 minutes x 10 = 200 minutes (original movie length). The encoding is m4v, and the quality isn't the greatest.

The CPU in the iMac is a quad core with hyperthreading, so it gets about 30% performance boost over just 4 cores. It can do up to 8 things in parallel, which may do even better for encoding video.

I don't think you want to be using 100% of the CPU 100% of the time to encode. You will certainly get glitches in the stream if the OS needs to do anything else (and it does).

The Intel Atom Z3735F @1.33GZ has a CPU mark of 908. Not good enough.

The Intel Atom D525 @1.80GHz has a CPU mark of 702. Even worse, though the GHz/clock rate is higher.

Here's a calculator you can use to figure out your hardware requirements:

http://www.luxriot.com/support/hardware-calculator/

Not sure if I trust it though.

This is from the person who designed the video compression.

"There really are a few problems with ARM : The CPUs themselves are really not that fast. As an illustration, when you run the NDI reference code (i.e. optimized) on an Intel CPU it will run without threads at ~30fps. That same code runs at ~1fps when run an a Rasberry Pi. Obviously we optimized the Intel codec to run at about 250fps on a single core on Intel, so making it 10+ faster using assembly is clearly possible and I would expect the same thing to be possible on ARM if we use NEON."
 
This is from the person who designed the video compression.

"There really are a few problems with ARM : The CPUs themselves are really not that fast. As an illustration, when you run the NDI reference code (i.e. optimized) on an Intel CPU it will run without threads at ~30fps. That same code runs at ~1fps when run an a Rasberry Pi. Obviously we optimized the Intel codec to run at about 250fps on a single core on Intel, so making it 10+ faster using assembly is clearly possible and I would expect the same thing to be possible on ARM if we use NEON."

The atom is an ARM level processor. The celeron is slightly better. Then Pentium. If it were me, almost no matter what the application, the least I would want to use is i3. If you need lots of parallelism and not speed per core, then you can find ARMs with lots of cores. Apple's ARM chip they use in the iPhone 7 and iPad Pro is really fast. Faster than the Macbook with core m-5y31 (Intel).

The guy is saying he might get more speed out of the encoder IF they broke down and hand crafted the most CPU intensive part of the program in machine language (assembly). It looks like he hasn't done so. NEON is a special instruction set in some ARM CPUs that is optimized for audio/video encoding. It is a coprocessor on the same chip as the CPU. The guy is saying IF they use the NEON instructions, they can get better performance (I'm not sure what 10+ means, 10x and then some? 10% more?). But it appears like they don't use those.

Here's a CPU benchmark for encoding x.264. Looks like 1080p, but I didn't dig around to find the bit rate. Whatever the bitrate they use is, you can roughly do 60fps at half the bitrate with the CPUs on the chart that do 30fps.

http://www.anandtech.com/bench/CPU/54
 
Another benchmark from the same site (anandtech) with more detail about the encoding parameters:

http://www.anandtech.com/show/8067/...athlon-53505150-and-sempron-38502650-tested/3

Video Conversion - x264 HD 3.03 Benchmark


Graysky's x264 HD test uses x264 to encode a 4Mbps 720p MPEG-2 source. The focus here is on quality rather than speed, thus the benchmark uses a 2-pass encode and reports the average frame rate in each pass.

64176.png



64177.png
 
How can you use hardware to accelerate it? Quote from him below...

"The real answer however is that some of these CPUs might never achieve the performance needed for basically "uncompressed quality" video without HW assistance."
 
How can you use hardware to accelerate it? Quote from him below...

"The real answer however is that some of these CPUs might never achieve the performance needed for basically "uncompressed quality" video without HW assistance."

A second chip on the motherboard that specializes in encoding/decoding. Or a plugin board. Or special encoding/decoding built into some CPUs.

You CAN do encoding entirely with the CPU. If you record raw to disk, then run it through a compressor like handbrake, it might take 100 hours to compress/encode. But once it's compressed, you have your mp4 file or whatever that will play in real time on all but the slowest CPUs.

There are video capture boards that plug into a slot in a PC that will compress/encode video on the fly and the software writes it to disk files.

Something like this might work, too:

http://www.magewell.com/usb-capture-hdmi

(It's hardware assistance)
 
A second chip on the motherboard that specializes in encoding/decoding. Or a plugin board. Or special encoding/decoding built into some CPUs.

You CAN do encoding entirely with the CPU. If you record raw to disk, then run it through a compressor like handbrake, it might take 100 hours to compress/encode. But once it's compressed, you have your mp4 file or whatever that will play in real time on all but the slowest CPUs.

There are video capture boards that plug into a slot in a PC that will compress/encode video on the fly and the software writes it to disk files.

Something like this might work, too:

http://www.magewell.com/usb-capture-hdmi

(It's hardware assistance)

This is for live broadcasting so it will come from the camera into the box then out to a video switcher which will decode for the broadcast. Think a blazer game. I need the feed from the camera converted to this IP video codec (called NDI) to be able to broadcast during a live show. There is to much latency with h.264 to use in live broadcasts. This new NDI makes it possible.

It will not be recorded on the converter.
 
This is for live broadcasting so it will come from the camera into the box then out to a video switcher which will decode for the broadcast. Think a blazer game. I need the feed from the camera converted to this IP video codec (called NDI) to be able to broadcast during a live show.

It will not be recorded on the converter.

Trust me, I understand what you're trying to do.

When the video comes from the source into your new device, it has to be compressed/encoded NDI on the fly so it can be output to the switcher.


https://www.cpubenchmark.net/mid_range_cpus.html
(4000 passmark range CPUs)


The encoding takes CPU processing power. See the big text below. 30% of an i7 6700 for decoding (I assume encoding is even more). So you need something in the 4000 passmark range, at least.

The computer system I spec'ed out for you is an SFF PC. See the red text below.


http://forums.vmix.com/default.aspx?g=posts&t=7077

Is it GPU or CPU based?
NDI encoding/decoding is CPU based using around 5% per 1080p30 camera on a modern i7 CPU.

What color spaces are supported?
Frames are sent/received from NDI at 4:2:2 8 bit, but NDI compresses at 16 bit internally.
NDI also has full support for alpha, sent as a separate channel. (so 4:2:2:4)

Will there be converter boxes?
More than likely, possibly from more than one manufacturer.
We are working on our own prototypes using off the shelf SFF (small form factor) PCs, but
the codec can theoretically be used on devices as small as a standard HDMI to SDI mini converter.

The main advantage of one of these converters is you will no longer need a capture card
opening up most laptops to multi camera productions without the need for thunderbolt!

My hope is the converters will be affordable.

What is the stream bitrate?

To my knowledge it is variable bit rate.
I've seen around 50Mbps to 100Mbps per camera in my tests so far.

...

I think "around 5% per 1080p30 camera" was quite optimistic, my own experience is that NDI uses a lot more resources than a capture card input.
Martin told me at IBC the NDI version 2 will be better when it comes to resource usage.

...

It seems to me it's using 20-30% cpu of an i7 6700 per NDI source on decoding - not encoding.

I'm just wondering if there is anything i can do on the vmix machine to ease up the decoding ?
 
This is for live broadcasting so it will come from the camera into the box then out to a video switcher which will decode for the broadcast. Think a blazer game. I need the feed from the camera converted to this IP video codec (called NDI) to be able to broadcast during a live show. There is to much latency with h.264 to use in live broadcasts. This new NDI makes it possible.

It will not be recorded on the converter.

Didn't I win a Thunder arena football jersey from you years ago when you were broadcasting at that indoor bike place off of 82nd ave? Where is my jersey?
 
Trust me, I understand what you're trying to do.

When the video comes from the source into your new device, it has to be compressed/encoded NDI on the fly so it can be output to the switcher.


https://www.cpubenchmark.net/mid_range_cpus.html
(4000 passmark range CPUs)


The encoding takes CPU processing power. See the big text below. 30% of an i7 6700 for decoding (I assume encoding is even more). So you need something in the 4000 passmark range, at least.

The computer system I spec'ed out for you is an SFF PC. See the red text below.


http://forums.vmix.com/default.aspx?g=posts&t=7077

Is it GPU or CPU based?
NDI encoding/decoding is CPU based using around 5% per 1080p30 camera on a modern i7 CPU.

What color spaces are supported?
Frames are sent/received from NDI at 4:2:2 8 bit, but NDI compresses at 16 bit internally.
NDI also has full support for alpha, sent as a separate channel. (so 4:2:2:4)

Will there be converter boxes?
More than likely, possibly from more than one manufacturer.
We are working on our own prototypes using off the shelf SFF (small form factor) PCs, but
the codec can theoretically be used on devices as small as a standard HDMI to SDI mini converter.

The main advantage of one of these converters is you will no longer need a capture card
opening up most laptops to multi camera productions without the need for thunderbolt!

My hope is the converters will be affordable.

What is the stream bitrate?

To my knowledge it is variable bit rate.
I've seen around 50Mbps to 100Mbps per camera in my tests so far.

...

I think "around 5% per 1080p30 camera" was quite optimistic, my own experience is that NDI uses a lot more resources than a capture card input.
Martin told me at IBC the NDI version 2 will be better when it comes to resource usage.

...

It seems to me it's using 20-30% cpu of an i7 6700 per NDI source on decoding - not encoding.

I'm just wondering if there is anything i can do on the vmix machine to ease up the decoding ?

I continued reading that thread and saw this. Does that mean that encoding will take less then the 30% that decoding takes?




I just did a quick test.

VLC playback (not NDI) of a MP4 clip at 1920x1080@30fps uses about 5% of my laptop's i7 CPU
VLC with the NDI plug-in of same clip, uses about 8% of my laptop's i7 CPU.

NDI Monitor is using about 6% CPU to decode the NDI source.

Not saying that other applications won't be different as they might be doing much more than the above tools, but that is what I'm seeing in a simple test of encoding and decoding.
 
Didn't I win a Thunder arena football jersey from you years ago when you were broadcasting at that indoor bike place off of 82nd ave? Where is my jersey?

Haha...you might have. I still have some of those suckers. Worth big money now that they don't exist any more.
 
You can pick up an Ivy Bridge cheap on ebay and a 1155 socket board. too. I pick up a neat low power quad, I-5 3475 on ebay for $90. Works great on the boat, draws only 3 amps (12v) running 5 apps in the boat.
I picked up a brute of a xeon quad and stuck in a standard LGA 775 board modified with a patch to accept the Xeon processor. It uses a hell of a lot more power but I don't care at home.
I think I got the processor for 45 bucks.
 
I continued reading that thread and saw this. Does that mean that encoding will take less then the 30% that decoding takes?




I just did a quick test.

VLC playback (not NDI) of a MP4 clip at 1920x1080@30fps uses about 5% of my laptop's i7 CPU
VLC with the NDI plug-in of same clip, uses about 8% of my laptop's i7 CPU.

NDI Monitor is using about 6% CPU to decode the NDI source.

Not saying that other applications won't be different as they might be doing much more than the above tools, but that is what I'm seeing in a simple test of encoding and decoding.

Decoding is meant to be fast, encoding is what takes time.

You should encode something and report the % CPU used for that.

Like I said, my 10000+ PASSMARK iMac encodes 200 minutes of DVD in so-so quality in about 20 minutes. Maybe 25.

200 real minutes/20 minutes to decode = 10x realtime. In theory, the iMac could encode 10 streams at once to use 100% of the CPU. So the encoding is roughly 10% of the CPU.

To play back the video, the iMac uses 5% or less of the CPU.

The CPU requirements may be entirely different for NDI compression. This is m4v compression I did on my iMac. They are different software algorithms, so the CPU usage will be different.

Those are the kind of numbers you need to get to determine how much CPU you need.

Remember, you need to do 1080p @ 60Hz if that's the desired compression you want, as well as the desired bitrate you want.
 
I just built a new build with a 6700k (yes I know the 7000s just came out but this thing is still faster than anything besides the 7700k) 16 gbs of ram, and an ssd, and it's very fast. Now to download some games to benchmark.
 
I just built a new build with a 6700k (yes I know the 7000s just came out but this thing is still faster than anything besides the 7700k) 16 gbs of ram, and an ssd, and it's very fast. Now to download some games to benchmark.

giphy.gif
 

Users who are viewing this thread

Back
Top