[vlc-devel] Re: vlc: svn commit r19076 (sigmunau)

Christophe Massiot massiot at via.ecp.fr
Thu Mar 1 18:42:26 CET 2007


Hello Remi,

On Thu, Mar 01, 2007, Remi Denis-Courmont wrote:

> Does it freezes UDP stream output or "merely" makes it miss deadlines, or
> what ? No ticket, no explanation...

The problem is that whenever I start streaming, I get thousands of these
messages with increasing delay :

[00000325] access_output_udp private debug: packet has been sent too late (20821)
[00000325] access_output_udp private debug: packet has been sent too late (22908)
[00000325] access_output_udp private debug: packet has been sent too late (25002)
[00000325] access_output_udp private debug: packet has been sent too late (27106)
[00000325] access_output_udp private debug: packet has been sent too late (29202)
[00000325] access_output_udp private debug: packet has been sent too late (31298)
[00000325] access_output_udp private debug: packet has been sent too late (33401)
[00000325] access_output_udp private debug: packet has been sent too late (35502)
[00000325] access_output_udp private debug: packet has been sent too late (37599)
[00000325] access_output_udp private debug: packet has been sent too late (39712)

Meaning that the access_out udp can't stream as fast as necessary (this
is udp/ts BTW).

> In the first case, it's definitely a bad kernel bug (bad as in bug that
> potentially breaks many things), is not VLC-specific and ought to be
> reported to kernel bugzilla.
> 
> If it is a deadline problem, then you should rather fix the translation
> from mtime_t to timespec that would be buggy. BTW, this patch does not
> suppress clock_nanosleep() at all; what it actually does is add an extra
> clock_gettime() call before clock_nanosleep() - which is bound to be
> slower.

This is not entirely true - if you look closely at the source, Sigmund's
version has an extra condition before calling clock_nanosleep :

    mtime_t delay = date - mdate();
    if( delay > 0 )
        msleep( delay );

However, commenting out the if() doesn't reintroduce the problem, so it
doesn't seem to be related. I am not as familiar as you with the
clock_nanosleep behaviour, but I can only suspect a kernel or libc bug
at this point.

-- 
Christophe Massiot.

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html



More information about the vlc-devel mailing list