Can I use Helix to stream a 'boardcast' generated by VLC?

Hi,

Can I use Helix to stream a 'boardcast' generated by VLC?  I
read that
Darwin can do it,
I wonder if Helix can do the same?

Thank you.

_______________________________________________
Helix-server-dev mailing list
Helix-server-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-server-dev

Meryl Silverburgh wrote:
 > Hi,
 >
 > Can I use Helix to stream a 'boardcast' generated by
VLC?  I read that
 > Darwin can do it,
 > I wonder if Helix can do the same?

Yes and no.

Unfortunately, VLC does not send a complete RTP stream; it
lacks RTCP 
sender reports, and they are required for incoming encoder
connections 
by the Helix Server.

There are three ways to get this to work:

1) Fix VLC through patching in RTCP SR generation.
2) Write a 'proxy' of sorts, used between VLC and the server
to 
synthesize the missing RTCP SR packets. (I have done this
before.)
3) Modify the server code to not require the presence of SR
packets and 
synthesize the needed information at the server itself the
same way the 
proxy mentioned previously might.

The format of RTCP Sender Reports is documented in RFC3550
section 6.4.1.

For an encoder, there are no 'sources' other than the
sender, so all 
that's needed in a Sender Report would be the normal RTCP SR
headers in 
packets arriving on the next-higher port from the RTP
packets (one for 
each media stream). Inside includes some arbitrary NTP
timestamp data, 
the RTP timestamp derived from the RTP stream, packet-count,
and 
byte-count information.

In Perl, you might synthesize an SR packet for a particular
RTP stream 
using code something like this (just a code segment; won't
work as-is):

use Time::HiRes qw( time gettimeofday );

#... UDP port setup and RTP receive loop here ...

if ( time > $next_sr_time ) {
     my ($bits, $pt, $seq, $ts, $ssrc) =
unpack("CCnNN", $rtp_datagram)
     my ($ntp_sec, $ntp_msec) = gettimeofday;
     $ntp_msec *= 4294; # conversion from plain msecs to
NTP-style
                        # fractional seconds
     my $sr = pack("CCCC",128,200,0,6) # hdr (0
rc, pt=200, len=6 words)
            . pack("N",     $ssrc) # word 1: ssrc
of sender
            . pack("N",  $ntp_sec) # word 2: ntp
timestamp msw
            . pack("N", $ntp_msec) # word 3: ntp
timestamp lsw
            . pack("N",       $ts) # word 4: rtp
timestamp
            . pack("N", $rtp_pkts) # word 5:
sender's pkt cnt
            . pack("N",$rtp_bytes) # word 6:
sender's byte cnt
     ;

     $rtcp_socket->send($sr);

     $next_sr_time += 5;
}

Hope this is helpful.

	-jrs


_______________________________________________
Helix-server-dev mailing list
Helix-server-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-server-dev

Jason,

Thanks for your detailed answer.

I have a few questions about approach #3:

1. Why you talk about "UDP port setup and RTP receive
loop here ..."?
Why helix server will have a RTP receive loop? It is sending
RTP
packet during the boardcast mode, right?

2. I look at the servrsnd.cpp code, I dont' the RTP receive
loop
there. Am I looking at the right place? If not, can you
please tell me
where should I look?

Thank you.
Sam

On 5/11/07, Jason Simpson <jsimpsonreal.com> wrote:
> Meryl Silverburgh wrote:
>  > Hi,
>  >
>  > Can I use Helix to stream a 'boardcast' generated
by VLC?  I read that
>  > Darwin can do it,
>  > I wonder if Helix can do the same?
>
> Yes and no.
>
> Unfortunately, VLC does not send a complete RTP stream;
it lacks RTCP
> sender reports, and they are required for incoming
encoder connections
> by the Helix Server.
>
> There are three ways to get this to work:
>
> 1) Fix VLC through patching in RTCP SR generation.
> 2) Write a 'proxy' of sorts, used between VLC and the
server to
> synthesize the missing RTCP SR packets. (I have done
this before.)
> 3) Modify the server code to not require the presence
of SR packets and
> synthesize the needed information at the server itself
the same way the
> proxy mentioned previously might.
>
> The format of RTCP Sender Reports is documented in
RFC3550 section 6.4.1.
>
> For an encoder, there are no 'sources' other than the
sender, so all
> that's needed in a Sender Report would be the normal
RTCP SR headers in
> packets arriving on the next-higher port from the RTP
packets (one for
> each media stream). Inside includes some arbitrary NTP
timestamp data,
> the RTP timestamp derived from the RTP stream,
packet-count, and
> byte-count information.
>
> In Perl, you might synthesize an SR packet for a
particular RTP stream
> using code something like this (just a code segment;
won't work as-is):
>
> use Time::HiRes qw( time gettimeofday );
>
> #... UDP port setup and RTP receive loop here ...
>
> if ( time > $next_sr_time ) {
>      my ($bits, $pt, $seq, $ts, $ssrc) =
unpack("CCnNN", $rtp_datagram)
>      my ($ntp_sec, $ntp_msec) = gettimeofday;
>      $ntp_msec *= 4294; # conversion from plain msecs
to NTP-style
>                         # fractional seconds
>      my $sr = pack("CCCC",128,200,0,6) # hdr
(0 rc, pt=200, len=6 words)
>             . pack("N",     $ssrc) # word 1:
ssrc of sender
>             . pack("N",  $ntp_sec) # word 2:
ntp timestamp msw
>             . pack("N", $ntp_msec) # word 3:
ntp timestamp lsw
>             . pack("N",       $ts) # word 4:
rtp timestamp
>             . pack("N", $rtp_pkts) # word 5:
sender's pkt cnt
>             . pack("N",$rtp_bytes) # word 6:
sender's byte cnt
>      ;
>
>      $rtcp_socket->send($sr);
>
>      $next_sr_time += 5;
> }
>
> Hope this is helpful.
>
>         -jrs
>
>

_______________________________________________
Helix-server-dev mailing list
Helix-server-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-server-dev

The example code I showed there was in no way related to
server code. It 
was more an example of approach #2: writing an RTP 'proxy'
script in 
Perl. I can't answer your questions as they aren't relevant
to that 
solution, sorry.

I imagine for approach #3, you'd want to focus on the code
in 
server/broadcast/transport/rtp/recv.

	-jrs

Meryl Silverburgh wrote:
> Jason,
> 
> Thanks for your detailed answer.
> 
> I have a few questions about approach #3:
> 
> 1. Why you talk about "UDP port setup and RTP
receive loop here ..."?
> Why helix server will have a RTP receive loop? It is
sending RTP
> packet during the boardcast mode, right?
> 
> 2. I look at the servrsnd.cpp code, I dont' the RTP
receive loop
> there. Am I looking at the right place? If not, can you
please tell me
> where should I look?
> 
> Thank you.
> Sam
> 
> On 5/11/07, Jason Simpson <jsimpsonreal.com> wrote:
>> Meryl Silverburgh wrote:
>>  > Hi,
>>  >
>>  > Can I use Helix to stream a 'boardcast'
generated by VLC?  I read that
>>  > Darwin can do it,
>>  > I wonder if Helix can do the same?
>>
>> Yes and no.
>>
>> Unfortunately, VLC does not send a complete RTP
stream; it lacks RTCP
>> sender reports, and they are required for incoming
encoder connections
>> by the Helix Server.
>>
>> There are three ways to get this to work:
>>
>> 1) Fix VLC through patching in RTCP SR generation.
>> 2) Write a 'proxy' of sorts, used between VLC and
the server to
>> synthesize the missing RTCP SR packets. (I have
done this before.)
>> 3) Modify the server code to not require the
presence of SR packets and
>> synthesize the needed information at the server
itself the same way the
>> proxy mentioned previously might.
>>
>> The format of RTCP Sender Reports is documented in
RFC3550 section 6.4.1.
>>
>> For an encoder, there are no 'sources' other than
the sender, so all
>> that's needed in a Sender Report would be the
normal RTCP SR headers in
>> packets arriving on the next-higher port from the
RTP packets (one for
>> each media stream). Inside includes some arbitrary
NTP timestamp data,
>> the RTP timestamp derived from the RTP stream,
packet-count, and
>> byte-count information.
>>
>> In Perl, you might synthesize an SR packet for a
particular RTP stream
>> using code something like this (just a code
segment; won't work as-is):
>>
>> use Time::HiRes qw( time gettimeofday );
>>
>> #... UDP port setup and RTP receive loop here ...
>>
>> if ( time > $next_sr_time ) {
>>      my ($bits, $pt, $seq, $ts, $ssrc) =
unpack("CCnNN", $rtp_datagram)
>>      my ($ntp_sec, $ntp_msec) = gettimeofday;
>>      $ntp_msec *= 4294; # conversion from plain
msecs to NTP-style
>>                         # fractional seconds
>>      my $sr = pack("CCCC",128,200,0,6) #
hdr (0 rc, pt=200, len=6 words)
>>             . pack("N",     $ssrc) # word
1: ssrc of sender
>>             . pack("N",  $ntp_sec) # word
2: ntp timestamp msw
>>             . pack("N", $ntp_msec) # word
3: ntp timestamp lsw
>>             . pack("N",       $ts) # word
4: rtp timestamp
>>             . pack("N", $rtp_pkts) # word
5: sender's pkt cnt
>>             . pack("N",$rtp_bytes) # word
6: sender's byte cnt
>>      ;
>>
>>      $rtcp_socket->send($sr);
>>
>>      $next_sr_time += 5;
>> }
>>
>> Hope this is helpful.
>>
>>         -jrs
>>
>>
> 

_______________________________________________
Helix-server-dev mailing list
Helix-server-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-server-dev

Jason,

Thank you.
Can you please help me understand
* what is the value of the $rtp_datagram?
*  why we only need to do  $rtcp_socket->send($sr);? why
we don't need
to send out the original $rtp_datagram?

* what is the rtcp_socket? is that the udp port that this
script is
listening to?


if ( time > $next_sr_time ) {
    my ($bits, $pt, $seq, $ts, $ssrc) =
unpack("CCnNN", $rtp_datagram)
    my ($ntp_sec, $ntp_msec) = gettimeofday;
    $ntp_msec *= 4294; # conversion from plain msecs to
NTP-style
                       # fractional seconds
    my $sr = pack("CCCC",128,200,0,6) # hdr (0 rc,
pt=200, len=6 words)
           . pack("N",     $ssrc) # word 1: ssrc
of sender
           . pack("N",  $ntp_sec) # word 2: ntp
timestamp msw
           . pack("N", $ntp_msec) # word 3: ntp
timestamp lsw
           . pack("N",       $ts) # word 4: rtp
timestamp
           . pack("N", $rtp_pkts) # word 5:
sender's pkt cnt
           . pack("N",$rtp_bytes) # word 6:
sender's byte cnt
    ;

    $rtcp_socket->send($sr);

    $next_sr_time += 5;
}

On 5/11/07, Jason Simpson <jsimpsonreal.com> wrote:
> The example code I showed there was in no way related
to server code. It
> was more an example of approach #2: writing an RTP
'proxy' script in
> Perl. I can't answer your questions as they aren't
relevant to that
> solution, sorry.
>
> I imagine for approach #3, you'd want to focus on the
code in
> server/broadcast/transport/rtp/recv.
>
>         -jrs
>
> Meryl Silverburgh wrote:
> > Jason,
> >
> > Thanks for your detailed answer.
> >
> > I have a few questions about approach #3:
> >
> > 1. Why you talk about "UDP port setup and RTP
receive loop here ..."?
> > Why helix server will have a RTP receive loop? It
is sending RTP
> > packet during the boardcast mode, right?
> >
> > 2. I look at the servrsnd.cpp code, I dont' the
RTP receive loop
> > there. Am I looking at the right place? If not,
can you please tell me
> > where should I look?
> >
> > Thank you.
> > Sam
> >
> > On 5/11/07, Jason Simpson <jsimpsonreal.com> wrote:
> >> Meryl Silverburgh wrote:
> >>  > Hi,
> >>  >
> >>  > Can I use Helix to stream a 'boardcast'
generated by VLC?  I read that
> >>  > Darwin can do it,
> >>  > I wonder if Helix can do the same?
> >>
> >> Yes and no.
> >>
> >> Unfortunately, VLC does not send a complete
RTP stream; it lacks RTCP
> >> sender reports, and they are required for
incoming encoder connections
> >> by the Helix Server.
> >>
> >> There are three ways to get this to work:
> >>
> >> 1) Fix VLC through patching in RTCP SR
generation.
> >> 2) Write a 'proxy' of sorts, used between VLC
and the server to
> >> synthesize the missing RTCP SR packets. (I
have done this before.)
> >> 3) Modify the server code to not require the
presence of SR packets and
> >> synthesize the needed information at the
server itself the same way the
> >> proxy mentioned previously might.
> >>
> >> The format of RTCP Sender Reports is
documented in RFC3550 section 6.4.1.
> >>
> >> For an encoder, there are no 'sources' other
than the sender, so all
> >> that's needed in a Sender Report would be the
normal RTCP SR headers in
> >> packets arriving on the next-higher port from
the RTP packets (one for
> >> each media stream). Inside includes some
arbitrary NTP timestamp data,
> >> the RTP timestamp derived from the RTP stream,
packet-count, and
> >> byte-count information.
> >>
> >> In Perl, you might synthesize an SR packet for
a particular RTP stream
> >> using code something like this (just a code
segment; won't work as-is):
> >>
> >> use Time::HiRes qw( time gettimeofday );
> >>
> >> #... UDP port setup and RTP receive loop here
...
> >>
> >> if ( time > $next_sr_time ) {
> >>      my ($bits, $pt, $seq, $ts, $ssrc) =
unpack("CCnNN", $rtp_datagram)
> >>      my ($ntp_sec, $ntp_msec) = gettimeofday;
> >>      $ntp_msec *= 4294; # conversion from
plain msecs to NTP-style
> >>                         # fractional seconds
> >>      my $sr =
pack("CCCC",128,200,0,6) # hdr (0 rc, pt=200,
len=6 words)
> >>             . pack("N",     $ssrc) #
word 1: ssrc of sender
> >>             . pack("N",  $ntp_sec) #
word 2: ntp timestamp msw
> >>             . pack("N", $ntp_msec) #
word 3: ntp timestamp lsw
> >>             . pack("N",       $ts) #
word 4: rtp timestamp
> >>             . pack("N", $rtp_pkts) #
word 5: sender's pkt cnt
> >>             . pack("N",$rtp_bytes) #
word 6: sender's byte cnt
> >>      ;
> >>
> >>      $rtcp_socket->send($sr);
> >>
> >>      $next_sr_time += 5;
> >> }
> >>
> >> Hope this is helpful.
> >>
> >>         -jrs
> >>
> >>
> >
>

_______________________________________________
Helix-server-dev mailing list
Helix-server-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-server-dev

As VLC does not generate its own RTCP packets, you would
need to make
ones. In making them, you need to re-use some information
that is pulled
out of the original RTP stream.

What I presented was not a complete solution, just an
example, a snippet,
a rough draft of the portion that might be used to craft an
appropriate
RTCP packet from an RTP stream. It was only used as an
example to show how
you might derive the necessary information that belongs in
the RTCP packet
from the associated RTP information. It's not a complete
solution, and it
cannot be used without having an understanding of how the
RTP/RTCP
protocols work.

Were you to proceed in attempting to author an
RTCP-generating RTP proxy:

> * what is the value of the $rtp_datagram?

The data from receiving... an RTP datagram! RTP data from
the encoder (VLC
or whatever).

> *  why we only need to do  $rtcp_socket->send($sr);?
why we don't need
> to send out the original $rtp_datagram?

An RTCP-generating proxy *would* need to also send the
original RTP
datagram along to the server.

> * what is the rtcp_socket? is that the udp port that
this script is
> listening to?

As the RTP protocol requires a pair of adjacent ports, one
for RTP data,
one for RTCP data, the rtcp_socket would be the socket that
handles the
RTCP data.

    -jrs


>
>
> if ( time > $next_sr_time ) {
>     my ($bits, $pt, $seq, $ts, $ssrc) =
unpack("CCnNN", $rtp_datagram)
>     my ($ntp_sec, $ntp_msec) = gettimeofday;
>     $ntp_msec *= 4294; # conversion from plain msecs to
NTP-style
>                        # fractional seconds
>     my $sr = pack("CCCC",128,200,0,6) # hdr
(0 rc, pt=200, len=6 words)
>            . pack("N",     $ssrc) # word 1:
ssrc of sender
>            . pack("N",  $ntp_sec) # word 2:
ntp timestamp msw
>            . pack("N", $ntp_msec) # word 3:
ntp timestamp lsw
>            . pack("N",       $ts) # word 4:
rtp timestamp
>            . pack("N", $rtp_pkts) # word 5:
sender's pkt cnt
>            . pack("N",$rtp_bytes) # word 6:
sender's byte cnt
>     ;
>
>     $rtcp_socket->send($sr);
>
>     $next_sr_time += 5;
> }
>
> On 5/11/07, Jason Simpson <jsimpsonreal.com> wrote:
>> The example code I showed there was in no way
related to server code. It
>> was more an example of approach #2: writing an RTP
'proxy' script in
>> Perl. I can't answer your questions as they aren't
relevant to that
>> solution, sorry.
>>
>> I imagine for approach #3, you'd want to focus on
the code in
>> server/broadcast/transport/rtp/recv.
>>
>>         -jrs
>>
>> Meryl Silverburgh wrote:
>> > Jason,
>> >
>> > Thanks for your detailed answer.
>> >
>> > I have a few questions about approach #3:
>> >
>> > 1. Why you talk about "UDP port setup and
RTP receive loop here ..."?
>> > Why helix server will have a RTP receive loop?
It is sending RTP
>> > packet during the boardcast mode, right?
>> >
>> > 2. I look at the servrsnd.cpp code, I dont'
the RTP receive loop
>> > there. Am I looking at the right place? If
not, can you please tell me
>> > where should I look?
>> >
>> > Thank you.
>> > Sam
>> >
>> > On 5/11/07, Jason Simpson <jsimpsonreal.com> wrote:
>> >> Meryl Silverburgh wrote:
>> >>  > Hi,
>> >>  >
>> >>  > Can I use Helix to stream a
'boardcast' generated by VLC?  I read
>> that
>> >>  > Darwin can do it,
>> >>  > I wonder if Helix can do the same?
>> >>
>> >> Yes and no.
>> >>
>> >> Unfortunately, VLC does not send a
complete RTP stream; it lacks RTCP
>> >> sender reports, and they are required for
incoming encoder
>> connections
>> >> by the Helix Server.
>> >>
>> >> There are three ways to get this to work:
>> >>
>> >> 1) Fix VLC through patching in RTCP SR
generation.
>> >> 2) Write a 'proxy' of sorts, used between
VLC and the server to
>> >> synthesize the missing RTCP SR packets. (I
have done this before.)
>> >> 3) Modify the server code to not require
the presence of SR packets
>> and
>> >> synthesize the needed information at the
server itself the same way
>> the
>> >> proxy mentioned previously might.
>> >>
>> >> The format of RTCP Sender Reports is
documented in RFC3550 section
>> 6.4.1.
>> >>
>> >> For an encoder, there are no 'sources'
other than the sender, so all
>> >> that's needed in a Sender Report would be
the normal RTCP SR headers
>> in
>> >> packets arriving on the next-higher port
from the RTP packets (one
>> for
>> >> each media stream). Inside includes some
arbitrary NTP timestamp
>> data,
>> >> the RTP timestamp derived from the RTP
stream, packet-count, and
>> >> byte-count information.
>> >>
>> >> In Perl, you might synthesize an SR packet
for a particular RTP
>> stream
>> >> using code something like this (just a
code segment; won't work
>> as-is):
>> >>
>> >> use Time::HiRes qw( time gettimeofday );
>> >>
>> >> #... UDP port setup and RTP receive loop
here ...
>> >>
>> >> if ( time > $next_sr_time ) {
>> >>      my ($bits, $pt, $seq, $ts, $ssrc) =
unpack("CCnNN",
>> $rtp_datagram)
>> >>      my ($ntp_sec, $ntp_msec) =
gettimeofday;
>> >>      $ntp_msec *= 4294; # conversion from
plain msecs to NTP-style
>> >>                         # fractional
seconds
>> >>      my $sr =
pack("CCCC",128,200,0,6) # hdr (0 rc, pt=200,
len=6
>> words)
>> >>             . pack("N",    
$ssrc) # word 1: ssrc of sender
>> >>             . pack("N", 
$ntp_sec) # word 2: ntp timestamp msw
>> >>             . pack("N",
$ntp_msec) # word 3: ntp timestamp lsw
>> >>             . pack("N",      
$ts) # word 4: rtp timestamp
>> >>             . pack("N",
$rtp_pkts) # word 5: sender's pkt cnt
>> >>             .
pack("N",$rtp_bytes) # word 6: sender's byte cnt
>> >>      ;
>> >>
>> >>      $rtcp_socket->send($sr);
>> >>
>> >>      $next_sr_time += 5;
>> >> }
>> >>
>> >> Hope this is helpful.
>> >>
>> >>         -jrs
>> >>
>> >>
>> >
>>
>


_______________________________________________
Helix-server-dev mailing list
Helix-server-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-server-dev