Internal Player has problems switching from Progressive to Interlaced video scanning mid-playback

[John@…]

Hi, in the UK on Freeview HD (DVB-T2), some programs (mostly filmed using film) are transmitted using Progressive Scan, and others (mostly filmed using video) are transmitted interlaced. Now, the internal player correctly detects which of the two to use at the start of playback, but I don't think it can detect/switch between the two during playback, as the scan can change in the middle of a program. I believe set-top boxes use a GOP boundry in the bitstream to determine which mode to display (​http://www.bbc.co.uk/blogs/researchanddevelopment/2011/04/software-upgrade-for-bbc-hd-on.shtml)

From what i've seen, it seems to be-able to respond to a change from Progressive to Interlaced, but not the other way around, so it ends up trying to de-interlace progressive video, which wastes system resources and also blurs the progressive video slightly.

So maybe for 1080 video, the scan switcher could be tweaked to pick-up whether the scan changes, and react appropriately from the bitsream being recieved, rather than guessing for itself?.

[John Bergqvist <John@…>]

Basically, this is what I've found. Instead of Detecting the scan (i.e. so in the scan method it would be selecting: Detect (I) or Detect(P), it seems to be just falling back to Interlaced all the time, instead of Detecting the scan method. This happens whenever I start a video, or if I seek to a new part of the video where the encoding has changed from what it was before I seeked, if you get what I mean. It should be properly detecting the encoding every time a seek is made, every time the video starts-up, and every time a change in the encoding is detected, rather than just defaulting to de-interlacing. If I press the 'Detect' option manually, it correctly gives me the encoding all the time, it's just that doesn't happen automatically.

[paulh]

I assume this is still a problem with current master?

[paulh]

If this is still a problem any chance of making a small sample available that displays the problem?

[Stuart Auchterlonie]

Moving to 0.29

[Stuart Auchterlonie]

Milestone renamed

[Stuart Auchterlonie]

Moving remaining open tickets to 0.28.2 milestone

[Stuart Auchterlonie]

Moving remaining open tickets to 29.2 milestone

[paul-h]

Probably already fixed in 30.0. I'll let Mark decide.

[Mark Kendall]

7 years down the line and much has changed - and much has not.

The code now assumes progressive by default and switches to interlaced as needed - but generally will not switch back to progressive mid-stream.

I've opened a new ticket to track improvements for 0.32 (#13594)