The VideoLAN Forums

Hi!

I'm currently maintaining a streaming server based on DSS.

As long as I used DSS 5.5.5 and vlc 0.8.6h/i everything was fine. Both UDP and TCP streaming worked pretty well on Linux, OS X and Windows.

Well, some weeks ago I tried to upgrade to DSS 6.0.3. vlc 0.8.6i unexpectedly started skipping at the beginning of streams a lot if TCP was used. eg. an audiostream of ~4 minutes skips often in the first 40 seconds with "PTS is out of range" messages. After that period the stream gets stable. So I decided to stay with DSS 5.5.

I recognized that DSS seems to start with doubled bandwith in TCP Mode for about 30-40 seconds and switches down afterwards. All the troubles occur in this "startup" phase.

Now vlc 0.9.2 appeared and I did some tests with our streaming server and a windows vlc. UDP works as expected. But TCP gets even worse. Feeding with DSS 5.5 VLC goes totally mad complaining about "audio drift too large" and upsampling to a speed nearly twice of normal and skipping a lot. After reaching about 1:30 of the stream in nearly half the time it resets back to normal speed and the stream continues perfectly. Again it looks like it's related to this double speed "startup" phase.

Switching to DSS6 shows the same effects described above usind vlc 0.8.6.

Using --rtsp-http shows the same effects.

Streaming video shows similar effects. Both video and audio is skipping. Video with "late picture skipped", audio with "PTS is out of range" or "audio drift is too big".

Streaming to quicktime client works perfectly. GStreamer 0.10.19 on Fedora 9 works nicely, too.

I'm happy about any help.

If needed I can provide URLs, tcpdumps, VLC debuglogs...

Regards, MASHtm

Hi!

I'm currently maintaining a streaming server based on DSS.

As long as I used DSS 5.5.5 and vlc 0.8.6h/i everything was fine. Both UDP and TCP streaming worked pretty well on Linux, OS X and Windows.

Well, some weeks ago I tried to upgrade to DSS 6.0.3. vlc 0.8.6i unexpectedly started skipping at the beginning of streams a lot if TCP was used. eg. an audiostream of ~4 minutes skips often in the first 40 seconds with "PTS is out of range" messages. After that period the stream gets stable. So I decided to stay with DSS 5.5.

I recognized that DSS seems to start with doubled bandwith in TCP Mode for about 30-40 seconds and switches down afterwards. All the troubles occur in this "startup" phase.

Now vlc 0.9.2 appeared and I did some tests with our streaming server and a windows vlc. UDP works as expected. But TCP gets even worse. Feeding with DSS 5.5 VLC goes totally mad complaining about "audio drift too large" and upsampling to a speed nearly twice of normal and skipping a lot. After reaching about 1:30 of the stream in nearly half the time it resets back to normal speed and the stream continues perfectly. Again it looks like it's related to this double speed "startup" phase.

Switching to DSS6 shows the same effects described above usind vlc 0.8.6.

Using --rtsp-http shows the same effects.

Streaming video shows similar effects. Both video and audio is skipping. Video with "late picture skipped", audio with "PTS is out of range" or "audio drift is too big".

Streaming to quicktime client works perfectly. GStreamer 0.10.19 on Fedora 9 works nicely, too.

I'm happy about any help.

If needed I can provide URLs, tcpdumps, VLC debuglogs...

Regards, MASHtm

We know about this problem. What DarwinSS does is something not defined in the RTSP specification and VLC currently cannot handle it very well. If you have any thoughts on how to handle it, we welcome it.

We know about this problem. What DarwinSS does is something not defined in the RTSP specification and VLC currently cannot handle it very well. If you have any thoughts on how to handle it, we welcome it.

Thanks for the info! I'll try to spend some more time investigating this issue.

Regards, MASHtm

We know about this problem. What DarwinSS does is something not defined in the RTSP specification and VLC currently cannot handle it very well. If you have any thoughts on how to handle it, we welcome it.

Thanks for the info! I'll try to spend some more time investigating this issue.

Regards, MASHtm

The problem is that we get data at Speed != 1 whereas DSS is not defining this. Thus we get packets with a time in the future which screws up our timing of the data processing.