[vlc-devel] Re: vlc: svn commit r13006 (fkuehne)

[Marian Durkovic]

Hi Derek, Felix,


   I really don't quite understand what's the problem here. In this context,
RTP is nothing else that UDP plus 12 bytes. But the huge difference is, that
it is standards based (RFC3550) and works properly over large networks 
(read Internet). It uses exactly the same payload format - MPEG2-TS.
In this context, we don't speak about RTSP and/or separate audio/video RTP 
streams.

   Could you please elaborate, what's the exact problem with replacing UDP by
RTP >>in streaming wizard<< ? I was under impression, that wizard is a easy-to
use tool, with limited choises (just UDP/HTTP) and my understanding is that
users should get the best possible alternative here for easy and reliable
streaming.  

   If there's a real case for raw UDP (e.g. set-top-box getting confused by
those 12 extra bytes), this option is available via StreamOuput dialog as
well as via command line. Anyway I consider clients not capable of
accepting RTP headers obsolete, since the RTP standard RFC1890 is here for
almost 10 years now. VLC/VLS sends/accepts RTP for 3 years - so now when
RTP reordering is available, I think it's the right time to make RTP the
defualt protocol and consider raw UDP special case only if needed.

   In any case, I'd suggest that RTP is at least added to the Wizard, since 
it's far better than raw UDP and most users don't have a real need for raw UDP.

   In case you wonder why I push RTP such much, please see the following
debug log for RTP stream from uoregon.edu to stuba.sk:

access_udp debug: RTP reordering: insert after 26002, new 26003
access_udp debug: RTP reordering: insert after 26009, new 26010
access_udp debug: RTP reordering: insert after 26017, new 26018
access_udp debug: RTP reordering: insert after 26027, new 26028
access_udp debug: RTP reordering: insert after 26033, new 26034
access_udp debug: RTP reordering: insert after 26037, new 26038
access_udp debug: RTP reordering: insert after 26062, new 26063
access_udp debug: RTP reordering: insert after 26064, new 26065
access_udp debug: RTP reordering: insert after 26079, new 26080
access_udp debug: RTP reordering: insert after 26092, new 26093
access_udp debug: RTP reordering: insert after 26096, new 26097

   As you can see, no packet was lost, but 11 out of 100 packets were 
reordered by the network. With raw UDP, you're lost - such stream is
completely unwatchable. With RTP, there's no single error.


	With kind regards,

		M.

   
  

On Fri, Oct 28, 2005 at 09:54:21PM +0200, Derk-Jan Hartman wrote:
> Hello Marian,
> 
> I applaud that you are so enthusiastic in your development efforts,  
> but I (and probably others) would also very much appreciate it if you  
> discussed making intrusive changes like this in the future. UDP is  
> not useless and has VERY specific uses for many of us. Please concur  
> with other developers on what is the best method of implementing  
> something.
> 
> DJ
> 
> 
> On 28-okt-2005, at 21:42, Subversion daemon wrote:
> 
> >r13006 | fkuehne | 2005-10-28 21:42:50 +0200 (Fri, 28 Oct 2005) | 1  
> >line
> >Changed paths:
> >   M /branches/0.8.4/modules/gui/wxwidgets/streamdata.cpp
> >   M /branches/0.8.4/modules/gui/wxwidgets/wizard.cpp
> >
> >* reverted [12957]. UDP-support is a must. don't remove it from the  
> >interface by overriding it with RTP
> >
> >-- 
> >This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
> >To unsubscribe, please read http://developers.videolan.org/lists.html
> >
> >
> >
> 
> -- 
> This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
> To unsubscribe, please read http://developers.videolan.org/lists.html
> 


--------------------------------------------------------------------------
----                                                                  ----
----   Marian Durkovic                       network  manager         ----
----                                                                  ----
----   Slovak Technical University           Tel: +421 2 524 51 301   ----
----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351   ----
----   812 43 Bratislava, Slovak Republic    E-mail/sip: md at bts.sk    ----
----                                                                  ----
--------------------------------------------------------------------------

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