(2015-07-18, 13:03)puithove Wrote:

(2015-07-17, 23:16)wizziwig Wrote: I looked at your sample. It uses repeat-first-field flags on the picture headers in order to extend 24fps content to 29.97fps video as specified by the sequence header. Because the repetition pattern is not regular, you end up with stutter because frames are presented at a variable frame rate. Intel is not going to fix this for you because it's not a bug. Their Windows driver will do the same thing. I don't think the field repeat flags are even visible to the VPP/Deinterlacer. This needs to be handled in the player (Kodi in this case) by taking decoded frames and buffering some of the fields to repeat on the next frame. You're basically converting a partially soft-telecined video into a fully hard-telecined one (wiki). The final frames with repeated fields applied can then be sent to VPP.

I covered this topic before in an older thread.

Now that you mention it, I do remember seeing your post on this before. Would you mind outlining your findings on the bug report (and therefore also indicating that I'm not the only one having this issue)?

In my mind, it seems like it would still be something Intel would need to fix. I'm not going to pretend I really know a whole lot in this area, but wouldn't the field repeat be applied after the frames are decoded but before being sent to the deinterlacer? This would all be in the VAAPI chain it seems.

@fritsch - any thoughts here? Anything that could be done on the Kodi side?

(2015-07-21, 19:46)trsqr Wrote: EDIT: Now that I read more carefully, nowhere is actually said that HEVC HW decoding would be supported yet in this build! Am I right?

(2015-07-21, 20:59)Boulder Wrote: This is somewhat off-topic but it's related to this new development: I'm using HSW hardware (a Celeron-based Chromebox) to run OpenELEC/Kodi. I encoded a concert with resolution [email protected] with Hi10p profile using x264 (avg bitrate around 5Mbps). That means I cannot use hardware decoding for the file.

The pop up menu shows that the CPU usage is around 60-70% for both cores. Still, I get a lot of skips per second unless I choose Bilinear as the scaling method.

Is it that the GPU cannot keep up or is the high CPU usage related? In either case, will the new development help me later on when it gets to the official code or should I forget the Hi10p profile for such material? I tested one similar concert which was encoded with an 8-bit x264 and it didn't have problems being scaled with Lanczos3 optimized to 1080p.

(2015-07-22, 00:10)Matt Devo Wrote: Hi10P is s/w decoded, so asking the CPU to that as well as lanczos3 upscaling is simply too much. Either using bilinear scaling or re-encode to 8-bit so hw/GPU decoding can be used

(2015-07-22, 07:41)FernetMenta Wrote: Upscaling is done by GPU, not CPU. In theory lanczos3 (fast) should work with sw decoding too but there are issue with mesa and EGL I haven't tracked down yet. The timing is strange and OpenGL calls block where they are not supposed to block.

(2015-07-22, 07:41)FernetMenta Wrote:

(2015-07-22, 00:10)Matt Devo Wrote: Hi10P is s/w decoded, so asking the CPU to that as well as lanczos3 upscaling is simply too much. Either using bilinear scaling or re-encode to 8-bit so hw/GPU decoding can be used

Upscaling is done by GPU, not CPU. In theory lanczos3 (fast) should work with sw decoding too but there are issue with mesa and EGL I haven't tracked down yet. The timing is strange and OpenGL calls block where they are not supposed to block.

(2015-07-22, 10:21)Boulder Wrote: My other 10-bit encodes work just fine (ranging from 1280x720 to full HD @ 23.976 or 25 fps) so it seems that the high framerate is what causes the "issue" in the end. So is bilinear the only one that doesn't have any timing problems? It's the first one that works, all the higher ones shows the same amount of dropped frames.