Hi Arion, I can see 3 x 200ms pauses in the 25147 TsReader log, and this concurs with what I observed on screen. Each time this was associated with Audio to render < 100ms. Any suggestions on where to look?
[confirm] Continous glitches in LiveTV (both SD & HD) (1 Viewer)
- Thread starter BertTRP
- Start date
Hi Arion, I can see 3 x 200ms pauses in the 25147 TsReader log, and this concurs with what I observed on screen. Each time this was associated with Audio to render < 100ms. Any suggestions on where to look?
- October 20, 2007
- 52
- 4
- Home Country
-
Netherlands
I can confirm the problem being introduced after TSreader.ax version 25138 as well.
I swapped versions this morning... now my logs no longer contain entries like"Demux : Audio to render" and the Shift+1 graph look smooth as can be.
Most important... after watchting 2 hours of HD channels the stutters has NOT occured once!
Attached are my most recent tsreader log files before and after i've changed versions to rev25138.
Cheers
I swapped versions this morning... now my logs no longer contain entries like"Demux : Audio to render" and the Shift+1 graph look smooth as can be.
Most important... after watchting 2 hours of HD channels the stutters has NOT occured once!
Attached are my most recent tsreader log files before and after i've changed versions to rev25138.
Cheers
The new TsReader introduces a small pause (0.2 sec) to avoid constant stuttering when it runs out of data. It is not clear to me why the old TsReader does not produce heavy stutter with those streams.
If I find some time, I will compile a special version of the current TsReader that will detect and log underflows but will not try to correct them by pausing. The logs might give us a clue, why there is no stuttering even though we run out of data.
If I find some time, I will compile a special version of the current TsReader that will detect and log underflows but will not try to correct them by pausing. The logs might give us a clue, why there is no stuttering even though we run out of data.
I'm having the same issues. If I pause livetv and resume it, the stutter is completely gone...
Old TsReader 25138 didn't help me
Still seeing constant drops from 50 FPS to 33 FPS for 3-7 seconds.W7 32 bit \ DVB-S \ Performace plan \ Nforce 9400
The new TsReader introduces a small pause (0.2 sec) to avoid constant stuttering when it runs out of data. It is not clear to me why the old TsReader does not produce heavy stutter with those streams.
If I find some time, I will compile a special version of the current TsReader that will detect and log underflows but will not try to correct them by pausing. The logs might give us a clue, why there is no stuttering even though we run out of data.
That would be very much appreciated...
Regards, LiviHam
The new TsReader introduces a small pause (0.2 sec) to avoid constant stuttering when it runs out of data. It is not clear to me why the old TsReader does not produce heavy stutter with those streams.
If I find some time, I will compile a special version of the current TsReader that will detect and log underflows but will not try to correct them by pausing. The logs might give us a clue, why there is no stuttering even though we run out of data.
Contemplating:
In the first RC versions the tsreader.ax did not pause before starting the stream, it started immediately. This did not give any stuttering, accept on one german channel, Prosieben.sat.1.
To eliminate stuttering on that channel, the 0.2 sec delay was introduced in the following RC versions to prevent running out of data because of fps difference in provided and requested data.
But this fix caused stuttering on a lot of systems and for all channels because the 0.2 sec buffer runs out after a while. Pausing fixes this because then a buffer is built up again.
As I understand it now it really is weird, like you said, that the stuttering wasn't there before because there wasn't even a buffer at all! Now there is a buffer and when it runs out, stuttering begins...
I'd say the old situation is better than before, so I would revert back to the old situation until there is another solution for the Prosieben.sat.1 problem or a solution for the running-out-of-data problem we have now.
I hope you (or others) can crack this nut soon. But I can see it's a hard nut!
Actually the buffer has always been there, and there is no way for TsReader to work without one, it will stutter like hell. The change was that previously, when the buffer was depleted, we did not do anything and the stuttering in this case would be constant. Now instead of stuttering constantly we pause for 0.2 sec for adequate amount of data to build up in the buffer and then continue. This means that there is a longer but not constant stutter.
It is simply impossible to get away with having less data than you are trying to display. Settop boxes may not have a problem with this, because the display refresh rate is driven directly from the video stream info (the hardware clock is locked to the stream timestamps using a PLL type arrangement). AFAIK there is no PC video card that can do that.
It is simply impossible to get away with having less data than you are trying to display. Settop boxes may not have a problem with this, because the display refresh rate is driven directly from the video stream info (the hardware clock is locked to the stream timestamps using a PLL type arrangement). AFAIK there is no PC video card that can do that.
But before 25138 people report no stuttering. And that was when nothing was done when the buffer was depleted...is that correct?
Yep, that's what's curious about it.
OK, I understand correctly now
Then I'd still say the old situation is better than the current, so I would revert back to the old situation until there is another solution for the Prosieben.sat.1 problem or a solution for the running-out-of-data problem we have in the current tsreader.ax.
I think it's better to have a bug for just one channel in germany then a bug for all MP users on all channels. Even though it's unknown at the moment why it works. Don't you agree?