[vlc] Re: Videoconference solutions
Rubén Lagar
ruben.lagar at gmail.com
Tue Oct 24 14:47:49 CEST 2006
I will try to explain myself.
A RTP stream is a lot of sequential UDP packets containing the
video/audio information.
You can specify the destiny ip adress and port of these packets. This is
where the user will receive the stream (eg 192.168.1.10:1234).
What I was asking is: is it also possible to specify the source UDP port
of these packets? The Ethernet interface will specify the local IP
adress, but what I was
asking was for the local UDP port. Now, the local UDP port is assigned
by the operating system randomly, it would be great to be able to
specify a concrete one.
I have tried those 2 parameters and they don't work as I say, I really
don't know what they are doing.
Mark Moriarty escribió:
> I'm not sure I understand -- VLC has settings for things like:
> #sout-rtp-port-audio=1230
> And
> #sout-rtp-port-video=1232
> Try using vlc --longhelp, to get a printout of the switches available.
> If you mean a physical Ethernet interface, a particular NIC, I generally use
> a route add command at a prompt, which tells the computer which NIC to use.
> -----Original Message-----
> From: vlc-bounce at videolan.org [mailto:vlc-bounce at videolan.org] On Behalf Of
> Rubén Lagar
> Sent: Tuesday, October 24, 2006 5:30 AM
> To: vlc at videolan.org
> Subject: [vlc] Re: Videoconference solutions
>
>
> 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,ac
>>>> o
>>>> dec=mp3,ab=96,channels=2}:duplicate{dst=std{access=rtp,mux=ts,dst=19
>>>> 3
>>>> .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
>
>
--
This is the vlc mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/support/lists.html
More information about the vlc
mailing list