dropouts when watching hd tv (3 Viewers)

[Owlsroost]

But again: what can I do to really get rid of this problem?
I mean obviously it's not that many people who have this problem.
Would changing the graphic card help? Is ATI known for this problem?

In terms of changing hardware, I don't know (I don't have the problem myself, so I've never tried to fix it with new hardware). I'd do the buffering tests first to make sure that it actually is a playback versus broadcast speed problem you have before you start changing hardware (and I don't understand why you don't have this problem with SD TV - unless these are different broadcasters using different delivery methods).

I used to have a version of TsReader that allowed me to adjust the playback speed using MPAR (for test purposes) - I'll check if I've still got it around (it might need a modified MPAR as well).

 

[Owlsroost]

@RicoHTPC Something to try

Attached is a new (experimental) version of TsReader which can slow down TV play by an adjustable, very small, amount. The idea is that running playback slightly slower should stop live TV running out of data and having to pause the graph to fix the issue.

Just replace the existing TsReader.ax (in C:\Program Files (x86)\Team MediaPortal\MediaPortal) with the new version and then play something in MP TV (to create a new registry key which you need to change to enable the new feature).

Open regedit and go to HKEY_CURRENT_USER\Software\Team MediaPortal\TsReader, find the "SlowPlayInPPM" value (it should have the value '0' ) and change it to decimal 100. The allowable range is 0 to 1000, but you shouldn't need much more than 100 - the value is the 'slow down' amount in parts-per-million, so 100 PPM = 0.01% slower than normal. To disable the feature just set the value to 0.

It works best when using LAV Audio decoder with the 'Auto A/V Sync correction' option enabled, and a standard audio renderer (not MPAR or ReClock).

As I said, this is very experimental, but I need someone who has the 'too fast playback' problem to try it out and provide feedback please.

Note - to allow this option to work best, if you have a client-server system use the 'UNC paths' mode (not the default RTSP mode).

 

[kilik360]

I do have dropouts to, but only with fix videos (TV). The video is great but I have dropouts in audio. It happens with the Colossus with variable bitrate (0 to 14)
in my case. If I put a CBR, I don't experience this issue. I'm pretty sure it's TsReader related because it happens on LiveTV and Recordings. And if I play the culprit videos from SMB it plays flawlessly.

I can post logs if you need it.

 

[Owlsroost]

I do have dropouts to, but only with fix videos (TV). The video is great but I have dropouts in audio. It happens with the Colossus with variable bitrate (0 to 14)
in my case. If I put a CBR, I don't experience this issue. I'm pretty sure it's TsReader related because it happens on LiveTV and Recordings. And if I play the culprit videos from SMB it plays flawlessly.

I can post logs if you need it.

We always need logs

Have you tried increasing the initial buffering delay ?

HKEY_CURRENT_USER\Software\Team MediaPortal\TsReader, set "BufferingDelayInMilliSeconds" to a (decimal) value in milliseconds (range is 0 to 2000, default is 0).

 

[mm1352000]

Really awesome work as always Owlsroost! It'll definitely be interesting to see what results other people have...

 

[Owlsroost]

Really awesome work as always Owlsroost! It'll definitely be interesting to see what results other people have...

All it's basically doing is (very slowly) pushing the sample timestamps further into the future. I tried the idea a long time ago, but couldn't make the audio side of it work properly.

Discovered this time that using the LAV Audio 'Auto A/V sync' option fixed the A/V sync problems I had before (and the LAV code gave me a clue as to what I needed to do in the TsReader code to make the idea work with other audio decode filters).

It might introduce artefacts into the audio occasionally, but I'm hoping that is much less of a problem than using 200ms pauses to fix the issue (as we do at present).

 

[HTPCSourcer]

@RicoHTPC , have you tested Owlsroost's TsReader? I was annoyed by the intermittent yet very short interruptions when watching football on Sky HD earlier today and remembered this thread.

I did increase the BufferDelay registry value to 100 ms some time ago but that did not change anything and I have been lazy noting the times and collecting logs. Have yet to try this TsReader.

 

[kilik360]

Have you tried increasing the initial buffering delay ?
HKEY_CURRENT_USER\Software\Team MediaPortal\TsReader, set "BufferingDelayInMilliSeconds" to a (decimal) value in milliseconds (range is 0 to 2000, default is 0).

Wow, I don't want to jump to conclusion too fast but, my first impression, I don't experience any audio dropouts after I add 10ms in "BufferingDelayInMilliSeconds". I add 500ms at first but when skipping in recordings or in timeshift, it was toooo long before it plays. 10ms is perfect !

thanks a lot ! I'll post back with true confirmation after more test.

 

[HTPCSourcer]

@Owlsroost , I've tried your tsreader.ax. With BufferingDelay = 0 and SlowPlay = 100 I still experience audible short interrruptions on my system. The sound breaks off for a split of a second. I could not see any visible picture dropouts - something that did happen before. My gut feel is that there are less incidents, hence it feels better but that's not yet a fully reliable assessment.

When I move back a minute in the buffer and play the same scene again, no interruption occurs. Therefore it should be OK to assume that the server stream itself plays OK and anything wrong happens on the client only, correct?

I'll continue monitoring this. Any log other than evr and tsreader needed?

 

[Owlsroost]

@Owlsroost , I've tried your tsreader.ax. With BufferingDelay = 0 and SlowPlay = 100 I still experience audible short interrruptions on my system. The sound breaks off for a split of a second. I could not see any visible picture dropouts - something that did happen before. My gut feel is that there are less incidents, hence it feels better but that's not yet a fully reliable assessment.

When I move back a minute in the buffer and play the same scene again, no interruption occurs. Therefore it should be OK to assume that the server stream itself plays OK and anything wrong happens on the client only, correct?

I'll continue monitoring this. Any log other than evr and tsreader needed?

There are two different 'data starvation' problems with live TV here:

1. The difference in rates between the broadcast stream and PC playback - the 'SlowPlay' option is designed to workaround the situation where the PC is playing faster than the broadcast stream is arriving.

2. The audio renderer might not have quite enough data buffered to keep it happy (so you get audio, but not video, dropouts/pauses) - the 'BufferingDelay' option is the best way to fix this because it allows the audio renderer to buffer more data at the start.

You may need to use both options - it just depends on the behaviour of your hardware, basically.

Note - to allow these options to work best, if you have a client-server system use the 'UNC paths' mode (not the default RTSP mode).

In both cases (providing it's single-seat or UNC paths mode), there shouldn't be problems playing recordings or delayed live TV, since then TsReader can get as much data as it needs.