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

[Viktor Kompaneyets]

Marian Durkovic wrote:

> On Tue, Nov 01, 2005 at 11:35:24AM +0200, Viktor Kompaneyets wrote:
>> > What
>> > application are you using for receiving the raw UDP streams? Do you
>> > have source code of this aplication?
>> 
>> Yes, I have. I had _removed_ RTP from them to achive better wandwith
>> consumtion (with RTP it is not enough!)
> 
> Well, VLC puts 7 TS packets into one UDP frame - this is 1316 bytes. UDP
> header is 8 bytes, IPv4 header 20 bytes. So alltogether it's 1344 bytes.

Your assumption is based on Ethernet framesize. There are a lot of other
(ATM, SDH etc..), which MTU is less or more than 1500bytes. 

In other words - if I'm putting 20 TS streams with 4.5Mbit/s bandith each -
with RTP I can't send it alltogether with RTP thru 100Mbit/s Ethernet. Only
19. But with UDP - it is possible. 

> 
> With RTP you'll only need additional 12 bytes - i.e. the frame grows to
> 1356 bytes in total. The difference is less than 0.9 %.

But, if I have to produce a LOT of streams, even 1% of overhead can be an
headache. And - I can't with RTP get well-syncronised streams in this case.
Tried a lot with same result - thanks ffmpeg&live555.com ;(( 

> 
> In other words, if you're streaming at e.g. 512 kbit/s, with RTP you'll
> need no more than 516.6 kbit/s. Does this really matter for your setup ?

I'm working on streams with 4.5+ Mb/s streams.

> 
>> > 1) it exactly identifies the payload.
>> 
>> I know exactly a payload of stream - so no need to make SDP.
>> 
>> > With raw UDP, only intelligent
>> > guesswork could be used to estimate the payload type and at least with
>> > some streams this is not 100% safe
>> 
>> No need - streams are hard defined.
>> 
>> > (sometimes MPEG-TS from Vbricks is
>> > misdetected as being MPEG-PS). Such exact identification could also
>> > assist to properly set quality-of-service parameters in the network.
>> 
>> No need in my setup.
> 
> Well I do understand that with hard defined values and very restricted
> environment these might not be needed. But such solution is limited to
> your special environment and can't work in a more general cases. 

You see, my case - is my case. I need raw UDP streams for a lot of other
(not only VLC-related) reasons.

> Also one 
> day you might need to support some additional formats...

For other formats we use RTP ;))

> My position here 
> is that compliance with RFC standards is _always_ good thing and since the
> bandwidth overhead is really negligible, it's generally not worth breaking
> the standards. If your environment needs special handling - fine, but
> still VLC is IMHO positioned as a player for broad range of different
> environments and therefore should promote standards compliance instead of
> breaking them.

Raw UDP is not standards-breaking mechanism. Look at DVB-over-IP, for
example ;)

-- 
Viktor Kompaneyets
Wnet project manager

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