(2015-11-07, 11:52)fritsch Wrote: Nope - not yet. Please go to bugs.freedesktop.org and file it accordingly if this did not already happen.

Edit: Check if your kernel contains this commit, mentioned in here: https://bugs.freedesktop.org/show_bug.cgi?id=91579
Edit2: You can try drm-intel-nightly before, please: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/CHANGES

(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-07, 02:16)FernetMenta Wrote: omx player is a different story. not even sure if it logs this. what exactly are your visual observations?

btw: the pi has some capability of "resampling" passthrough

(2015-11-07, 13:29)m_gl Wrote:

(2015-11-07, 02:16)FernetMenta Wrote: omx player is a different story. not even sure if it logs this. what exactly are your visual observations?

btw: the pi has some capability of "resampling" passthrough

The visual observations are judder with 25fps files (all i tested) and the strange thing is that all other fps are fine, even with passthrough.
With "sync to display" and pcm all is fine.

(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.

(2015-11-07, 14:51)FernetMenta Wrote:

(2015-11-07, 13:29)m_gl Wrote:

(2015-11-07, 02:16)FernetMenta Wrote: omx player is a different story. not even sure if it logs this. what exactly are your visual observations?

btw: the pi has some capability of "resampling" passthrough

The visual observations are judder with 25fps files (all i tested) and the strange thing is that all other fps are fine, even with passthrough.
With "sync to display" and pcm all is fine.

if it was a kodi or kernel issue, we would see the same symtom for 50 fps material because 25 fps plays with 50hz refresh rate. i am quite sure that this issue is intrduced by re-encoding. just don't use passthrough. it has zero advantage anyway.

(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

Quote:I have applied the recommended settings "While watching a SD(!) video, that is accelerated by VAAPI, e.g. mpeg-2 or h264" ok but do I concern myself with the settings when watching HD material as these are different when checked?

Quote:The DVI Input can be set to either Normal or Full, where Normal represents video levels (16-235) and Full corresponds to PC levels (0-255) but if the input is straight HDMI – rather than a HDMI to DVI connection – the VT50 will automatically operate in Normal mode.