BBC One HD This Autumn

Irritatingly the i/p change to the BBC HD Channel has an unfortunate side effect on my Sony KDL-32EX403, I am now experiencing frequent 'choking' of the Audio on the channel as a result. Have notified the BBC and it's been acknowledged.

Wonder how long this'll take for them to sort out.

It'll have to do it dynamically - the BBC specify 50i rollers on 25p content, rather than 25p, and masters are delivered as 50i.

I thought MBAFF (which the BBC use on DSat) supported progressive vs interlaced flagging on a macroblock basis (meaning static interlaced image areas can also benefit from progressive encoding) - with PAFF (which Sky used on DSat) supporting this on a whole-picture basis only?

Does look like the stats suggest 25p though - be interesting to see what happens. AIUI when US broadcasters did lab tests on set top boxes with dynamic 60i / 24p switching - loads of them froze, crashed or otherwise choked...

What H264 codec are you using, and if you're using DXVA which video card manufacturer?

(ATI cards had all sorts of issues with BBC HD on DSat for ages because of a fault in the way Microsoft and ATI handled the more advanced AVC tools being used by the BBC's encoders)

My graphics card:
NVida Geforce 9300M GS 256MB

H.264 decoder in DVBViewer:
CoreAVC 2.5 (it utilises GPU by using CUDA)

Ah - so it's not using DXVA (I.e. utilising the GPU and drivers for H264 decoding and acceleration using nVidia's algorithms) and instead is using CUDA (I.e. utilising the GPU as a computation tool and using CoreAVC's algorithms for H264 decoding)

I bought CoreAVC a while back - when I didn't have a proper DXVA graphics card that would support 1080i H264 decoding - and whilst impressed with its speed, wasn't hugely impressed with its quality (and when I tried it with CUDA after upgrading it seemed a bit worse)

That suggests that CoreAVC has an issue with the encoding being used. It took them quite a while to get MBAFF support into their product - as it didn't work with BBC HD in the early days (2006 ISTR) as the BBC (and then ZDF/ARD/Arte HD) were the first to use MBAFF extensions (which improve encoder efficiency) and at one point they charged extra for MBAFF support...

(Elgato's EyeTV (on the Mac) apparently uses the CoreAVC codebase - though presumably without access to CUDA-style acceleration.)

I've been using DXVA acceleration for a while now - with nVidia (9400 IGP - OK de-interlacing), ATI (4550 GPU - took ages for ATI/MS to fix when the Beeb changed encoders but decent de-interlacing once VA enabled) and Intel (i3-540 on-die IGP - rubbish at 23.976Hz - OK de-interlacing)

I suspect hardware decoders in set-top boxes and the like are more likely to be OK - as they go through more rigorous testing to ensure that they are fully H264 compliant for the profiles they are marketed to support. (Can you imagine the furore if a compliant stream didn't decode on a TV or set-top box?)

Only for uncompressed 50i vs 50p, not compressed. Also, for 50p, since not all set top boxes will have the chips needed, they're surely going to need to wait years to be able to broadcast 1080/50p if they decide to .

Yep - I suspect it's just dynamically switching the encoder between 50i and 25p modes based on content. 1080/50p isn't an option - it's not supported by the current UK DTG H264 profile AIUI.

Tonight was a good example

Wonders was in 1080p(25) whereas the previous Everything and Nothing was in 1080i(50), the continuity is peculiar though, afaics it seems to lag, it adopts the standard of the preceeding programme, the switch between the two if required occurring at the start of the next programme. Whether this is how the network will run in future is debatable.

No the switching is at content level, not programme/event driven, seems to be at GOP 'granularity'.

As Mark says - it must be the encoder doing the 25p/50i (aka p25/i25) switching dynamically based on what it sees coming into it. The BBC don't accept HD masters in the 25p format - all of their content will be from 50i format (aka i25) sources.

Shows like The One Show and Top Gear actively mix 50i and 25p content within their shows (Top Gear use 25p for their 'films' but the studio and lap stuff is 50i)

Similarly many dramas shot at 25p will have 50i rolling credits (the BBC stipulate that 25p rollers shouldn't be used), and some drama might drop in the odd 50i sequence for dramatic effect (simulating news footage for instance)

The encoder is presumably taking the decision as to whether to encode using 50i or 25p at something like the GOP level (switching on a GOP boundary?)

Presumably on mixes - where you may go from a 25p source to a 50i source and in the middle have both superimposed on the other, the encoder has to decide when to leave 25p mode and return to 50i? This is going to be tricky. (Standards converters have a similar problem when you roll or crawl semi-transparent graphics over moving sequences - and suddenly each pixel has TWO motion vectors not just one...)

I'll watch some content over the week with the SI overlay on, which details the source type, and see whether theres any dynamic 'in programme' switching between the two modes and report back.

And who sorts it out? Could be argued that if the BBC stream is compliant, it is Sony's job to sort out a firmware upgrade?

Suspect they'll suspend the tests until a solution can be found if it is all Sony T2 sets that have the issue.