[fritsch]

fetch the remote, checkout fernet's master branch and search :-)

[noggin]

Hmm - Not sure it's YADIF de-interlacing causing the problems - think there is something odd with software (well we don't have a choice of hardware ;-) ) 4:2:2 H264 decoding.

I have the same content in both 4:2:2 and 4:2:0 (the 4:2:0 version was transcoded from the 4:2:2 via baseband HD-SDI and ProRes HQ).

Playing back the 4:2:0 transcode with either YADIF 2x or W3FDIF (with either VAAPI or Sotware multithreaded decoding) delivers good results.
Playing back the 4:2:2 source with BOB gives better results than YADIF 2x (though not perfect) - there is still a strange effect on fast moving content (particularly saturated lighting) Watching the same thing with W3FDIF I get all sorts of blocking break up.

I also have to force de-interlace to on with 4:2:2 - de-interlace AUTO doesn't recognise that the content is native interlaced.

I think there are issues with 4:2:2 H264 support still.

Other observations :

4:2:0 software multithreaded decoding and W3FDIF also has issues. (Lots of frame drops/skips)
4:2:0 software multithreaded decoding and YADIF is OK and doesn't have the motion artefacts that YADIF has with 4:2:2 stuff.

4:2:0 VAAPI decoding on both YADIF - and I think W3FDIF (assuming I compiled correctly) - was fine. *** EDIT : I didn't compile correctly so was using YADIF still ***

(For info - 4:2:2 source was 38Mbs, transcode was around 35Mbs)

[noggin]

fetch the remote, checkout fernet's master branch and search :-)

I'm not an expert - just git cloned the fernetmenta xbmc git and did a recursive grep looking for "yadif". Couldn't see any other areas in the xbmc code where YADIF was involved - so think my W3FDIF mods were suitable for deinterlacing both software and VAAPI decoded video?

Think I've done enough to realise there's probably an issue with 4:2:2 - which is such a niche requirement (more so than Hi10p - though at least there is a reason for 4:2:2 !) that I suspect I'll just have to hope someone investigates.

[fritsch]

fritsch@t440s:~/Desktop/xbmc-fritsch/xbmc$ git grep yadif
xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecFFmpeg.cpp: m_filters_next = "yadif=0:-1";
xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecFFmpeg.cpp: m_filters_next = "yadif=1:-1";
xbmc/cores/dvdplayer/DVDCodecs/Video/VAAPI.cpp: filter = "yadif=1:-1"; <============================

[fritsch]

The change is a one liner ... CPU used is ultra high - my core i5 4200U cannot catch up at all - not with the simple and obviously not with the complex setting.

Edit: Btw.: Yadif can use slide threading, w3fdif for now has no threading support as it seems. You can see that with ffmpeg -filters

[noggin]

fritsch@t440s:~/Desktop/xbmc-fritsch/xbmc$ git grep yadif
xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecFFmpeg.cpp: m_filters_next = "yadif=0:-1";
xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecFFmpeg.cpp: m_filters_next = "yadif=1:-1";
xbmc/cores/dvdplayer/DVDCodecs/Video/VAAPI.cpp: filter = "yadif=1:-1"; <============================

Aaah! Cheers fritsch - missed that one. Suspect my Core i7 will similarly conk out if it isn't multithreaded.

[noggin]

Well I gave it a go with the VAAPI.cpp tweaked from yadif to w3fdif so I could software deinterlace VAAPI decoded stuff with w3fdif.

On an i7-2600K clocked at 4GHz I get CPU 0 sitting at 50% with simple coefficients and bouncing between 55 and 78% with complex coefficients. No frame drops or skips though. (All the other 7 CPUs sitting <10% most of the time)
Running with software decoding of MPEG2 4:2:2 one of my CPUs sits at 98-100% but the system just about copes without dropping or skipping.

Need to spend some time watching it and comparing to YADIF 2x.

Doesn't help my original issue - H264 4:2:2 stuff looking "weird"... Great way to spend an afternoon playing - and learned a little bit more than I knew this morning.

[FernetMenta]

according to the ffmpeg docu it should make use of more threads. will have a deeper look at this.

w3fdif
EDIT: .flags = AVFILTER_FLAG_SUPPORT_TIMELINE_INTERNAL,

means it does not support multi-threading. makes this filter pretty useless if not even an i7 can cope with it, no?

[noggin]

according to the ffmpeg docu it should make use of more threads. will have a deeper look at this.

w3fdif
EDIT: .flags = AVFILTER_FLAG_SUPPORT_TIMELINE_INTERNAL,

means it does not support multi-threading. makes this filter pretty useless if not even an i7 can cope with it, no?

My i7 is coping with it for VAAPI decoded content, and software decoded high bitrate MPEG2 4:2:2 and H264 4:2:0. It can't cope with software decoded high bitrate 4:2:2 H264 - but I think there is something odd going on there.

Interesting to compare it with YADIF 2x (particularly if it can be optimised). It's the standard de-interlacing filter in some broadcast kit (including Snell Alchemist standards converters I believe - which are the global standard for high quality 50i<->60i live field/frame-rate conversion?) It was added to ffmbc (and thus ffmpeg) by the BBC when their patent expired I believe. They've also added some software frame rate conversion (not PhC but pretty effective) that was also under patent until recently. Most of their News output file-based conversions are done in ffmbc I believe (so US inserts fed as a file will be converted from 60i to 50i using ffmbc-based processes these days. W3FDIF then a frame rate convert, then a re-interlace)

However - given that YADIF 2x works on a Celeron 2955U/1007U etc. I do see that most won't see any point in implementing Weston 3-field. Intellectual curiosity made me do it!

[FernetMenta]

My i7 is coping with it for VAAPI decoded content, and software decoded high bitrate MPEG2 4:2:2 and H264 4:2:0. It can't cope with software decoded high bitrate 4:2:2 H264 - but I think there is something odd going on there.

Maybe not. I think our renderer just does not support required PIX_FMT like PIX_FMT_YUV422P. Can you provide a sample of 4:2:2 ?

[noggin]

Yep - will do. I get reasonable results with H264 4:2:2 using YADIF 2x, it's not like the picture is totally borked, just that some elements have odd motion rendition - but not all. (Fast moving cameras past foreground elements or beams of lights moving quickly across frame)

[noggin]

FernetMenta - you have a PM

[FernetMenta]

What exactly do I have to look for. Both samples play fine and I can't tell any difference. Tried on i5-4570T Linux, sw multi-threaded decoding and on i7 Windows.
The i5 is approximately at 50% CPU playing the 4:2:2 sample with yadif.

[robo989]

Sorry super noob question, have looked but I just get confused...

"For HSW you need to install at least 1.3.2 version of libva-driver-intel"

How would one go about upgrading that on a working install, did try from scratch but I'm just going round in circles as can't find the proper instructions for building the driver, or a debian package to just simply install, added the VAAPI testing ppa but it's saying it's unavailable in the repo

Thank you in advance.
Also on a side note how do I go about getting username to show as donater, made a donation a few weeks back.

[fritsch]

No idea about the second question, for the first part:

Code:

wget https://launchpad.net/~wsnipex/+archive/ubuntu/vaapi/+files/i965-va-driver_1.3.2-2~trusty_amd64.deb https://launchpad.net/~wsnipex/+archive/ubuntu/vaapi/+files/libva-intel-vaapi-driver_1.3.2-2~trusty_all.deb

sudo dpkg -i *1.3.2*deb