[fritsch]

Too late to the party: http://www.computershopper.com/computex-...l-braswell <- seems zotac is planning one, too.

That would be a passively cooled N3150.

[fritsch]

Those we already had, right? http://androidpcreview.com/just-announce...i-pc/3063/

[afremont]

Today I purchased a NUC5PPYH. I got it locally for $170. I'd have gone with the Celeron CPYH, but I wanted to see if it's capable of being a decent MythTV back-end as well as a Kodi front-end box. I went with a Crucial 4GB DDR3L 1666 stick ($24) and a PNY Elite Performance 64GB SDXC ($30) that claims up to 90MB/S transfer rate, we'll have to see how that really works out with hdparm testing. I already have a spare 250GB 2.5" laptop drive (toshiba) so I won't be buying an SSD as I have to keep the cost down. I plan to use the SD card for the Kodi (OE actually) install and the hard drive for MythTV (likely Mythbuntu).

The CPYH would have been $40 less and would put the whole bill, including tax, under $200, but I just feel like the extra 2 cores and GPU EUs are worth the $40. Maybe they're not, but I'd rather have overkill instead of incapability. I would prefer two memory slots though.

I couldn't seem to find any of the other 4" boxes locally, and I don't want the size of an itx setup. I really like how compact these little boxes are. I plan to use it as a demonstration device for potential cable-cutter customers. I like to use HDHomerun network streaming TV tuners so I don't need any room for a tuner card in the box itself. I love the idea of built in wifi and an IR receiver that will work with Kodi.

I downloaded OpenELEC Isengard Beta 5.95.5 (x64) and after several times of it hanging at 25-28%, I went to get my daughter from the school bus. While I was gone, I guess it managed to successfully install itself to the the SDXC flash card. Go figure. :? I'm using a wired network connection for the time being, but it does seem to see the wireless fine. I was able to enable passthrough audio, but I haven't really tested it yet as I have it hooked to an HDMI monitor instead of my AVR. It doesn't seem to see my media-center type remote control yet. I'll worry about that later though.

Now, for the key things, let's start with the video. I left all the acceleration defaults on, and I noticed some jerkiness with a 1080i live TV broadcast. I disabled the VDPAU stuff, and it looks a little better using only VAAPI settings, but it is using a lot of CPU and experiencing some jerkiness and stuttering. The CPU speed is maxing out at 2500MHz according to /proc/cpuinfo. top shows the kodi app using 25-30% which seems way too high for this beast of a processor since the RPi2, uses less than 10%. I'd ask for help on that, but that probably warrants creating a new thread somewhere else. I only intended to give my first impressions here.

I am impressed with the GUI smoothness and responsiveness, this is obviously a much more powerful CPU than the RPi2.

I hooked it to my AVR, and I'm not getting any video out of the HDMI output for some reason. Just discovered that there is no config.txt file to force the HDMI on like the ARM versions of OE. Time to start struggling and learning again. Sorry if this was too far off topic for this thread. I was hoping to end the debate about HD audio, but first I have to get video working and then properly accelerated. Maybe I should be using another build of OE?

[afremont]

Okay, back with some audio passthrough results now. I can confirm, that with OE Generic 5.95.5 Beta, that I have good passthrough with DD 5.1 (from live TV), DD+ 7.1, TrueHD 7.1 and DTS Master 7.1 using my Onkyo AVR. Real honest to goodness passthrough (without conversion) via the HDMI cable. I downloaded the test clips from http://www.demo-world.eu/2d-demo-trailers-hd/

My prior video problem was with the HDMI cable. It worked fine with a monitor, but wouldn't work with my AVR at all. It wasn't OE, but the whole box since I couldn't even see the boot info that shows before OE loads. Still don't have the IR working with my media center type remote that I use with my RPi2. That's another problem though.

I'm still concerned with the live TV playback of MPEG2 not appearing to be accelerated by the hardware. MP4 seems to work, but I didn't check the CPU usage when I was playing the audio test videos.

I tried the latest Fritsch build of OE, but my MythTV PVR client wasn't compatible so I couldn't test the MPEG2 decoding with it. I just pasted the tar file into the updates folder and fell back to the 5.95.5 Beta of Generic OE.

So far, I'm impressed with this little box. It's quite snappy for such a puny thing. Granted it's quite a bit larger than a RPi, it also has room for a 2.5" HD inside plus it already has the wifi, bluetooth and IR devices too.

[fritsch]

Try to update to: http://fritsch.fruehberger.net/openelec/...f7773d.tar (Isengard based)

and read the second post of: http://forum.kodi.tv/showthread.php?tid=231955 concerning the autostart.sh change.

It's fully clear that mainline beta version is not even comparable as fast as those tech demos. It needs to copy every single frame and bands the colors on top ...

[afremont]

Thanks for the reply. I put on the upgrade that you recommended and it appears that MythTV PVR Client is working okay. I also created the autostart.sh script and set the permissions to 755. I'm still seeing jerkiness with MPEG2 live TV programs. It's really noticeable with 1080i video containing any kind of marquis scrolling across the display. I've tried the various sync playback to display and adjust refresh rate settings, but they don't seem to help. Adjusting refresh rate with my home theater setup (Optima projector and Onkyo AVR) causes black screens while things try to adjust. It's very disruptive. I get the same thing with the Raspberry Pi too when I enable adjust refresh rate. Sync playback to display results in immediate audio/video sync problems.

Interestingly enough, disabling the acceleration button for Use MPEG-2 VAAPI results in much smoother playback and cuts the CPU usage to approximately 13% instead of more than 25%. The CPU cores are also throttled back to about 2GHz maximum instead of pegging at 2500MHz. hmmmmm.. It would appear that VAAPI is having some trouble with MPEG-2 interlaced video (maybe all video, but interlaced is all I've really tested so far).

[afremont]

In case you're interested in seeing them, here are some debug logs
This is the one with MPEG2 VAAPI disabled. Everything looks good, audio/video in sync and passthrough is good. Total CPU from OSD is 55.72%. All cores running between 1500MHz and 2000MHz.
http://sprunge.us/VUPb

Here is a log with MPEG2 MPEG2 VAAPI enabled, twitchy video Total CPU from OSD is 124%
All cores running between 2000MHz and 2500MHz.
http://sprunge.us/QejG

Hope this helps. I'm good with disabling the acceleration for MPEG2. I have to admit, I like seeing my useless passthrough lights, especially since it all seems good with sync and smoothness. I'm pretty picky and usually notice subtle issues. I'm not noticing anything odd with the adjust refresh rate and sync to display disabled, at least so far anyway. Thanks for all your hard work on this.

Should I create another thread in the forum support area to talk about this? I feel like I'm hijacking this thread.

[fritsch]

Try this sample and post a Debug Log

http://solidrun.maltegrosse.de/~fritsch/...samples.ts (mpeg-2 is my primary SD TV use case - without any issues).

[afremont]

Here is the log with MPEG-2 VAAPI disabled:
http://sprunge.us/KgHE
Total CPU-KODI about 40%
and here it is enabled:
http://sprunge.us/HKeU
Total CPU-KODI about 30%

Looking at /proc/cpuinfo, the cpu clocks are slower with it enabled which would seem to indicate that it works as one would expect. I do notice that your video is not interlaced and is of lower resolution than the live TV which is full 1080i (1920x1080).

When I try a 720p channel (1280x720) I get results like you would expect; enabled it uses less CPU than disabling MPEG-2 VAAPI acceleration. This, in my limited experience, seems to indicate that interlaced video is not benefiting from enabling the hardware VAAPI MPEG2 decoding. With 1080i video, enabling MPEG-2 VAAPI results in poor performance with twitchy video that speeds up and slows down a bit.

I will record some 1080i broadcast and try the recorded file to eliminate the PVR client as being a potential source of the problem. If I still experience it, I will upload a sample of 1080i US broadcast video that you can play around with. It may be a few hours before I can do that though as I have some other life things to deal with right now.

[fritsch]

My video is interlaced. I hope - you use the following settings:

Video -> Acceleration:
VDPAU: off
VAAPI: on
VAAPI-Mpeg2: on
VAAPI-VC1: on
Prefer VAAPI Render: on

And when playing a video:

Deinterlacing: Auto (never set this to ON)
Deinterlace-Method: VAAPI-Motion compesnation (*)

-> Save for all movies.

(*) By default here the Auto setting would copy the decoded content back to system memory and then do OpenGL deinterlacing, which costs additional performance. But as VAAPI-BOB, VAAPI-MADI, VAAPI-MCDI were broken on SNB, IVB in the past - we chose Auto here.

Edit: From your log

09:08:29 T:140457174628096 DEBUG: ffmpeg[7FBEBBFFF700]: [src] w:1920 h:1080 pixfmt:nv12 tb:1/1 fr:0/1 sar:1/1 sws_param:
09:08:29 T:140457174628096 DEBUG: CFFmpegPostproc::Init - skip deinterlacing

You additionally use the ffmpeg yadif postprocessing which is fully CPU bound. So that explains your load.

[afremont]

My video is interlaced. I hope - you use the following settings:

Video -> Acceleration:
VDPAU: off
VAAPI: on
VAAPI-Mpeg2: on
VAAPI-VC1: on
Prefer VAAPI Render: on

And when playing a video:

Deinterlacing: Auto (never set this to ON)
Deinterlace-Method: VAAPI-Motion compesnation (*)

-> Save for all movies.

(*) By default here the Auto setting would copy the decoded content back to system memory and then do OpenGL deinterlacing, which costs additional performance. But as VAAPI-BOB, VAAPI-MADI, VAAPI-MCDI were broken on SNB, IVB in the past - we chose Auto here.

Edit: From your log

09:08:29 T:140457174628096 DEBUG: ffmpeg[7FBEBBFFF700]: [src] w:1920 h:1080 pixfmt:nv12 tb:1/1 fr:0/1 sar:1/1 sws_param:
09:08:29 T:140457174628096 DEBUG: CFFmpegPostproc::Init - skip deinterlacing

You additionally use the ffmpeg yadif postprocessing which is fully CPU bound. So that explains your load.

Yes, those are the settings that I am using for Kodi Acceleration. I have the VDPAU stuff off and everything else on with the renderer set to automatic.

How do I turn off yadif postprocessing? I don't recall doing anything to turn it on. I am using a new install and haven't modified any of the configuration files except to create the autostart.sh file you wanted.

[fritsch]

While playing the video. Press return, click on the film role, that brings up the video settings. Here you can change those settings.

[afremont]

While playing the video. Press return, click on the film role, that brings up the video settings. Here you can change those settings.

Okay thanks for that, will do. Will this fix the live TV and TV recordings playback too?

EDIT: It looks like it does remember that for TV playback after setting it one time. This significantly reduced the CPU usage for 1080i. It's on the order of 30% CPU-KODI and core clocks are running at reduced rates.

[fritsch]

Recordings have another more sever bug which cause 100% cpu usage - which is not related to the BSW.

Try to play that recording directly from disk - not via the PVR Manager and check.

[afremont]

I edited my previous post while you were writing this response. All the videos I tested were copied to the Videos directory of the Kodi box, no PVR stuff involved with that. I'll have to do more experimenting to see if TV recordings work out okay. If you can include the MythPVR in all of your builds, I will put them on regularly and test them. I have to have the Myth PVR client. It's a wife thing. I wouldn't mind testing the Jarvis (or is that what this is?) nightly builds as long as the Myth PVR client is in them.