[confirm] Continous glitches in LiveTV (both SD & HD) (1 Viewer)

[LiviHam]

Perhaps the statement "no stuttering" is incorrect? A forced 200ms delay can be clearly seen, but something much shorter and who knows, perhaps quite frequent may not really be noticeable. The proposed special version may show this up, where the naked eye doesn't...

Regards, LiviHam

 

[kkendall]

Perhaps the statement "no stuttering" is incorrect? A forced 200ms delay can be clearly seen, but something much shorter and who knows, perhaps quite frequent may not really be noticeable. The proposed special version may show this up, where the naked eye doesn't...

Regards, LiviHam

I don't think that's it. Because people report that the error logs also are clean with the early version. The playback looks really supersmooth with that version, I can't imagine there is unnoticable stutter...
And even when there is stutter that nobody can detect with the human eye, I'd still prefer that over noticable freezes of 0,2sec twice a minute. At least untill there is a solution.

 

[LiviHam]

I think you are probably right - I couldn't think of any other explanation that would mask an underflow condition though...

Assuming there is no underflow, then perhaps the threshold for the 200ms pause is set too high? I don't know anything about the Prosiebien.sat.1 problem and what would happen if it was lowered, but a threshold of 100ms appears to be a nominal type value and some adjustment may be beneficial. My own logs show Audio to renderer sizes that are getting smaller, but the difference between successive logs are also tending to reduce and would perhaps bottom out somewhere >0 & <100. Perhaps there is a compromise threshold that would suit all?

How are the Audio/Video to renderer sizes determined?

Another observation is that it always appears to be audio that trips the pause on my system. Is that the same for others?

 

[CHli]

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.

I think someone is wrong on the Internet !

STB are driven by their own internal clock, but they benefit from the fact that one single clock source drives the audio and the video.

I don't think they would try to sync their internal clock to the DVB stream timestamp.

 

[arion_p]

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.

I think someone is wrong on the Internet !

STB are driven by their own internal clock, but they benefit from the fact that one single clock source drives the audio and the video.

I don't think they would try to sync their internal clock to the DVB stream timestamp.

If you read the standard about how to encapsulate an audio/video stream into a PES container and how to multiplex the PE streams into a Transport Stream, you will notice that there are a number of provisions to allow the receiver/decoder to derive its internal clock from the stream. This is usually done using a VCO controlled by the phase difference of the target clock (stream) and the VCO output (possibly multiplied/divided by an integer factor) in other words a PLL. Having a single clock source is not enough - it merely prevents A/V sync drift. The video refresh rate has to follow the stream clock or it would either run out of data or buffer space.

BTW: I did not mean that there is no video card that can sync its clock to the video stream (there is none but that in itself is not important). I meant that none offers fine enough control over their clock frequency, in order to implement a PLL in software. The finest control possible is through PowerStrip (which is closed source and commercial) and when I tested it on some ATI and nVidia cards control was not fine enough to allow seamless frame rate adaption.