[ilovethakush]

What's the difference between VAAPI Motion Compensated and VAAPI Motion Adaptive and which would you suggest for the chromebox?

I know right now on the wiki it says Motion Adaptive but for the longest time it said Motion Compensated. Just wondering.

This is my understanding :

MADI uses Motion Adaptive techniques. This is where a picture, or elements of a picture, are analysed across fields to detect whether they are static or moving. If they are static then both fields are used to create a frame (i.e. a Weave) - and if they are moving then elements from just one field (i.e. a simple Bob) are used to create a frame (possibly with a bit of filtering to reduce the visibility of the vertical resolution drop and avoid jagged edges) Some deinterlacers use Motion Adaption across the entire field/frame (so switch between all-Bob or all-Weave) whilst others divide the picture into blocks and apply the Bob/Weave decision on a block-by-block basis. I think the Intel approach is the latter. (Some cheap TVs and consumer devices that deinterlace use the former, and you see weave artefacts on shot changes between i and p native content) Effectively with MADI you get the best of both Weave and Bob techniques (either globally across a frame/field or block-by-block within a frame/field).

MCDI uses Motion Compensative techniques. This is where the motion between fields is detected as in MADI and block-based detection is used BUT the motion within blocks between fields is also analysed so a motion vector for each block can be generated, which allows for more than one field to be used to create the output frame even for moving content. The motion vector is detected and allows for the motion to be compensated for, allowing information from both fields to be used to create a frame, even on moving content (you move the content from one field by the motion vectors generated to create the missing field to pair with the field before or after). This is a lot better than the Bob (or Bob with a bit of filtering) that is used on moving content in MADI. It should mean increased vertical resolution on moving content compared to MADI. The quality achieved will depend on the number of fields that are analysed and stored by the deinterlacer, and the motion detection algorithm used.

MADI just needs motion detection, MCDI needs motion detection AND some vector generation algorithm (like block matching) to compensate for the motion. As a result MADI requires less processing than MCDI, so for some very low spec GPUs you can only do MADI.

Thanks a lot, that was very descriptive.

I was just thinking to myself that based on what you said it would probably be better to use motion compensated, and then I check the chromebox wiki and the change has already been made, that was fast.

One more question, and sorry for my ignorance, I'm relatively new to this. For video scaling method, what's the advantage of having it be "lanczos 3 - optimised" and not "auto"?

[m_gl]

Yes, as said: Sync to display compensates this issue for you by resampling.

Can you post a Debug Log from the PI using DVDPlayer and not omxplayer and with it's Sync playback to Display disabled? The Pi has a special syncer that slows down / slows up hdmi clock directly to compensate.

http://pastebin.com/mQ3yZ4fA
Omxplayer disabled , mmal enabled

@fritsch - did you actually mean DVDPlayer, or do you just want non-omxplayer (ie. mmal)?

Build #1105 (the log above) is based on VideoPlayer. The last DVDPlayer-based test build is #0907, or @m_gl could try the release version of OpenELEC 6.0 as this is also DVDPlayer based.

Think he means just non-omxplayer, because of the ppl sync.

[fritsch]

What's the difference between VAAPI Motion Compensated and VAAPI Motion Adaptive and which would you suggest for the chromebox?

I know right now on the wiki it says Motion Adaptive but for the longest time it said Motion Compensated. Just wondering.

This is my understanding :

MADI uses Motion Adaptive techniques. This is where a picture, or elements of a picture, are analysed across fields to detect whether they are static or moving. If they are static then both fields are used to create a frame (i.e. a Weave) - and if they are moving then elements from just one field (i.e. a simple Bob) are used to create a frame (possibly with a bit of filtering to reduce the visibility of the vertical resolution drop and avoid jagged edges) Some deinterlacers use Motion Adaption across the entire field/frame (so switch between all-Bob or all-Weave) whilst others divide the picture into blocks and apply the Bob/Weave decision on a block-by-block basis. I think the Intel approach is the latter. (Some cheap TVs and consumer devices that deinterlace use the former, and you see weave artefacts on shot changes between i and p native content) Effectively with MADI you get the best of both Weave and Bob techniques (either globally across a frame/field or block-by-block within a frame/field).

MCDI uses Motion Compensative techniques. This is where the motion between fields is detected as in MADI and block-based detection is used BUT the motion within blocks between fields is also analysed so a motion vector for each block can be generated, which allows for more than one field to be used to create the output frame even for moving content. The motion vector is detected and allows for the motion to be compensated for, allowing information from both fields to be used to create a frame, even on moving content (you move the content from one field by the motion vectors generated to create the missing field to pair with the field before or after). This is a lot better than the Bob (or Bob with a bit of filtering) that is used on moving content in MADI. It should mean increased vertical resolution on moving content compared to MADI. The quality achieved will depend on the number of fields that are analysed and stored by the deinterlacer, and the motion detection algorithm used.

MADI just needs motion detection, MCDI needs motion detection AND some vector generation algorithm (like block matching) to compensate for the motion. As a result MADI requires less processing than MCDI, so for some very low spec GPUs you can only do MADI.

Thanks a lot, that was very descriptive.

I was just thinking to myself that based on what you said it would probably be better to use motion compensated, and then I check the chromebox wiki and the change has already been made, that was fast.

One more question, and sorry for my ignorance, I'm relatively new to this. For video scaling method, what's the advantage of having it be "lanczos 3 - optimised" and not "auto"?

Auto does use settings that work on most hardware. In the concrete implementation. It would use Lanczsos 3 Optimized for 576 content and it would use Bilinear for 720p. So it's not exactly what we want. Therefore we set our own "defaults". Our settings can't be the defaults for all - cause of poor hw out there - see for example the Baytrail NUCs, which would "suffer" by default if we did.

[paradix]

@fritsch: I have been using kodi on ubuntu for few days now together with the kernel you supplied for my Baytrail Zotac CI320.
As long as colors are great, than the movie playback is kind of jerky. I don't know how to describe the behaviour exactly, but it is not smooth.
It seems like it is a problem with deinterlacing, in the log I was able to find entries that the deinterlacing method was not supported and it fallback to BOB.
I tried different VAAPI deinterlacing methods but the playback wasn't good with any of it. May this be because of the CPU or the h264 mkv file I was playing?

[fritsch]

Deinterlacing only makes sense whenever you play interlaced content. Never ever set Deinterlacing to On - always keep it on Auto. As you are running a Baytrail ... it is not fast enough to support VPP-MADI in all cases - you should use VAAPI-BOB.

I can tell you with a proper Debug Log file or mediainfo of the file.

[paradix]

Deinterlacing only makes sense whenever you play interlaced content. Never ever set Deinterlacing to On - always keep it on Auto. As you are running a Baytrail ... it is not fast enough to support VPP-MADI in all cases - you should use VAAPI-BOB.

I can tell you with a proper Debug Log file or mediainfo of the file.

here is the log --> http://xbmclogs.com/pzhlybr3x

As for the rest of the settings, they are as you described

[fritsch]

Yeah - set the Scaling method to "Bilinear" and save it for all files - also too much for Baytrail.

[paradix]

Time to change the hardware then. Thnx again ;-)

[D-an-W]

Evening fritsch, I plan to do a reset of OE using your build to remove any possible remnants of older versions. Is it simply a case of resetting in OE and copying my 4 *.xml files (NAS passwords, folders etc) back over then rechecking the default settings?

[fritsch]

No idea - as OE saves some stuff in kodi directory concerning its binary addons and so on - no guarantees - i'd reconfigure from scratch also.

[AndyFurniss]

Thanks much for the summary. I assume the same.

It's always struck me that the motion vectors in H264 and MPEG2 encoding/decoding would be useful for deinterlacing - yet there never seems to be a way of feeding them from the decoder to the deinterlacer?

I'm old enough to remember the HD-MAC HDTV system - which sent a 576/50i analogue component video signal which had been derived from a 1152/50i HDTV source, and used 1:1, 2:1 and 4:1 interlacing paths on a block-by-block basis BUT also sent the vectors and interlacing technique for each block as digital data in the vertical blanking, to allow a receiver to reconstruct without having to do the motion detecting itself (as the encoder sent the vectors it thought would be best for decoding). The data was carried in VBI and HBI along with digital audio.

H264 and MPEG2 use similar techniques, with the encoder sending the motion vectors rather than the decoder having to detect them, so it seems strange that they can't be fed forward to the deinterlacer?

If the vectors were available, and were useful, they'd reduce the computation requirement of the deinterlacer?

Interesting about the MAC system.

I guess the reason the deinterlacers don't rely on vectors is there may not be any for some blocks - I think the encoder can just use intra for any block as it wants.

Also it's not just vectors, it's vectors + residual and I guess the residual may affect things.

[noggin]

Interesting about the MAC system.

I guess the reason the deinterlacers don't rely on vectors is there may not be any for some blocks - I think the encoder can just use intra for any block as it wants.

Also it's not just vectors, it's vectors + residual and I guess the residual may affect things.

Yep - could be. Though every little helps? Having guide vectors would massively speed up block matching in a deinterlacer to find the right deinterlacing vector, as you could start with the guide vector and work around it? It's a bit like Phase Correlation being used upstream of Block Matching in Alchemist or Quasar?

[soder]

I got a question about watching 4k with this version.

I got a NUC Braswell, running OE Fritsch, and a new 4k TV.

Just when I got it I tested the 4k videos I got and it was all smooth.

Now it isn't and the only thing I know I've changed is that I now use the hdmi cable for sound too. Before I used a toslink cable for sound.

Can that make the video not play smooth?

/Söder

[AndyFurniss]

Deinterlacing only makes sense whenever you play interlaced content. Never ever set Deinterlacing to On - always keep it on Auto. As you are running a Baytrail ... it is not fast enough to support VPP-MADI in all cases - you should use VAAPI-BOB.

Exceptions can prove rules :-)

There may be times like mixed content (UK HD TV) when forcing on + MADI is the best way. I am thinking here of old threads where it was noticed that auto switching according to the stream flags caused a black frame - maybe that is solved?

With MADI in theory at least always on shouldn't hurt progressive as it's MADI so won't blend when not needed.

Maybe the OPs Baytrail is less than mine (J1900 + dual ram), but I could run 40mbit 30i h264 OK with MADI and get smooth 60fps with bilinear. Tested before the EGL work = I wouldn't get 60fps when there was an overlay - but that's not really a problem unless you watch TV with an overlay always on :-)

BOB is really not very nice for scaled up SD. The bobbing is less noticeable for HD.

Random VAAPI question - does kodi just detect intel and refuse to use it for anything else eg. radeonsi_drv_video.so -> gallium_drv_video.so ?

[noggin]

Deinterlacing only makes sense whenever you play interlaced content. Never ever set Deinterlacing to On - always keep it on Auto. As you are running a Baytrail ... it is not fast enough to support VPP-MADI in all cases - you should use VAAPI-BOB.

Exceptions can prove rules :-)

There may be times like mixed content (UK HD TV) when forcing on + MADI is the best way. I am thinking here of old threads where it was noticed that auto switching according to the stream flags caused a black frame - maybe that is solved?

With MADI in theory at least always on shouldn't hurt progressive as it's MADI so won't blend when not needed.

Yes - the 25p/50i encoder switching in use in the UK on terrestrial HDTV is confusing to many. It's chosen GOP-by-GOP AIUI - and AIUI the choice made by the TX encoder isn't always right...