[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