•   
  • 1
  • 120
  • 121
  • 122(current)
  • 123
  • 124
  • 128
  •   
  Thread Closed
[Linux] VAAPI: Nuc, Chromebox, HSW, IVB, Baytrail with Ubuntu 14.04
Guys!

Not sure if this is the right thread but I've been harassing Smile lmyllari with some pm questions on color space etc. Since he knows a lot I thought I'd share he's answer if anybody else finds it useful. Thanks Lauri!

Question:

Hey Lauri!

Sorry if I keep asking the same questions Smile

I've been following the vaapi thread and saw this yesterday from you:

"It's better to use xrandr to set full range, then match Kodi and TV settings (either full or limited - shouldn't make much of a difference with dithering enabled)."

Is there no difference between full and limited as long as you match kodi and tv (with xrandr set to full)? I was under the impression that we had less conversions if we set kodi and tv to limited?

Also, how do I enable dithering, and do I need it?

Thank you!


Answer:

Hi Johan!

The VAAPI work is landing a little earlier than I expected, and it's really good stuff. Smile The idea is that we get frames from the hardware decoder without any processing (just like from the ffmpeg software decoder) - and they are already in GPU memory and can be used as textures for OpenGL. This makes for perfect quality and very good performance.

The decoded frames are in limited range (16-235) YCbCr. They are converted to RGB in the GLSL renderer, scaled if needed and then converted to full range (0-255) RGB if needed. The result is still in higher than 8 bit precision, so no information is lost yet.

If dithering is not enabled, the result is just cut into 8 bits. This is where the banding is introduced if the signal was converted from limited to full range (the levels don't map 1-to-1). If it is kept in limited range, it should fit into 8 bits with maybe a tiny loss of precision in the scaling results.

If dithering is enabled, a small amount of noise (less than 1 bit) is added to the picture before cutting it to 8 bits. This causes some pixels to round down and some up. The end result is more than 8 bit precision with a small amount of noise.

You'll find the dithering settings in System->Video (set settings level to Expert). It should be enabled by default in the builds that have it.

If you have your GPU set to full range with xrandr and are using limited range in Kodi and your TV, dithering is not needed (but it shouldn't hurt either). If you want full range signal, then dithering eliminates the banding from that conversion.

Even with limited range output you might want dithering to keep more information from scaling. It becomes more important when you use a 3dlut. I'm hoping to introduce that soon - I have it already working in my branch but there's no user controls yet.

So the short answer is that it is enabled by default if your build has it, but your setup doesn't (yet) need it. It shouldn't hurt picture quality - and if you find a case where it does, please report it so we can fix it.

Happy watching Smile
Lauri


ps. if you found this helpful, feel free to post the question and answer publically
Thanks much for this summary.

This work is in the latest build I posted. This is btw. the first time at all - that someone can get perfect colors from VAAPI without going the sw path :-). I really hope to push it into OpenELEC 6.1 - though we need to check if there are regressions on other platforms as the Generic release is not intel only.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
(2015-06-29, 08:29)fritsch Wrote: Thanks much for this summary.

This work is in the latest build I posted. This is btw. the first time at all - that someone can get perfect colors from VAAPI without going the sw path :-). I really hope to push it into OpenELEC 6.1 - though we need to check if there are regressions on other platforms as the Generic release is not intel only.

Again, great news! As there are many releases around, after this excellent work from you and finally some real hw from Intel, there should be definitely an Intel build availableSmile There is no better hw (and I think will not be for long time) then Intel's for Kodi.
While Pi2 and other devices are very good, impressive and nice to have, they are all very limited in many ways (live tv, deinterlacing, scaling quality, etc.).

I do understand that most of the users don't need livetv and some advance features that are now possible with Intel, they just need a buy-install in 5 min- and never touch again device.
HTPC 1: ASRock N3150DC-ITX, 8GB DDR3L, 64GB SSD, Ubuntu Server 16.04 LTS + Kodi v17 EGL
HTPC 2: RPi2 + HiFiBerry DIGI+, LibreElec
Aha - so the dithering is similar to the approach used by Quantel's patented "Dynamic Rounding", which they've used since the 80s to avoid banding on broadcast kit during colourspace conversion and bit depth truncation (as is common in broadcast video processing like mixing, keying etc.), and which people like Sony have licensed in the past (Digital Betacam used it)
Quote:Dynamic Rounding
Dynamic Rounding is a clever technique devised by Quantel for truncating the word length of pixels – a process you can't avoid when you are processing images. Rather than simply losing the lower bits, Dynamic Rounding uses their information to control, via a randomiser, the dither of the LSB of the truncated result. This effectively removes any artefacts that would otherwise be visible. Dynamic rounding is non-cumulative on any number of passes and produces statistically correct results. Dynamic rounding eliminates any truncation artefacts leaving you great looking pictures whatever the bit depth, whatever the processing. Dynamic Rounding is patented technology that you simply can't get anywhere else.
http://digitalfactbook.tv/d/dynamic-rounding/
Not sure if the Quantel patent still applies...
This is super exciting news for a picture quality nerd! I'm very new to openelec and linux, only 2 weeks since I left windows for good. And I'm extremely thankful for all the work you guys keep doing!

So let me get this straight. When this has all been merged and double checked and pushed into official releases I will be able to use vaapi rendering without any compromises when it comes to color space conversion, banding etc etc?! Will the xrandr full rgb trick also be unnecessary?

Thanks!
(2015-06-29, 10:41)Hufvudet Wrote: This is super exciting news for a picture quality nerd! I'm very new to openelec and linux, only 2 weeks since I left windows for good. And I'm extremely thankful for all the work you guys keep doing!

So let me get this straight. When this has all been merged and double checked and pushed into official releases I will be able to use vaapi rendering without any compromises when it comes to color space conversion, banding etc etc?! Will the xrandr full rgb trick also be unnecessary?

Thanks!

Exactly. You are welcome to test the builds I have posted. Just upgrade from a freshly installed beta2 image.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Short question:

Any bugs left you get with the EGL version I have posted two days ago? All fine? Something that sucks? (*)


(*) Video Playbackwise only of course.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
@fritsch, bugs free. At least for me. thanks!
Now waiting for Lauri's 3dlut support to be pushed Big GrinTongue
ZOTAC MAGNUS EN1060K: Win 10 x64+ Kodi DSPlayer x64
LG OLED 65EF950v / Denon AVR-X3200W / KEF E305 / Synology DS2415+ / Vu+ SOLO2
Ruling them all with a Logitech Harmony 950 Remote
(2015-06-29, 22:07)fritsch Wrote: Short question:

Any bugs left you get with the EGL version I have posted two days ago? All fine? Something that sucks? (*)

Braswell N3150 board:

Don't know if it's relevant for your EGL changes, but i am reporting it here anyway:

* having tested your EGL Openelec Build, and Video in Live TV is perfect: No skips, no drops.

* but opening an overlay (return key) : -> skips noticably.

* opening the TV Channels Overlay: -> skips like hell, clearly stuttering Video Playback.

* closing Overlay: Skipping stops.

* the skipping with active overlay happens mostly on 720-er HD channels like ZDF, ARD, ORF and so on. On most 1080er HD Channels (like Servus TV: no skipping, even with active overlay; DMAX HD is an exception here: skips).

Max
Now the Braswell N3700 is alive. The missing DRM-Intel-nightly kernel was the Problem.
As I have no 4k equipment, I can´t test the system.

What I recognised: While playing HEVC 1080 files, the system load goes up to 200 %.
I haven't tried this with the OE image, only my own builds from the EGL branch. Maybe someone could verify on the test build?

If you play a video, hit backspace to go back to the file list and select a new video while the other is still playing in the background, it won't start. Instead, the previous video is replaced with the menu background (I think). After hitting "x", video playback will work again for any video selected.
(2015-06-30, 03:35)_Manfred_ Wrote: Now the Braswell N3700 is alive. The missing DRM-Intel-nightly kernel was the Problem.
As I have no 4k equipment, I can´t test the system.

What I recognised: While playing HEVC 1080 files, the system load goes up to 200 %.

HEVC is not hw accelerated. This is missing in ffmpeg and kodi.

Edit: And the 4k tests here are decoder, scaler tests only. They are output at 1080p -> so you can very well test those.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
(2015-06-30, 00:07)maxodolo Wrote:
(2015-06-29, 22:07)fritsch Wrote: Short question:

Any bugs left you get with the EGL version I have posted two days ago? All fine? Something that sucks? (*)

Braswell N3150 board:

Don't know if it's relevant for your EGL changes, but i am reporting it here anyway:

* having tested your EGL Openelec Build, and Video in Live TV is perfect: No skips, no drops.

* but opening an overlay (return key) : -> skips noticably.

* opening the TV Channels Overlay: -> skips like hell, clearly stuttering Video Playback.

* closing Overlay: Skipping stops.

* the skipping with active overlay happens mostly on 720-er HD channels like ZDF, ARD, ORF and so on. On most 1080er HD Channels (like Servus TV: no skipping, even with active overlay; DMAX HD is an exception here: skips).

Max

Thanks much for this report.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
I'm guessing there isn't going to be any interest in 4:2:2 rendering (which I think requires NV16 rather than NV12?) in Kodi any time soon?

I realise I'm one of the few people who watch 4:2:2 rather than 4:2:0 content regularly, but it would be great to see it in full resolution (and without the odd deinterlacing issues that appear to hit saturated content)

I'm guessing this is software decode and non-VAAPI rendering?
Though libva is providing: http://01org.github.io/libva_staging_dox...40bdde9df6 YUV422 the intel driver does not implement it: http://cgit.freedesktop.org/vaapi/intel-...ocessing.c
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
  •   
  • 1
  • 120
  • 121
  • 122(current)
  • 123
  • 124
  • 128
  •   
  Thread Closed
 
Thread Rating:
  • 16 Vote(s) - 4.81 Average



Logout Mark Read Team Forum Stats Members Help
VAAPI: Nuc, Chromebox, HSW, IVB, Baytrail with Ubuntu 14.044.8116