[BigL-New]

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/mai...nt/CHANGES

The same with drm-intel-nightly. Message is little bit more informative, but still happens:

[drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=141704 end=141705) time 255 us, min 1073, max 1079, scanline start 1067, end 1084

[fritsch]

Good - then bugs.freedesktop.org is the way to go.

[fritsch]

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?

Yes - fully right.

[m_gl]

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.

[fritsch]

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.

[FernetMenta]

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.

[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

[m_gl]

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.

50fps i haven´t test, if i find a file i will do. I knew that 50 fps and 25 fps will be played at 50hz.
Anyway i will use sync to display and pcm, but i was curious whats the reason 23,79 and 24 fps playing fine and 25fps not.

[Milhouse]

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.

[D-an-W]

Hi fritsch, please excuse my ignorance...I am at the bottom of a STEEP learning curve here

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?

If it matters, I am using your OpenELEC-Generic.x86_64-6.0.95-fritsch.tar on my ASUS Chromebox M061U Desktop (Core i3 4010U 1.7GHz, 4GB RAM, 16GB SSD).

[fritsch]

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?

Hehe - yeah. You enabled "Use HQ scaling when scaling above 20%". That means: There won't be any HQ scalers when watching content > 1280 x 720 on a 1920x1080 Display. Those are automatically disabled then. Therefore you need to watch a 1280x720 file to be able to choose those settings. Got it?

Edit: All fine with what you did.

[D-an-W]

Thanks, I checked a 720p HD file and confirmed your recommended settings were in place. When playing a 1080p file the Video Scaling Method is shown as "Nearest Neighbour".

I just need to check now if my TV is capable of the full colour range or not (A THX Calibrated Panasonic TX-P55VT50B).

EDIT:

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.

[fritsch]

Exactly. That's how it should be. Background: Why would one use a high quality upscaler to process a 1080p file that _is_ already 1080p ...

Edit: My OE image uses Limited Range Passthrough 16:235 by default. If black is black - don't touch anything and keep it as is. Here, test with that sample: https://dl.dropboxusercontent.com/u/5572...k-nv12.mkv

[D-an-W]

Sample looks good thanks, should I also disable Dither as I am using the limited 16:235 range?

[fritsch]

Just keep it. It does not harm.