[vlc] Re: Videoconference solutions

Tue Oct 24 11:30:22 CEST 2006

By the way.... with this way of streaming from command line, is there 
any way to force VLC to use a concrete udp port in the local machine?

I  have tried
--sout-rtp-port 777
and
--rtp-client-port 7777

But they don't work. It would be great if there was an option to do this.

Thanks!

Mark Moriarty escribió:
> It sounds like people are doing well with this :)
> For me, what I've been using:
> I use a server command line like:
> c:\vlc\vlc.exe dshow:// :dshow-adev="none":dshow-vdev="Osprey-210 Video
> Device 1" :dshow-adev="none" :dshow-size="640x480" :dshow-amtuner-mode=1
> :sout=#transcode{vcodec=mp4v,vb=1536,scale=1}:duplicate{dst=std{access=rtp,m
> ux=ts,dst=239.20.30.40:1234}} :sout-transcode-fps=25.0 :sout-udp-ttl=4
> :sout-rtp-ttl=4
>
> And for the client is then:
> c:\vlc\vlc.exe rtp://@239.20.30.40:1234
>
> with:
> dshow-caching=40
> rtsp-caching=30
> realrtsp-caching=30
> sout-udp-caching=30
> udp-caching=30
> rtp-late=30
> sout-display-delay=30
>
> set for both sides (some of the delay values are for the TX end, others for
> the RX, but I'm lazy and just set them in VLCRC; likewise I know some of
> these aren't needed) 
>
> If anyone gets what they believe is the very best quality and low latency,
> please post :)
>
> -----Original Message-----
> From: vlc-bounce at videolan.org [mailto:vlc-bounce at videolan.org] On Behalf Of
> Rubén Lagar
> Sent: Monday, October 23, 2006 12:34 PM
> To: vlc at videolan.org
> Subject: [vlc] Re: Videoconference solutions
>
>
> You are right, now it is about half a second. With --sout-ffmpeg-keyint set
> to 4 or 5 it is not so bad quality.
>
> I would invite you to some beers for your help, but I think it is going to
> be difficult.
>
> Thank you very much!! :)
>
>
>
> Sigmund Augdal Helberg escribió:
>   
>> On Mon, 2006-10-23 at 17:55 +0200, Rubén Lagar wrote:
>>   
>>     
>>> Great, setting all parameters to 20, and setting those parameters you 
>>> told me, I got a delay of about 1 second. It is better now.
>>>
>>> But now the video quality is horrible, I will try to adjust these 
>>> parameters.
>>>
>>> vlc.exe -vvv -I rc --rc-quiet --sout-ffmpeg-bframes 0 
>>> --sout-ffmpeg-keyint 3 --sout-ts-shaping 100 --sout-ts-dts-delay 100 
>>> --sout-udp-caching 20 --realrtsp-caching 20 --rtsp-caching 20 
>>> --udp-caching 20 --dshow-caching 400 dshow:// vdev="" adev=""
>>> --sout=#transcode{vcodec=H263,width=176,height=144,vb=256,scale=1,aco
>>> dec=mp3,ab=96,channels=2}:duplicate{dst=std{access=rtp,mux=ts,dst=193
>>> .147.53.32:1234}}
>>>     
>>>       
>> I think it's possible to reduce shaping and delay a bit more. Also the 
>> real delay here (if you were down to 1s) is the 400ms dshow caching.
>> Increasing keyint will improve quality.
>>
>> Sigmund
>>   
>>     
>>> Sigmund Augdal Helberg escribió:
>>>     
>>>       
>>>> On Mon, 2006-10-23 at 14:28 +0200, Rubén Lagar wrote:
>>>>   
>>>>       
>>>>         
>>>>> Hello,
>>>>>
>>>>> I am working for a French company, and we want to include a 
>>>>> videoconference application in our web site (it is a collaborative 
>>>>> site). For this, we have been testing VLC as solution. It works 
>>>>> fine, we get a better sound and video quality than Skype.
>>>>>
>>>>> The way we have done this is including a VLC activeX in the web 
>>>>> page that shows the remote WebCam. For streaming we use a java 
>>>>> applet that runs VLC from command line, and stream the local webcam 
>>>>> to the remote site. We have solved also NAT issues, so anyone can 
>>>>> videoconference. As I say, it is really good quality, and video and 
>>>>> audio are fluid (we are using H263 and MP3 codifications).
>>>>>
>>>>> We have just one problem, that may cause that we drop VLC as 
>>>>> solution, and this would make me really upset. We can not remove a 
>>>>> 2 seconds delay from the system, what makes conversation a pain. I 
>>>>> have set to 0 almost every cache paremeter that I know, and the 2
>>>>>           
> seconds dealy is still there.
>   
>>>>>     
>>>>>         
>>>>>           
>>>> I think 0 is an invalid value for most caching options, and vlc will 
>>>> reset them to default if they are set to 0. I'd try to set the 
>>>> caching options to something like 20.
>>>>
>>>> Other options that may, or may not affect the delay:
>>>> --sout-ts-shaping and --sout-ts-dts-delay (if you use mux=ts) 
>>>> --sout-ffmpeg-bframes and --sout-ffmpeg-keyint (if you use ffmpeg 
>>>> for encoding (which I guess you do)). Try setting bframes to 0 and 
>>>> keyint to
>>>> 1 to get the lowest possible delay, then try increasing keyint and 
>>>> see if that improves quality without increasing delay (too much).
>>>>
>>>> Regards
>>>>
>>>> Sigmund
>>>>   
>>>>       
>>>>         
>>>>> I was wondering if any of the VLC developers could help me in 
>>>>> locating where is this delay located, to try to remove it.
>>>>>
>>>>> Thank you in advance,
>>>>> Rubén.
>>>>>
>>>>>     
>>>>>         
>>>>>           
>>>>   
>>>>       
>>>>         
>>   
>>     
>
> --
> This is the vlc mailing-list, see http://www.videolan.org/vlc/ To
> unsubscribe, please read http://www.videolan.org/support/lists.html
>
>   

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