Bug 79528

here is the link to the sample I was using: https://dl.dropboxusercontent.com/u/47522966/1080i50.ts

576i seems to work

Does it work on IVB ?

I don't have a IVB system for testing. I tried a mpeg2 1080i sample which was ok. Looks like it fails on any h264 regardless of size.

I would have thought that postprocessing would not care about codec

I got my IVB System up and running and it seems, that it totally ignores every method despite method 1 which is BOB (1):
LANG=US gst-launch-0.10 filesrc location=~/1080i50.ts ! tsdemux ! vaapidecode ! vaapipostproc deinterlace=1 deinterlace-method=3 ! vaapisink display=0
libva info: VA-API version 0.35.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_35
libva info: va_openDriver() returns 0
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...

(gst-launch-0.10:19451): GStreamer-CRITICAL **: _gst_util_uint64_scale: assertion 'denom != 0' failed
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
WARNING: A forward temporal reference is needed for Motion adaptive deinterlacing !!!
vaapisink Current fps: 19.36, Total avg fps: 19.36
vaapisink Current fps: 25.00, Total avg fps: 21.82
vaapisink Current fps: 25.00, Total avg fps: 22.79
vaapisink Current fps: 25.00, Total avg fps: 23.30
vaapisink Current fps: 25.00, Total avg fps: 23.62
vaapisink Current fps: 25.00, Total avg fps: 23.84
vaapisink Current fps: 25.00, Total avg fps: 24.00
vaapisink Current fps: 25.00, Total avg fps: 24.12
vaapisink Current fps: 25.00, Total avg fps: 24.22


gstreamer-vaapi version: 90713fdc442f27b4ea449b92660a294f7796f83e on branch 0.4 of git://gitorious.org/gst-plugins-vaapi/gst-plugins-vaapi.git

VAAPI:
vainfo: VA-API version: 0.35 (libva 1.3.2.pre1)
vainfo: Driver version: Intel i965 driver for Intel(R) Ivybridge Desktop - 1.3.2.pre1 (master)

Tennis.ts is working as it should with MADI (method 3), MACI looks so interlaced, that I am not sure it does anything at all.

@Haihao: Does that work on your test systems?

So, to summarize that correctly:

IVB:
1080i50ts h264 sample -> nothing despite BOB is doing anything, MADI / MACI does not deinterlace at all, but also does not produce green surfaces. See the "WARNING: A forward temporal reference is needed for Motion adaptive deinterlacing !!!"

tennis.ts: BOB, MADI are fine, MACI tells that it would do something - but in fact does nothing (might be not supported on IVB).

HSW:
Same as Rainer reported, tested on a core i5 4200U.

(In reply to comment #5)
> So, to summarize that correctly:

IVB:
1080i50ts h264 sample -> nothing
> despite BOB is doing anything, MADI / MACI does not deinterlace at all, but
> also does not produce green surfaces. See the "WARNING: A forward temporal
> reference is needed for Motion adaptive deinterlacing !!!"

Seems it is gst vaapi issue.

tennis.ts: BOB,
> MADI are fine, MACI tells that it would do something - but in fact does
> nothing (might be not supported on IVB).

MACI isn't supported on IVB.

HSW:
Same as Rainer reported,
> tested on a core i5 4200U.

Is there any software, library out there that has VPP succesfully imlemented on HSW, that proofs the driver is working correctly on real world data?

(In reply to comment #7)
> Is there any software, library out there that has VPP succesfully imlemented
> on HSW, that proofs the driver is working correctly on real world data?

As Rainer said 576i works without the warning message

(In reply to comment #8)
> (In reply to comment #7)
> > Is there any software, library out there that has VPP succesfully imlemented
> > on HSW, that proofs the driver is working correctly on real world data?
> 
> As Rainer said 576i works without the warning message

That was mpeg2. h264 fails on every size.

VPP doesn't know where the frame comes from :)

That we hope so.

From what I see, the driver goes in "no don't hurt me"-mode after it gets one time an empty reference list, which can easily happen when the material has a semi broken frame. It can easily happen, when processing real world data like live tv and so on.

As we are currently developing VPP for xbmc - do you have a sample that is known to be working?

I only checked MPEG-2 video too, I will try other H.264 samples

(In reply to comment #11)
> That we hope so.

From what I see, the driver goes in "no don't hurt
> me"-mode after it gets one time an empty reference list, which can easily
> happen when the material has a semi broken frame. It can easily happen, when
> processing real world data like live tv and so on.

How about falling back to BobDI for this case ?


As we are currently
> developing VPP for xbmc - do you have a sample that is known to be working?

You could return a bobbed surface and warn as it is already done right now, but the driver should not disable MADI for the rest of the processing just handle that case gracefully. Also please no assert.

That missing reference might always occur when one fast forwards.

Let's see what Rainer says. He has implemented support for every video decoding API on this linux planet and can share how vdpau, obsolete xvba and also dxva on windows handle that case.

(In reply to comment #14)
> You could return a bobbed surface and warn as it is already done right now,
> but the driver should not disable MADI for the rest of the processing just
> handle that case gracefully. Also please no assert.
> 
> That missing reference might always occur when one fast forwards.
> 
> Let's see what Rainer says. He has implemented support for every video
> decoding API on this linux planet and can share how vdpau, obsolete xvba and
> also dxva on windows handle that case.

I think falling back to bob is ok. The Windows driver for intel accepts one forward and one backward reference. None of those are mandatory.

fixed by recent changes of Gwenole:
https://github.com/gbeauchesne/libva-intel-driver/commits/17.vpp.vebox

(In reply to comment #16)
> fixed by recent changes of Gwenole:
> https://github.com/gbeauchesne/libva-intel-driver/commits/17.vpp.vebox

Well, I'd prefer to keep the bug open until the changes land the git master branch. :)

Can you reproduce this issue with the latest driver? I remember all patches have been merged into master branch.

all fine. this can be closed.

Thanks for your confirmation, closed it as fixed