[Live-devel] live-devel Digest, Vol 42, Issue 22
N Anche Naveen-RQJM87
RQJM87 at motorola.com
Tue May 1 20:49:07 PDT 2007
Thank you very much. That solved the problem.
-Naveen
-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of
live-devel-request at ns.live555.com
Sent: Tuesday, May 01, 2007 12:11 AM
To: live-devel at ns.live555.com
Subject: live-devel Digest, Vol 42, Issue 22
Send live-devel mailing list submissions to
live-devel at lists.live555.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.live555.com/mailman/listinfo/live-devel
or, via email, send a message with subject or body 'help' to
live-devel-request at lists.live555.com
You can reach the person managing the list at
live-devel-owner at lists.live555.com
When replying, please edit your Subject line so it is more specific than
"Re: Contents of live-devel digest..."
Today's Topics:
1. Re: Cannot play an RTSP stream (Ross Finlayson)
2. Re: Live555 MPEG2 Transport Stream packet loss (ilya77 at gmail.com)
3. About the openRTSP source code (hong liu)
4. Re: About the openRTSP source code (Ross Finlayson)
5. linking RTCP RR and RTSP sessions (Thomas Vander Stichele)
6. Re: Live555 MPEG2 Transport Stream packet loss
(xcsmith at rockwellcollins.com)
----------------------------------------------------------------------
Message: 1
Date: Fri, 27 Apr 2007 12:42:21 -0700
From: Ross Finlayson <finlayson at live555.com>
Subject: Re: [Live-devel] Cannot play an RTSP stream
To: LIVE555 Streaming Media - development & use
<live-devel at ns.live555.com>
Message-ID: <f06240807c258010f166f@[66.80.62.44]>
Content-Type: text/plain; charset="us-ascii"
>I downloaded live55MediaServer from live555.com and ran it on my linux
>system. I downloaded live source code and built it according to steps
>given in
><http://www.live555.com/liveMedia/#config-unix>http://www.live555.com/l
>iveMedia/#config-unix
>
>I downloaded Mplayer and built it.
>
>When i try to play an rtsp file, i get an error: Here is the complete
log:
>
>[root at pclin518 bin]# ./mplayer rtsp://10.232.67.150:8554/dvb_sub.mpeg
>MPlayer 1.0rc1-4.1.0 (C) 2000-2006 MPlayer Team
>CPU: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz (Family: 6,
>Model: 15, Step
>ping: 6)
>CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled
>for x86 CPU with extensions: MMX MMX2 SSE SSE2
>
>Playing rtsp://10.232.67.150:8554/dvb_sub.mpeg.
>Resolving 10.232.67.150 for AF_INET6...
>Couldn't resolve name for AF_INET6: 10.232.67.150 Connecting to server
>10.232.67.150[10.232.67.150]: 8554...
>connect error: Connection refused
>Resolving 10.232.67.150 for AF_INET6...
>Couldn't resolve name for AF_INET6: 10.232.67.150 Connecting to server
>10.232.67.150[10.232.67.150]: 8554...
>connect error: Connection refused
>File not found: '10.232.67.150:8554/dvb_sub.mpeg'
>Failed to open rtsp://10.232.67.150:8554/dvb_sub.mpeg.
>
>
>Exiting... (End of file)
>
>Am I doing something wrong?
First, for "live555MediaServer" to be able to stream your file, its name
cannot end with ".mpeg". If your file is a MPEG Program Stream file,
then it's name must end with ".mpg" (not ".mpeg"). However, if (as
seems likely from the name "dvb_sub") it is actually a MPEG
*Transport* Stream file, then you must rename it to "dvb_sub.ts", before
you will be able to stream it.
Second, the "connection refused" error means that either
- 10.232.67.150 is not the real IP address of the server (that
is running "live555MediaServer"). (Perhaps you have a NAT box in the
middle??), or
- You are not actually running "live555MediaServer" on your
server machine.
Also, I recommend using VLC as your media player client rather than
MPlayer.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.live555.com/pipermail/live-devel/attachments/20070427/690d0
606/attachment-0001.html
------------------------------
Message: 2
Date: Sun, 29 Apr 2007 14:53:44 +0300
From: "ilya77 at gmail.com" <ilya77 at gmail.com>
Subject: Re: [Live-devel] Live555 MPEG2 Transport Stream packet loss
To: "LIVE555 Streaming Media - development & use"
<live-devel at ns.live555.com>
Message-ID:
<ec6233bc0704290453s10d1b07ay3d4a89fe7a19856d at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
We've eliminated the NAT/ATM from the equation, and tried streaming the
MPEG-2 TS over UDP (connecting the viewing PC directly to an ADSL line),
and it did improve the sittuation dramatically, however, we sill have
around 0.3- 0.7% packet loss over the WAN which results in video
smearing here and there, and audio glitches (which are worse than video
smearing because they are easily identified by ear and are more
disturbing).
We are wondering if either TS or RTP provide some means of forward error
correction, since this rate of lost packets is normal over the public
Internet, and from what we can tell the player (VLC) can not deal with
those errors (and conceal them from the viewer).
We are trying to find some information regarding embedding FEC
information into the transport stream (as far as we understand it
provides at least a container for error correction data), yet with no
success.
Any ideas?
Many thanks,
Ilya
On 4/26/07, Morgan T?rvolt <morgan.torvolt at gmail.com> wrote:
>
> > Also, your email says you are using ATM (Asynchronous Transfer
> Mode?). I
> > check this on wikipedia, and notice that the data must be divided
> > into
> very
> > small cells for delivery. It seems like ATM is a protocol for
> > time-sensitive data, like VoIP. RTP also is designed to meet
> > special timing needs of the data. Could there be a problem combining
> > these two time-sensitive protocols? "If a circuit is exceeding its
> > traffic
> contract,
> > the network can either drop the cells or mark the Cell Loss Priority
> (CLP)
> > bit (to identify a cell as discardable further down the line)." The
> > RTP delivery can be somewhat bursty, so maybe you need to check your
> > ATM contract and make sure you have the correct one (VBR maybe?)
one?
>
> ATM is just a transport layer, as Ethernet, SDH and others. ATM is
> usually used in for example ADSL connections. That the packet size is
> 155 (or something like that) is not obvious, or even visible, to the
> end hardware. It sees only an ordinary Ethernet link.
> ATM is not very suited to do anything really. It is like a duck, it
> can swim, fly and make sound, but does neither extremely well. For
> extremely time sensitive data one uses SDH, which even keeps the
> original input clock through the links. For time insensitive data one
> uses Ethernet. ATM is very good at prioritizing traffic though, and it
> could sound like the Ethernet packets are given a low priority,
> possibly due to the fact that it is UDP. I have experienced this
> before, and the configuration of a Ethernet card in one of the nodes
> was to blame. It did not keep it's config due to hardware failure. In
> your case this should be configurable in the ATM nodes, or management
> software.
>
> As a "most likely" option, I would have to opt for bandwidth problem.
> I have spent too many hours saying that it is not so on ATM networks
> before. Check that your VCs and VPs are set up correctly, and try
> transmitting TCP and UDP data from other sources than live. VLC stream
> output would be a good place to start I believe.
>
> I agree with Ross here. You say it works well without the ATM, but not
> with it. The reason for the problems is then too obvious. As there are
> literally thousands of users of this software, I do believe that the
> way it handles the Ethernet part works according to standard (unless
> your OS or some configurations therein is to blame). One should not
> make custom fixes to allow for broken hardware or configuration. In
> this case "your network" seems like a good term, as most of the other
> networks seems to work just fine.
>
> -Morgan-
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.live555.com/pipermail/live-devel/attachments/20070429/e0998
e46/attachment-0001.html
------------------------------
Message: 3
Date: Sun, 29 Apr 2007 17:46:05 -0700 (PDT)
From: hong liu <l1436636 at yahoo.com>
Subject: [Live-devel] About the openRTSP source code
To: live-devel at ns.live555.com
Message-ID: <521302.36565.qm at web51109.mail.re2.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"
>>I start looking at the source code of openRTSP, and try to modify the
>>code to add SPS an PPS NAL units of H264 into saved file.
>To do this, you would modify (or extend) the "H264VideoFileSink" class.
May I ask the reason why the openRTSP program doesn't save received
SPS and PPS NAL units of H.264 into a local video file?
Thank you so much!
Hong
Hong Liu
------------------------------
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
Check outnew cars at Yahoo! Autos.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.live555.com/pipermail/live-devel/attachments/20070429/ec397
bf3/attachment-0001.html
------------------------------
Message: 4
Date: Sun, 29 Apr 2007 20:02:15 -0700
From: Ross Finlayson <finlayson at live555.com>
Subject: Re: [Live-devel] About the openRTSP source code
To: LIVE555 Streaming Media - development & use
<live-devel at ns.live555.com>
Message-ID: <f06240804c25b0cb4df18@[66.80.62.44]>
Content-Type: text/plain; charset="us-ascii"
> >>I start looking at the source code of openRTSP, and try to modify
>>>the code to add SPS an PPS NAL units of H264 into saved file.
>
>>To do this, you would modify (or extend) the "H264VideoFileSink"
class.
>
>May I ask the reason why the openRTSP program doesn't save received SPS
>and PPS NAL units of H.264 into a local video file?
Because the code wasn't written to do this.
Note that these NAL units aren't part of the RTP stream, but are instead
sent as an encoded string in the stream's SDP description.
However, there exists a function ("MediaSubsession::
fmtp_spropparametersets()()") to access this string, and another
function ("parseSPropParameterSets()") to decode this string into binary
data - which you could, if you wished, write to a file.
Sometime in the future, I might update the "H264VideoFileSink" class to
do this itself....
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.live555.com/pipermail/live-devel/attachments/20070429/079f0
e2d/attachment-0001.html
------------------------------
Message: 5
Date: Mon, 30 Apr 2007 18:09:05 +0200
From: Thomas Vander Stichele <thomas at apestaart.org>
Subject: [Live-devel] linking RTCP RR and RTSP sessions
To: live-devel at ns.live555.com
Message-ID: <1177949345.28381.80.camel at level.fluendo.lan>
Content-Type: text/plain
I was wondering exactly what the correct way is to relate RTCP RR
reports to RTSP sessions on a server. I would like to know because, if
I understand the RFC's correctly, an RTSP server MAY use any "wellness"
information from clients (for example, RTCP RR packets) to keep the RTSP
session alive.
AFAICT, most mobile phones do not do keepalive on the RTSP layer, so an
RTSP server has the need to tie RTCP RR packets to the RTSP sessions.
(If I am wrong at this point, please do correct me, this stuff eats my
brain when I think about it)
The RTCP RR reports only provide the server with:
- the client's (apparent) IP address (possibly changed through NAT)
- the outgoing client UDP port from which these RTCP reports get sent
(which I assume could have been changed through NAT)
- the incoming server UDP port on which the server receives RTCP reports
- the client's SSRC
Of these, only the client's IP address was communicated to the RTSP
server; the server knows which incoming UDP/RTCP port it asked the
client to send to.
I see the following options for the server to be able to map RTSP
sessions to RTCP RR reports:
- The server allocates a unique rtp and rtcp reception port for each
RTSP session; this allows the server to id RTCP RR reports based on the
incoming RTCP port.
- The server uses the same rtp/rtcp reception port for each new RTSP
session from a not-yet-known IP; if the same IP does a new session
request, the server bumps rtp/rtcp reception ports.
- The server uses the same rtp/rtcp reception port for everyone; it
pretends that there is one session per IP.
The first solution has the huge disadvantage that the server is limited
to about 30k clients, given the number of ports it can receive on. Not
to mention that select() would go out the window for checking activity
:)
The second solution is a little less greedy with ports, but harder to
code.
The third one seems wrong to me.
I was wondering what the behaviour is of the live555 libraries. Anyone
know ?
Thanks
Thomas
------------------------------
Message: 6
Date: Mon, 30 Apr 2007 13:41:13 -0500
From: xcsmith at rockwellcollins.com
Subject: Re: [Live-devel] Live555 MPEG2 Transport Stream packet loss
To: "LIVE555 Streaming Media - development & use"
<live-devel at ns.live555.com>
Message-ID:
<OF41048D6C.0FF2323F-ON862572CD.0065AA84-862572CD.0066E126 at rockwellcolli
ns.com>
Content-Type: text/plain; charset=US-ASCII
Hi all,
We've eliminated the NAT/ATM from the equation, and tried streaming the
MPEG-2 TS over UDP (connecting the viewing PC directly to an ADSL line),
and it did improve the sittuation dramatically, however, we sill have
around 0.3 - 0.7% packet loss over the WAN which results in video
smearing here and there, and audio glitches (which are worse than video
smearing because they are easily identified by ear and are more
disturbing).
We are wondering if either TS or RTP provide some means of forward error
correction, since this rate of lost packets is normal over the public
Internet, and from what we can tell the player (VLC) can not deal with
those errors (and conceal them from the viewer).
We are trying to find some information regarding embedding FEC
information into the transport stream (as far as we understand it
provides at least a container for error correction data), yet with no
success.
Any ideas?
Many thanks,
Ilya
Re: Are you watching the video in real time or just recording it? you
could use openRTSP to record the video stream and see if it helps at all
to do this. in openRTSP you can adjust the amount of time to wait for a
late packet. I'm not sure how much difference it would make. Have you
tried going back to TCP streaming? If a packet is too late, it will be
discarded, but if you are only doing a recording and not trying to watch
the video real time, then you can wait a little longer for late packets.
I don't think the TS format provides any sort of other error correction,
aside from having very small packets to stop packet loss from having a
dramatic effect on the system. I do not believe there is any way to
recalculate the missing data from nearby data, if that's what you are
asking.
------------------------------
_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
End of live-devel Digest, Vol 42, Issue 22
******************************************
More information about the live-devel
mailing list