[Devil-Strike]

Just played a bit and must say very nice job, 1080i(mbaff) mpeg4 11mbit live tv works perfect now on a j1800.

I only see some blurred line at the bottom with 720p/1080p. contect, tested with some dl files and a bluray.

[fritsch]

Screenshot, Debug Log, please - cause I cannot see it :-)

[Devil-Strike]

Ok just wait a minut now booting system, incl debug.

Log: http://pastebin.com/fSmcdibh

screenshot:
http://imgur.com/3Ppd4VH
Not the best quality but you can see it.

[lmyllari]

See: https://github.com/FernetMenta/xbmc/comm...t-11814215 (make sure to also read the commit he answered to, I wanted to get the colorspace right, but VPP ignores it).

I looked at the driver code and it's a mess. If Intel fixes it, there should either be an option to specify the RGB range or the coefficients. An RGB range with colorspace flag would be simple to use but limited to the colorspaces the driver knows. Passing the coefficients all the way from the client would be more flexible (VDPAU does this). If neither is implemented, we'll probably see the same banding issue as with vaPutSurface.

Maybe NV12 surfaces are the way to go.

[fritsch]

I also hope on NV12 way of doing it. This is btw. the approach we are working with intel (I CCed you on the email this morning).

[lmyllari]

Thanks for including me.

I'm thinking of hacking the coefficients to limited range BT.709 for now so I can update my work to the EGL branch. It might be useful for the test builds too.

[fritsch]

Wait a bit. I really hope to get the NV12 code this week. Then you need to do the job only once - or even better can reuse what you already have.

[noggin]

VPP fully ignores all color flags we give it, therefore we need to use the relevant matrices (that are already in kodi's shadercode) afterwards ourselves. We now get out something "looking like" Limited RGB Range with wrong 601 colorspace, this won't change for now.

We hope to implement this NV12 surface copy and afterwards scale with the correct functions (matrices, that are already there) to be able to output RGB (at the very last moment), which is what OpenGL does at the end. For now nothing else is possible in this "fast path" or in shorter: We have to take _that_ RGB that we are given and have no influence on it.

See: https://github.com/FernetMenta/xbmc/comm...t-11814215 (make sure to also read the commit he answered to, I wanted to get the colorspace right, but VPP ignores it).

Btw. we are working with Lauri Millary to make fully sure we get "the best out of it" that is possible. E.g. direct unaltered output of the HW decoder, then asking the color space via dvdplayer / ffmpeg and use the relevant shader code to output in the color format we want.

To be more precise: As of now(!) there is _not_ a single chance to get "non altered f*cked up colors" when not using

a) the SSE4 copy (does not scale for 4k ... high load)
b) vaPutSurface, which uses BT601 and BT709 but scales "up" to Full Range RGB ...

Interesting stuff fritsch

So is :
a) software deinterlace using YADIF 2x (slower but allows for limited range to be observed all the way through)
b) hardware deinterlace as previously implemented (faster but goes via 0-255 so bands and loses <16 and >235 content?) ?

Does this also explain why a 1280x720/50p and 1920x1080/50i to 3840x2160/50p (4:2:0 output) on Kepler and Maxwell nVidia cards with the new nVidia 2160/50p 4:2:0 output mode drivers compiled into an otherwise master branch OpenElec build frame drops like mad?

And is the subtext to the colorStandard flags being ignored a 'this is a bit too difficult' do you think? Broadcast video is quite tricky to get right if you try to cut corners - but if you follow the rules it does work...

(But then I've seen high-end broadcast kit get the SD 4:3/16:9 line-width of 702 vs 720 stuff wrong when up/downconverting between 576i and 1080i such that picture width changes were happening for a few frames on BBC One HD in the early days... The technical rule is that an SD 4:3 or 16:9 picture is 702x576 NOT 720x576. The extra 9 samples each side are to avoid clipping transients and mean the 720x576 frame is slightly wider than 16:9 or 4:3. If you scale a 720x576 image to 1920x1080 or 1280x720 it should be the 702x576 portion that is scaled to full screen NOT 720x576. Similarly a 1920x1080 or 1280x720 16:9 image should be scaled to a 702x576 area within a 720x576 frame, not stretched to 720x576 full width)

[fritsch]

Does this also explain why a 1280x720/50p and 1920x1080/50i to 3840x2160/50p (4:2:0 output) on Kepler and Maxwell nVidia cards with the new nVidia 2160/50p 4:2:0 output mode drivers compiled into an otherwise master branch OpenElec build frame drops like mad?

No, not at all ... _this_ above code is nowhere near in any OpenELEC master branch. Besides that nobody has tested this recently on anything other than intel ... it's for intel testers only and WIP.

a) software deinterlace using YADIF 2x (slower but allows for limited range to be observed all the way through)
b) hardware deinterlace as previously implemented (faster but goes via 0-255 so bands and loses <16 and >235 content?) ?

This is right for _the_ old code (not in this images).

New code:
a) software deinterlace as it was before
b) Output of Limited Range RGB while only the BT601 coefficients were used on transformation. <- this is just there to show the performance impact.

VDPAU is offtopic here and this EGL branch does not care at all for nvidia at the moment. It is WIP and nothing else.

[noggin]

Does this also explain why a 1280x720/50p and 1920x1080/50i to 3840x2160/50p (4:2:0 output) on Kepler and Maxwell nVidia cards with the new nVidia 2160/50p 4:2:0 output mode drivers compiled into an otherwise master branch OpenElec build frame drops like mad?

No, not at all ... _this_ above code is nowhere near in any OpenELEC master branch. Besides that nobody has tested this recently on anything other than intel ... it's for intel testers only and WIP.

Sorry fritsch - I wasn't clear. I meant that because current OE master builds don't have the above code, they don't experience the speed gain, so have the issues you mention. However as it is VDPAU I realise it is off topic so won't discuss it further.

a) software deinterlace using YADIF 2x (slower but allows for limited range to be observed all the way through)
b) hardware deinterlace as previously implemented (faster but goes via 0-255 so bands and loses <16 and >235 content?) ?

This is right for _the_ old code (not in this images).

New code:
a) software deinterlace as it was before
b) Output of Limited Range RGB while only the BT601 coefficients were used on transformation. <- this is just there to show the performance impact.

VDPAU is offtopic here and this EGL branch does not care at all for nvidia at the moment. It is WIP and nothing else.

Thanks fritsch - glad I understand what is going on. Look forward to running it on my Intel boxes. (Now if only Intel could do HDMI 2.0 4:2:0 2160/50p and 60p output over legacy HDMI 1.4a hardware like nVidia have...)

[fritsch]

Chad has already delivered: https://github.com/chadversary/mesa/comm...-transcode

Though, i am currently quite busy at work (ever fucked arround with window's DWM forbidding swapbuffers with vsync ;-)) - hope to find some time during weekend.

[rob77]

Hi

Thanks Fritsch for the latest build it is running well with my nuc 2820. Sorry if this has been mentioned but the only problem I have is the colour is washed out. I am running full RGB and it looks like it is defaulting to limited. Choosing Bilinear instead of Lanczos3, Spline36 and the colours are okay.

Cheers

[fritsch]

Do me a favor and read the last pages ... don't want to repeat myself there. Colors are work in progress.

[rob77]

Thanks

I have read back through the thread and I have set:

Prefer vaapi Render: Off
Deinterlace: Auto
Deinterlace Method: Deinterlace (Edit: Actually bob works better for 1080i)
Scaling: Lanczos3

Hope this is okay and using the Lanczos3 scaling method correctly

[joelones]

Pardon this stupid question, would I be able to attempt this on my Kodibuntu setup running 14.2 provided I do the following:

Code:

Kodi 14.2
Kernel 4.0.5 from mainline kernel
xserver-xorg-video-intel https://dl.dropboxusercontent.com/u/5572..._amd64.deb
Wsnipex's i965/libva drivers - currently 1.6.0pre1

I have a rather old IVB CPU (G1610)

and the following:

Code:

libva-intel-vaapi-driver:
  Installed: 1.3.0-1ubuntu1
  Candidate: 1.3.0-1ubuntu1
  Version table:
*** 1.3.0-1ubuntu1 0
uname -a
Linux daisy 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Hardware: http://paste.ubuntu.com/11769005/

Great work, btw.