Judder/Stutter on BBC1 & 2 HD via DVB-S2

For country-specific questions and topics regarding Media Center

Re: Judder/Stutter on BBC1 & 2 HD via DVB-S2

Post#21 » Wed Jul 03, 2013 11:14 am

AndyBMK wrote:I'm sorry Alun and Holidayboy, the honest answer is that I simply don't know. The issue is certainly quite complex as I understand the problem can still exist using some of those "immune" GPUs unless post-processing has been disabled. Ideally the issue should, of course, be corrected at its source however I suspect the BBC is very unlikely to resolve it since it has been one that has affected DVB-T2 users for longer (and I'm assuming it's still ongoing with Media Center users of that platform unless they've tried workarounds). I don't know if the issue also affects MediaPortal, XBMC, etc on Windows and / or Linux or just us. Either way I think since HTPC users form a relatively-small number of viewers I just can't see the problem being resolved at the pre-broadcast stage (I live in hope I'm wrong though!).
If Microsoft can't be arsed fixing it (the LAV example demonstrates that it is "fixable") it's a fair bet that the BBC won't fix it either.
foxwood
 
Posts: 1743
Joined: 7 September 2012

Post#22 » Wed Jul 03, 2013 11:22 am

There's a lot of very heated debate on some other forums (chiefly in the US with the 29/60 "bug") whether Microsoft should do a fix or if the GPU manufacturers should resolve the problem!
AndyBMK
 
Posts: 6
Joined: 3 July 2013
Location: Milton Keynes, GB
HTPC Specs: Show details

Post#23 » Wed Jul 03, 2013 12:07 pm

The best place to fix it would be in Microsoft's code. The fix would work for everyone, and it would only apply to the content that people see a problem with. Fixing video drivers would mean that some will, some won't, and some people will have to compromise between a setting that fixes WMC but breaks some other function that they also use the PC for. But there will never be a fix from MS.

At this point, the best outcome would be for someone with the necessary skills to figure out how to make FF/Rewind work with the LAV drivers. It could become a universal solution.
foxwood
 
Posts: 1743
Joined: 7 September 2012

Post#24 » Wed Jul 03, 2013 5:55 pm

According to this Microsoft link, there is still no known resolution
http://support.microsoft.com/kb/2658140

Although the knowledge base article suggests a faster GPU may help, from my experience this only applies to MPEG2 HD broadcasts in the US. For MPEG4/AVC in the UK, there seems to be no hardware workaround. As others have already said, changing from the MS decoder to LAV does fix the stuttering, but this is not a trivial change, and there is an associated loss of functionality.

IMO we're dependent on Microsoft updating their AVC decoder (presumably to prevent the video pipeline from being reset at each frame-rate change), or alternatively on the BBC reconfiguring their encoder to the way it was a few weeks ago.

Optimistically, I wonder if Windows 8.1 has anything to offer, or if the post-Wimbledon/3D broadcasts will be stutter-free again.
Pixelz
 
Posts: 99
Joined: 10 June 2011
Location: UK
HTPC Specs: Show details

Post#25 » Wed Jul 03, 2013 7:40 pm

I've checked the 4-1-1 info screen as suggested in the linked Wiki article but mine is always showing 50 fps even while juddering like crazy.

Can anybody else report back their finding in 4-1-1 screen ?
wally007
 
Posts: 88
Joined: 24 August 2012

Post#26 » Wed Jul 03, 2013 8:36 pm

That's exactly what I found. No change in the fps reported, but still juddering.
wyerd
 
Posts: 24
Joined: 28 June 2011

Post#27 » Wed Jul 03, 2013 9:05 pm

Me too, I stared intently at the frame rate display for ages and nothing changed even briefly

I wonder, is there a tool of some sort that can take a .wtv file and analyze the stream at a frame level to see if this is indeed the problem?
AlunS
 
Posts: 18
Joined: 7 May 2012

Post#28 » Wed Jul 03, 2013 11:04 pm

I've recorded a small piece from Wednesday night's BBC One HD 10 O'Clock News during the Wimbledon report with a camcorder and passed the output through VideoReDo so I could capture some individual frames from the movie as JPG files. Throughout the recording the fps shows 50 most of the time but every few seconds, sometimes more frequently, the "50" flickers in real time. When each frame of the camcorder movie is seen, you can just about make out the 50 momentarily changes to 25. I've uploaded the JPGs, please see http://www.flickr.com/photos/98400451@N06/. Frames 1 to 4 show the sequence in consecutive frames and the 25 lasts less than one tenth of a second in this sequence. A few seconds later (frames 5 to 8) I captured a drop from 50 to 47.9521.

Apologies for the low quality capture but it seemed the quickest way to demonstrate what I see; I'm not sure why all PCs aren't showing the same thing.

The issue definitely improved significantly (if not 100%, certainly enough to not see it as a major problem) when I swapped my GPU to the HD 6450. I was lucky that I had one of the "immune" ones elsewhere in my house but might have felt reluctant to go and buy a new one just to see if it did the trick. Just hoping you guys can possibly borrow a GPU shown on the list from somewhere just to see if it works for you (sorry AlunS, I know that's not an option for you).
AndyBMK
 
Posts: 6
Joined: 3 July 2013
Location: Milton Keynes, GB
HTPC Specs: Show details

Post#29 » Wed Jul 03, 2013 11:46 pm

There is more to this issue for UK content than there is for US content. The UK content is intentionally encoded with a mixture of progressive and interlaced frames, thus the progressive_frame flag fluctuates legitimately. This differs from US content, where only hard-telecined content ever legitimately contains a mixture of progressive and interlaced frames (and most telecined content in the US is soft-telecined, not hard-telecined).

I am currently using an Intel HD4000 GPU, and it plays US 29/59 content smoothly. I attempted to play a clip of UK 25/50 content, and it does not play smoothly on my GPU. This leads me to believe that something else is happening besides a just the change in the progressive_frame flag.

foxwood wrote:The best place to fix it would be in Microsoft's code. The fix would work for everyone, and it would only apply to the content that people see a problem with.

It is impossible to "fix" the progressive_frame flag fluctuations by altering Microsoft's code. First, you can't fix something that isn't broken (UK content is flagged correctly, and US hard-telecined content may be flagged correctly). Second, even if the progressive_frame flag is set incorrectly, how do you logically determine what it is supposed to be? And of course, even if you did figure out some way of determining the correct state of the progressive_frame flag, it would still fluctuate with content that contains legitimate fluctuations (like the UK content or hard-telecined content), so the side-effects (stuttering, blanking, flickering, etc.) would still exist on certain GPUs/drivers/settings.

That said, I think the other MPEG-4 decoding issues can certainly be fixed by altering Microsoft's code. However, that's just my opinion. I don't know enough about the MPEG-4 issues (sans progressive_frame fluctuations) to make any kind of educated statement one way or the other.
richard1980
 
Posts: 2623
Joined: 8 June 2011
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#30 » Thu Jul 04, 2013 1:45 am

richard1980 wrote:
foxwood wrote:The best place to fix it would be in Microsoft's code. The fix would work for everyone, and it would only apply to the content that people see a problem with.

It is impossible to "fix" the progressive_frame flag fluctuations by altering Microsoft's code.
Richard, nobody cares about fixing progressive frame flag fluctuations. We only care about "fixing" the display of content so that people can't see the juddering. It absolutely IS possible to display this content without judder, and the only reason it won't be fixed in WMC is because Microsoft has no interest in fixing it.
foxwood
 
Posts: 1743
Joined: 7 September 2012

Post#31 » Thu Jul 04, 2013 3:53 am

AlunS wrote:I wonder, is there a tool of some sort that can take a .wtv file and analyze the stream at a frame level to see if this is indeed the problem?

Not that I'm aware of. I've had to either convert files to a different format or manually read the headers in a hex editor. I used to have a program that would allow me to step through frame by frame and it would show me the headers. I really liked that program because it had a video screen and I could view the header data along with the recomposed picture simultaneously...which allowed me to identify when the progressive_frame flag was set incorrectly. It seems like I also had a command line program that would accept a file for input and it would spit out a text file that contained the header info. Unfortunately I haven't used either of those two programs in quite a while, and I don't remember the name of either of them. I'll do some digging and see if I can find anything. If I find something, I'll post back. In the meantime, you should be able to open the file in a hex editor to check the various flags. Of course, that will require you to be familiar with the MPEG headers. I haven't really looked into MPEG-4, but I know there is quite a bit of info on the web about the MPEG-2 headers.

foxwood wrote:We only care about "fixing" the display of content so that people can't see the juddering. It absolutely IS possible to display this content without judder, and the only reason it won't be fixed in WMC is because Microsoft has no interest in fixing it.

Before you assume that Microsoft has no interest in fixing anything, you should consider whether or not a solution is actually viable. Since the judder (at least for US 29/59 content) is caused by dropped frames due to the time a GPU takes to switch the state of the interlacer/deinterlacer, the only way to stop the judder (without changing the GPU or the GPU settings) would be to stop the GPU from switching the state of the interlacer/deinterlacer...by either forcing it into a constant on or off state or by performing the processing with the CPU instead of the GPU. Forcing the interlacer/deinterlacer into a constant on or off state would work if MPEG streams were always composed of either 100% interlaced frames or 100% progressive frames. Unfortunately, they aren't. A lot of content (e.g., hard-telecined content and some UK content) legitimately contains a mixture of both interlaced and progressive frames. If you try to force that content to be processed one way or the other, picture quality will be terrible. You can reference the WEC wiki that was previously linked for some examples. Performing the processing with the CPU instead of the GPU certainly is an option. Of course, it's a 20-year step backwards, and copy protected content could not be played (due to the lack of a protected path), not to mention the fact that CPU performance is highly unpredictable.

So I don't think it's a case of Microsoft having no interest in fixing anything...it's just that solution isn't very good, and IMO (and probably Microsoft's as well) it's actually worse than leaving things as they are.
richard1980
 
Posts: 2623
Joined: 8 June 2011
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#32 » Thu Jul 04, 2013 10:16 am

This is all starting to get a bit over my head, but there's one thing I don't really understand here. I can sort of understand why a broadcaster might want to switch between progressive/interlaced when switching from one source to another, for a reasonably long period, but this seems to occur several times, in the same scene, from the same source, and only for a tiny fraction of a second at a time.

Now, what possible advantage can that offer to the broadcaster to do it that way?

BTW looking more carefully at the LAV decoder settings it would appear that it doesn't support HW interlacing using DXVA2, only CUDA, so that might explain why we're not seeing these problems with LAV.
AlunS
 
Posts: 18
Joined: 7 May 2012

Post#33 » Thu Jul 04, 2013 10:51 am

I really doubt we're seeing 29/59 bug mentioned. During Formula 1 race, when there were long panning shots from helicopter, video would be smooth for 4-5 seconds, then stutter for 2 and then smooth again.
So in span of 10 seconds from same source (camera) you'd have smooth video with stutter in middle of it and stutter again and so on ....
wally007
 
Posts: 88
Joined: 24 August 2012

Post#34 » Thu Jul 04, 2013 11:45 am

The BBC originally wanted to have DRM on the Freeview HD channels, they just encrypt the Freeview HD EPG now. If I was a more cynical person then I'd say that they saw how non "official Freeview HD" boxes were struggling with the new encoders and decided to use them on Freesat HD too!
User avatar
holidayboy
 
Posts: 2442
Joined: 5 June 2011
Location: Northants, UK
HTPC Specs: Show details
5+ YrsTGB VeteranStaff
Rob.

TGB.tv - the one stop shop for the more discerning Media Center user.

Post#35 » Fri Jul 05, 2013 3:29 am

AlunS wrote:This is all starting to get a bit over my head, but there's one thing I don't really understand here. I can sort of understand why a broadcaster might want to switch between progressive/interlaced when switching from one source to another, for a reasonably long period, but this seems to occur several times, in the same scene, from the same source, and only for a tiny fraction of a second at a time.

Now, what possible advantage can that offer to the broadcaster to do it that way?

http://www.bbc.co.uk/blogs/researchandd ... d-on.shtml

"A great deal of material is shot natively at 1080p25 and there are significant advantages in maintaining 1080p25 through to the viewer's display. Within a single programme interlaced may be used for moving credits, cross-fades and studio shots whereas progressive may be used for location shot material."

But that's not all. A single video frame often contains data from multiple sources, and those multiple sources may not be encoded the same way. The correct way to create such a frame would be to standardize all of the sources so that the resulting frame is either fully progressive or fully interlaced, but that's not always what ends up happening. Sometimes video editors take shortcuts, resulting in a single frame that contains a mixture of both interlaced and progressive material. In such a scenario, there's really no telling how the frame will actually be encoded.

wally007 wrote:I really doubt we're seeing 29/59 bug mentioned.

It has already been confirmed that the content in question is encoded with mixed progressive_frame flags. However, it has not been confirmed that the progressive_frame flag fluctuations are responsible for the problems that are being described.
richard1980
 
Posts: 2623
Joined: 8 June 2011
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#36 » Fri Jul 05, 2013 8:13 am

That's all very well, but the fact remains that before this change they seemingly managed to transmit everything in interlaced mode, regardless of what odd mixture of progressive/interlaced mode the program material was delivered in, so why can't they continue to do so?
AlunS
 
Posts: 18
Joined: 7 May 2012

Post#37 » Fri Jul 05, 2013 6:32 pm

its pretty annoying watch the tennis right now...
bobbob
 
Posts: 676
Joined: 26 October 2011

Post#38 » Fri Jul 05, 2013 7:14 pm

AlunS wrote:That's all very well, but the fact remains that before this change they seemingly managed to transmit everything in interlaced mode, regardless of what odd mixture of progressive/interlaced mode the program material was delivered in, so why can't they continue to do so?

  1. Conversion from progressive to interlaced is a downgrade.
  2. If they plan on just passing along whatever signal they receive, they can take their encoders out of commission. I'm betting this is probably a bigger factor than trying to deliver a better picture quality.
richard1980
 
Posts: 2623
Joined: 8 June 2011
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#39 » Sat Jul 06, 2013 9:35 am

I have this issue too... Very frustrating. I hope a solution comes along soon!

The only thing I can do at the moment is to watch back recordings in a different media player...
ziggyball
 
Posts: 2
Joined: 6 July 2013

Post#40 » Sat Jul 06, 2013 11:51 am

ziggyball wrote:The only thing I can do at the moment is to watch back recordings in a different media player...
You must be mistaken - according to Richard, any fix implemented in software is actually worse than just leaving things as they are.
foxwood
 
Posts: 1743
Joined: 7 September 2012

PreviousNext

Return to International Issues



Who is online

Users browsing this forum: No registered users and 1 guest

cron