Re: [xine-devel] input_rtp now works with vbrick PATCH

[Graham B. <gb...@im...>]

If I get time in the next couple of days, I'll hack together a version=20
of input_rtp which uses a non-blocking socket and eliminates the read=20
thread to see how well it functions.

Graham


On Wednesday 14 January 2004 4:03 pm, Ramon van der Aar wrote:
> Here's my understanding (I'm not sure if I'm correct): nbc's
> purpose is to filter out errors during transmission over the
> network. The udp packages might arrive delayed, and therefore the
> player should buffer before starting to play. If a package is
> delayed the player can still play from it's buffer. In theory the
> buffer should never be empty, but it varies between a low and a
> high watermark if there are no real transmission errors. In case
> real transmission errors occur the buffer would reach the lower
> watermark (which may be 0% in my opinion) and the player will be
> paused. If transmission resumes, the buffer will reach the high
> watermark (which should not be 100%!! because packages will be
> dropped then, and poor playback is the result) and the player
> continues to play. This way a small network error will not disrupt
> playback. That's the purpose.
>
> Now in the rc2 version the calculation of the buffer fill was
> incorrect, and the buffer went from 20% fill directly to a 100%
> fill, jumping over the high watermark threshold, and packages were
> dropped causing the poor playback. Poor playback resulted in
> buffers getting empty, and in xine you saw a lot of "buffering
> xxx%". Now the thread in the input_rtp plugin deals with buffering
> and nbc is not realy used (which is wrong, I fully agree). But as I
> said before, it seems the buffer calculation is working correct at
> the moment, so the plugin can rely on nbc again.
>
> Ram=F3n