[noggin]

Gigabyte J1900 already available. Lots and lots of connectivity (4xUSB3.0, DVI, VGA2560x1600, 2xUTP, S/PDIF even 2xSerial and 2xPS2).

So what is missing? straight hmdi...If only...

http://hexus.net/tech/news/mainboard/663...therboard/

How do these CPU compare to the Celeron 1037?

J1800 doesn't support SSE which mean no hardware decoding for videos. But then again, I'm no expert and I may be wrong.

SSE is not the same as hardware decoding...

The N2820 Bay Trail does have hardware VAAPI decoding for the same types of video that most other GPUs accelerate (standard H264, MPEG2, VC-1 (*) etc.). (Like most other solutions there isn't hardware acceleration for the less widespread formats like Hi10p H264 and 4:2:2 H264 - and these will be software decoded. AIUI The N2820 is quite a low power, Atom-based but Celeron-branded CPU in comparison to more standard, and powerful, Celeron offerings like the 1007, 1037U and 2955U. (Passmark for N2820 is 1048, for 1007U is 1442, for 1037U is 1750, for 2955U is 1531 - so you can see the 1037U is 70% faster than the N2820 in CPU terms using Passmark)

However Intel drivers in Linux have lots of bugs, particularly around de-interlacing. The OpenElec devs produced some builds with Bob hardware de-interlacing (as well as some with more advanced de-interlacing like Motion and Vector Adaptive). However these were really unreliable across various processors, because of the buggy nature of the Intel Drivers AIUI.

So the developers took a different tack, that of VAAPI hardware decoding of the video codec, but software de-interlacing of the decoded video. So the H264/MPEG2/VC-1 encoded video is decoded in hardware, but the CPU then takes over to handle de-interlacing.

De-interlacing is pretty processor intensive (it's actually doing something quite complex) but the OpenElec guys have optimised the de-interlacing code to take advantage of modern CPU features that make computation faster, like SSE, allowing a Yadif 2x de-interlace to be done very efficiently.

"Normal" Celerons like the 1007U, the 1037U, the 2955U support YADIF 2x software de-interlacing with VAAPI decoding. (My 2955U Chromebook and my 1007U Revo RL80 are both fine with 1080/50i broadcast content like Live TV) However the N2820 doesn't have the processing power (maybe it has different optimisations that can be exploited? It looks as if the new Atoms - sorry "Celerons" - have had Hyperthreading removed now that they support out-of-order execution, and that they have a new SSE implementation?)

AIUI the 1007U is probably the base processor for OpenElec if you want 1080/60i de-interlacing (the 847 can just about do 1080/50i I believe - but the extra 10fps needed for 60i push it over the edge?)

I stress - this is related to de-interlacing in software, not video decoding in hardware. It's not relevant to 1080p or 720p content codec using standard H264 profiles and levels.

(*) There is also an issue with interlaced VC-1 content on Intel hardware I believe - which means that software decoding is better for this. I'm not sure what the base level of hardware required is. Hi10p stuff is always software decoded. AIUI the 1037U is fine, the N2820 struggles.