[noggin]

Hi all

I have a GT640 nVidia card installed in a Core2Duo build from a few years ago. Am I right in assuming that 4:2:2 decoding isn't supported in VDPAU? When I play 4:2:0 stuff I get smooth playback and it appears to be using a VDPAU decoder, however 4:2:2 (quite high bitrate stuff) stutters badly, and appears not to be using a VDPAU decoder and so my C2D runs out of steam.

Wanted to check this was the case - have tried OpenElec and XBMCBuntu current releases.

If that is the case - does anyone have a suggested minimum Sandy/IvyBridge processor that would support 4:2:2 H264 content at around 38Mbs?

[nickr]

AFAIK VDPAU only supports 4:2:0.

[noggin]

Thanks nickr

Just tried running XBMCBuntu with a GT640 and i7-2600K build and that struggled with anything other than a Bob de-interlace. With Bob, one of the CPUs was running around 80%. With other de-interlaces it was hitting 100% and dropping frames badly.

I guess this means that 4:2:2 1080/50i H264 content is a bit too demanding for current XBMC Linux builds?

[nickr]

Well it is hard to know what is causing a bottleneck. Where is this material sourced from? Do you have a sample?

[FernetMenta]

hw decoders can only do 4:2:0.
sw decoding for 4:2:2 is single threaded whereas already multi threaded for Hi10p.

[Ned Scott]

Are people really trying to use Hi422P in a consumer setting?

[noggin]

Are people really trying to use Hi422P in a consumer setting?

Some of us are trying watch 1080i 4:2:2 MPEG2 and increasingly H264 content at home certainly.

They are the standards used used for most high quality satellite broadcast backhauls (i.e. the feed from the OB site to base, or from an international event to broadcasters showing it). This is usually of the order 24-40Mbs, though it can go higher (I've seen 60Mbs MPEG2 4:2:2 feeds in the past). (4:2:0 is really only used for lower-quality news-grade links)

These aren't always encrypted, particularly for major events (think Olympics Opening Ceremony, Eurovision Song Contest etc.) Being able to watch them in XBMC rather than VLC (or MPC-HC on Windows - with MadVR and LAV) would be useful - as the XBMC UI and Linux-based approach is much nicer than Windows or using a desktop-based app, and purely selfishly I watch everything else through XBMC and don't like changing apps!

There's quite a lot of this stuff around if you know where to look.

Similarly 4:2:2 MPEG2 / H264 is used for shooting broadcast material (and in some cases delivery)

---

Well it is hard to know what is causing a bottleneck. Where is this material sourced from? Do you have a sample?

DVB-S2 satellite backhauls of broadcast events. I'll see if I can extract a short segment using FFMBC.

Sounds as if single-threaded decode is the issue. I assume the CPU load change suggests that decode and de-interlace are handled by the same thread on the same CPU ?

The material can obviously be re-encode to 4:2:0 H264 - but this will introduce a reduction in quality and take a reasonable amount of time. Obviously nicer to watch the source unaltered if possible.

[Tent]

I guess this means that 4:2:2 1080/50i H264 content is a bit too demanding for current XBMC Linux builds?

let alone Planar 4:2:2 YUV 10-bit LE

[wsnipex]

did you try turning on multithreaded decoding(software only) in gotham builds?

[noggin]

did you try turning on multithreaded decoding(software only) in gotham builds?

Will report back. Haven't tried the H264 4:2:2 stuff in XBMC for a while. (I transcoded a lot to H264 4:2:0 using x264 to avoid the issue)

Hope it does help - be awesome if XBMC could play H264 4:2:2 live feeds streamed from a DVB-S2 TV Headend receiver or similar.

Since my original post the C2Duo board has been retired to server duties, and replaced with an i5-3570.

[noggin]

Just installed an OpenElec Gotham nightly from here : http://openelec.tv/forum/20-development-...tly-builds

Selecting "Allow frame-multi-threaded decoding" allows me to watch 1080/50i 4:2:2 H264 stuff fine. For some reason sometimes the CPU spread on my i5-3570K seems to vary with files (though all are H264 4:2:2 at roughly the same 34Mbs bitrate) In one case one CPU was at about 60%, the others at around 3-5% (though which CPU was under most load kept changing), whilst with another file it appeared more equally spread at around 15-20% per CPU.

What I have noticed is that I have to force de-interlacing to ON, in AUTO mode it doesn't recognise that the source is interlaced (which it definitely is). I wonder if the interlace/progressive detection is confused by 4:2:2?

(The content is a mix of 25p and 50i native content)

Very happy with this result. Many thanks to the developers for the continual improvement. (Being able to watch 4:2:2 H264 content is a great bonus for me - and I know a few others who will be very grateful to have it. Now if only there was an Open Source Dolby E decoder...)

[noggin]

I notice that the latest OpenElec 3.95 Beta 4 still has the issue of not de-interlacing native interlaced 4:2:2 H264 content in AUTO mode (you have to force de-interlace to ON). Is there anywhere I can log this?

[nickr]

Post in bug tracker?

[noggin]

Hmm - noticed another issue with H264 4:2:2 decoding (software multithreaded).

I have the same content in 4:2:2 and 4:2:0 H264. One was derived from the other (not via a straight transcode - but via baseband and through a non-linear editor). It is interlaced native 50i (i.e. with motion between the fields in a frame).

When I watch the 4:2:2 H264 source (using a YADIF 2x de-interlace) there are some strange motion artefacts on fast moving elements (stuff really moving quickly through frame) that appears to give them 25p rather than 50p motion. The same content watched 4:2:0 H264 - either using software or hardware VAAPI decoding - and a YADIF 2x de-interlace looks OK. The 4:2:2 content is around 38Mbs, the 4:2:0 (encoded for Blu-ray) is VBR averaging a bit less.

Could there be something odd about how the 4:2:2 decoding is implemented? (Something to do with MBAFF? PAFF?)