(2015-11-07, 12:34)noggin Wrote:

(2015-11-07, 06:22)ilovethakush Wrote: 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.

(2015-11-07, 16:04)Milhouse Wrote:

(2015-11-07, 15:05)m_gl Wrote:

(2015-11-07, 13:32)fritsch Wrote: 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.

(2015-11-07, 17:15)ilovethakush Wrote:

(2015-11-07, 12:34)noggin Wrote:

(2015-11-07, 06:22)ilovethakush Wrote: 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"?

(2015-11-07, 19:53)fritsch Wrote: 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.

(2015-11-07, 12:51)noggin Wrote:

(2015-11-07, 12:39)fritsch Wrote: 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?

(2015-11-08, 14:37)AndyFurniss Wrote: 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.

(2015-11-07, 19:53)fritsch Wrote: 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.

(2015-11-08, 15:02)AndyFurniss Wrote:

(2015-11-07, 19:53)fritsch Wrote: 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.