Recommend me A fast 1080p Transcoding NAS

Something to keep in mind, I assume you are using the default h.264 options. Cranking quality can make a big difference, as well as file size. Just thinking about the i7-4790 rates...

Under .10.1 with my i5-3570 cranked to 4GHz, I pump out around 8-10FPS with my current very high quality settings for 1080p to 1080p encodes. Of course I can turn it down and a 480p to 480p is well up in to the several hundred frames a second range. I have pretty exacting demands for quality as well as compressed size.

That is with NR turned off BTW (which I only use for really noise source material with a ultra light or light NR pass. That can take things down to 4-6FPS with NR on. I shudder to think what 4k to 4k would be. I'll need a Canonlake-E octocore processor to even think about it with my kind of settings...let alone h.265 *sob*)

azazel1024 said:

Something to keep in mind, I assume you are using the default h.264 options. Cranking quality can make a big difference, as well as file size. Just thinking about the i7-4790 rates...

Under .10.1 with my i5-3570 cranked to 4GHz, I pump out around 8-10FPS with my current very high quality settings for 1080p to 1080p encodes. Of course I can turn it down and a 480p to 480p is well up in to the several hundred frames a second range. I have pretty exacting demands for quality as well as compressed size.

That is with NR turned off BTW (which I only use for really noise source material with a ultra light or light NR pass. That can take things down to 4-6FPS with NR on. I shudder to think what 4k to 4k would be. I'll need a Canonlake-E octocore processor to even think about it with my kind of settings...let alone h.265 *sob*)

Click to expand...

Feel free to PM me your configs - would be interesting to see with similar source files the delta between an i5-3570 and the i7-4790 - they're clocked pretty similar, but HSW brings a bit more resources to the considerable amount of CPU on the IVY i-53570... but we're getting off-topic with the OP's original question

I was just sharing the 2957U to show what QSV brings to the table to answer the realtime advantages...

azazel1024 - got your PM - check my replies - shared my settings and reference files... something's odd with your framerates, but this isn't On the Fly rates at this point, so very much off-topic (if folks want to know, speak up and we can share findings)

Anyways, hope my hints help...

I recommend this transcoding NAS: NONE.
Rather, do it in batch on a fast PC.

stevech said:

I recommend this transcoding NAS: NONE.
Rather, do it in batch on a fast PC.

Click to expand...

but when using xbmc or plex it is easier to through the 1080p to the NAS and let it do the work passing it to the TV , instead of keeping my Mac CPU busy transcoding

easy = $$$

I think what it comes down this - one can have a decent BitRate file in the shared folder, and for this use case, depending on the client - tablet/desktop/smartphone/set top box - on the fly transcodes do relieve the storage pressure, along with the time/energy to be specific to the client type...

If the NAS box has the function, it's all good, esp. if it doesn't impact performance of the other functionality... e.g. workflows, file sharing, and backups...

Do you mean transcoding in advance? If I had kept all of the BR and DVD source (well, I have the physical disks) I'd probably be looking at something like 8-12TB of required storage. Since that is mirrored 3 ways, that is a LOT of expensive storage. Like $1,000-1,500 in storage.

Since I did transcode in advance, it only takes up about 2TB of storage (about 2.7TB for everything I have, but 700GB is non-video).

Granted, dropping an 8GB 1080p file on my phone would be not fun, or even on my tablet. On the other hand, my primary storage is massively smaller. No issues streaming within my house to my phone, tablet or Apple TV. So no worries about client device side storage. If I want to take something on the go...now THAT can be an issue. However, you aren't transcoding on the fly there at all. Then again, an 8GB 1080p, or 3GB 720p or whatever is a lot more portable then the BR source that might be 25-50GB. If I really, really needed something smaller for my phone or even tablet for on-the-go, I could quick run the larger file through handbrake with QSV with some nits turned up to increase compression some, and probably halve the file size/drop resolution in a few minutes and then load it up on my device.

If I wanted to watching things remotely over the internet, now THEN transcoding on the fly could be really useful. But I basically have zero use case for that.

Azazel and I have been discussing things on side-bar for transcoding and whatnot with regards to h264 performance on SandyBridge/IvyBridge/Haswell, on both QuickSync (which is very fast) and transcoding on the CPU...

Took me awhile to sort this, as Baytrail-D was just jamming on task that an i5-4260u was working hard at (the 4260u is Hawell-ULT on a Macbook Air 2014 at 1.4GHz)... I even dual-booted it into Win7Pro to use the QSV driver, and still...

Then I saw this little note - http://lists.freedesktop.org/archives/intel-gfx/2014-October/053546.html

Well documented that the Baytrail-D Chip (J1800/J1900) has Intel Gen7 graphics (4 EU's) that support QSV. Which explains much, but not all...

This, QSV, we've all discussed on the thread so far, but Baytrail-D also has, which the big-cores (IVB/HSW/SNB) lack, an Imagination Technologies VXD392 decoder block, which by itself, can do one h264 1080P/60FPS stream (or two 1080P/30FPS streams) on it's own... it's a beast, and a functional block we see in a lot of ARM cores targeted towards SmartPhones and Tablets, mainly for playback.

Now it all makes sense... some folks had claimed that QNAP had some special silicon on the board to do the high bitrate stuff, but actually, it's a functional block on Baytrail-D.

Clever

that is pretty cool sfx200 and very useful info. indeed , many thanks

kamin99 said:

that is pretty cool sfx200 and very useful info. indeed , many thanks

Click to expand...

Well, I feel kinda dumb, as I should have known better...

I was in a few meetings over in the Noyce bldg, mostly on the Atom Z variant for mobiles/tablets/UMC's, but I was focused on portability so Diamondville (e.g. N270) was more interesting to me...

The GPU on the Z-chip wasn't very interesting at the time as it was closed source, and that was a problem for Android 1.6 (Cupcake), which, at the time, I was porting over to x86.

Moblin/Meego, Intel provided the blobs for the GPU on the Crown Beach SDK...

Sorry for missing this one folks...

sfx

One of the things that does bug me a bit, is that chipmakers/ODMs/OEMs are bit obtuse on actual capabilities of their various chips in terms of video decode, either fixed function and/or direct CPU lifting.

1080p60 is nice to know...but the question is, at what profile is it capable of that. These days I don't worry about it to much, but just a couple of years ago looking at hardware, I'll grant I transcode with some wicked high settings (think high profile, but then turn on all of the other switches and knobs that existing in h.264) and I've managed to get noticeable frame drop in chips that supposedly supported 1080p30 high profile, when playing back 1080p24 content (and it wasn't an error in the 23.927 or whatever frame rate it is that movies are actually encoded in that a handful of chips have issues with, as it would play back 1080p24 content encoded at regular high profile settings okay).

My concerns is primarily once h.265 starts hitting mainstream as I'd bet the first few years of chips with h.265 decode engines aren't necessarily going to be as up to snuff as manufacturers claims (we can do 4k30 single stream playback of h.265 content*! Aren't we awesome! *Please note, 4k30 h.265 medium high profile settings, not the highest profile. Good luck with that).

This might solve part of the question - this is a Atom Z3735F - basically a tablet focused processor...

4 core Silvermont, about half the speed of a J1900, and it's transcoding a 1080P-60FPS stream in real time on Handbrake, using H264-QSV as the destination codec...

See the CPU utilization - pretty remarkable - this is using one of the Big_Buck_Bunny reference files - this one is their 1080P-60FPS version...

Just goes to show that fixed function logic blocks can be pretty darned awesome.

At some point it would be nice to see dedicated low-cost logic blocks for h265/hevc encode/decode - starting to see h265 decode on arm, but not sure if this is at a logic block level, or via GPU, same with x86 on AMD/Nvidia/Intel on more recent chips, again, mostly for decode, again, looks like it's more on the GPU shaders than a functional block...