[vlc-devel] Not respecting --rstp-caching if SDP aquired without RTSP Describe (was: What *-caching should we use?)

David Glaude david.glaude at gmail.com
Wed Apr 21 22:13:43 CEST 2010


Someone in my team think he found a potential explanation of our problem.

Our RTSP streaming are describe by SDP file that can be:
1) Dynamically generated based on a MP4 file
2) Dynamically adapted by a DSS based on the encoder SDP file
3) Statistic (such as a local file or a file downloaded with HTTP)

In all case we use the VLC "live" module from LIVE555.
We believe that when the SDP is not aquired with an RTSP Describe the proper
initialisation of the caching parameter is not done and our --rtsp-caching
parameter is not taken into account.

That would explain why we always have 320ms as caching for our multicast
stream.

Before opening something in trac, if someone who know the code can give it's
opinion... it would help.

Thanks for your help.

David Glaude

PS: Here are more detail.

1) When we access a Vod Stream with a rtsp://.../xxx.mp4 the --rtsp-caching
is respected and used:
--rtsp-caching 8000 =>
[00e31f44] main input debug: Stream buffering done (8036 ms in 8076 ms)
--rtsp-caching=2000 =>
[00e38314] main input debug: Stream buffering done (2036 ms in 1999 ms)

2) When we access a live unicast stream with a rtsp://.../xxx.sdp the
--rtsp-caching is respected and used:
--rtsp-caching 8000 =>
[00be18f4] main input debug: Stream buffering done (8001 ms in 7906 ms)

3) When the SDP file is not transmitted accross an RTSP Describe command
(such as reading from a local file) then --rtsp-caching is not respected:
--rtsp-caching=8000
[0048be34] main input debug: Stream buffering done (320 ms in 258 ms)
--rtsp-caching=60
[0048be34] main input debug: Stream buffering done (320 ms in 299 ms)

2010/4/20 David Glaude <david.glaude at gmail.com>

> Is the --rtsp-caching=xxx working for multicast live stream?
>
> We did run the following 3 lines
> $ "C:/Program Files/VideoLAN/VLC/VLC.exe" -vvv --rtsp-caching=100
> --verbose=2 MCAST.sdp &> caching=100.txt
> $ "C:/Program Files/VideoLAN/VLC/VLC.exe" -vvv --rtsp-caching=1000
> --verbose=2 MCAST.sdp &> caching=1000.txt
> $ "C:/Program Files/VideoLAN/VLC/VLC.exe" -vvv --rtsp-caching=10000
> --verbose=2 MCAST.sdp &> caching=10000.txt
>
> The result is always the same and the buffering done is always arround 320
> ms.
> [00e645c0] main input debug: Stream buffering done (319 ms in 289 ms)
> [00e6c078] main input debug: Stream buffering done (320 ms in 273 ms)
> [00e647f8] main input debug: Stream buffering done (320 ms in 304 ms)
>
> Where can we change this value?
>
> On a side note --rtsp-caching=60000 does work with unicast VOD where you
> really have to wait 1 minute before it start.
> Thanks
>
> David Glaude
> Le 17 avril 2010 13:10, Rémi Denis-Courmont <remi at remlab.net> a écrit :
>
>> Le samedi 17 avril 2010 14:01:51 David Glaude, vous avez écrit :
>> > We are still trying to get the most stable VLC with low latency. Nowdays
>> we
>> > try with VLC 1.0.5 waiting for 1.1.0.
>> > However we fail to see wich *-caching parameter we need to use.
>> >
>> > Our stream is multicast UDP+RTP packet described by an SDP file wich is
>> > downloaded via http and we are on WIN32 with VLC player (and next come
>> the
>> > IE pluggin).
>> live is --rtsp-caching; and that's what VLC will use given your SDP. Note
>> that
>> 10000 ms is really long. You might end up clogging up the buffers.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20100421/7abe5716/attachment.html>


More information about the vlc-devel mailing list