Posts: 6,780
Joined: Oct 2008
Reputation:
329
noggin
Posting Freak
Posts: 6,780
2014-12-09, 23:37
(This post was last modified: 2014-12-10, 01:20 by noggin.)
Simpsons could be a 60i to 50i standards conversion, and if so it may well have interlaced motion from the conversion (even if the source is progressive). (I don't think it's 24p to 25p speed-up which would mean no intra-frame motion)
I suspect you'll see it on all shows on Freeview HD, though stuff shot natively interlaced may not flip to progressive that much other than on very static shots. It's a function of the Freeview HD encoding profile that is being used. Not sure how widespread it is in other countries. (The i/p decision is taken by the encoder dynamically based on the content of the 50i signal it is fed with. If it detects any intra-field motion it will encode in interlaced mode, but if it doesn't it will assume the content is progressive and encode it in progressive mode, which is potentially more efficient for progressive content)
Posts: 12
Joined: May 2012
Reputation:
0
You're correct noggin, been doing some channel hopping and the use of this adaptive encoder is in use across all Freeview HD channels and content type so the screen flashes are frequent.
When AndyFurniss first explained its use with the signer for the deaf, I thought its use would be restricted to changes of content type within a broadcast e.g showing archive footage/prerecorded vt/commercials but as you explain above and my test samples have shown, the encoder is adapting constantly to whatever its being fed so the i/p transitions are happening frequently even within the same type of content.
So that being said, now that its been show to be a standard in UK DVB-T2 broadcasts a question for the devs:
Is there scope to improve how vaapi hw decoding handles deinterlacing this type of adaptive content without the i/p transitions being visible on screen as the renderer adapts, or is it a limitation of decoding in hw? As I mentioned, decoding in sw handles the transitions without any screen flash.
If there is scope, should I submit a bug report on trac?
Posts: 286
Joined: Jun 2009
Reputation:
0
menno
Senior Member
Posts: 286
Fritsch,
Will you release a test openelec version with your patched 3.18 kernel?
What will you think will be the roadmap on this? It seems mostlikely that
after a final helix openelec, some .1 version will be released with a patched 3.18 kernel?
Posts: 23,468
Joined: Aug 2011
Reputation:
1,101
fritsch
Team-Kodi Developer
Posts: 23,468
No, not planned. I did that kernel over night, cause I have absolutely no time. When I see that those are working I will push them to OpenELEC directly.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Posts: 286
Joined: Jun 2009
Reputation:
0
menno
Senior Member
Posts: 286
Ok thanks! Your work and that of Chris is very much appreciated!
Posts: 160
Joined: Mar 2013
Reputation:
0
2014-12-12, 06:29
(This post was last modified: 2014-12-12, 06:34 by jjslegacy.)
Compiled Openelec from master for my chromebox and played around for a while with Prefer VAAPI render method enabled and had no signs of hangs or anything else. Appeared to be working quite well
Only issue is I can't seem to get my grayscale ramp to look smooth - always looks choppy and can see the bars. The only way I get it smooth is with setting full on the chromebox and setting kodi to limited 16:235 with Prefer VAPPI render method disabled. Not sure where the breakdown is between the chromebox, denon4520 and jvc4810
Posts: 23,468
Joined: Aug 2011
Reputation:
1,101
fritsch
Team-Kodi Developer
Posts: 23,468
2014-12-12, 08:48
(This post was last modified: 2014-12-12, 08:48 by fritsch.)
Yes, that's intended ™, e.g. we cannot do anything against it.
As explained in this thread before, the VAAPI Render Method uses a full rgb vaPutSurface method, which spreads it to 0 .. 255. As it seems your AVR and your TV only do limited Range. You have two choices left: a) force the intel driver to limited (which is the default btw.) and don't touch kodi settings b) do what you did and disable VAAPI render
We currently have no other way of getting unscaled VAAPI picture data when the VAAPI Render Method is in use.
Btw. you build after I pushed the gpu hang fix, right?
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Posts: 160
Joined: Mar 2013
Reputation:
0
Thanks Fritsch
Yes I built it right after I saw the commits go in to start to test it out.
One question if I do choice A should I expect a smooth grayscale ramp? The colors look about proper but I can see the bars slightly in the ramp - just not as smooth as choice B.
Is that expected or is there something else wrong somewhere in my chain?
Posts: 23,468
Joined: Aug 2011
Reputation:
1,101
fritsch
Team-Kodi Developer
Posts: 23,468
Nope. That's sadly fine. Egl API to come.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Posts: 23,468
Joined: Aug 2011
Reputation:
1,101
fritsch
Team-Kodi Developer
Posts: 23,468
Nice guys. If someone of you want to thank chris wilson directly, join #intel-gfx and ping ickle <- that's his name there.
Really cool, finally.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
