• 1
  • 122
  • 123
  • 124(current)
  • 125
  • 126
  • 128
Linux VAAPI: Nuc, Chromebox, HSW, IVB, Baytrail with Ubuntu 14.04
(2015-07-04, 08:34)grantonstar Wrote: I'm getting a crash every time I stop playing a video. Using a gigabyte brix celeron 1037u running Ubuntu 14.04.

Interestingly, if I press back button so video plays behind menu and hit stop then it's OK.
Indeed interesting. Using a Gigabyte C1037UN-EU m-ITX board myself, also running Ubuntu 14.04 as well as OpenELEC. Not experiencing the crashes you mention. Pastebinit your kodi.log and/or crash log file(s).

How about a clean install of Ubuntu 14.04 and of Kodi without additional addons (which build/ppa?), and try again.
I want his Debug Log and the other logs from thread 1.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
https://dl.dropboxusercontent.com/u/5572...1fac66.tar <- here is an update with the announced EGL fixes.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
(2015-07-05, 09:11)fritsch Wrote: https://dl.dropboxusercontent.com/u/5572...1fac66.tar <- here is an update with the announced EGL fixes.

same results as the previous build here:

(2015-07-04, 19:31)Matt Devo Wrote: not seeing any crashes here on video stoppage, but am seeing an issue with SD interlaced content.

For 576i50 material, with deinterlacing set to 'auto' and lanczos3 scaling, video output is 30fps (dropping tons of frames; setting back to 'off' afterwards does not change). Setting to 'on' outputs properly at 50p. 720pi50 and 1080i50 material deinterlaced properly

I should note that the issue is present with interlaced SD content and any scaling method other than nearest neighbor or bilinear, not just lanczos3.
@MattDevo - can I see your Debug Log, please?

Same with this: http://solidrun.maltegrosse.de/~fritsch/...samples.ts ?
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
(2015-07-05, 11:55)fritsch Wrote: @MattDevo - can I see your Debug Log, please?

Same with this: http://solidrun.maltegrosse.de/~fritsch/...samples.ts ?

http://sprunge.us/bDJD

pretty sure it's related to my display's native output res being 1900x1200, since if I switch to 1080p everything looks good (except the colorspace, which appears to change from Full at 1200p to limited at 1080p)
(2015-07-05, 11:55)fritsch Wrote: @MattDevo - can I see your Debug Log, please?

Same with this: http://solidrun.maltegrosse.de/~fritsch/...samples.ts ?

I should also mention that 2160p60 content scaled/output at 1080p60 via lanczos3 was perfect on builds r21051-g505f665d and r21057-g565ca1a, but broken (30fps, tons of skips) on r21086-g7d85271 and r21092-g61fac66. Bilinear scaling works fine.

debug log
The older builds did not do Lanczos3 Optimized at all, it was bypassed ... we had a bug there, see: http://forum.kodi.tv/showthread.php?tid=...pid2039320
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
(2015-07-02, 19:34)AndyFurniss Wrote:
(2015-07-02, 01:16)noggin Wrote: However whilst luminance heavy content has deinterlaced properly to 50p, saturated, chroma-heavy stuff has appeared to deinterlace to 25p. It's almost as if luminance and chrominance were being deinterlaced separately, and the luma was being deinterlaced to 50p but the chroma to 25p?

Odd. And a tiny bit annoying as a lot of my content originates 4:2:2 and it would be nice to watch it full quality rather than subsampled to 4:2:0 (which is also a pain).

The issue is that the chroma sub-sampling positions for 4:2:0 are different for interlaced and progressive and of course a de-interlacer will expect the interlaced variant.

If you convert from/to 4:2:0 you need to know whether to do interlaced or progressive. By default in the "computer player world" progressive is assumed. Doing this results in interlaced chroma bleeding between fields - which confuses de-interlacers, and can look like you describe - IME what it looks like varies with the de-interlacer and the content/speed/direction etc.

Playing with kodi git from today using gl renderer I can see that ffmpeg is doing a progressive scale - I don't know anything about how kodi calls ffmpeg but from cli ffmpeg experience with interlaced content the words "auto inserted scaler" tend to be bad news.

Code:
16:50:02 T:140492792747776   DEBUG: ffmpeg[7FC707015700]: [src] w:704 h:576 pixfmt:yuv422p tb:1/50 fr:0/1 sar:1/1 sws_param:
16:50:02 T:140492792747776   DEBUG: ffmpeg[7FC707015700]: [auto-inserted scaler 0] w:iw h:ih flags:'bilinear' interl:0
16:50:02 T:140492792747776   DEBUG: ffmpeg[7FC707015700]: [Parsed_yadif_0] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'Parsed_yadif_0'
16:50:02 T:140492792747776   DEBUG: ffmpeg[7FC707015700]: [auto-inserted scaler 0] w:704 h:576 fmt:yuv422p sar:1/1 -> w:704 h:576 fmt:yuv420p sar:1/1 flags:0x2

interl:0 means progressive. As it happens ffmpegs yadif can take 4:2:2 so had the scaler been after it all would have been good. Still 4:2:0 though - I assume kodi gl yuv->rgb doesn't do 4:2:2?

The same happens without de-interlacer enabled.

Random kodi git observations - the preview picture for 422 looks wrong ( I guess it blindly assumes 420). While messing with per vid deint settings they sometimes failed to save - but then maybe I was not always quiing cleanly enough eg.change setting <s> enter on highlighted <exit>

Other thoughts - yadif needs a lot of cpu for HD content fine for SD. I don't know what h/w you use but even though radeonsi vdpau advertises 422 (packed) it doesn't work. It's possible to workaround but not (IIRC) that safe!

Really interesting stuff Andy. Will muse. Certainly the saturated chroma deinterlacing to look more 25p than 50p could be explained by some of what you are talking about. I'm using both an Ivy Bridge i5 and a Haswell i5 to play this stuff, and YADIF 2x deinterlace, so both CPU decode and CPU deinterlace.

My source material and my display resolution are the same though - so there shouldn't be a scale in the process? (unless there is 1080 vs 1088 oddness) My source material is 1920x1080 4:2:2 H264 50i (or ProRes or DNX HD) and my display resolution is 1920x1080/50p via HDMI, and output is either via Intel GPU or nVidia GPU.
(2015-07-05, 20:32)noggin Wrote: Really interesting stuff Andy. Will muse. Certainly the saturated chroma deinterlacing to look more 25p than 50p could be explained by some of what you are talking about. I'm using both an Ivy Bridge i5 and a Haswell i5 to play this stuff, and YADIF 2x deinterlace, so both CPU decode and CPU deinterlace.

My source material and my display resolution are the same though - so there shouldn't be a scale in the process? (unless there is 1080 vs 1088 oddness) My source material is 1920x1080 4:2:2 H264 50i (or ProRes or DNX HD) and my display resolution is 1920x1080/50p via HDMI, and output is either via Intel GPU or nVidia GPU.

There is still a chroma scale to 420 then to rgb, the first of which is the cause of the problem you see.

You could play 422 OK with say mpv --vo=opengl as it seems to be able to do 422 yuv -> rgb in opengl. You could also use ffmpeg yadif if you wanted --vf=lavfi=[yadif=1].

FWIW it may be possible to use your TV to de-interlace if you put it in an interlaced mode it may just do it. My 2010 Panasonic plasma does and it's my normal way of watching uk hd tv. I guess interlaced modes are GPU dependent - my baytrail and various radeons can do them.

There is the issue of field sync, though, I don't think kodi can use ffmpegs tinterlacex2 filter even though I got the idea from this forum.

So it's mpv again, if your source is 422 (planar) all you would need to do was put the TV into 1080i50 mode and do -

mpv -vo opengl --display-fps=50 --vf=lavfi=[tinterlace=interlacex2] ...

for most the source is going to be 420 so it needs an interlace aware conversion to 422 (as like everything mpvs yuv -> rgb would do progressive 420 -> rgb and mess things up, 422 -> rgb is the same whether it's progressive or interlaced) ) it would look like

--vf=lavfi=[scale=interl=1,format=pix_fmts=yuv422p,tinterlace=interlacex2]

tinterlace x2 could be considered a bit of a hack as you may be a field out sound wise. It works by placing a weaved frame on the display and updating half the lines at field rate, as long as you have vsync the fieldsync always sorts its self out even though it's not true field sync as you don't know what field the gpu is scanning out, it doesn't matter as each line stays on screen for 2 fields

Anyway I think I am getting a bit off topic :-) quickly think of something byt related - I wonder if intel will ever do deep colour and yuv 422/444 for HDMI, radeonsi will do deep color and may do 422 one day (deep colour needs patched xserver)

The idea of 422 is interesting - many TVs, including mine, sneakily turn rgb input back to 422 anyway - no idea how that would work with xserver, though.
(2015-07-05, 09:11)fritsch Wrote: https://dl.dropboxusercontent.com/u/5572...1fac66.tar <- here is an update with the announced EGL fixes.

Hardware: Intel BYT Celeron N2930
video scaling method: in general Lanczos3 is to heavy for this Celeron, therefore using bilinear.

1080i50 with MADI / MCDI deinterlacing on a 1080p display: skips a lot
576i50 with MADI / MCDI deinterlacing scaling to 1080p: perfect
720p50 with MADI / MCDI scaling to 1080p: perfect
4kp30 with MADI / MCDI scaling to 1080p: perfect
4kp60 with MADI / MCDI scaling to 1080p: skips ~20 in 10 minutes
AS Rock Beebox * Kodi 17.0-RC2 * Ubuntu 16.04 LTS
Can you triple verify, that Lanczos3 Optimized does not work for the 576i to 1080? Perhaps with VAAPI-BOB? And also not for the 720p50?

We are much more efficent with this EGL approach as we don't have to copy surfaces at all for display.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
just got back from vacation - can't wait to test this out tonight.

I have a chromebox/Denon AVR / JVC projector and have had to run full on the chromebox and limited in kodi to get smooth scaling - looks like all this may go away - excellent!

Thanks for all the work on this fritsch!
I only packaged it! Code was done by fernetmenta and lauri ... besides some bug fixes I could not contribute anything this time. Have fun testing it.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Well thank you fernetmenta and lauri also! Will definitely play with it tonight and report back on any issues.
  • 1
  • 122
  • 123
  • 124(current)
  • 125
  • 126
  • 128

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