RE: [RFC] New architecture for a video server

some comments on streaming more than one channels from
the satellite....
i also feel that sending MPTS on IP is not a good idea
..first of all many(nearly all)players dont handle
this without additional efforts, even hardware
decoders that take TS need SPTS.
...second in case of MPTS any person viewing a channel
on his PC need to recieving the data for all the he is
not watching..thus increasing network data
unnecessarily.
There is an easy solution to this put each SPTS on
different multicast:port combination ( like channel
One on 239.10.10.10:8000, Channel two on
239.10.10.10:8001 ...and so on )
These channels can be announced through SAP/SDP
protocol. ( Session Announcement & Session
Description)
They are pretty simple to implement ...the link to the
RFC's are 
http://www.ietf.org/rfc/rfc2974.txt
http://www.ietf.org/rfc/rfc2327.txt
This way an SPTS stream would go into a network only
if there player listening on that particular multicast
address.
SAP has a standard muticast IP address which will
announce using SDP ...which program is coming on which
address.
regards
SUKESH






-----Original Message-----
From: Christophe Massiot [mailto:[email protected]]
Sent: Monday, August 05, 2002 3:04 PM
To: [email protected]
Subject: Re: [RFC] New architecture for a video server


At 20:45 +0200 4/08/2002, Jean-Paul Saman wrote :

>>Similarly, VLC is currently unable to decode several
programs 
>>within the same input. That is we couldn't stream
more than one 
>>program from a satellite input. Again, VLS will
still be useful for 
>>that kind of situations, until VLC's input is
extended to support 
>>decoding multiple programs.
>>
>For most VOD uses that is no real problem. Usually
one channel of a 
>satelitte is used.

Yeah but it's a problem for IPTV.

>In order to really leverage this great idea it would
be great if it 
>were possible to bypass going to the ES level for
satelitte and SPTS 
>streaming. Is there really no way of doing that in
the current 
>libvlc?

Of course there is a way. We would need to add a
semantic to 
data_packet_t and pes_packet_t coming from the input,
so that we'd be 
sure they're actual TS and PES packets.

However, I'm almost convinced that we do not want to
that way. 
Recently I have spent a few hours debugging one of our
users. It 
turned out that the stream he used (coming from a
local VOD dealer) 
only had ONE PAT/PMT at the beginning. So bad for
random access...

And I'm not even talking about streams which have
funky PCRs, or 
whatever. We spend really a lot of time debugging
problems which in 
turn are related to bad/unexpected TS streams, so that
I think it's a 
damn good idea to demux/remux the stream, just in
case.

>>A drawback of this architecture : we have a lot of
threads. 1 
>>thread for the input, 1 thread for the interface, 1
thread per ES, 
>>and optionally one thread for the stream output.
However, on 
>>current machines VLS and VLMS only take up a margin
of the CPU 
>>power, so that we can afford a little more CPU time.
>>
>What is a little more? a few percents or 30-50
percent?

I can't assess that, because I do not know the current
overhead of 
VLS and VLMS. However, considering how VLC's input
(which already 
features a lot of computation) performs on today's
machine, it will 
probably be marginal. And anyway, the bottleneck of
such a system 
will still be I/O.

>>Finally, if the user requested the stream to be
constant bitrate 
>>(CBR), the TS multiplexor will add TS packets for
stuffing. The 
>>resulting TS packets are placed in a FIFO, in the
right order, with 
>>emission dates.
>>
>Will the VBR case also be handled? Or are you
intending to only stick to CBR?

VBR is the same as CBR but without padding, so it will
be way more 
simple to implement.

-- 
Christophe Massiot.

-- 
This is the vls-devel mailing-list, see
http://www.videolan.org/vls-devel/
To unsubscribe, please read
http://www.videolan.org/lists.html
If you are in trouble, please contact
<[email protected]>


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

-- 
This is the vls-devel mailing-list, see http://www.videolan.org/vls-devel/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <[email protected]>