bad PTS after 3-5 hours of http streaming

[drus]

hello

i'm trying to make server-client streaming of audio. server and client have windows xp sp2
i'm using vlc-0.8.4a and vlc-0.8.5. but the situation is the same with both versions.
so, i use wxwidgets interface, but i'll try to write server mrl:

Code: Select all

vlc dshow://:dshow-vdev="none":dshow-adev="NVIDIA(R) nForce(TM) Audio":dshow-size="" --sout='#transcode{acodec=mpga,ab=192,channels=2}:duplicate{dst=std{access=http,mux=ts,dst=:1234}}'

the client mrl is simple:

Code: Select all

vlc http://192.168.0.5:1234

so, at first it works well, the only messages are:
main audio output warning: buffer is 40739 in advance, triggering downsampling
main audio output warning: resampling stopped after 9533078 usec (drift: 51)
main audio output warning: buffer is 40005 in advance, triggering downsampling
main audio output warning: resampling stopped after 9639512 usec (drift: -135)

but after few hours of streaming the sound disappear, cpu load is 100% on client-side. and in the log i've got messages like:
main audio output warning: PTS is out of range (4674343), dropping buffer

on server there are no critical mistakes, the stream is going, if i reconnect client, it works fine again, but only 3-5 hours

can anybody help with it? why such things appear?

[The DJ]

Answer. Don't use HTTP. It's not a streaming protocol. it's a file protocol.

RTSP or UDP/MPEG2TS are the only protocols that I recommend for streaming.

[drus]

thank you for answer i'll try today this variant.
but one more question:
yesterday i made the same server-client streaming, but i used linux server (vlc-0.8.4a), and windows client (vlc-0.8.4a). on server side i used v4l module. all other parameters were the same. today i've got no error messages on client side, but it worked all night.
there is a supposition that windows have not accurate system clock.
what do you think about it?

thank you

[md]

As The DJ pointed out, HTTP is not the way to go. The problem is that you have two independent freerunning clocks which after some time unavoidably create buffer underruns or overruns.

I'd recommend using MPEG2-TS over RTP which is the most robust implementation.

(BTW, I'm afraid with live555 library the clocksynchro algorithm is disabled and as such it's subject to the same problems as HTTP)

[drus]

As The DJ pointed out, HTTP is not the way to go. The problem is that you have two independent freerunning clocks which after some time unavoidably create buffer underruns or overruns.

I'd recommend using MPEG2-TS over RTP which is the most robust implementation.

(BTW, I'm afraid with live555 library the clocksynchro algorithm is disabled and as such it's subject to the same problems as HTTP)

hm. but if problem is in freerunning clocks on two different computers, than how can streaming protocol influence it?
how i can enable live555 in windows? i remember such library in linux, but i don't know it's functions.

[md]

The difference is in transport layer. HTTP uses TCP, while RTP uses UDP.

UDP is much less complicated than TCP and simply delivers the packet to the application as soon as it's received. This is an advantage, because by comparing the time when UDP packets were received with the timestamps inside the MPEG2 TS you can compute the clock difference and compensate the drift.

Live555 in included in windows versions - but it is not used for MPEG2 TS container.

[drus]

Answer. Don't use HTTP. It's not a streaming protocol. it's a file protocol.

RTSP or UDP/MPEG2TS are the only protocols that I recommend for streaming.

it really works even in windows, thank you ^_^

because by comparing the time when UDP packets were received with the timestamps inside the MPEG2 TS you can compute the clock difference and compensate the drift.

Live555 in included in windows versions - but it is not used for MPEG2 TS container.

does it mean that some other muxer will work fine with http? for example asf.