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.
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.
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)
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.
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 ?
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?
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.
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.
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.
