[Koying]

I don't need a selection of all inferior deinterlacing methods. The hardware should do the best it has to offer.

Yep, my opinion, too. I don't see the point of having deinterlacing options if one is clearly the best for a given hardware.
VAAPI doesn't know which h/w it talks to, so it might make sense to have a choice, there, but the mediacodec implementations talk directly to the h/w, so they know what is the best possible.

[shomari]

... somewhat in that vein, I suppose.

https://github.com/xbmc/xbmc/commit/7602...ce6d038fb7

[fritsch]

The very moment, you need to drop, skip and so on, you at glad you can instrument hw to skip some post processing. Is there any droid vendor that does all right in firmware? I don't. Crystal HD is long dead :-)

[Koying]

How do you skip de-interlacing?
Or is vaapi degrading to a lesser cpu intensive grade?

[fritsch]

VAAPI can skip cycles, VDPAU, too. So if it goes "hard" you just get some interlaced frames. Much better than dropping complete images.

See: xbmc/cores/VideoPlayer/DVDCodecs/Video/DVDVideoCodecFFmpeg.h: virtual bool CanSkipDeint() {return false; }

[Koying]

VAAPI can skip cycles, VDPAU, too. So if it goes "hard" you just get some interlaced frames.

I still think you don't have the same understanding of "interlaced" frame as I do...
Interlaced pictures are coded as 2 fields, which are half the height of a full frame.

De-interlacing is the process of combining those 2 fields to produce a full, progressive, frame. The most basic way to do so is to "weave" (interlace) the 2 fields, which leads to the well-known comb effect.

So you can't "get interlaced frames". Best you could do is skip a field and render 1 field as the full frame, but I doubt it..

[fritsch]

You get what kodi gets if you switch off deinterlacing.

Edit: Depending where you skip, you can also skip the rendering after deinterlacing, when you are doing 50i to 50p, not all frames need to be rendered.

[fritsch]

Aml on linux uses this on le to skip deint completely when not fullscreen, so a very useful feature. What we plan for the future: extend process info to fall back scaler and deint if we have too many skips, drops. Too bad if no API would exist for doing this.

[Koying]

You get what kodi gets if you switch off deinterlacing..

Hehe, yep. We get what Kodi gets from mediacodec in all cases.

See, not that different

[fritsch]

I see a big difference there, cause the decision what you get and what the decoder / postprocesser and at the end the renderer does is in our hands. As we sync audio separately, how should mediacodec know what is best to do?

[Koying]

I'm afraid we're derailing from the topic.
We're speaking about h/w decoding and zero copy, here.

I never, ever, saw Kodi waiting for MediaCodec...

But hey, if you feel putting a 1 rather than 2 in a field when calling an API gives you control, glad for you...

[fritsch]

I never, ever, saw Kodi waiting for MediaCodec...

Now - you got the point. Would be good to say: ey, you are too slow, skip a deint cycle or drop some frames or skip same frames to render. If this control is not there, the content will be unplayable. Therefore yes: I feel comfortable with an API allowing me to instruct the decoder to do certain things.

[Koying]

Now - you got the point.

No, you missed mine.
I meant mediacodec is never "too slow".

This is 2016, with quad cores and dedicated vpu's

[CiNcH]

In the DVBViewer we did something which we called "skip fast forward". When fast forwarding, we did not decode every frame but skipped over some data between every frame. This worked perfectly even with DXVA and full VPP. Frames got updated almost instantly. I also don't really think that there is a real performance bottleneck anymore with most hardware. Those hardware accelerators have really become powerful and decoding and VPP are well balanced. I only have real experience with Intel QuickSync though. I can't remember how many H.264 1080i MBAFF streams I could decode and deinterlace in parallel. But it certainly was > 4 streams on an Ivy Bridge CPU. However skipping is more a matter of latency than throughput...

[fritsch]

skip in kodi context: don't show a certain frame