From tim at viber.com  Thu Nov  1 04:01:04 2012
From: tim at viber.com (Tsimafei Harbakon)
Date: Thu, 1 Nov 2012 14:01:04 +0300
Subject: [Live-devel] Android video streaming
Message-ID: <CA++w728i8L3S=5Zvsc6JDNSLsrWHmy0=nCW-5uh7fFLZKGsXKA@mail.gmail.com>

Hello,
Android can record videos from camera encoded H263, H264, MPEG 4 SP;
resulting files have H.263, H.264 / AVC, MPEG-4 Video codecs. Can this
files be streamed using live555 in any way?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121101/a2164db8/attachment.html>

From finlayson at live555.com  Thu Nov  1 04:22:22 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 1 Nov 2012 07:22:22 -0400
Subject: [Live-devel] Android video streaming
In-Reply-To: <CA++w728i8L3S=5Zvsc6JDNSLsrWHmy0=nCW-5uh7fFLZKGsXKA@mail.gmail.com>
References: <CA++w728i8L3S=5Zvsc6JDNSLsrWHmy0=nCW-5uh7fFLZKGsXKA@mail.gmail.com>
Message-ID: <1CAFAE28-08DF-40CE-A53E-07978079D4EE@live555.com>

> Android can record videos from camera encoded H263, H264, MPEG 4 SP; resulting files have H.263, H.264 / AVC, MPEG-4 Video codecs. Can this files be streamed using live555 in any way?

It depends: What is the format of these files?

However, each of the video codecs that you mentioned can be streamed directly by our RTSP server - i.e., by having the server read directly from the video encoder, rather than from a file.  (This is explained in the FAQ.)


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/20121101/adfbf1e2/attachment.html>

From tim at viber.com  Thu Nov  1 04:46:48 2012
From: tim at viber.com (Tsimafei Harbakon)
Date: Thu, 1 Nov 2012 14:46:48 +0300
Subject: [Live-devel] Android video streaming
In-Reply-To: <1CAFAE28-08DF-40CE-A53E-07978079D4EE@live555.com>
References: <CA++w728i8L3S=5Zvsc6JDNSLsrWHmy0=nCW-5uh7fFLZKGsXKA@mail.gmail.com>
 <1CAFAE28-08DF-40CE-A53E-07978079D4EE@live555.com>
Message-ID: <CA++w729Wb+vz7zGF+CkWAHN6B1692TxkEGK4Zo80QooC-uRqmg@mail.gmail.com>

The format is .mp4. I've tested VLC on PC to receive streams. There is
h263+ support in live555, mpeg4 examples need elementary streams, and for
h264 live555 says there is no support for short headers

On Thu, Nov 1, 2012 at 2:22 PM, Ross Finlayson <finlayson at live555.com>wrote:

> Android can record videos from camera encoded H263, H264, MPEG 4 SP;
> resulting files have H.263, H.264 / AVC, MPEG-4 Video codecs. Can this
> files be streamed using live555 in any way?
>
>
> It depends: What is the format of these files?
>
> However, each of the video codecs that you mentioned can be streamed
> directly by our RTSP server - i.e., by having the server read directly from
> the video encoder, rather than from a file.  (This is explained in the FAQ.)
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> 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/20121101/c0b43b59/attachment.html>

From finlayson at live555.com  Thu Nov  1 04:51:13 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 1 Nov 2012 07:51:13 -0400
Subject: [Live-devel] Android video streaming
In-Reply-To: <CA++w729Wb+vz7zGF+CkWAHN6B1692TxkEGK4Zo80QooC-uRqmg@mail.gmail.com>
References: <CA++w728i8L3S=5Zvsc6JDNSLsrWHmy0=nCW-5uh7fFLZKGsXKA@mail.gmail.com>
 <1CAFAE28-08DF-40CE-A53E-07978079D4EE@live555.com>
 <CA++w729Wb+vz7zGF+CkWAHN6B1692TxkEGK4Zo80QooC-uRqmg@mail.gmail.com>
Message-ID: <B7EBA28A-A866-4841-83D9-344D7813CE28@live555.com>

> The format is .mp4

Sorry, but we currently don't support streaming from this file format.

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/20121101/b5d2ac06/attachment.html>

From tim at viber.com  Thu Nov  1 05:08:54 2012
From: tim at viber.com (Tsimafei Harbakon)
Date: Thu, 1 Nov 2012 15:08:54 +0300
Subject: [Live-devel] Android video streaming
In-Reply-To: <B7EBA28A-A866-4841-83D9-344D7813CE28@live555.com>
References: <CA++w728i8L3S=5Zvsc6JDNSLsrWHmy0=nCW-5uh7fFLZKGsXKA@mail.gmail.com>
 <1CAFAE28-08DF-40CE-A53E-07978079D4EE@live555.com>
 <CA++w729Wb+vz7zGF+CkWAHN6B1692TxkEGK4Zo80QooC-uRqmg@mail.gmail.com>
 <B7EBA28A-A866-4841-83D9-344D7813CE28@live555.com>
Message-ID: <CA++w729=baQKkXi27jyhdof7f46vB466F=-P4ijwwiDhVhbGYg@mail.gmail.com>

So, MPEG-4 (.mp4) is not supported, and 3GPP (.3gp) is not supported too?
Only way is to stream directly from encoder, without file? Thanks a lot

On Thu, Nov 1, 2012 at 2:51 PM, Ross Finlayson <finlayson at live555.com>wrote:

> The format is .mp4
>
>
> Sorry, but we currently don't support streaming from this file format.
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> 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/20121101/af32bfe8/attachment-0001.html>

From finlayson at live555.com  Thu Nov  1 07:10:03 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 1 Nov 2012 10:10:03 -0400
Subject: [Live-devel] Android video streaming
In-Reply-To: <CA++w729=baQKkXi27jyhdof7f46vB466F=-P4ijwwiDhVhbGYg@mail.gmail.com>
References: <CA++w728i8L3S=5Zvsc6JDNSLsrWHmy0=nCW-5uh7fFLZKGsXKA@mail.gmail.com>
 <1CAFAE28-08DF-40CE-A53E-07978079D4EE@live555.com>
 <CA++w729Wb+vz7zGF+CkWAHN6B1692TxkEGK4Zo80QooC-uRqmg@mail.gmail.com>
 <B7EBA28A-A866-4841-83D9-344D7813CE28@live555.com>
 <CA++w729=baQKkXi27jyhdof7f46vB466F=-P4ijwwiDhVhbGYg@mail.gmail.com>
Message-ID: <A997A5E0-61BD-4F42-A9CB-F00384BD2072@live555.com>

> So, MPEG-4 (.mp4) is not supported, and 3GPP (.3gp) is not supported too? Only way is to stream directly from encoder, without file?

We support streaming from H.264 and MPEG-4 *elementary stream* files - i.e., from files that contain encoded video data only.  And we support streaming from 'Matroska' (i.e., ".mkv") files.  But we don't currently support streaming from ".mp4" or ".3gp" files.

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/20121101/f981b59e/attachment.html>

From tim at viber.com  Thu Nov  1 07:26:47 2012
From: tim at viber.com (Tsimafei Harbakon)
Date: Thu, 1 Nov 2012 17:26:47 +0300
Subject: [Live-devel] Android video streaming
In-Reply-To: <A997A5E0-61BD-4F42-A9CB-F00384BD2072@live555.com>
References: <CA++w728i8L3S=5Zvsc6JDNSLsrWHmy0=nCW-5uh7fFLZKGsXKA@mail.gmail.com>
 <1CAFAE28-08DF-40CE-A53E-07978079D4EE@live555.com>
 <CA++w729Wb+vz7zGF+CkWAHN6B1692TxkEGK4Zo80QooC-uRqmg@mail.gmail.com>
 <B7EBA28A-A866-4841-83D9-344D7813CE28@live555.com>
 <CA++w729=baQKkXi27jyhdof7f46vB466F=-P4ijwwiDhVhbGYg@mail.gmail.com>
 <A997A5E0-61BD-4F42-A9CB-F00384BD2072@live555.com>
Message-ID: <CA++w72-qY227Ed0yiHomvnOBen+82u3WDWLAxG56a1AXw3X3pg@mail.gmail.com>

Thanks for response, and no plans for now for mp4, 3gp?

On Thu, Nov 1, 2012 at 5:10 PM, Ross Finlayson <finlayson at live555.com>wrote:

> So, MPEG-4 (.mp4) is not supported, and 3GPP (.3gp) is not supported too?
> Only way is to stream directly from encoder, without file?
>
>
> We support streaming from H.264 and MPEG-4 *elementary stream* files -
> i.e., from files that contain encoded video data only.  And we support
> streaming from 'Matroska' (i.e., ".mkv") files.  But we don't currently
> support streaming from ".mp4" or ".3gp" files.
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> 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/20121101/e3966088/attachment.html>

From finlayson at live555.com  Thu Nov  1 07:49:39 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 1 Nov 2012 10:49:39 -0400
Subject: [Live-devel] Android video streaming
In-Reply-To: <CA++w72-qY227Ed0yiHomvnOBen+82u3WDWLAxG56a1AXw3X3pg@mail.gmail.com>
References: <CA++w728i8L3S=5Zvsc6JDNSLsrWHmy0=nCW-5uh7fFLZKGsXKA@mail.gmail.com>
 <1CAFAE28-08DF-40CE-A53E-07978079D4EE@live555.com>
 <CA++w729Wb+vz7zGF+CkWAHN6B1692TxkEGK4Zo80QooC-uRqmg@mail.gmail.com>
 <B7EBA28A-A866-4841-83D9-344D7813CE28@live555.com>
 <CA++w729=baQKkXi27jyhdof7f46vB466F=-P4ijwwiDhVhbGYg@mail.gmail.com>
 <A997A5E0-61BD-4F42-A9CB-F00384BD2072@live555.com>
 <CA++w72-qY227Ed0yiHomvnOBen+82u3WDWLAxG56a1AXw3X3pg@mail.gmail.com>
Message-ID: <9D23DF5D-4919-4BA1-9C3A-09B39292D39A@live555.com>

> Thanks for response, and no plans for now for mp4, 3gp?

No.

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/20121101/f7405503/attachment.html>

From finlayson at live555.com  Thu Nov  1 08:53:30 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 1 Nov 2012 11:53:30 -0400
Subject: [Live-devel] RTSP Support for VLC on SLES 11.2
In-Reply-To: <508F1978.500@gmail.com>
References: <508F1978.500@gmail.com>
Message-ID: <E47A03A6-9A23-464C-A595-A1D18F468710@live555.com>

VLC is not our software.  Questions about building VLC need to be posted to a VLC mailing list - not here.

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/20121101/56136f17/attachment.html>

From Jeremiah.Morrill at econnect.tv  Thu Nov  1 17:53:10 2012
From: Jeremiah.Morrill at econnect.tv (Jeremiah Morrill)
Date: Fri, 2 Nov 2012 00:53:10 +0000
Subject: [Live-devel] RTPInterface::sendRTPorRTCPPacketOverTCP on Server 2003
Message-ID: <80C795F72B3CB241A9256DABF0A04EC52DF20F8B@CH1PRD0710MB391.namprd07.prod.outlook.com>

First, I want to apologize for bringing up this list's favorite topics, Windows Server and JPEG streaming. =)

Using the latest (10.24.2012) Live555, I was having an odd issue streaming JPEG over TCP from any Windows Server 2003 box, even a Server 2003 VM running on the same machine.  I would only get a frame once in a while...sometimes none.  UDP always streamed great.  I tested from many Windows Server 2008 boxes and TCP _and_ UDP worked great also.

I tried fiddling with the RTSPServer's socket send buffer (increaseSendBufferTo 2MB) and it had no effect.  After more fiddling with Live555 code, I landed in the RTPInterface::sendRTPorRTCPPacketOverTCP method and found that the first call to RTPInterface::sendDataOverTCP that sends the framingHeader was failing, returning an EAGAIN in the envir().getErrno().  This caused it to never execute the second call to sendDataOverTCP which sends out the packet.

Changing the first call that sends out the framingHeader to sendDataOverTCP to set the forceSendToSucceed parameter to "True" instead of "False" fixed the problem on my Windows Server 2003 boxes and it now streams great via TCP.

if (!sendDataOverTCP(socketNum, framingHeader, 4, True)) break;


I don't like the idea of modifying the Live555 code and I don't like changing things that were coded a certain way for a reason.  I was wondering what the side effects may be and  I was hoping someone may have any idea of what is going wrong (besides using Windows hehe) and if there was a better way to fix this.

Thanks for any help!

-Jeremiah Morrill

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121102/965898ad/attachment-0001.html>

From finlayson at live555.com  Thu Nov  1 18:14:37 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 1 Nov 2012 21:14:37 -0400
Subject: [Live-devel] RTPInterface::sendRTPorRTCPPacketOverTCP on Server
	2003
In-Reply-To: <80C795F72B3CB241A9256DABF0A04EC52DF20F8B@CH1PRD0710MB391.namprd07.prod.outlook.com>
References: <80C795F72B3CB241A9256DABF0A04EC52DF20F8B@CH1PRD0710MB391.namprd07.prod.outlook.com>
Message-ID: <828BF266-6059-41A9-AD0D-C4049FFD59DE@live555.com>

> I don?t like the idea of modifying the Live555 code and I don?t like changing things that were coded a certain way for a reason.  I was wondering what the side effects may be and  I was hoping someone may have any idea of what is going wrong (besides using Windows hehe) and if there was a better way to fix this.

Yes, a better way to fix this is to not use JPEG.  JPEG is a *terrible* codec for video streaming.

The "EAGAIN" error that you're getting - despite having increased your OS's socket buffering - is occurring because the bitrate of your stream is exceeding the capacity of your TCP connection.  If you try to 'fix' things by doing blocking sends for all packets, then this may work if you're streaming from a file (it'll be just like delivering a file from a web server), but if you're streaming from a live stream (i.e., from a video camera), then the stream will get further and further behind in time, you will eventually run out of data *somewhere* (e.g., in whatever buffering you have between your encoder and the LIVE555 server).

In any case, if you modify the supplied source code, you can expect no support on this mailing list.


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/20121101/3ca27448/attachment.html>

From sujith at vvidiacom.com  Fri Nov  2 02:48:05 2012
From: sujith at vvidiacom.com ( Sudhakaran, Sujith)
Date: Fri, 2 Nov 2012 15:18:05 +0530
Subject: [Live-devel] Does Live555 support MP4/3GP streaming
Message-ID: <000301cdb8df$2b66fd40$8234f7c0$@vvidiacom.com>

Hi All,

 

I am very much new to streaming and came across LIVE555, I wanted to stream
mp4 and 3gp file through LIVE555.

Does it support streaming of mp4 and 3gp files currently?

 

Thanks in advance.

 

Thanks & Regards,

Sujith Sudhakaran

Member Of Technical Staff 

Description: Description: Description: cid:image001.gif at 01CCC400.2FFFF750 

Description: Description: cid:38EDA677-CBD3-4144-AD7E-5299BC92665C

yGSM Mobile (Voice & Data): +91-7709872228

(Tel: +91-22-40212598 I (Fax:+91-22-40212596

7E- Mail:  <mailto:Sujith at vvidiacom.com> Sujith at vvidiacom.com I 8Web:
<http://www.vvidiacom.com/> http://www.vvidiacom.com 

 

P Please don't print this e-mail unless you really need to, this will
preserve trees on planet earth. 

----------------------------Disclaimer--------------------------------------
----------------------------------------------------------------------------
----------------------------------------------------------------------------
---------

The information contained in this message (including any attachments) is
confidential and may be privileged. If you have received it by mistake
please notify the sender by return e-mail and permanently delete this
message and any attachments from your system. Please note that e-mails are
susceptible to change and malwares. VVIDIA COMMUNICATIONS PVT LTD.
(including its group companies) shall not be liable for the improper or
incomplete transmission of the information contained in this communication
nor for any delay in its receipt or damage to your system. 

----------------------------------------------------------------------------
---------------------------------------------Disclaimer---------------------
----------------------------------------------------------------------------
---------

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121102/8fb376f5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1580 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121102/8fb376f5/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 2904 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121102/8fb376f5/attachment.png>

From finlayson at live555.com  Fri Nov  2 04:06:15 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 2 Nov 2012 07:06:15 -0400
Subject: [Live-devel] Does Live555 support MP4/3GP streaming
In-Reply-To: <000301cdb8df$2b66fd40$8234f7c0$@vvidiacom.com>
References: <000301cdb8df$2b66fd40$8234f7c0$@vvidiacom.com>
Message-ID: <A23D87DF-FC23-4567-AA5F-3C9E4F67FC47@live555.com>

> I am very much new to streaming and came across LIVE555, I wanted to stream mp4 and 3gp file through LIVE555.
> Does it support streaming of mp4 and 3gp files currently?

No.


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/20121102/3aa64da9/attachment-0001.html>

From sujith at vvidiacom.com  Fri Nov  2 04:59:12 2012
From: sujith at vvidiacom.com ( Sudhakaran, Sujith)
Date: Fri, 2 Nov 2012 17:29:12 +0530
Subject: [Live-devel] Does Live555 support MP4/3GP streaming
In-Reply-To: <A23D87DF-FC23-4567-AA5F-3C9E4F67FC47@live555.com>
References: <000301cdb8df$2b66fd40$8234f7c0$@vvidiacom.com>
 <A23D87DF-FC23-4567-AA5F-3C9E4F67FC47@live555.com>
Message-ID: <002701cdb8f1$7c8a9b20$759fd160$@vvidiacom.com>

Hi,

 

Is there any way that you can suggest, where I can do some modification.

I found some post which was saying to :

define and implement your own new subclass of
"OnDemandServerMediaSubsession" 

that reimplements the two pure virtual functions "createNewStreamSource()"
and "createNewRTPSink()".  

This new subclass will probably be similar to the existing
"H264VideoFileServerMediaSubsession" class 

(which is used for streaming from a H.264 Video Elementary Stream file).

 

I would like to understand the significance of these two functions.  If you
can give in some inputs it would be very helpful.

What things are really necessary for making a to edit in these virtual
functions?

 

Thanks in advance.

 

 

Thanks & Regards,

Sujith Sudhakaran

Member Of Technical Staff 

Description: Description: Description: cid:image001.gif at 01CCC400.2FFFF750 

Description: Description: cid:38EDA677-CBD3-4144-AD7E-5299BC92665C

yGSM Mobile (Voice & Data): +91-7709872228

(Tel: +91-22-40212598 I (Fax:+91-22-40212596

7E- Mail: Sujith at vvidiacom.com I 8Web:  <http://www.vvidiacom.com/>
http://www.vvidiacom.com 

 

P Please don't print this e-mail unless you really need to, this will
preserve trees on planet earth. 

----------------------------Disclaimer--------------------------------------
----------------------------------------------------------------------------
----------------------------------------------------------------------------
---------

The information contained in this message (including any attachments) is
confidential and may be privileged. If you have received it by mistake
please notify the sender by return e-mail and permanently delete this
message and any attachments from your system. Please note that e-mails are
susceptible to change and malwares. VVIDIA COMMUNICATIONS PVT LTD.
(including its group companies) shall not be liable for the improper or
incomplete transmission of the information contained in this communication
nor for any delay in its receipt or damage to your system. 

----------------------------------------------------------------------------
---------------------------------------------Disclaimer---------------------
----------------------------------------------------------------------------
---------

 

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: 02 November 2012 16:36
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Does Live555 support MP4/3GP streaming

 

I am very much new to streaming and came across LIVE555, I wanted to stream
mp4 and 3gp file through LIVE555.

Does it support streaming of mp4 and 3gp files currently?

 

No.

 

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/20121102/965b4682/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1580 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121102/965b4682/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 2904 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121102/965b4682/attachment.png>

From zammargu at marvell.com  Fri Nov  2 09:03:58 2012
From: zammargu at marvell.com (Zahira Ammarguellat)
Date: Fri, 2 Nov 2012 09:03:58 -0700
Subject: [Live-devel] RTP header in an MPEG2-TS
Message-ID: <B2A7C617B3AB7F44B7B44C7D374B431E13A13321EB@sc-vexch3.marvell.com>

Hello,

I have an encapsulated MPEG2-TS input stream with RTP header. Is LiveMedia able to parse such stream? Can it extract those RTP headers and return the stream without them?
Thanks,

-Zahira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121102/aa205683/attachment.html>

From Jeremiah.Morrill at econnect.tv  Fri Nov  2 12:19:48 2012
From: Jeremiah.Morrill at econnect.tv (Jeremiah Morrill)
Date: Fri, 2 Nov 2012 19:19:48 +0000
Subject: [Live-devel] RTPInterface::sendRTPorRTCPPacketOverTCP on
	Server	2003
In-Reply-To: <828BF266-6059-41A9-AD0D-C4049FFD59DE@live555.com>
References: <80C795F72B3CB241A9256DABF0A04EC52DF20F8B@CH1PRD0710MB391.namprd07.prod.outlook.com>
 <828BF266-6059-41A9-AD0D-C4049FFD59DE@live555.com>
Message-ID: <80C795F72B3CB241A9256DABF0A04EC52DF22F79@CH1PRD0710MB391.namprd07.prod.outlook.com>

Thank you very much for taking the time to respond!

I hate JPEG streaming too, but the unfortunate part is we have a lot of customers with investments with (old) MJPEG video encoders.  It's a slow, but eventual process in moving them to H264 encoders.

You are also 100% correct with your assessment of my issue.  I was increasing the send buffer size of socket passed to the RTSPServer constructor, which had no effect.  I have now subclassed RTSPServer::RTSPClientConnection and increased the buffer size on the socket sent to this constructor and this fixed all my issues and back to a supported version of Live555 =)

Thanks again for your quick response and hard work!

-Jer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121102/0d412324/attachment-0001.html>

From finlayson at live555.com  Sun Nov  4 12:54:45 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 4 Nov 2012 15:54:45 -0500
Subject: [Live-devel] Patch for iOS 6 compilation
In-Reply-To: <CAG7SQq5TQsa104tz3So9BzB-9PHhT3DTpT+dryvf-YZ3QeM9Zg@mail.gmail.com>
References: <CAG7SQq5TQsa104tz3So9BzB-9PHhT3DTpT+dryvf-YZ3QeM9Zg@mail.gmail.com>
Message-ID: <41F92AD8-1875-48EE-9FD4-4E7F3E35741B@live555.com>


On Oct 31, 2012, at 4:45 PM, Chris Ballinger <chrisballinger at gmail.com> wrote:

> I found the answer on StackOverflow (http://stackoverflow.com/questions/11369933/live555-compile-for-ios-build-error) but it appears no one submitted a patch yet, so here it is! <config.iphoneos.patch>

Thanks.  This will be included in the next release of the software.

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/20121104/de4dbac1/attachment.html>

From finlayson at live555.com  Mon Nov  5 04:54:24 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 5 Nov 2012 07:54:24 -0500
Subject: [Live-devel] RTP header in an MPEG2-TS
In-Reply-To: <B2A7C617B3AB7F44B7B44C7D374B431E13A13321EB@sc-vexch3.marvell.com>
References: <B2A7C617B3AB7F44B7B44C7D374B431E13A13321EB@sc-vexch3.marvell.com>
Message-ID: <3A06DFA1-2D5B-475C-917E-9805F601AB6D@live555.com>

> I have an encapsulated MPEG2-TS input stream with RTP header.

By this I assume you mean that your input stream consists of RTP packets containing MPEG-2 TS data.


> Is LiveMedia able to parse such stream? Can it extract those RTP headers and return the stream without them?

Yes.  Note, for example, the code for the "testMPEG2TransportReceiver" demo application, which does this - it receives a stream of RTP packets that contain MPEG-2 Transport Stream data, and writes the Transport Stream data to a file.

See "testProgs/testMPEG2TransportReceiver.cpp".  Of course, to use it on your stream, you'll probably need to change "sessionAddressStr" and "rtpPortNum".


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/20121105/7ddd867e/attachment.html>

From zammargu at marvell.com  Mon Nov  5 06:08:09 2012
From: zammargu at marvell.com (Zahira Ammarguellat)
Date: Mon, 5 Nov 2012 06:08:09 -0800
Subject: [Live-devel] RTP header in an MPEG2-TS
In-Reply-To: <3A06DFA1-2D5B-475C-917E-9805F601AB6D@live555.com>
References: <B2A7C617B3AB7F44B7B44C7D374B431E13A13321EB@sc-vexch3.marvell.com>
 <3A06DFA1-2D5B-475C-917E-9805F601AB6D@live555.com>
Message-ID: <B2A7C617B3AB7F44B7B44C7D374B431E13A13F103C@sc-vexch3.marvell.com>

Ross,

Yes that's what I mean.
Thanks much!

-Zahira

From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Monday, November 05, 2012 7:54 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] RTP header in an MPEG2-TS

I have an encapsulated MPEG2-TS input stream with RTP header.

By this I assume you mean that your input stream consists of RTP packets containing MPEG-2 TS data.



Is LiveMedia able to parse such stream? Can it extract those RTP headers and return the stream without them?

Yes.  Note, for example, the code for the "testMPEG2TransportReceiver" demo application, which does this - it receives a stream of RTP packets that contain MPEG-2 Transport Stream data, and writes the Transport Stream data to a file.

See "testProgs/testMPEG2TransportReceiver.cpp".  Of course, to use it on your stream, you'll probably need to change "sessionAddressStr" and "rtpPortNum".

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/20121105/10d9e81d/attachment.html>

From simon.roehrl.ext at siemens.com  Mon Nov  5 07:34:52 2012
From: simon.roehrl.ext at siemens.com (Roehrl, Simon)
Date: Mon, 5 Nov 2012 16:34:52 +0100
Subject: [Live-devel] Timestamp conversion in RTPSink.cpp
Message-ID: <76EB6D54AFDD1349B9D48319372F7BA70A384D1B6B@DEMCHP99E84MSX.ww902.siemens.net>

Hi,

we want to use live555 in one of our products on the WinCE platform and we have some issues with timestamp calculation.
>From file liveMedia/RTPSink.cpp:

u_int32_t RTPSink::convertToRTPTimestamp(struct timeval tv) {

// Begin by converting from "struct timeval" units to RTP timestamp units:

u_int32_t timestampIncrement = (fTimestampFrequency*tv.tv_sec);

timestampIncrement += (u_int32_t)((2.0*fTimestampFrequency*tv.tv_usec + 1000000.0)/2000000);

// note: rounding

...

Could you tell me why you are calculation the timstampIncrement like this? Is there a reason for adding '1000000.0'?
This doesn't make sense to me.

I would suggest:

timestampIncrement += (tv.tv_usec*fTimestampFrequency/1000000.0);

Kind Regards,

Simon R?hrl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121105/1b5244bc/attachment.html>

From finlayson at live555.com  Mon Nov  5 07:59:17 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 5 Nov 2012 10:59:17 -0500
Subject: [Live-devel] Timestamp conversion in RTPSink.cpp
In-Reply-To: <76EB6D54AFDD1349B9D48319372F7BA70A384D1B6B@DEMCHP99E84MSX.ww902.siemens.net>
References: <76EB6D54AFDD1349B9D48319372F7BA70A384D1B6B@DEMCHP99E84MSX.ww902.siemens.net>
Message-ID: <AEC0D578-84B8-403A-8FF2-531F9F4E1CF9@live555.com>

> we want to use live555 in one of our products on the WinCE platform and we have some issues with timestamp calculation.
> From file liveMedia/RTPSink.cpp:
> u_int32_t RTPSink::convertToRTPTimestamp(struct timeval tv) {
> 
> // Begin by converting from "struct timeval" units to RTP timestamp units:
> 
> u_int32_t timestampIncrement = (fTimestampFrequency*tv.tv_sec);
> 
> timestampIncrement += (u_int32_t)((2.0*fTimestampFrequency*tv.tv_usec + 1000000.0)/2000000);
> 
> // note: rounding
> 
> ...
> 
> Could you tell me why you are calculation the timstampIncrement like this?

It's done this way so that the result is rounded to the nearest integer.  Suppose, for example, that "fTimestampFrequency*tv.tv_usec" is 1990000.  Computing "tv.tv_usec*fTimestampFrequency/1000000.0" will give you 1 (when converted back to an "int").  However, computing "(2.0*fTimestampFrequency*tv.tv_usec + 1000000.0)/2000000" will give you 2, which is more accurate.

What specific 'issues' do you think you are having with timestamp calculation?  Are you having a problem specifically with this line of code??  If not, then your 'issues' are probably not with timestamp calculation.  Note that developers usually don't need to concern themselves with RTP timestamps; our software automatically converts presentation times to RTP timestamps (on transmission), and then back to presentation times (on reception).  As a developer, the important thing that you need to concern yourself with is ***presentation times***.  Your data sources' frames *must* have accurate presentation times, and they must be aligned to 'wall clock' time (i.e., the time that you would get by calling "gettimeofday()".)


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/20121105/abecf289/attachment.html>

From shaman.lab.x11 at gmail.com  Fri Nov  2 06:40:30 2012
From: shaman.lab.x11 at gmail.com (=?KOI8-R?B?88XSx8XKIOLB09TSwcvP1w==?=)
Date: Fri, 2 Nov 2012 17:40:30 +0400
Subject: [Live-devel] RTCPInstance error: Hit limit when reading incoming
 packet over TCP. Increase "maxRTCPPacketSize"
Message-ID: <CAA0p+4PxROutkgWXPyU1O-2gtVCPngmYptqUmcC1Sxrx3SEP0Q@mail.gmail.com>

Hello, all
I wrote dll library by proxy example. It works well, but sometimes there is
a mistake "RTCPInstance error: Hit limit when reading incoming packet over
TCP. Increase "maxRTCPPacketSize"" and one of streams is freeze. It occurs
when clients are connected and one of them stops playing.
After that in the log will be this line before server restart.
http://pastebin.com/wc6JGvpn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121102/f18cf4fa/attachment-0001.html>

From finlayson at live555.com  Mon Nov  5 11:31:48 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 5 Nov 2012 14:31:48 -0500
Subject: [Live-devel] RTCPInstance error: Hit limit when reading
	incoming packet over TCP. Increase "maxRTCPPacketSize"
In-Reply-To: <CAA0p+4PxROutkgWXPyU1O-2gtVCPngmYptqUmcC1Sxrx3SEP0Q@mail.gmail.com>
References: <CAA0p+4PxROutkgWXPyU1O-2gtVCPngmYptqUmcC1Sxrx3SEP0Q@mail.gmail.com>
Message-ID: <078A8D67-C134-4FDC-B0F1-AF6051D30385@live555.com>

> I wrote dll library by proxy example. It works well, but sometimes there is a mistake "RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize"

Are you using the latest version of the software?  Recent upgrades to the software should have made this error message much less likely.

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/20121105/d640b351/attachment.html>

From ranshalit at gmail.com  Sat Nov  3 13:45:36 2012
From: ranshalit at gmail.com (Ran Shalit)
Date: Sat, 3 Nov 2012 22:45:36 +0200
Subject: [Live-devel] constant rate
Message-ID: <CAJ2oMhJ6mrc+n1VayNttqmY2pEW4Ov02qPriPntKDwGrFC+F9A@mail.gmail.com>

Hello,

I would like to ask what is the advantage of transmitting bitrate in
constant rate (with null packets) instead of a regular transmit
without null packets in lower average rate ?

Thank you,
Ran

From finlayson at live555.com  Mon Nov  5 16:14:31 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 5 Nov 2012 19:14:31 -0500
Subject: [Live-devel] constant rate
In-Reply-To: <CAJ2oMhJ6mrc+n1VayNttqmY2pEW4Ov02qPriPntKDwGrFC+F9A@mail.gmail.com>
References: <CAJ2oMhJ6mrc+n1VayNttqmY2pEW4Ov02qPriPntKDwGrFC+F9A@mail.gmail.com>
Message-ID: <DC659D33-F58F-451C-BC8D-069408C7586B@live555.com>

> I would like to ask what is the advantage of transmitting bitrate in
> constant rate (with null packets) instead of a regular transmit
> without null packets in lower average rate ?

What a strange question.  There is *no* advantage in transmitting packets at a constant rate (with null packets) over the Internet.  Nobody does this (and certainly not us).

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/20121105/9c210b7e/attachment.html>

From simon.roehrl.ext at siemens.com  Tue Nov  6 02:48:31 2012
From: simon.roehrl.ext at siemens.com (Roehrl, Simon)
Date: Tue, 6 Nov 2012 11:48:31 +0100
Subject: [Live-devel] Timestamp conversion in RTPSink.cpp
In-Reply-To: <AEC0D578-84B8-403A-8FF2-531F9F4E1CF9@live555.com>
References: <76EB6D54AFDD1349B9D48319372F7BA70A384D1B6B@DEMCHP99E84MSX.ww902.siemens.net>
 <AEC0D578-84B8-403A-8FF2-531F9F4E1CF9@live555.com>
Message-ID: <76EB6D54AFDD1349B9D48319372F7BA70A384D1DFD@DEMCHP99E84MSX.ww902.siemens.net>


we want to use live555 in one of our products on the WinCE platform and we have some issues with timestamp calculation.
>From file liveMedia/RTPSink.cpp:

u_int32_t RTPSink::convertToRTPTimestamp(struct timeval tv) {

// Begin by converting from "struct timeval" units to RTP timestamp units:

u_int32_t timestampIncrement = (fTimestampFrequency*tv.tv_sec);

timestampIncrement += (u_int32_t)((2.0*fTimestampFrequency*tv.tv_usec + 1000000.0)/2000000);

// note: rounding

...

Could you tell me why you are calculation the timstampIncrement like this?

It's done this way so that the result is rounded to the nearest integer.  Suppose, for example, that "fTimestampFrequency*tv.tv_usec" is 1990000.  Computing "tv.tv_usec*fTimestampFrequency/1000000.0" will give you 1 (when converted back to an "int").  However, computing "(2.0*fTimestampFrequency*tv.tv_usec + 1000000.0)/2000000" will give you 2, which is more accurate.

What specific 'issues' do you think you are having with timestamp calculation?  Are you having a problem specifically with this line of code??  If not, then your 'issues' are probably not with timestamp calculation.  Note that developers usually don't need to concern themselves with RTP timestamps; our software automatically converts presentation times to RTP timestamps (on transmission), and then back to presentation times (on reception).  As a developer, the important thing that you need to concern yourself with is ***presentation times***.  Your data sources' frames *must* have accurate presentation times, and they must be aligned to 'wall clock' time (i.e., the time that you would get by calling "gettimeofday()".)


Thank you very much for your answer. Your words make sense concerning the calculation!
There were two different (independent) problems:
1 the underlined line returns 0 on Freescale's I.MX53 ARM cpu, the reason:    "fTimestampFrequency*tv.tv_usec" is too large for 32bit. As the datatype of "timestampIncrement" is u_int32_t the calculation is performed with 32 bit width. On a 64bit PC this seems not to be a problem because it calculates automatically with 64bit. The fix for this is to use a u_int64_t variable which is casted back to 32bit in the addition of TimestampBase and incrementTimestamp.

2  in the gettimeofday function in GroupSockHelper.cpp (line 700):
    Theres a define for WinCE, but unfortunately the WinCE version oft gettimeofday is not working properly, I assume that it wasn't tested? You can find alot occurences of this problem in WinCE world. The problem is the "GetSystemTime()" call, which should fill the SYSTEMTIME struct, but it does not, at least not the milliseconds field (which is always 0). The solution I used:

int gettimeofday(struct timeval* tp, int* /*tz*/) {
#if defined(_WIN32_WCE)
  /* FILETIME of Jan 1 1970 00:00:00. */
  static const unsigned __int64 epoch = 116444736000000000LL;
  static Boolean isFirstCall = True;
  static LONGLONG unixStartTime = 0;
  static DWORD firstTickCount=0;

  if (isFirstCall) {

    FILETIME fileTime;

    GetSystemTimeAsFileTime(&fileTime);

    LARGE_INTEGER date;
    date.HighPart = fileTime.dwHighDateTime;
    date.LowPart = fileTime.dwLowDateTime;

    unixStartTime= (date.QuadPart - epoch) / 10000000L;

    firstTickCount = GetTickCount();

    tp->tv_sec=(long)unixStartTime;
    tp->tv_usec= 0L;

    isFirstCall = False; // for next time

  } else {
    // add elapsed seconds
    tp->tv_sec= (long)unixStartTime + (GetTickCount()-firstTickCount)/1000;
    tp->tv_usec=(GetTickCount()-firstTickCount)%1000 * 1000;
}

#else
...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121106/e19ad50f/attachment.html>

From finlayson at live555.com  Tue Nov  6 06:41:52 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 6 Nov 2012 09:41:52 -0500
Subject: [Live-devel] Timestamp conversion in RTPSink.cpp
In-Reply-To: <76EB6D54AFDD1349B9D48319372F7BA70A384D1DFD@DEMCHP99E84MSX.ww902.siemens.net>
References: <76EB6D54AFDD1349B9D48319372F7BA70A384D1B6B@DEMCHP99E84MSX.ww902.siemens.net>
 <AEC0D578-84B8-403A-8FF2-531F9F4E1CF9@live555.com>
 <76EB6D54AFDD1349B9D48319372F7BA70A384D1DFD@DEMCHP99E84MSX.ww902.siemens.net>
Message-ID: <44AD56E7-EDB8-4359-86BA-DB275ADB896B@live555.com>

> Thank you very much for your answer. Your words make sense concerning the calculation! 
> There were two different (independent) problems:
> 1 the underlined line returns 0 on Freescale's I.MX53 ARM cpu, the reason:    "fTimestampFrequency*tv.tv_usec" is too large for 32bit. As the datatype of "timestampIncrement" is u_int32_t the calculation is performed with 32 bit width. On a 64bit PC this seems not to be a problem because it calculates automatically with 64bit. The fix for this is to use a u_int64_t

No, that shouldn't be necessary.  The following should overcome the problem:

	timestampIncrement += (u_int32_t)(fTimestampFrequency*(tv.tv_usec/1000000.0) + 0.5);

because the calculation will be done with floats, but then converted to a "u_int32_t" at the end - without any overflow.

(2.0*fTimestampFrequency*tv.tv_usec + 1000000.0)/2000000);


> 2  in the gettimeofday function in GroupSockHelper.cpp (line 700):
>     Theres a define for WinCE, but unfortunately the WinCE version oft gettimeofday is not working properly, I assume that it wasn't tested?

I don't (and will never) use WinCE myself, so any contributions of WinCE-specific code - such as this - have come from other WinCErs.  I have to trust that it works.


> You can find alot occurences of this problem in WinCE world. The problem is the "GetSystemTime()" call, which should fill the SYSTEMTIME struct, but it does not, at least not the milliseconds field (which is always 0). The solution I used:
>  
> int gettimeofday(struct timeval* tp, int* /*tz*/) {
> #if defined(_WIN32_WCE)
>   /* FILETIME of Jan 1 1970 00:00:00. */
>   static const unsigned __int64 epoch = 116444736000000000LL;
>   static Boolean isFirstCall = True;
>   static LONGLONG unixStartTime = 0;
>   static DWORD firstTickCount=0;
>  
>   if (isFirstCall) {
>  
>     FILETIME fileTime;
>  
>     GetSystemTimeAsFileTime(&fileTime);
>  
>     LARGE_INTEGER date;
>     date.HighPart = fileTime.dwHighDateTime;
>     date.LowPart = fileTime.dwLowDateTime;
>  
>     unixStartTime= (date.QuadPart - epoch) / 10000000L;
>  
>     firstTickCount = GetTickCount();
>  
>     tp->tv_sec=(long)unixStartTime;
>     tp->tv_usec= 0L;
>  
>     isFirstCall = False; // for next time
>  
>   } else {
>     // add elapsed seconds
>     tp->tv_sec= (long)unixStartTime + (GetTickCount()-firstTickCount)/1000;
>     tp->tv_usec=(GetTickCount()-firstTickCount)%1000 * 1000;
> }
>  
> #else

OK, I'll make both these changes in the next release of the software.

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/20121106/cac2a692/attachment-0001.html>

From finlayson at live555.com  Tue Nov  6 07:00:20 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 6 Nov 2012 10:00:20 -0500
Subject: [Live-devel] Timestamp conversion in RTPSink.cpp
In-Reply-To: <76EB6D54AFDD1349B9D48319372F7BA70A384D1DFD@DEMCHP99E84MSX.ww902.siemens.net>
References: <76EB6D54AFDD1349B9D48319372F7BA70A384D1B6B@DEMCHP99E84MSX.ww902.siemens.net>
 <AEC0D578-84B8-403A-8FF2-531F9F4E1CF9@live555.com>
 <76EB6D54AFDD1349B9D48319372F7BA70A384D1DFD@DEMCHP99E84MSX.ww902.siemens.net>
Message-ID: <44A23EE7-3ED7-4D77-96FF-C60A46D7B741@live555.com>

> You can find alot occurences of this problem in WinCE world. The problem is the "GetSystemTime()" call, which should fill the SYSTEMTIME struct, but it does not, at least not the milliseconds field (which is always 0). The solution I used:

>  
> int gettimeofday(struct timeval* tp, int* /*tz*/) {
> #if defined(_WIN32_WCE)
>   /* FILETIME of Jan 1 1970 00:00:00. */
>   static const unsigned __int64 epoch = 116444736000000000LL;
>   static Boolean isFirstCall = True;
>   static LONGLONG unixStartTime = 0;
>   static DWORD firstTickCount=0;
>  
>   if (isFirstCall) {
>  
>     FILETIME fileTime;
>  
>     GetSystemTimeAsFileTime(&fileTime);
>  
>     LARGE_INTEGER date;
>     date.HighPart = fileTime.dwHighDateTime;
>     date.LowPart = fileTime.dwLowDateTime;
>  
>     unixStartTime= (date.QuadPart - epoch) / 10000000L;
>  
>     firstTickCount = GetTickCount();
>  
>     tp->tv_sec=(long)unixStartTime;
>     tp->tv_usec= 0L;
>  
>     isFirstCall = False; // for next time
>  
>   } else {
>     // add elapsed seconds
>     tp->tv_sec= (long)unixStartTime + (GetTickCount()-firstTickCount)/1000;
>     tp->tv_usec=(GetTickCount()-firstTickCount)%1000 * 1000;
> }
>  
> #else

Correction: On further thought, I don't want to make this change 'as is'.  The problem is that it's possible for the "gettimeofday()" function to be called concurrently from multiple threads.  (This is legal for LIVE555-based systems that use different "UsageEnvironment" and "TaskScheduler" objects for each thread.)  So, the implementation needs to be 'thread safe'.  If the "if" branch of the "if (isFirstCall)" statement gets executed concurrently by more than one thread, then "unixStartTime" and/or "firstTickCount" might get set to bad values.

So, please rewrite your implementation to ensure that the "if" branch of the code (i.e., the part of the code that sets static variables) is executed only once, even if the code is called by multiple threads.  (Because this code is for WinCE only, it's OK to use some WinCE-specific locking mechanism, if necessary.)

(However, I'll make the change to the timestamp conversion code in the next release of the software.)

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/20121106/a19273c9/attachment.html>

From dalcaraz at eye-cam.com  Thu Nov  8 01:43:28 2012
From: dalcaraz at eye-cam.com (David Alcaraz Moreno)
Date: Thu, 08 Nov 2012 10:43:28 +0100
Subject: [Live-devel] rtp server
Message-ID: <509B7EC0.4030007@eye-cam.com>

Hello,
I'm a begginer with the real time protocol, I need  to know the way to 
send video only with the rtp, but i don't find a guide to do it. I would 
like to know the clases that I need to create a rtp server and how to?
Is there a documentation how to do this with live555?
Where I can find this documentation?
Sorry for my english.
thanks!
Best regards!

From finlayson at live555.com  Thu Nov  8 04:13:45 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 8 Nov 2012 07:13:45 -0500
Subject: [Live-devel] rtp server
In-Reply-To: <509B7EC0.4030007@eye-cam.com>
References: <509B7EC0.4030007@eye-cam.com>
Message-ID: <71CE8D1E-C399-4C32-A073-6EACD38C44D1@live555.com>

> I'm a begginer with the real time protocol, I need  to know the way to send video only with the rtp, but i don't find a guide to do it. I would like to know the clases that I need to create a rtp server and how to?
> Is there a documentation how to do this with live555?
> Where I can find this documentation?

You need to begin by reading the FAQ - as you were asked to do before posting to the mailing list.

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/20121108/4e48d446/attachment.html>

From kkc.sai at gmail.com  Wed Nov  7 22:43:45 2012
From: kkc.sai at gmail.com (kumar krishna chakraborty)
Date: Thu, 8 Nov 2012 12:13:45 +0530
Subject: [Live-devel] Error in Outputting mp4 format file
Message-ID: <CAD=rtvyXg9CkemLC_5E_+vcVDsRfMjWL9AQVeDR53=3xh8rAjQ@mail.gmail.com>

Hi,
  I have downloaded the tar.gz file and built the openrtsp application in
my 32 bit linux machine. The build was successfull. Then I went to the
testProgs directory and typed the following command to output the received
data
to stdout in .mp4 format
./openRTSP -4 -d 20 rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115.mov

The connection gets established successfully and I also get the print
"Started playing session Receiving streamed data (for up to 20.000000
seconds)"
But finally I get the error messages "QuickTimeFileSink::setWord():
SeekFile64 failed (err 29).
I want to know why this error is coming and how to resolve the issue.

thanks and regards,
Sai Krishna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121108/ebc3d5a4/attachment.html>

From gery.kahn at gmail.com  Wed Nov  7 23:56:29 2012
From: gery.kahn at gmail.com (Gery)
Date: Thu, 08 Nov 2012 09:56:29 +0200
Subject: [Live-devel] To read H264 file and stream MPEG2TS
Message-ID: <509B65AD.2020202@gmail.com>

i am trying to stream MPEG2TS from H264 file. Basically, to get together 
examples testH264VideotoTransportStream and MPEG2TransportStreamer

Running the result code makes VLC lost frames and as a result shows very 
jumpy video.

Any idea what can be wrong with my application would be greatly appreciated.

The source content is H264 file with 1280x720 resolution.
Both original examples work good.
The source code can be found at http://pastebin.com/G9EcDYyM


From simon.roehrl.ext at siemens.com  Thu Nov  8 08:04:11 2012
From: simon.roehrl.ext at siemens.com (Roehrl, Simon)
Date: Thu, 8 Nov 2012 17:04:11 +0100
Subject: [Live-devel] Timestamp conversion in RTPSink.cpp
In-Reply-To: <44A23EE7-3ED7-4D77-96FF-C60A46D7B741@live555.com>
References: <76EB6D54AFDD1349B9D48319372F7BA70A384D1B6B@DEMCHP99E84MSX.ww902.siemens.net>
 <AEC0D578-84B8-403A-8FF2-531F9F4E1CF9@live555.com>
 <76EB6D54AFDD1349B9D48319372F7BA70A384D1DFD@DEMCHP99E84MSX.ww902.siemens.net>
 <44A23EE7-3ED7-4D77-96FF-C60A46D7B741@live555.com>
Message-ID: <76EB6D54AFDD1349B9D48319372F7BA70A38548441@DEMCHP99E84MSX.ww902.siemens.net>

The windows (not CE) implementation wasn't threadsafe, so I've changed that code too.
Find attached the new GroupsockHelper.cpp. This solution is ok for us, so I won't spend any further time in this topic

________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Dienstag, 6. November 2012 16:00
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Timestamp conversion in RTPSink.cpp

You can find alot occurences of this problem in WinCE world. The problem is the "GetSystemTime()" call, which should fill the SYSTEMTIME struct, but it does not, at least not the milliseconds field (which is always 0). The solution I used:

int gettimeofday(struct timeval* tp, int* /*tz*/) {
#if defined(_WIN32_WCE)
  /* FILETIME of Jan 1 1970 00:00:00. */
  static const unsigned __int64 epoch = 116444736000000000LL;
  static Boolean isFirstCall = True;
  static LONGLONG unixStartTime = 0;
  static DWORD firstTickCount=0;

  if (isFirstCall) {

    FILETIME fileTime;

    GetSystemTimeAsFileTime(&fileTime);

    LARGE_INTEGER date;
    date.HighPart = fileTime.dwHighDateTime;
    date.LowPart = fileTime.dwLowDateTime;

    unixStartTime= (date.QuadPart - epoch) / 10000000L;

    firstTickCount = GetTickCount();

    tp->tv_sec=(long)unixStartTime;
    tp->tv_usec= 0L;

    isFirstCall = False; // for next time

  } else {
    // add elapsed seconds
    tp->tv_sec= (long)unixStartTime + (GetTickCount()-firstTickCount)/1000;
    tp->tv_usec=(GetTickCount()-firstTickCount)%1000 * 1000;
}

#else

Correction: On further thought, I don't want to make this change 'as is'.  The problem is that it's possible for the "gettimeofday()" function to be called concurrently from multiple threads.  (This is legal for LIVE555-based systems that use different "UsageEnvironment" and "TaskScheduler" objects for each thread.)  So, the implementation needs to be 'thread safe'.  If the "if" branch of the "if (isFirstCall)" statement gets executed concurrently by more than one thread, then "unixStartTime" and/or "firstTickCount" might get set to bad values.

So, please rewrite your implementation to ensure that the "if" branch of the code (i.e., the part of the code that sets static variables) is executed only once, even if the code is called by multiple threads.  (Because this code is for WinCE only, it's OK to use some WinCE-specific locking mechanism, if necessary.)

(However, I'll make the change to the timestamp conversion code in the next release of the software.)

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/20121108/02e8a588/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: GroupsockHelper.cpp
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121108/02e8a588/attachment-0001.ksh>

From finlayson at live555.com  Thu Nov  8 08:13:46 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 8 Nov 2012 11:13:46 -0500
Subject: [Live-devel] Error in Outputting mp4 format file
In-Reply-To: <CAD=rtvyXg9CkemLC_5E_+vcVDsRfMjWL9AQVeDR53=3xh8rAjQ@mail.gmail.com>
References: <CAD=rtvyXg9CkemLC_5E_+vcVDsRfMjWL9AQVeDR53=3xh8rAjQ@mail.gmail.com>
Message-ID: <DB8FFF55-8DDB-47B4-AB26-EF7ECADF8B19@live555.com>

>   I have downloaded the tar.gz file and built the openrtsp application in my 32 bit linux machine. The build was successfull. Then I went to the testProgs directory and typed the following command to output the received data
> to stdout in .mp4 format
> ./openRTSP -4 -d 20 rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115.mov

You didn't explain how you redirected 'stdout' to a file, but if you do it on the command line in the usual way - e.g., 
	./openRTSP -4 -d 20 rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115.mov > outputFile.mp4
then things should work OK.  The basic issue here is that the file written to by "QuickTimeFileSink" has to be 'seekable', because ".mov"/".mp4" files contain header information near the start that can be filled in only when the stream ends.

Alternatively, if that doesn't work, you could modify your copy of "playCommon.cpp" to change the call to "QuickFileFileSink::createNew()" (on line 686) to use your output file name, instead of "stderr".

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/20121108/d5dc04d0/attachment.html>

From finlayson at live555.com  Thu Nov  8 08:58:51 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 8 Nov 2012 11:58:51 -0500
Subject: [Live-devel] Timestamp conversion in RTPSink.cpp
In-Reply-To: <76EB6D54AFDD1349B9D48319372F7BA70A38548441@DEMCHP99E84MSX.ww902.siemens.net>
References: <76EB6D54AFDD1349B9D48319372F7BA70A384D1B6B@DEMCHP99E84MSX.ww902.siemens.net>
 <AEC0D578-84B8-403A-8FF2-531F9F4E1CF9@live555.com>
 <76EB6D54AFDD1349B9D48319372F7BA70A384D1DFD@DEMCHP99E84MSX.ww902.siemens.net>
 <44A23EE7-3ED7-4D77-96FF-C60A46D7B741@live555.com>
 <76EB6D54AFDD1349B9D48319372F7BA70A38548441@DEMCHP99E84MSX.ww902.siemens.net>
Message-ID: <D708043B-CB4B-4948-97FF-21CCCB17C566@live555.com>

> The windows (not CE) implementation wasn't threadsafe, so I've changed that code too.
> Find attached the new GroupsockHelper.cpp.

Thanks.  This has been included in a new (just released) version of the software: 2012.11.08


> This solution is ok for us, so I won't spend any further time in this topic

One of the things that makes "open source" projects like this work well is that many people are willing to help out, even on things that might not immediately benefit them.  In this case, I hope that some other Windows (and/or WinCE) experts will review this new code, just to make sure that there are no problems with it.

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/20121108/c5c4bd2b/attachment.html>

From CERLANDS at arinc.com  Thu Nov  8 10:26:16 2012
From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS))
Date: Thu, 8 Nov 2012 18:26:16 +0000
Subject: [Live-devel] TEARDOWN issue when using response handler
Message-ID: <ED766D6CFBFD8243B5285413AFCC66F421F7B7E8@EXANPMB2.arinc.com>

I'm using the liveMedia (2012.11.05) connecting to a Cisco VSM (version
6.3.2-47d). The server, as I've mentioned in a previous post, requires the
client to wait for the TEARDOWN-response, otherwise the server logs will be
filled with errors and things will eventually go bad. This can arguably be
considered an issue with the server, but it should anyhow be possible to
work around.

 

The issue on the client side is that whenever using a TEARDOWN response
handler it crashes once in a while. I want to point out that I've has the
issue when using sendTeardownCommand() without a response handler. Our
client cycles through streams frequently and I'd say I see the problem about
1 time out of 7000. That means about once every other hour when cycling
through 10 cameras every 10s. 

 

After sending TEARDOWN the response handler is never called, but instead an
exception is thrown. I haven't been able to catch the exception in the
liveMedia DLL, but I instead get an AccessViolationException in the C# code
that uses it. Logging shows that the exception happens at the exact same
place every time, which is right after calling sendTeardownCommand(), but it
never reaches the response handler.

 

Please see sample code below.

 

The code can't really be simpler, and I've no idea why it occurs.

Have I missed something obvious? Anyone experienced anything similar?

 

 

 

void shutdownStream(RTSPClient* rtspClient, int exitCode)

{

// Code omitted, as shutdownStream() is identical to the testRTSPClient
example

// beside having moved Medium::close(rtspClient) to a separate function and
adding

// the TEARDOWN response handler

...

if (someSubsessionsWereActive)

                rtspClient->sendTeardownCommand(*scs.session,
continueAfterTEARDOWN);

           else

                cleanUpStream(rtspClient);

     }

     else

     {

           cleanUpStream(rtspClient);

     }

}

 

 

void continueAfterTEARDOWN(RTSPClient* rtspClient, int resultCode, char*
resultString)

{

     cleanUpStream(rtspClient);

}

 

 

void cleanUpStream(RTSPClient* rtspClient)

{

     UsageEnvironment& env = rtspClient->envir();

 
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStart
StreamEvent);

 
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStopS
treamEvent);

 
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->mySeekA
bsoluteEvent);

 

     env << *rtspClient << "Closing the stream.\n";

     Medium::close(rtspClient);

}

 

 

/Claes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121108/1972474b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5740 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121108/1972474b/attachment-0001.bin>

From matt at schuckmannacres.com  Thu Nov  8 10:32:59 2012
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Thu, 08 Nov 2012 10:32:59 -0800
Subject: [Live-devel] Live555 and webRTC
Message-ID: <509BFADB.50803@schuckmannacres.com>

Hi Ross,
I was wondering if you had been watching the developments with WebRTC 
and it's acceptance by a few of the major browser players (Chrome, 
Firefox, and Opera)

Based on my first pass looking at it, it looks like the transport is RTP 
with another signalling protocol called ROAP instead of RTSP or SIP. It 
also looks like they trying to integrate some of the NAT traversal 
protocols like STUN and ICE.
Google has a open source library for the WebRTC protocol, I think it's 
called Jingle but it would be nice if it turned out that Live555 could 
just work with it.

Anyway I was just wondering if you were at all thinking about bring 
WebRTC support to Live555.

Thanks,
Matt S.

From matt at schuckmannacres.com  Thu Nov  8 10:45:24 2012
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Thu, 08 Nov 2012 10:45:24 -0800
Subject: [Live-devel] TEARDOWN issue when using response handler
In-Reply-To: <ED766D6CFBFD8243B5285413AFCC66F421F7B7E8@EXANPMB2.arinc.com>
References: <ED766D6CFBFD8243B5285413AFCC66F421F7B7E8@EXANPMB2.arinc.com>
Message-ID: <509BFDC4.1000501@schuckmannacres.com>

Are you sure you're calling sendTeardownCommand() from the liveMedia 
thread?
Typically I've seen random crashes like this when calling a liveMedia 
method from the wrong thread, usually inadvertently.

Matt S.

On Thursday, November 08, 2012 10:26:16 AM, Erlandsson, Claes P 
(CERLANDS) wrote:
> I'm using the liveMedia (2012.11.05) connecting to a Cisco VSM
> (version 6.3.2-47d). The server, as I've mentioned in a previous post,
> requires the client to wait for the TEARDOWN-response, otherwise the
> server logs will be filled with errors and things will eventually go
> bad. This can arguably be considered an issue with the server, but it
> should anyhow be possible to work around.
>
> The issue on the client side is that whenever using a TEARDOWN
> response handler it crashes once in a while. I want to point out that
> I've has the issue when using sendTeardownCommand() without a response
> handler. Our client cycles through streams frequently and I'd say I
> see the problem about 1 time out of 7000. That means about once every
> other hour when cycling through 10 cameras every 10s.
>
> After sending TEARDOWN the response handler is never called, but
> instead an exception is thrown. I haven't been able to catch the
> exception in the liveMedia DLL, but I instead get an
> AccessViolationException in the C# code that uses it. Logging shows
> that the exception happens at the exact same place every time, which
> is right after calling sendTeardownCommand(), but it never reaches the
> response handler.
>
> Please see sample code below.
>
> The code can't really be simpler, and I've no idea why it occurs.
>
> Have I missed something obvious? Anyone experienced anything similar?
>
> voidshutdownStream(RTSPClient* rtspClient, int exitCode)
>
> {
>
> // Code omitted, as shutdownStream() is identical to the
> testRTSPClient example
>
> // beside having moved Medium::close(rtspClient) to a separate
> function and adding
>
> // the TEARDOWN response handler
>
> ...
>
> if(someSubsessionsWereActive)
>
> rtspClient->sendTeardownCommand(*scs.session, continueAfterTEARDOWN);
>
> else
>
>                 cleanUpStream(rtspClient);
>
>      }
>
> else
>
>      {
>
>            cleanUpStream(rtspClient);
>
>      }
>
> }
>
> voidcontinueAfterTEARDOWN(RTSPClient* rtspClient, int resultCode,
> char* resultString)
>
> {
>
>      cleanUpStream(rtspClient);
>
> }
>
> voidcleanUpStream(RTSPClient* rtspClient)
>
> {
>
>      UsageEnvironment& env = rtspClient->envir();
>
>
> env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStartStreamEvent);
>
>
> env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStopStreamEvent);
>
>
> env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->mySeekAbsoluteEvent);
>
>      env << *rtspClient << "Closing the stream.\n";
>
>      Medium::close(rtspClient);
>
> }
>
> /Claes
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

From CERLANDS at arinc.com  Thu Nov  8 11:30:49 2012
From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS))
Date: Thu, 8 Nov 2012 19:30:49 +0000
Subject: [Live-devel] TEARDOWN issue when using response handler
In-Reply-To: <509BFDC4.1000501@schuckmannacres.com>
References: <ED766D6CFBFD8243B5285413AFCC66F421F7B7E8@EXANPMB2.arinc.com>
 <509BFDC4.1000501@schuckmannacres.com>
Message-ID: <ED766D6CFBFD8243B5285413AFCC66F421F7B803@EXANPMB2.arinc.com>

Yes, I only call shutdownStream() from my StopStreamEvent, which is
triggered by triggerEvent(), and from other "internal" functions, similar to
the testRTSPClient example.

If that was the case though, I imagine it would be more random, and also
happen when not using a response handler. A few months back I did the
mistake of not using triggerEvent() and I sure experiences random crashes,
but this looks different.

/Claes


-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Matt Schuckmann
Sent: Thursday, November 08, 2012 12:45 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] TEARDOWN issue when using response handler

Are you sure you're calling sendTeardownCommand() from the liveMedia 
thread?
Typically I've seen random crashes like this when calling a liveMedia 
method from the wrong thread, usually inadvertently.

Matt S.

On Thursday, November 08, 2012 10:26:16 AM, Erlandsson, Claes P 
(CERLANDS) wrote:
> I'm using the liveMedia (2012.11.05) connecting to a Cisco VSM
> (version 6.3.2-47d). The server, as I've mentioned in a previous post,
> requires the client to wait for the TEARDOWN-response, otherwise the
> server logs will be filled with errors and things will eventually go
> bad. This can arguably be considered an issue with the server, but it
> should anyhow be possible to work around.
>
> The issue on the client side is that whenever using a TEARDOWN
> response handler it crashes once in a while. I want to point out that
> I've has the issue when using sendTeardownCommand() without a response
> handler. Our client cycles through streams frequently and I'd say I
> see the problem about 1 time out of 7000. That means about once every
> other hour when cycling through 10 cameras every 10s.
>
> After sending TEARDOWN the response handler is never called, but
> instead an exception is thrown. I haven't been able to catch the
> exception in the liveMedia DLL, but I instead get an
> AccessViolationException in the C# code that uses it. Logging shows
> that the exception happens at the exact same place every time, which
> is right after calling sendTeardownCommand(), but it never reaches the
> response handler.
>
> Please see sample code below.
>
> The code can't really be simpler, and I've no idea why it occurs.
>
> Have I missed something obvious? Anyone experienced anything similar?
>
> voidshutdownStream(RTSPClient* rtspClient, int exitCode)
>
> {
>
> // Code omitted, as shutdownStream() is identical to the
> testRTSPClient example
>
> // beside having moved Medium::close(rtspClient) to a separate
> function and adding
>
> // the TEARDOWN response handler
>
> ...
>
> if(someSubsessionsWereActive)
>
> rtspClient->sendTeardownCommand(*scs.session, continueAfterTEARDOWN);
>
> else
>
>                 cleanUpStream(rtspClient);
>
>      }
>
> else
>
>      {
>
>            cleanUpStream(rtspClient);
>
>      }
>
> }
>
> voidcontinueAfterTEARDOWN(RTSPClient* rtspClient, int resultCode,
> char* resultString)
>
> {
>
>      cleanUpStream(rtspClient);
>
> }
>
> voidcleanUpStream(RTSPClient* rtspClient)
>
> {
>
>      UsageEnvironment& env = rtspClient->envir();
>
>
>
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStart
StreamEvent);
>
>
>
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStopS
treamEvent);
>
>
>
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->mySeekA
bsoluteEvent);
>
>      env << *rtspClient << "Closing the stream.\n";
>
>      Medium::close(rtspClient);
>
> }
>
> /Claes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5740 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121108/e406a9d8/attachment.bin>

From live555 at csmiller.demon.co.uk  Thu Nov  8 09:11:13 2012
From: live555 at csmiller.demon.co.uk (live555 at csmiller.demon.co.uk)
Date: Thu, 08 Nov 2012 17:11:13 +0000
Subject: [Live-devel] playRTPMPEG source code location
Message-ID: <E1TWVdJ-000Bwg-B5@pr-webmail-2.demon.net>

Hi,
Is the source code for playRTPMPEG available?
It doesn't seem to part of the main live555 tarball.

On a related note, the MS-Windows installer on 
   http://www.live555.com/multikit/windows/playRTPMPEGSetup.exe
has a 16-bit application within it, this is preventing it from installing on Windows7 64bit, as MS decided to remove 16 bit support from Windows7 64bit.

TIA,
Colin S. Miller


From finlayson at live555.com  Thu Nov  8 14:08:13 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 8 Nov 2012 17:08:13 -0500
Subject: [Live-devel] playRTPMPEG source code location
In-Reply-To: <E1TWVdJ-000Bwg-B5@pr-webmail-2.demon.net>
References: <E1TWVdJ-000Bwg-B5@pr-webmail-2.demon.net>
Message-ID: <AF65FC67-648B-4ACF-B55F-5BA68FC7BE91@live555.com>

Oh wow - that application hasn't been supported in almost a decade.  I didn't know that it was even available on our web site anymore.

Instead, you should look at the "LIVE555 Streaming Media" software - in particular, the demo applications in the "testProgs" directory.


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/20121108/0ab908b2/attachment.html>

From finlayson at live555.com  Thu Nov  8 14:29:30 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 8 Nov 2012 17:29:30 -0500
Subject: [Live-devel] Live555 and webRTC
In-Reply-To: <509BFADB.50803@schuckmannacres.com>
References: <509BFADB.50803@schuckmannacres.com>
Message-ID: <DDBC682D-E7D4-4678-8419-46DAFE57403A@live555.com>

Believe me, I've been keeping *very* close track of the WebRTC work.  In fact, at this very moment I'm at the IETF meeting in Atlanta, and have attended both of the WebRTC sessions that have been held there.

I hope that someday it will be possible to view LIVE555 server streams from a WebRTC-enabled web browser.

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/20121108/a5904ecc/attachment-0001.html>

From matt at schuckmannacres.com  Thu Nov  8 14:48:33 2012
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Thu, 08 Nov 2012 14:48:33 -0800
Subject: [Live-devel] Live555 and webRTC
In-Reply-To: <DDBC682D-E7D4-4678-8419-46DAFE57403A@live555.com>
References: <509BFADB.50803@schuckmannacres.com>
 <DDBC682D-E7D4-4678-8419-46DAFE57403A@live555.com>
Message-ID: <509C36C1.8010800@schuckmannacres.com>

Very cool, thanks for keeping up on this. Bet it feels good that the 
industry is finally moving in the direction that you've been working on 
for so long.

Matt S.

On Thursday, November 08, 2012 2:29:30 PM, Ross Finlayson wrote:
> Believe me, I've been keeping *very* close track of the WebRTC work.
>  In fact, at this very moment I'm at the IETF meeting in Atlanta, and
> have attended both of the WebRTC sessions that have been held there.
>
> I hope that someday it will be possible to view LIVE555 server streams
> from a WebRTC-enabled web browser.
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

From finlayson at live555.com  Thu Nov  8 15:24:08 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 8 Nov 2012 18:24:08 -0500
Subject: [Live-devel] To read H264 file and stream MPEG2TS
In-Reply-To: <509B65AD.2020202@gmail.com>
References: <509B65AD.2020202@gmail.com>
Message-ID: <7CFF08CC-0CCC-44AC-A9C4-D3AF8E8E27F1@live555.com>

I suspect that the problem here is that by feeding a "MPEG2TransportStreamFromESSource" directly into a "SimpleRTPSink", you end up sending very small RTP packets - each containing just one (188-byte) Transport Packet.

For greater efficiency, you should insert - between the "MPEG2TransportStreamFromESSource" and the "SimpleRTPSink" - a new 'filter', that you would write, that accumulates incoming MPEG Transport Stream packets into groups of 7 (i.e., 7*188 = 1316 bytes), before feeding it into the "SimpleRTPSink". 


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/20121108/f9ef1543/attachment.html>

From michael.denczek at l-3com.com  Mon Nov 12 12:55:29 2012
From: michael.denczek at l-3com.com (michael.denczek at l-3com.com)
Date: Mon, 12 Nov 2012 15:55:29 -0500
Subject: [Live-devel] Low Frame Rate Live Streaming
Message-ID: <910E82F60F64E34D8388CAFCE988965B148980B017@mail>

Hello,

I am using Live555 to stream raw H.264 live video via RTP/RTSP.  In order to provide the video at various frame rates, 1 or more uncompressed video samples are dropped before being passed to the H264 encoder.  This works well for the source frame rate of 29.97 fps and also frame rates of 14.985, 9.99, 5.994, and 4.995 fps.  When the frame rate is dropped further to 2.997 fps or below, video playback in VLC freezes with warning messages stating "picture is too late to be displayed (missing xxx ms)" followed by an avcodec error message "more than 5 seconds of late video -> dropping frame (computer too slow ?)".

I get this same behavior whether streaming H264 discrete NALs or AnnexB frames.  I would like to support three lower frame rates of 2.997, 1.998, and 0.999 fps but after extensive searching through the Live555 source code, the VLC source code and trying various timestamping offsets, I am unable to figure out why the problem is occuring.

Is there a correlation between video source frame rate and an allowable tolerance on the RTSP client side?  Any suggestions are greatly appreciated.

I've included part of the VLC log below, followed by the Live555 debug output:

VLC Messages

main error: ES_OUT_RESET_PCR called
main warning: picture is too late to be displayed (missing 22 ms)
main warning: picture is too late to be displayed (missing 31 ms)
main warning: picture is too late to be displayed (missing 40 ms)
main warning: picture is too late to be displayed (missing 33 ms)
main warning: picture is too late to be displayed (missing 38 ms)
avcodec error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
main warning: picture is too late to be displayed (missing 4367 ms)
main warning: picture is too late to be displayed (missing 4374 ms)
main warning: picture is too late to be displayed (missing 4036 ms)
main warning: picture is too late to be displayed (missing 35 ms)
main warning: picture is too late to be displayed (missing 41 ms)
avcodec error: more than 5 seconds of late video -> dropping frame (computer too slow ?)

Live555 Debug Output

accept()ed connection from 166.201.101.178
RTSPClientConnection[13C30068]::handleRequestBytes() read 128 new bytes:OPTIONS rtsp://166.201.101.178:5544/stream RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13)

parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "", urlSuffix "stream", CSeq "2", Content-Length 0, with 0 bytes following the message.
sending response: RTSP/1.0 200 OK
CSeq: 2
Date: Mon, Nov 12 2012 20:36:12 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

RTSPClientConnection[13C30068]::handleRequestBytes() read 154 new bytes:DESCRIBE rtsp://166.201.101.178:5544/stream RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13)
Accept: application/sdp

parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "stream", CSeq "3", Content-Length 0, with 0 bytes following the message.
sending response: RTSP/1.0 200 OK
CSeq: 3
Date: Mon, Nov 12 2012 20:36:13 GMT
Content-Base: rtsp://166.201.101.178:5544/stream/
Content-Type: application/sdp
Content-Length: 453

v=0
o=- 1352752561887715 1 IN IP4 166.201.101.178
s=Mobile-Vision
i=Live Stream
t=0 0
a=tool:LIVE555 Streaming Media v2012.10.22
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:Streamer
a=x-qt-text-inf:Live Stream
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:500
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=42C00A;sprop-parameter-sets=Z0LACtoFB/EycBEAAAMD6QAAF3CPEiag,aM48gA==
a=control:track1
RTSPClientConnection[13C30068]::handleRequestBytes() read 185 new bytes:SETUP rtsp://166.201.101.178:5544/stream/track1 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13)
Transport: RTP/AVP;unicast;client_port=61044-61045

parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "stream", urlSuffix "track1", CSeq "4", Content-Length 0, with 0 bytes following the message.
sending response: RTSP/1.0 200 OK
CSeq: 4
Date: Mon, Nov 12 2012 20:36:13 GMT
Transport: RTP/AVP;unicast;destination=166.201.101.178;source=166.201.101.178;client_port=61044-61045;server_port=6970-6971
Session: EA51CD5B

RTSPClientConnection[13C30068]::handleRequestBytes() read 164 new bytes:PLAY rtsp://166.201.101.178:5544/stream/ RTSP/1.0
CSeq: 5
User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13)
Session: EA51CD5B
Range: npt=0.000-

parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "stream", urlSuffix "", CSeq "5", Content-Length 0, with 0 bytes following the message.
RTCPInstance[13C80A58]::RTCPInstance()
schedule(2.635291->1352752575.699293)
sending response: RTSP/1.0 200 OK
CSeq: 5
Date: Mon, Nov 12 2012 20:36:13 GMT
Range: npt=0.000-
Session: EA51CD5B
RTP-Info: url=rtsp://166.201.101.178:5544/stream/track1;seq=34988;rtptime=1296858229

RTSPClientConnection[13C30068]::handleRequestBytes() read 154 new bytes:GET_PARAMETER rtsp://166.201.101.178:5544/stream/ RTSP/1.0
CSeq: 6
User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13)
Session: EA51CD5B

parseRTSPRequestString() succeeded, returning cmdName "GET_PARAMETER", urlPreSuffix "stream", urlSuffix "", CSeq "6", Content-Length 0, with 0 bytes following the message
.
sending response: RTSP/1.0 200 OK
CSeq: 6
Date: Mon, Nov 12 2012 20:36:13 GMT
Session: EA51CD5B

[13C80A58]saw incoming RTCP packet (from address 166.201.101.178, port 61045)
81c90007 e19e90c2 6a65ecb8 00ffffff 00018900 0000006e 00000000 00000000 81ca0004 e19e90c2 01094441 56454d2d 44543200
RR
RTSP client session (id "EA51CD5B", stream name "stream"): Liveness indication
validated RTCP subpacket (type 2): 1, 201, 0, 0xe19e90c2
UNSUPPORTED TYPE(0xca)
validated RTCP subpacket (type 2): 1, 202, 12, 0xe19e90c2
validated entire RTCP packet
sending REPORT
sending RTCP packet
80c80006 6a65ecb8 d44bdc3f b4101f32 e79b102c 00000063 0001f667 81ca0004 6a65ecb8 01094441 56454d2d 44543200
schedule(1.521657->1352752577.231249)
schedule(1.073723->1352752578.305810)
schedule(1.315771->1352752579.622907)
sending REPORT
sending RTCP packet
80c80006 6a65ecb8 d44bdc43 a0232096 e7a0730f 00000120 0005b484 81ca0004 6a65ecb8 01094441 56454d2d 44543200
schedule(2.467409->1352752582.098886)
[13C80A58]saw incoming RTCP packet (from address 166.201.101.178, port 61045)
81c90007 e19e90c2 6a65ecb8 00ffffff 00018a15 00000155 dc43a023 00010f4d 81ca0004 e19e90c2 01094441 56454d2d 44543200
RR
RTSP client session (id "EA51CD5B", stream name "stream"): Liveness indication
validated RTCP subpacket (type 2): 1, 201, 0, 0xe19e90c2
UNSUPPORTED TYPE(0xca)
validated RTCP subpacket (type 2): 1, 202, 12, 0xe19e90c2
validated entire RTCP packet
sending REPORT
sending RTCP packet
80c80006 6a65ecb8 d44bdc46 1ac4e725 e7a3da98 000001a5 00085e35 81ca0004 6a65ecb8 01094441 56454d2d 44543200
schedule(4.129500->1352752586.241355)
[13C80A58]saw incoming RTCP packet (from address 166.201.101.178, port 61045)
81c90007 e19e90c2 6a65ecb8 00ffffff 00018b27 000001f5 dc461ac4 0003ecb4 81ca0004 e19e90c2 01094441 56454d2d 44543200
RR
RTSP client session (id "EA51CD5B", stream name "stream"): Liveness indication
validated RTCP subpacket (type 2): 1, 201, 0, 0xe19e90c2
UNSUPPORTED TYPE(0xca)
validated RTCP subpacket (type 2): 1, 202, 12, 0xe19e90c2
validated entire RTCP packet
schedule(0.379229->1352752586.621720)
schedule(0.755303->1352752587.377771)
sending REPORT
sending RTCP packet
80c80006 6a65ecb8 d44bdc4b 60fd4bf1 e7ab18d7 000002af 000da6ca 81ca0004 6a65ecb8 01094441 56454d2d 44543200
reap: checking SSRC 0xe19e90c2: 4 (threshold 0)
schedule(4.851568->1352752592.235369)
RTSPClientConnection[13C30068]::handleRequestBytes() read 149 new bytes:TEARDOWN rtsp://166.201.101.178:5544/stream/ RTSP/1.0
CSeq: 7
User-Agent: LibVLC/2.0.4 (LIVE555 Streaming Media v2012.09.13)
Session: EA51CD5B

parseRTSPRequestString() succeeded, returning cmdName "TEARDOWN", urlPreSuffix "stream", urlSuffix "", CSeq "7", Content-Length 0, with 0 bytes following the message.
RTCPInstance[13C80A58]::~RTCPInstance()
sending BYE
sending RTCP packet
80c80006 6a65ecb8 d44bdc4f 9dd9c27f e7b0eaab 00000373 001183b5 81cb0001 6a65ecb8
sending response: RTSP/1.0 200 OK
CSeq: 7
Date: Mon, Nov 12 2012 20:36:31 GMT

RTSPClientConnection[13C30068]::handleRequestBytes() read -1 new bytes (of 10000); terminating connection!




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121112/d2742a54/attachment-0001.html>

From finlayson at live555.com  Mon Nov 12 13:31:47 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 12 Nov 2012 13:31:47 -0800
Subject: [Live-devel] Low Frame Rate Live Streaming
In-Reply-To: <910E82F60F64E34D8388CAFCE988965B148980B017@mail>
References: <910E82F60F64E34D8388CAFCE988965B148980B017@mail>
Message-ID: <A4A49A66-D841-47A0-B79A-61942609CAF6@live555.com>

> Is there a correlation between video source frame rate and an allowable tolerance on the RTSP client side?

No.  As long as your frames are given accurate 'presentation times' (aligned with 'wall-clock time' - i.e., the times that you would get by calling "gettimeofday()"), then you should have no problem.

The problems that you are seeing with VLC seem to be unrelated to its use as a LIVE555 RTSP client, so you'll need to contact a VLC mailing list to ask them about your problem.


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/20121112/ecc39d2f/attachment.html>

From gery.kahn at gmail.com  Wed Nov 14 07:57:05 2012
From: gery.kahn at gmail.com (Gery)
Date: Wed, 14 Nov 2012 17:57:05 +0200
Subject: [Live-devel] To read H264 file and stream MPEG2TS
In-Reply-To: <7CFF08CC-0CCC-44AC-A9C4-D3AF8E8E27F1@live555.com>
References: <509B65AD.2020202@gmail.com>
 <7CFF08CC-0CCC-44AC-A9C4-D3AF8E8E27F1@live555.com>
Message-ID: <50A3BF51.6050309@gmail.com>

Thank you. I am aggregating 7 TS packets now.
My VLC still complains because of high bitrate.

is there way to delay reading from H264 file?



On 11/09/2012 01:24 AM, Ross Finlayson wrote:
> I suspect that the problem here is that by feeding a
> "MPEG2TransportStreamFromESSource" directly into a "SimpleRTPSink",
> you end up sending very small RTP packets - each containing just one
> (188-byte) Transport Packet.
>
> For greater efficiency, you should insert - between
> the "MPEG2TransportStreamFromESSource" and the "SimpleRTPSink" - a new
> 'filter', that you would write, that accumulates incoming MPEG
> Transport Stream packets into groups of 7 (i.e., 7*188 = 1316 bytes),
> before feeding it into the "SimpleRTPSink". 
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel


From finlayson at live555.com  Wed Nov 14 18:08:39 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 14 Nov 2012 18:08:39 -0800
Subject: [Live-devel] To read H264 file and stream MPEG2TS
In-Reply-To: <50A3BF51.6050309@gmail.com>
References: <509B65AD.2020202@gmail.com>
 <7CFF08CC-0CCC-44AC-A9C4-D3AF8E8E27F1@live555.com>
 <50A3BF51.6050309@gmail.com>
Message-ID: <3ECF378E-A1E8-46DA-9EC8-0718FDF496BB@live555.com>

> Thank you. I am aggregating 7 TS packets now.
> My VLC still complains because of high bitrate.
> 
> is there way to delay reading from H264 file?


The "H264VideoStreamFramer" class automatically sets the duration of each frame (i.e., the "fDurationInMicroseconds") based on what it thinks is the stream's frame rate.  Unfortunately, if the input source does not specify a frame rate - in a "SPS" NAL unit - then the code assumes a (commonly-used) frame rate of 25 frames-per-second.

I suspect that your input H.264 video file does not begin with a "SPS" NAL unit.  Unless it does, the code will not be able to figure out the stream's correct frame rate.


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/20121114/0093a218/attachment.html>

From kingaceck at 163.com  Fri Nov 16 05:37:55 2012
From: kingaceck at 163.com (=?GBK?B?s8K/rQ==?=)
Date: Fri, 16 Nov 2012 21:37:55 +0800 (CST)
Subject: [Live-devel] is it a bug of proxy server
Message-ID: <2cc0984f.24704.13b0970a694.Coremail.kingaceck@163.com>

      I am using proxy server to relay the rtp stream that coming from a back-end rtsp server.After following steps the proxy server is broken down.
The steps as the following:
1)begin to relay the rtp stream and connect to the server using vlc.
2)restart the back-end rtsp server,after [30..61] seconds(the OPTION command delay) close the vlc that opened at step 1
3)then the proxy server is broken down and there have a segmentation fault error at the linux console
     I have read the source code and found that
when the proxy server lost connect to the back-end server it will delete all Subsessions(using fOurServerMediaSession.deleteAllSubsessions()).
But when vlc is closed it will send a TEARDOWN command to the proxy server and the proxy server will delete stream for each subsession(at the RTSPServer::RTSPClientSession
::handleCmd_TEARDOWN(...)).When deleting the streams the subsession has been deleted at the deleteAllSubsessions() function,so the subsession is a invalidate pointer.
When calling the invalidate pointer the proxy server is broken down.Is there anything to do to correct this issue?
 
 Thank you very much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121116/5d031708/attachment.html>

From finlayson at live555.com  Fri Nov 16 19:12:25 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 16 Nov 2012 19:12:25 -0800
Subject: [Live-devel] is it a bug of proxy server
In-Reply-To: <2cc0984f.24704.13b0970a694.Coremail.kingaceck@163.com>
References: <2cc0984f.24704.13b0970a694.Coremail.kingaceck@163.com>
Message-ID: <C8A74924-F450-4673-BBD5-167F013A36CB@live555.com>

Thanks for the report.  I've just installed a new version (2012.11.17) of the "LIVE555 Streaming Media" software that should fix this.

(A FYI to anyone who has written their own proxy server: The signature to "ProxyServerMediaSession::createNew()" has now changed.  This function now also takes (a pointer to) the "RTSPServer" object as parameter.)


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/20121116/abe86534/attachment.html>

From nmenne at dcscorp.com  Mon Nov 19 10:49:49 2012
From: nmenne at dcscorp.com (Menne, Neil)
Date: Mon, 19 Nov 2012 18:49:49 +0000
Subject: [Live-devel] RTP URL question
Message-ID: <B12A0552C51D3E4EB3B3581D5E1FF625014240@MPEXCHMBX1.dcscorp.com>

Hello, all

I have a quick question. I'm looking to add the capability of adding an RTP stream that is specified only by a URL of the form "rtp://<ip>:<port>" This is an add on to an existing video widget. I have also seen examples where people specify the URL as "rtp://@<ip>:<port>"

Is this possible with Live555? If so, which form of the URL is appropriate? With or without '@'?

-Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121119/c08623c3/attachment.html>

From finlayson at live555.com  Mon Nov 19 13:46:18 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 19 Nov 2012 13:46:18 -0800
Subject: [Live-devel] RTP URL question
In-Reply-To: <B12A0552C51D3E4EB3B3581D5E1FF625014240@MPEXCHMBX1.dcscorp.com>
References: <B12A0552C51D3E4EB3B3581D5E1FF625014240@MPEXCHMBX1.dcscorp.com>
Message-ID: <B9B8BBE4-41C4-4975-BC5E-EB602C233D65@live555.com>

> I have a quick question. I?m looking to add the capability of adding an RTP stream that is specified only by a URL of the form ?rtp://<ip>:<port>? This is an add on to an existing video widget. I have also seen examples where people specify the URL as ?rtp://@<ip>:<port>?
>  
> Is this possible with Live555?

No, because this type of URL (which has never been standardized) doesn't give you enough information about the stream.  In particular, it doesn't tell you the RTP payload format (i.e., the data type) of the stream.  Also, specifying only one port number isn't enough, because to properly receive a RTP stream, you need to know not just the stream's destination RTP port, but also the RTCP port on which the sender should receive RTCP "RR" packets back from the receiver.

Instead, the best way to receive a stream is to use the RTSP protocol (i.e., a "rtsp://" URL).  This protocol gives the client all of the information that it needs to receive the stream.


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/20121119/97feb2db/attachment-0001.html>

From tbatra18 at gmail.com  Mon Nov 19 05:47:43 2012
From: tbatra18 at gmail.com (Tarun Batra)
Date: Mon, 19 Nov 2012 19:17:43 +0530
Subject: [Live-devel] How can i set the reclamation time for particular
 session-id in my live media server
Message-ID: <CAALD5ixg7Lk1EDJFLnEZ=k8hmNg31-sUNyT+8Vauuu=rPcMQng@mail.gmail.com>

Hello Sir

I am using your "test on Demand RTSP server code" to make RTSP server and
streaming the dta through the function "A MPEG-2 Transport Stream, coming
from a live UDP (raw-UDP or RTP/UDP) source",after 65 seconds i have to
re-connect to the server as reclamation time is 65 seconds and i am
streaming over http.

 if i can found the liveliness of my client how can i set the reclamation
time for particular session-id in my live media server.Is there any in
built function available?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121119/c6c398a1/attachment.html>

From finlayson at live555.com  Mon Nov 19 15:45:53 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 19 Nov 2012 15:45:53 -0800
Subject: [Live-devel] How can i set the reclamation time for particular
	session-id in my live media server
In-Reply-To: <CAALD5ixg7Lk1EDJFLnEZ=k8hmNg31-sUNyT+8Vauuu=rPcMQng@mail.gmail.com>
References: <CAALD5ixg7Lk1EDJFLnEZ=k8hmNg31-sUNyT+8Vauuu=rPcMQng@mail.gmail.com>
Message-ID: <B0E24F92-45DB-4185-BA91-C56B3274502F@live555.com>

> I am using your "test on Demand RTSP server code" to make RTSP server and streaming the dta through the function "A MPEG-2 Transport Stream, coming from a live UDP (raw-UDP or RTP/UDP) source",after 65 seconds i have to re-connect to the server as reclamation time is 65 seconds and i am streaming over http.

You haven't said anything about your client.  It needs to send periodic RTCP "Reception Report" (RR) packets back to the server.  The server will use these to note that the client is alive (and thus avoid timing it out).  If your client uses our software, then these should get sent automatically.


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/20121119/325d08e4/attachment.html>

From Sathish.Manohar at aricent.com  Tue Nov 20 06:42:51 2012
From: Sathish.Manohar at aricent.com (Sathish Kumar Manohar)
Date: Tue, 20 Nov 2012 20:12:51 +0530
Subject: [Live-devel] Reg: MPEG2TS over UDP
In-Reply-To: <50A3BF51.6050309@gmail.com>
References: <509B65AD.2020202@gmail.com>
 <7CFF08CC-0CCC-44AC-A9C4-D3AF8E8E27F1@live555.com>,
 <50A3BF51.6050309@gmail.com>
Message-ID: <295BBDFA57CDE94BB3B04B5D5F28EE32048DB26C1D@GUREXMB02.ASIAN.AD.ARICENT.COM>

Hi,

We are currently working for a rtsp client, which needs to support MPEG2TS over UDP instead of RTP.

I have seen same kind of questions in this forum but didn't answer my question

>From one of the mail threads , I saw that it's the server which decides whether to send data over RTP or UDP after initial RTSP negotiations.

Is there any way to configure the live555 server to send TS data over UDP only?

This requirement is for Video on Demand.

Regards
Sathish Kumar M




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================


From finlayson at live555.com  Tue Nov 20 11:40:48 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 20 Nov 2012 11:40:48 -0800
Subject: [Live-devel] Reg: MPEG2TS over UDP
In-Reply-To: <295BBDFA57CDE94BB3B04B5D5F28EE32048DB26C1D@GUREXMB02.ASIAN.AD.ARICENT.COM>
References: <509B65AD.2020202@gmail.com>
 <7CFF08CC-0CCC-44AC-A9C4-D3AF8E8E27F1@live555.com>,
 <50A3BF51.6050309@gmail.com>
 <295BBDFA57CDE94BB3B04B5D5F28EE32048DB26C1D@GUREXMB02.ASIAN.AD.ARICENT.COM>
Message-ID: <C6483F46-FF7C-4696-A73B-15EC054B4A11@live555.com>

> Is there any way to configure the live555 server to send TS data over UDP only?

Perhaps.  However, the situation is complicated by the fact that there is no standard defined for how to specify raw-UDP streaming within the RTSP protocol.  Different 'raw-UDP' RTSP clients - because they are non-standard - may use the RTSP protocol in different (perhaps non-standard) ways.  (For example, the Amino set-top box client doesn't use the RTSP "PLAY" command at all.  Instead, it uses only the RTSP "SETUP" command, without sending "PLAY".)

So, to answer your question, I'd need to know how your client works.  So, could you please send us the RTSP protocol exchange between your client and our RTSP server (serving a Transport Stream file)?  To do this, add the line

#define DEBUG 1

to the start of "liveMedia/RTSPServer.cpp", recompile the server, and rerun it.


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/20121120/dd2bc725/attachment.html>

From sutuglon at gmail.com  Tue Nov 20 05:33:31 2012
From: sutuglon at gmail.com (chema benito)
Date: Tue, 20 Nov 2012 14:33:31 +0100
Subject: [Live-devel] iOS packet loss
Message-ID: <CAA9OH5p=UfSeh89svgQcpO5eG4RjJrPQRaW3dm-1ajL8EuKA7Q@mail.gmail.com>

Hello,
 this is my first email to this list. That said, we are trying to receive
RTSP video (h264 and MPEG4) from our cameras. The problem is we are
experiencing packet loss in our devices (iPhone 4, iPad 2 and 3) when we go
to higher resolutions (say around 720x536) that are not occurring in the
iOS simulation, which seems to discard problems in our implementation. My
test application is running an openRTSP style receiver in its own thread,
then doing nothing with its payload, which discards blocking issues of the
thread by other processing. All it does is

 1) select
 2) handle to MultiFramedRTPSource networkHandler
 3) reordering
 4) handle afterGettingFrame, which is empty.

 with yet this is enough for packet loss.

 I discard Wifi issues because the code never loses a packet running in the
iOS simulator on a MacBookAir over Wifi.
 I also increasedReceiveBufferTo 2000000 bytes which somewhat
alleviated the problem, but did not get rid of it completely.

 have you experienced or heard of similar problems of other people with
this issue? Is it a iOS hardware limitation? Any ideas what could be going
wrong?

 Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121120/1eb86c5e/attachment.html>

From 503430770 at qq.com  Tue Nov 20 07:47:26 2012
From: 503430770 at qq.com (=?utf-8?B?Li4u?=)
Date: Tue, 20 Nov 2012 23:47:26 +0800
Subject: [Live-devel] about SDP
Message-ID: <tencent_1DED5CD67246DF9303D8DE02@qq.com>

An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121120/a04036dc/attachment.html>

From Sathish.Manohar at aricent.com  Tue Nov 20 22:32:39 2012
From: Sathish.Manohar at aricent.com (Sathish Kumar Manohar)
Date: Wed, 21 Nov 2012 12:02:39 +0530
Subject: [Live-devel] Reg: MPEG2TS over UDP
In-Reply-To: <C6483F46-FF7C-4696-A73B-15EC054B4A11@live555.com>
References: <509B65AD.2020202@gmail.com>
 <7CFF08CC-0CCC-44AC-A9C4-D3AF8E8E27F1@live555.com>,
 <50A3BF51.6050309@gmail.com>
 <295BBDFA57CDE94BB3B04B5D5F28EE32048DB26C1D@GUREXMB02.ASIAN.AD.ARICENT.COM>,
 <C6483F46-FF7C-4696-A73B-15EC054B4A11@live555.com>
Message-ID: <295BBDFA57CDE94BB3B04B5D5F28EE32048DB26C22@GUREXMB02.ASIAN.AD.ARICENT.COM>

Hi Ross,
Thanks for the quick response.
We are currently implementing our RTSP client for Android Platform. I will share our client and live555 server negotiations soon.

There is already a Server which supports MPEG2TS over UDP at our client's place. We don't have access to that.
We thought Live555 would be better for our offshore development.

This is already a RTSP client in Linux platform and their negotiations are as follows. We just have this log.
Our End solution would look like this only. Just see whether this data would help.

OPTIONS rtsp://172.17.178.94:554/2032153999 RTSP/1.0
CSeq: 4

RTSP/1.0 200 OK
Server: XXX
CSeq: 4
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER

DESCRIBE rtsp://172.17.178.94:554/2032153999 RTSP/1.0
CSeq: 5
User-Agent: XYZ Player

RTSP/1.0 200 OK
Server: XXX
CSeq: 5
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER
Content-Type: application/sdp
Content-Length: 212

v=0
o=- 2032153999 0 IN IP4 172.17.178.94
s=2032153999
t=0 0
c=IN IP4 172.17.178.94
b=AS:9746.000
a=type:vodrtf
a=range:npt=0-6992
m=video 0 MP2T/H2221/UDP 33
m=video 0 UDP 33
m=video 0 RTP/AVP/UDP 33

SETUP rtsp://172.17.178.94:554/2032153999 RTSP/1.0
CSeq: 6
Transport: RAW/RAW/UDP;unicast;destination=10.149.174.231;client_port=33260
User-Agent: XYZ Player

RTSP/1.0 200 OK
Server: XXX
CSeq: 6
Session: 2032153999;timeout=60
Transport: RAW/RAW/UDP;unicast;destination=10.149.174.231;client_port=33260;source=172.17.178.94;server_port=10000

PLAY rtsp://172.17.178.94:554/2032153999 RTSP/1.0
CSeq: 7
Scale: 1.000000
Range: npt=0-
Session: 2032153999

RTSP/1.0 200 OK
Server: XXX
CSeq: 7
Session: 2032153999
Scale: 1.00
Range: npt=0-


Regards
Sathish Kumar M
________________________________________
From: live-devel-bounces at ns.live555.com [live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson [finlayson at live555.com]
Sent: Wednesday, November 21, 2012 1:10 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Reg: MPEG2TS over UDP

Is there any way to configure the live555 server to send TS data over UDP only?

Perhaps.  However, the situation is complicated by the fact that there is no standard defined for how to specify raw-UDP streaming within the RTSP protocol.  Different 'raw-UDP' RTSP clients - because they are non-standard - may use the RTSP protocol in different (perhaps non-standard) ways.  (For example, the Amino set-top box client doesn't use the RTSP "PLAY" command at all.  Instead, it uses only the RTSP "SETUP" command, without sending "PLAY".)

So, to answer your question, I'd need to know how your client works.  So, could you please send us the RTSP protocol exchange between your client and our RTSP server (serving a Transport Stream file)?  To do this, add the line

#define DEBUG 1

to the start of "liveMedia/RTSPServer.cpp", recompile the server, and rerun it.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/





===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================


From finlayson at live555.com  Tue Nov 20 23:15:24 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 20 Nov 2012 23:15:24 -0800
Subject: [Live-devel] Reg: MPEG2TS over UDP
In-Reply-To: <295BBDFA57CDE94BB3B04B5D5F28EE32048DB26C22@GUREXMB02.ASIAN.AD.ARICENT.COM>
References: <509B65AD.2020202@gmail.com>
 <7CFF08CC-0CCC-44AC-A9C4-D3AF8E8E27F1@live555.com>,
 <50A3BF51.6050309@gmail.com>
 <295BBDFA57CDE94BB3B04B5D5F28EE32048DB26C1D@GUREXMB02.ASIAN.AD.ARICENT.COM>,
 <C6483F46-FF7C-4696-A73B-15EC054B4A11@live555.com>
 <295BBDFA57CDE94BB3B04B5D5F28EE32048DB26C22@GUREXMB02.ASIAN.AD.ARICENT.COM>
Message-ID: <7359C60B-05CF-4802-95DB-BA1122E7912A@live555.com>

> We are currently implementing our RTSP client

I don't understand.  If you're implementing your own RTSP client, then why not have it use the standard RTP/UDP transport?  The overhead is negligible, and you get several benefits (including proper handling of reordered packets, and RTCP reception statistics) from using a standard transport.

But anyway, if you program your client to use a "Transport:" header with "RAW/RAW/UDP" as the transport in the RTSP "SETUP" command, then our LIVE555 RTSP server implementation will probably accept that (even though it returned "RTP/AVP" in the SDP response to the previous "DESCRIBE" command).  Because you're using a non-standard protocol, however, you can expect no further support from me on this.


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/20121120/de579235/attachment.html>

From finlayson at live555.com  Wed Nov 21 14:40:35 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 21 Nov 2012 14:40:35 -0800
Subject: [Live-devel] iOS packet loss
In-Reply-To: <CAA9OH5p=UfSeh89svgQcpO5eG4RjJrPQRaW3dm-1ajL8EuKA7Q@mail.gmail.com>
References: <CAA9OH5p=UfSeh89svgQcpO5eG4RjJrPQRaW3dm-1ajL8EuKA7Q@mail.gmail.com>
Message-ID: <1ACD701F-1395-4F01-9E58-4A42ABFC0DCD@live555.com>

On Nov 20, 2012, at 5:33 AM, chema benito <sutuglon at gmail.com> wrote:
> 
> we are trying to receive RTSP video (h264 and MPEG4) from our cameras. The problem is we are

Do 'we' not have our own domain name? :-)

> experiencing packet loss in our devices (iPhone 4, iPad 2 and 3) when we go to higher resolutions (say around 720x536) that are not occurring in the iOS simulation, which seems to discard problems in our implementation.

The only thing that I can think of is that perhaps your iOS device - unlike the Mac on which you run the iOS simulator - does not have enough CPU power.  What are you doing with the received video frames?  Passing them through video decoding software?

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/20121121/20f131a9/attachment.html>

From finlayson at live555.com  Wed Nov 21 15:31:05 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 21 Nov 2012 15:31:05 -0800
Subject: [Live-devel] about SDP
In-Reply-To: <tencent_1DED5CD67246DF9303D8DE02@qq.com>
References: <tencent_1DED5CD67246DF9303D8DE02@qq.com>
Message-ID: <DC3F6778-E9BF-4755-AF98-9F90A230EDFF@live555.com>

>        Hi,I'm using live555 as a server of realtime H264 data.  I just write a "FramedSource" subclass ,then use H264VideoStreamDiscreteFramer as the FramedSource.   Now, useing VLC as client  is ok(also our own client), but I have some problems.
>  
>       1. To contrast the SDP information with others, my SDP info have no "a=fmtp:xx packetization-mode=1 profile-level-id=xx  sprop-parameter-sets=xx,xx". 

The problem here is probably that your input H.264 stream does not contain any SPS and PPS NAL units - at least not anywhere near the start of the stream.  These NAL units are important, because information from them is needed to construct the "a=fmtp:..." line.

So, you need to make sure that your stream contains SPS and PPS NAL units.  E.g., you could put them at the start of the input stream that you feed to "H264VideoStreamDiscreteFramer".

Alternatively, you could use (in your "createNewRTPSink" implementation) one of the alternative forms of "H264VideoRTPSink::createNew()" that takes the SPS and PPS NAL units as parameters.  See "liveMedia/include/H264VideoRTPSink.hh".


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/20121121/6072b454/attachment.html>

From dalcaraz at eye-cam.com  Thu Nov 22 08:10:51 2012
From: dalcaraz at eye-cam.com (David Alcaraz Moreno)
Date: Thu, 22 Nov 2012 17:10:51 +0100
Subject: [Live-devel] Not error but doesn't send RTP packages
Message-ID: <50AE4E8B.8050406@eye-cam.com>

my library doesn't send RTP packages.
I have implemented a FramedSource subclass and 
onDemandServerMediaSubsession sublclas in my library.
For start the streaming, the first that I do is :
this->videoSink->startPlaying(*(this->videoSource), 
afterPlayingFunction, this->videoSink);
this->envv->taskScheduler().doEventLoop();
second:
setFrames(frame *data,dataLength)
The setFrames function throws a event:
ourScheduler->triggerEvent(FramedSource::eventTriggerId, ourDevice);

In debug mode, i can see how the frames are consumed by FramedSource in 
the  deliverFrame function, but nothing happens, my machine doesn't  
send the RTP packages.  what do I have to do?

the VLC message:
VLC is unable to open the MRL << rtp :/ / 192.168.0.248:4446 >>

Sorry for my english!

regards!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121122/d713abb7/attachment.html>

From finlayson at live555.com  Thu Nov 22 08:45:54 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 22 Nov 2012 08:45:54 -0800
Subject: [Live-devel] Not error but doesn't send RTP packages
In-Reply-To: <50AE4E8B.8050406@eye-cam.com>
References: <50AE4E8B.8050406@eye-cam.com>
Message-ID: <B7A8E7D6-854A-4D96-B068-C4520AFABAD9@live555.com>

> VLC is unable to open the MRL << rtp :/ / 192.168.0.248:4446 >>

You should, instead, be using a "rtsp://" URL, because your application is creating a RTSP server (at least, it should be).

Also, because VLC is not our software, you should first be using "testRTSPClient" (or "openRTSP") as your receiving client.


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/20121122/e639983f/attachment.html>

From longkexi at gmail.com  Wed Nov 21 21:47:03 2012
From: longkexi at gmail.com (longkexi)
Date: Thu, 22 Nov 2012 13:47:03 +0800
Subject: [Live-devel] about using
Message-ID: <310B571F-2F0B-4A0B-9590-05006B7169E1@gmail.com>


Hello sir?
I'm trying to use live555 in my Android Project.I've compiled it once using NDK r8 ,but the output .so was only 2KB.
Is there any easy way to make it?Or,what am I supposed to do when I writing the Android.mk ?
Many thanks!


???? iPhone


From alessio at debian.org  Thu Nov 22 04:54:53 2012
From: alessio at debian.org (Alessio Treglia)
Date: Thu, 22 Nov 2012 12:54:53 +0000
Subject: [Live-devel] [PATCH] liblivemedia failed to build with -Wformat
	-Werror=format-security
Message-ID: <CAMHuwoyPY4H2Bb5DxOn9bQ1Zq3o7rSpNqy7_LR6yPshcggztAg@mail.gmail.com>

Hello,

liblivemedia fails to build on Debian if compiled with -Wformat
-Werror=format-security, I'm attaching a minimalistic patch which
solves this.

Thanks for considering, and cheers!

-- 
Alessio Treglia          | www.alessiotreglia.com
Debian Developer         | alessio at debian.org
Ubuntu Core Developer    | quadrispro at ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 301_hardening.patch
Type: application/octet-stream
Size: 580 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121122/619a3462/attachment-0001.obj>

From finlayson at live555.com  Thu Nov 22 13:26:38 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 22 Nov 2012 13:26:38 -0800
Subject: [Live-devel] [PATCH] liblivemedia failed to build with -Wformat
	-Werror=format-security
In-Reply-To: <CAMHuwoyPY4H2Bb5DxOn9bQ1Zq3o7rSpNqy7_LR6yPshcggztAg@mail.gmail.com>
References: <CAMHuwoyPY4H2Bb5DxOn9bQ1Zq3o7rSpNqy7_LR6yPshcggztAg@mail.gmail.com>
Message-ID: <BC4DF322-060C-4873-BE7D-3658F7FFF137@live555.com>

Thanks.  I've just installed a new release (2012.11.22) that includes this change.

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/20121122/3b7d9f1a/attachment.html>

From alessio at debian.org  Thu Nov 22 13:47:23 2012
From: alessio at debian.org (Alessio Treglia)
Date: Thu, 22 Nov 2012 21:47:23 +0000
Subject: [Live-devel] [PATCH] liblivemedia failed to build with -Wformat
	-Werror=format-security
In-Reply-To: <BC4DF322-060C-4873-BE7D-3658F7FFF137@live555.com>
References: <CAMHuwoyPY4H2Bb5DxOn9bQ1Zq3o7rSpNqy7_LR6yPshcggztAg@mail.gmail.com>
 <BC4DF322-060C-4873-BE7D-3658F7FFF137@live555.com>
Message-ID: <CAMHuwoxF58TzqqgeR5TQ9KMxVmtt69T_9mzvnq33dmUJXq_deA@mail.gmail.com>

On Thu, Nov 22, 2012 at 9:26 PM, Ross Finlayson <finlayson at live555.com> wrote:
> Thanks.  I've just installed a new release (2012.11.22) that includes this
> change.

Actually I revised the patch before uploading the new release to
Debian experimental.
I fixed the linux-specific configuration in order to make the
buildsystem process the LDFLAGS properly, you may find the new patch
attached.

Cheers!

-- 
Alessio Treglia          | www.alessiotreglia.com
Debian Developer         | alessio at debian.org
Ubuntu Core Developer    | quadrispro at ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 301_hardening.patch
Type: application/octet-stream
Size: 956 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121122/6b6c38c8/attachment.obj>

From serdel at toya.net.pl  Fri Nov 23 03:05:51 2012
From: serdel at toya.net.pl (serdel)
Date: Fri, 23 Nov 2012 12:05:51 +0100
Subject: [Live-devel] Continuous 2-3s Lag in android port of live555
Message-ID: <f05280e7859cbbd0c5c352d1fcad993a@toya.net.pl>

Hello, 

I am testing an WiFi android streaming that uses live555 as native jni
library. The problem is that after some time of running (totally random but
usually after more than 10 min) the application gets a lag for 2-3 seconds
which doesn't go away. Sometimes there are some 'janks', you can see that
some frames are definitely missing but that's only for a blink and the the
stream get's back to normal - that's OK. However, the lag I am referring to
freezes the app for about 2seconds and then stays that way, meaning that
the stream is from this point delayed (for approximately this 2 seconds).
This delay is unacceptable. It is quite hard to log this situation due to
complete randomness of the lag, but I have noticed that when the lag occurs
the 'packetLossPreceded' variable in 'MultiFramedRTPSource.cpp' file is set
to true and following that, in the MultiFramedRTPSource::doGetNextFrame1()
function, multiple times the packet is rejected after
MultiFramedRTPSource::networkReadHandler call (this can last even up to
500ms). Following by that the decoding function in the video decoder throws
0 frames finished and the 'ReorderingPacketBuffer::reset' is called (this
happens about 2 seconds). For the reordering packets I tried setting the
PacketReorderingThresholdTime from 200ms to 0 or 1 us - unfortunately it
did not helped. On the other hand since the transmission is only on WiFi it
shouldn't matter since WiFi does not allow reordering packets... with this
I am quite lost here... does any one have a suggestion?

From 503430770 at qq.com  Fri Nov 23 10:04:49 2012
From: 503430770 at qq.com (=?ISO-8859-1?B?Li4u?=)
Date: Sat, 24 Nov 2012 02:04:49 +0800
Subject: [Live-devel] about SDP
Message-ID: <tencent_1D7A733E51F42D5D50062EC3@qq.com>

>Alternatively, you could use (in your "createNewRTPSink" implementation) one of the alternative forms of >"H264VideoRTPSink::createNew()" that takes the SPS and PPS NAL units as parameters.  See >"liveMedia/include/H264VideoRTPSink.hh".

      Hi, I use  the alternative forms of "H264VideoRTPSink::createNew()" that takes the SPS and PPS NAL units as parameters.Now the SDP have "a=fmtp:xx packetization-mode=1 profile-level-id=xx  sprop-parameter-sets=xx,xx",but the wireshark can't analysis the sprop-parameter-sets correctly. I find that my SPS's length is 122 (byte). I find other's SPS's length is shorter. Is there something wrong or the wireshark's problem??  
      Thanks !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121124/cc012d47/attachment.html>

From finlayson at live555.com  Fri Nov 23 17:52:07 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 23 Nov 2012 17:52:07 -0800
Subject: [Live-devel] Continuous 2-3s Lag in android port of live555
In-Reply-To: <f05280e7859cbbd0c5c352d1fcad993a@toya.net.pl>
References: <f05280e7859cbbd0c5c352d1fcad993a@toya.net.pl>
Message-ID: <E855AC38-1CDB-493D-BBE1-73A59F320E77@live555.com>

The 2-3 second delay is (obviously) being caused by packet data getting buffered, so the question you need to answer is "Where is this buffering occurring?".  I can tell you for sure that the buffering is *not* occurring in our "LIVE555 Streaming Media" code.  (The only buffering delay that ever occurs in our code is the 100 ms (by default) delay that we introduce to correct for reordered incoming packets - and that occurs only immediately after a packet loss.)

So, the buffering (and thus the 2-3 second delay) must be occurring in the operating system (perhaps device drivers) of the sender and/or the receiver - *not* in our code.

I suspect that your sender's WiFi device driver is buffering outgoing packets, apparently because your outgoing data rate is approaching (or exceeding) the capacity of the WiFi network.  If you are streaming via multicast, then you should note that WiFi routers' multicast performance - especially by default - is notoriously bad.


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/20121123/d85713b9/attachment.html>

From finlayson at live555.com  Fri Nov 23 17:54:02 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 23 Nov 2012 17:54:02 -0800
Subject: [Live-devel] about SDP
In-Reply-To: <tencent_1D7A733E51F42D5D50062EC3@qq.com>
References: <tencent_1D7A733E51F42D5D50062EC3@qq.com>
Message-ID: <3294CEEB-8E08-41B2-9FC9-27083CC8EDA9@live555.com>

> I find that my SPS's length is 122 (byte). I find other's SPS's length is shorter. Is there something wrong

No; the SPS and PPS NAL units are usually quite short.


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/20121123/7eaa0bce/attachment.html>

From lanewu at hotmail.com  Fri Nov 23 23:35:55 2012
From: lanewu at hotmail.com (Lei Wu)
Date: Sat, 24 Nov 2012 07:35:55 +0000
Subject: [Live-devel] live555ProxyServer crashes on back-end stream
	disconnection
Message-ID: <BAY147-W30AF020BBE9A0D34CB70ECCB590@phx.gbl>





livemedia version: 2012.11.16, 2012.11.22
system: Ubuntu 12.04here are the steps to reproduce,prepare a back-end stream for testing with: vlc rtsp://<CAMERA_URL> --sout=#rtp{sdp=rtsp://<LOCAL_IP>/Video}play the proxied stream with: vlc rtsp://<LOCAL_IP>/Videostop back-end stream in step 1 by pressing Stop button in VLC interfacelive555MediaServer crasheschanges in 2012.11.22 does NOT fix this bug.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121124/03891163/attachment-0001.html>

From finlayson at live555.com  Sat Nov 24 00:23:57 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 24 Nov 2012 00:23:57 -0800
Subject: [Live-devel] live555ProxyServer crashes on back-end stream
	disconnection
In-Reply-To: <BAY147-W30AF020BBE9A0D34CB70ECCB590@phx.gbl>
References: <BAY147-W30AF020BBE9A0D34CB70ECCB590@phx.gbl>
Message-ID: <DE8B73FB-64F2-4F4D-9A5A-921488CE836E@live555.com>

> here are the steps to reproduce,
> prepare a back-end stream for testing with: vlc rtsp://<CAMERA_URL> --sout=#rtp{sdp=rtsp://<LOCAL_IP>/Video}
> play the proxied stream with: vlc rtsp://<LOCAL_IP>/Video
> stop back-end stream in step 1 by pressing Stop button in VLC interface
> live555MediaServer crashes
I'm confused, for several reasons:
- Your "Subject:" line says that the "live555ProxyServer" crashes, but in step 4 you say that "live555MediaServer" crashes.
- In your steps, you don't mention "live55ProxyServer" at all.  Also, "live555ProxyServer" produces a (front-end, proxied) stream whose URL ends with "proxyStream", not "Video".
- The command lines that you give to VLC in steps 1 and 2 have nothing to do with our proxy server implementation (which is not used in VLC at all).


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/20121124/7d4f8ec4/attachment.html>

From nation at o2.pl  Mon Nov 26 14:53:00 2012
From: nation at o2.pl (=?UTF-8?Q?nation@o2.pl?=)
Date: Mon, 26 Nov 2012 23:53:00 +0100
Subject: [Live-devel] =?utf-8?q?openRTSP_-_streamin_non_standard/applicati?=
	=?utf-8?q?on_data?=
Message-ID: <73f48a3.5207fb40.50b3f2cc.c1eed@o2.pl>

Hello.
?
Is this is possible to stream non standard data ( for example application data from Microsoft Streaming Server - AppV technology )?
?
I'm trying to stream application data from AppV Server using RTSP protocol, but I'm getting error message:
?
Bad SDP "m=" linne: m=application 0/2 RTP/SDCP/TCP 125
Bad SDP "m=" linne: m=application 49152/2 RTP/SDCP/TCP 125
This sesion has no media subsessions.
?
,even if I use -S switch.
?
I would like to ask You if this is possible at all, or maybe I should stop trying ;-).
?
I want to make some test for my master thesis.
?
?
I would be grateful for any response.
?
?
Regards
?
Mateusz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121126/4860adea/attachment.html>

From finlayson at live555.com  Mon Nov 26 15:09:14 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 26 Nov 2012 15:09:14 -0800
Subject: [Live-devel] openRTSP - streamin non standard/application data
In-Reply-To: <73f48a3.5207fb40.50b3f2cc.c1eed@o2.pl>
References: <73f48a3.5207fb40.50b3f2cc.c1eed@o2.pl>
Message-ID: <35147EFB-CC28-4519-A63F-9478BD7021D9@live555.com>

> I would like to ask You if this is possible at all

Unfortunately not.  This is a completely non-standard RTP profile (and payload format) that - to my knowledge - isn't publicly described anywhere.

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/20121126/be16ed6c/attachment.html>

From shaman.lab.x11 at gmail.com  Tue Nov 27 05:42:58 2012
From: shaman.lab.x11 at gmail.com (=?KOI8-R?B?88XSx8XKIOLB09TSwcvP1w==?=)
Date: Tue, 27 Nov 2012 17:42:58 +0400
Subject: [Live-devel] live555proxy as dll library.
 System.AccessViolationException when server closing
Message-ID: <CAA0p+4NwoE_V4HSzJzSjwhi2=uxUS=gQXSsGKQ1Mf4_36e=qeQ@mail.gmail.com>

Hello, all
I have a project, which should stream video from cameras in network
(internet too). By technical project, the program should be implemented in
c sharp for windows. I want to use live555. It already works as separate
processes. This works good, but i have no feedback with processes (Of
course I have an process object, but this is not what need). I try write a
dll library. As a basis, I took the proxy code. It works sometimes. But I
can not stop the server correctly.
I do it so:

"if (env!=NULL)
env->taskScheduler().doEventLoop(&done);"
"done = ~0;
if (rtspServer!=NULL)
Medium::close(rtspServer);"

In principle, the server stops after "done = ~ 0", but socket stays open.
Next server launch (Main application is not closed) is success, but I have
no stream. I found, that "Medium::close(...)" stops all. In my library I
get exception when it calls. Visual Studio debugger goes to Media.cpp in
liveMedia, string 151: "delete medium;" in remove function.
Excuse me for my english, I hope for your help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121127/6cdab8a1/attachment.html>

From finlayson at live555.com  Tue Nov 27 17:41:27 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 27 Nov 2012 17:41:27 -0800
Subject: [Live-devel] live555proxy as dll library.
	System.AccessViolationException when server closing
In-Reply-To: <CAA0p+4NwoE_V4HSzJzSjwhi2=uxUS=gQXSsGKQ1Mf4_36e=qeQ@mail.gmail.com>
References: <CAA0p+4NwoE_V4HSzJzSjwhi2=uxUS=gQXSsGKQ1Mf4_36e=qeQ@mail.gmail.com>
Message-ID: <52162EF4-4F44-4E91-951D-52E5EFF12605@live555.com>

> "if (env!=NULL)
> 	env->taskScheduler().doEventLoop(&done);"
> "done = ~0;

The "doEventLoop()" function does not return *until* the variable "done" is set to some non-zero value, so if the value of "done" is zero before you call "doEventLoop()", then that call will never return (and so you will never get to the statement "done = ~0;").

If you want to leave the event loop (using this method), then you will need to set "done = ~0;" either
	- within the event loop (i.e., when you handle a LIVE555 event), or
	- from a different thread.


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/20121127/76041fee/attachment.html>

From shaman.lab.x11 at gmail.com  Wed Nov 28 06:41:03 2012
From: shaman.lab.x11 at gmail.com (=?KOI8-R?B?88XSx8XKIOLB09TSwcvP1w==?=)
Date: Wed, 28 Nov 2012 18:41:03 +0400
Subject: [Live-devel] live555proxy as dll library.
 System.AccessViolationException when server closing
In-Reply-To: <CAA0p+4OV9RNdpvHGv9=n_y+kwWeYZL7WzEd4S9ivZavD3jQbsA@mail.gmail.com>
References: <CAA0p+4NwoE_V4HSzJzSjwhi2=uxUS=gQXSsGKQ1Mf4_36e=qeQ@mail.gmail.com>
 <52162EF4-4F44-4E91-951D-52E5EFF12605@live555.com>
 <CAA0p+4OV9RNdpvHGv9=n_y+kwWeYZL7WzEd4S9ivZavD3jQbsA@mail.gmail.com>
Message-ID: <CAA0p+4NUc4N7iqXyxR2Nj=MwuDDt4+TDa5ogQuQg0jWHZuDoUg@mail.gmail.com>

I tried to solve the problem, and got the following results (I have dll
library with live555 code and host application that used this library):
- I have no media sessions, launch and run empty server. Start and stop are
OK. Media::close(rtspServer) runs with no errors. Next server starts also
OK.
- I have one or more media sessions (from camera stream). First launch is
OK. Players (vlc for example) are connected to proxy and played
successfully. If we have no clients and try call Medium::close for rtsp
server, there is exception in RTCP.cpp:240 (2012.11.22 version). Callstack:
"live555proxyDLLNative.dll!RTCPInstance::setByeHandler(void (void *)*
handlerTask, void * clientData, bool handleActiveParticipantsOnly)  Line
240 + 0x6 bytes C++
  live555proxyDLLNative.dll!ProxyServerMediaSubsession::~ProxyServerMediaSubsession()
 Line 342 C++
  live555proxyDLLNative.dll!ProxyServerMediaSubsession::`scalar deleting
destructor'()  + 0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 152 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!ServerMediaSession::deleteAllSubsessions()
 Line 195 + 0xc bytes C++
  live555proxyDLLNative.dll!ServerMediaSession::~ServerMediaSession()  Line
84 C++
  live555proxyDLLNative.dll!ProxyServerMediaSession::~ProxyServerMediaSession()
 Line 93 + 0xf bytes C++
  live555proxyDLLNative.dll!ProxyServerMediaSession::`scalar deleting
destructor'()  + 0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 152 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!RTSPServer::removeServerMediaSession(ServerMediaSession
* serverMediaSession)  Line 74 + 0x9 bytes C++
  live555proxyDLLNative.dll!RTSPServer::~RTSPServer()  Line 260 C++
  live555proxyDLLNative.dll!RTSPServer::`scalar deleting destructor'()  +
0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 152 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!DoLoop()  Line 50 + 0xc bytes C++"

If we have clients and try call Medium::close for rtsp server, there is
exception in RTSPClient.cpp:1205 (2012.11.22 version). Callstack:

 "live555proxyDLLNative.dll!RTSPClient::handleAlternativeRequestByte1(unsigned
char requestByte)  Line 1205 + 0x27 bytes C++
  live555proxyDLLNative.dll!RTSPClient::handleAlternativeRequestByte(void *
rtspClient, unsigned char requestByte)  Line 1196 C++
  live555proxyDLLNative.dll!SocketDescriptor::~SocketDescriptor()  Line 348
+ 0x14 bytes C++
  live555proxyDLLNative.dll!SocketDescriptor::`scalar deleting
destructor'()  + 0xf bytes C++
  live555proxyDLLNative.dll!SocketDescriptor::deregisterRTPInterface(unsigned
char streamChannelId)  Line 391 + 0x20 bytes C++
  live555proxyDLLNative.dll!deregisterSocket(UsageEnvironment & env, int
sockNum, unsigned char streamChannelId)  Line 159 C++
  live555proxyDLLNative.dll!RTPInterface::stopNetworkReading()  Line 274 +
0x1d bytes C++
  live555proxyDLLNative.dll!RTCPInstance::~RTCPInstance()  Line 185 C++
  live555proxyDLLNative.dll!RTCPInstance::`scalar deleting destructor'()  +
0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 152 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!MediaSubsession::deInitiate()  Line 807 + 0xf
bytes C++
  live555proxyDLLNative.dll!MediaSubsession::~MediaSubsession()  Line 602
C++
  live555proxyDLLNative.dll!MediaSubsession::`scalar deleting destructor'()
 + 0xf bytes C++
  live555proxyDLLNative.dll!MediaSession::~MediaSession()  Line 82 + 0x23
bytes C++
  live555proxyDLLNative.dll!MediaSession::`scalar deleting destructor'()  +
0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 152 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!ProxyServerMediaSession::~ProxyServerMediaSession()
 Line 91 + 0xc bytes C++
  live555proxyDLLNative.dll!ProxyServerMediaSession::`scalar deleting
destructor'()  + 0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 152 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!RTSPServer::removeServerMediaSession(ServerMediaSession
* serverMediaSession)  Line 74 + 0x9 bytes C++
  live555proxyDLLNative.dll!RTSPServer::~RTSPServer()  Line 260 C++
  live555proxyDLLNative.dll!RTSPServer::`scalar deleting destructor'()  +
0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 152 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!DoLoop()  Line 50 + 0xc bytes C++"

I was mistaken in this thread
http://lists.live555.com/pipermail/live-devel/2012-November/016105.html.
Problem is saved here.
Library source: http://pastebin.com/FKrFX1wa


2012/11/28 ?????? ????????? <shaman.lab.x11 at gmail.com>

> This parts of code are in different functions.
> "env->taskScheduler().doEventLoop(&done);" called in dll's function in
> other thread,  "done = ~0; is in stop function. With doEventLoop return I
> have no problem.
> 28.11.2012 5:47 ???????????? "Ross Finlayson" <finlayson at live555.com>
> ???????:
>
>> "if (env!=NULL)
>> env->taskScheduler().doEventLoop(&done);"
>> "done = ~0;
>>
>>
>> The "doEventLoop()" function does not return *until* the variable "done"
>> is set to some non-zero value, so if the value of "done" is zero before you
>> call "doEventLoop()", then that call will never return (and so you will
>> never get to the statement "done = ~0;").
>>
>> If you want to leave the event loop (using this method), then you will
>> need to set "done = ~0;" either
>> - within the event loop (i.e., when you handle a LIVE555 event), or
>>  - from a different thread.
>>
>>
>> Ross Finlayson
>> Live Networks, Inc.
>> http://www.live555.com/
>>
>>
>> _______________________________________________
>> 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/20121128/d89efbb1/attachment-0001.html>

From finlayson at live555.com  Wed Nov 28 16:10:33 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 28 Nov 2012 16:10:33 -0800
Subject: [Live-devel] live555proxy as dll library.
	System.AccessViolationException when server closing
In-Reply-To: <CAA0p+4NUc4N7iqXyxR2Nj=MwuDDt4+TDa5ogQuQg0jWHZuDoUg@mail.gmail.com>
References: <CAA0p+4NwoE_V4HSzJzSjwhi2=uxUS=gQXSsGKQ1Mf4_36e=qeQ@mail.gmail.com>
 <52162EF4-4F44-4E91-951D-52E5EFF12605@live555.com>
 <CAA0p+4OV9RNdpvHGv9=n_y+kwWeYZL7WzEd4S9ivZavD3jQbsA@mail.gmail.com>
 <CAA0p+4NUc4N7iqXyxR2Nj=MwuDDt4+TDa5ogQuQg0jWHZuDoUg@mail.gmail.com>
Message-ID: <CAD2BB47-4C4D-4181-9442-78A9DD2A181D@live555.com>

Thanks for the report.  I have just installed a new version - 2012.11.28 - of the "LIVE555 Streaming Media" software that (I think) fixes this problem.

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/20121128/065b6a4e/attachment.html>

From shaman.lab.x11 at gmail.com  Thu Nov 29 00:14:22 2012
From: shaman.lab.x11 at gmail.com (=?KOI8-R?B?88XSx8XKIOLB09TSwcvP1w==?=)
Date: Thu, 29 Nov 2012 12:14:22 +0400
Subject: [Live-devel] live555proxy as dll library.
 System.AccessViolationException when server closing
In-Reply-To: <CAD2BB47-4C4D-4181-9442-78A9DD2A181D@live555.com>
References: <CAA0p+4NwoE_V4HSzJzSjwhi2=uxUS=gQXSsGKQ1Mf4_36e=qeQ@mail.gmail.com>
 <52162EF4-4F44-4E91-951D-52E5EFF12605@live555.com>
 <CAA0p+4OV9RNdpvHGv9=n_y+kwWeYZL7WzEd4S9ivZavD3jQbsA@mail.gmail.com>
 <CAA0p+4NUc4N7iqXyxR2Nj=MwuDDt4+TDa5ogQuQg0jWHZuDoUg@mail.gmail.com>
 <CAD2BB47-4C4D-4181-9442-78A9DD2A181D@live555.com>
Message-ID: <CAA0p+4Omd8R_eeCb4+KZ7pdq2xXwYoti_+4srVc2qxkvc53hpw@mail.gmail.com>

I got latest source code, yes "RTCPInstance error: Hit limit when reading
incoming packet over TCP. Increase "maxRTCPPacketSize" has ceased to appear
at first play/stop. But second stop still generates error. Exceptions in
this release also saved.


2012/11/29 Ross Finlayson <finlayson at live555.com>

> Thanks for the report.  I have just installed a new version - 2012.11.28 -
> of the "LIVE555 Streaming Media" software that (I think) fixes this problem.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> 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/20121129/f9c2a52c/attachment.html>

From finlayson at live555.com  Thu Nov 29 01:09:06 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 29 Nov 2012 01:09:06 -0800
Subject: [Live-devel] live555proxy as dll library.
	System.AccessViolationException when server closing
In-Reply-To: <CAA0p+4Omd8R_eeCb4+KZ7pdq2xXwYoti_+4srVc2qxkvc53hpw@mail.gmail.com>
References: <CAA0p+4NwoE_V4HSzJzSjwhi2=uxUS=gQXSsGKQ1Mf4_36e=qeQ@mail.gmail.com>
 <52162EF4-4F44-4E91-951D-52E5EFF12605@live555.com>
 <CAA0p+4OV9RNdpvHGv9=n_y+kwWeYZL7WzEd4S9ivZavD3jQbsA@mail.gmail.com>
 <CAA0p+4NUc4N7iqXyxR2Nj=MwuDDt4+TDa5ogQuQg0jWHZuDoUg@mail.gmail.com>
 <CAD2BB47-4C4D-4181-9442-78A9DD2A181D@live555.com>
 <CAA0p+4Omd8R_eeCb4+KZ7pdq2xXwYoti_+4srVc2qxkvc53hpw@mail.gmail.com>
Message-ID: <B7AE4A7E-F3DB-4715-BFD5-7BBA83240B98@live555.com>

> But second stop still generates error. 

If you're still seeing a crash, even with the latest version of the software, then please send us a stack trace.

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/20121129/ada205b6/attachment.html>

From finlayson at live555.com  Thu Nov 29 01:17:17 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 29 Nov 2012 01:17:17 -0800
Subject: [Live-devel] live555proxy as dll library.
	System.AccessViolationException when server closing
In-Reply-To: <B7AE4A7E-F3DB-4715-BFD5-7BBA83240B98@live555.com>
References: <CAA0p+4NwoE_V4HSzJzSjwhi2=uxUS=gQXSsGKQ1Mf4_36e=qeQ@mail.gmail.com>
 <52162EF4-4F44-4E91-951D-52E5EFF12605@live555.com>
 <CAA0p+4OV9RNdpvHGv9=n_y+kwWeYZL7WzEd4S9ivZavD3jQbsA@mail.gmail.com>
 <CAA0p+4NUc4N7iqXyxR2Nj=MwuDDt4+TDa5ogQuQg0jWHZuDoUg@mail.gmail.com>
 <CAD2BB47-4C4D-4181-9442-78A9DD2A181D@live555.com>
 <CAA0p+4Omd8R_eeCb4+KZ7pdq2xXwYoti_+4srVc2qxkvc53hpw@mail.gmail.com>
 <B7AE4A7E-F3DB-4715-BFD5-7BBA83240B98@live555.com>
Message-ID: <654B95A6-DA84-48B5-927E-047643B345AD@live555.com>

>> But second stop still generates error. 
> 
> If you're still seeing a crash, even with the latest version of the software, then please send us a stack trace.

And also let us know what you are doing to cause the crash to happen.

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/20121129/362707c8/attachment.html>

From shaman.lab.x11 at gmail.com  Thu Nov 29 03:44:16 2012
From: shaman.lab.x11 at gmail.com (=?KOI8-R?B?88XSx8XKIOLB09TSwcvP1w==?=)
Date: Thu, 29 Nov 2012 15:44:16 +0400
Subject: [Live-devel] live555proxy as dll library.
 System.AccessViolationException when server closing
In-Reply-To: <CAA0p+4PfpO-4zM-sAEwfce1N-X+D=1PkbNXZtW1qAQoQAce7jw@mail.gmail.com>
References: <CAA0p+4NwoE_V4HSzJzSjwhi2=uxUS=gQXSsGKQ1Mf4_36e=qeQ@mail.gmail.com>
 <52162EF4-4F44-4E91-951D-52E5EFF12605@live555.com>
 <CAA0p+4OV9RNdpvHGv9=n_y+kwWeYZL7WzEd4S9ivZavD3jQbsA@mail.gmail.com>
 <CAA0p+4NUc4N7iqXyxR2Nj=MwuDDt4+TDa5ogQuQg0jWHZuDoUg@mail.gmail.com>
 <CAD2BB47-4C4D-4181-9442-78A9DD2A181D@live555.com>
 <CAA0p+4Omd8R_eeCb4+KZ7pdq2xXwYoti_+4srVc2qxkvc53hpw@mail.gmail.com>
 <B7AE4A7E-F3DB-4715-BFD5-7BBA83240B98@live555.com>
 <654B95A6-DA84-48B5-927E-047643B345AD@live555.com>
 <CAA0p+4PfpO-4zM-sAEwfce1N-X+D=1PkbNXZtW1qAQoQAce7jw@mail.gmail.com>
Message-ID: <CAA0p+4MrO+3oEiGr1thoRq=g1-RLR0_HS-y1xcUY8+idK_d02w@mail.gmail.com>

I found that in ProxyServerMediaSubSession.cpp:339 for
fClientMediaSubsession destructor has already been called, although further
we call fClientMediaSubsession.rtcpInstance(), which return 0x00000000.


2012/11/29 ?????? ????????? <shaman.lab.x11 at gmail.com>

> Now, when proxy have clients and I do Medium::close(rtspServer) (after
> doEventLoop() return of course) error occur in the same place as the first
> case, when proxy haven't clients. Call stacks are same.
>        "live555proxyDLLNative.dll!RTCPInstance::setByeHandler(void (void
> *)* handlerTask, void * clientData, bool handleActiveParticipantsOnly)
>  Line 240 + 0x6 bytes C++
>   live555proxyDLLNative.dll!ProxyServerMediaSubsession::~ProxyServerMediaSubsession()
>  Line 342 C++
>   live555proxyDLLNative.dll!ProxyServerMediaSubsession::`scalar deleting
> destructor'()  + 0xf bytes C++
>   live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
>  Line 151 + 0x21 bytes C++
>   live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
> char * name)  Line 54 C++
>   live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 +
> 0x17 bytes C++
>   live555proxyDLLNative.dll!ServerMediaSession::deleteAllSubsessions()
>  Line 195 + 0xc bytes C++
>   live555proxyDLLNative.dll!ServerMediaSession::~ServerMediaSession()
>  Line 84 C++
>   live555proxyDLLNative.dll!ProxyServerMediaSession::~ProxyServerMediaSession()
>  Line 93 + 0xf bytes C++
>   live555proxyDLLNative.dll!ProxyServerMediaSession::`scalar deleting
> destructor'()  + 0xf bytes C++
>   live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
>  Line 151 + 0x21 bytes C++
>   live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
> char * name)  Line 54 C++
>   live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 +
> 0x17 bytes C++
>   live555proxyDLLNative.dll!RTSPServer::removeServerMediaSession(ServerMediaSession
> * serverMediaSession)  Line 74 + 0x9 bytes C++
>   live555proxyDLLNative.dll!RTSPServer::~RTSPServer()  Line 260 C++
>   live555proxyDLLNative.dll!RTSPServer::`scalar deleting destructor'()  +
> 0xf bytes C++
>   live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
>  Line 151 + 0x21 bytes C++
>   live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
> char * name)  Line 54 C++
>   live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 +
> 0x17 bytes C++
>   live555proxyDLLNative.dll!DoLoop()  Line 50 + 0xc bytes C++"
>
>
> 2012/11/29 Ross Finlayson <finlayson at live555.com>
>
>> But second stop still generates error.
>>
>>
>> If you're still seeing a crash, even with the latest version of the
>> software, then please send us a stack trace.
>>
>>
>> And also let us know what you are doing to cause the crash to happen.
>>
>>
>> Ross Finlayson
>> Live Networks, Inc.
>> http://www.live555.com/
>>
>>
>> _______________________________________________
>> 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/20121129/f1866642/attachment-0001.html>

From finlayson at live555.com  Thu Nov 29 05:43:33 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 29 Nov 2012 05:43:33 -0800
Subject: [Live-devel] live555proxy as dll library.
	System.AccessViolationException when server closing
In-Reply-To: <CAA0p+4MrO+3oEiGr1thoRq=g1-RLR0_HS-y1xcUY8+idK_d02w@mail.gmail.com>
References: <CAA0p+4NwoE_V4HSzJzSjwhi2=uxUS=gQXSsGKQ1Mf4_36e=qeQ@mail.gmail.com>
 <52162EF4-4F44-4E91-951D-52E5EFF12605@live555.com>
 <CAA0p+4OV9RNdpvHGv9=n_y+kwWeYZL7WzEd4S9ivZavD3jQbsA@mail.gmail.com>
 <CAA0p+4NUc4N7iqXyxR2Nj=MwuDDt4+TDa5ogQuQg0jWHZuDoUg@mail.gmail.com>
 <CAD2BB47-4C4D-4181-9442-78A9DD2A181D@live555.com>
 <CAA0p+4Omd8R_eeCb4+KZ7pdq2xXwYoti_+4srVc2qxkvc53hpw@mail.gmail.com>
 <B7AE4A7E-F3DB-4715-BFD5-7BBA83240B98@live555.com>
 <654B95A6-DA84-48B5-927E-047643B345AD@live555.com>
 <CAA0p+4PfpO-4zM-sAEwfce1N-X+D=1PkbNXZtW1qAQoQAce7jw@mail.gmail.com>
 <CAA0p+4MrO+3oEiGr1thoRq=g1-RLR0_HS-y1xcUY8+idK_d02w@mail.gmail.com>
Message-ID: <67FC9387-D958-42CD-A27F-027887FEF7A4@live555.com>

> I found that in ProxyServerMediaSubSession.cpp:339 for fClientMediaSubsession destructor has already been called, although further we call fClientMediaSubsession.rtcpInstance(), which return 0x00000000.

Sergei,

Thanks again.  I have installed another new version (2012.11.29) of the code that should fix this bug.


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/20121129/377db295/attachment.html>

From keith.thornton at zeiss.com  Fri Nov 30 02:11:34 2012
From: keith.thornton at zeiss.com (Keith Thornton)
Date: Fri, 30 Nov 2012 11:11:34 +0100
Subject: [Live-devel] WG: problem with rtp streaming after upgrading from
	VLC 2.0.3 to VLC 2.0.4
Message-ID: <OF5A70945D.2E70F0CA-ONC1257AC6.0037EF60-C1257AC6.0037FD93@LocalDomain>

Good Morning
I can no longer stream RTP from my embedded gstreamer server to VLC. 
A bug report exists at VLC (#7786) but the developer answering the bug 
report closed it saying that the problem is in the used live555 libraries.
The bug reporter claims that the live555 library changed from VLC 2.0.3 
(2011.12.23) to VLC 2.0.4 (2012.09.13)
The VLC developer(Courmisch) also thought that the Reporter had a faulty 
SDP file. II am experiencing the same problem but other than having 
updated from VLC 2.0.3 to VLC 2.0.4, nothing has changed.
Have you a test case which might help find the reason why this no longer 
works?

Gr?sse   Keith Thornton


---------------------------------------- 
This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121130/e2818d6b/attachment.html>

From finlayson at live555.com  Fri Nov 30 06:15:58 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 30 Nov 2012 06:15:58 -0800
Subject: [Live-devel] WG: problem with rtp streaming after upgrading
	from VLC 2.0.3 to VLC 2.0.4
In-Reply-To: <OF5A70945D.2E70F0CA-ONC1257AC6.0037EF60-C1257AC6.0037FD93@LocalDomain>
References: <OF5A70945D.2E70F0CA-ONC1257AC6.0037EF60-C1257AC6.0037FD93@LocalDomain>
Message-ID: <D00AA6A1-7B5E-43A7-BDE9-F5154DC3E2B1@live555.com>

> I can no longer stream RTP from my embedded gstreamer server to VLC. 
> A bug report exists at VLC (#7786) but the developer answering the bug report closed it saying that the problem is in the used live555 libraries.
> The bug reporter claims that the live555 library changed from VLC 2.0.3 (2011.12.23) to VLC 2.0.4 (2012.09.13)
> The VLC developer(Courmisch) also thought that the Reporter had a faulty SDP file. II am experiencing the same problem but other than having updated from VLC 2.0.3 to VLC 2.0.4, nothing has changed.

It's difficult for us to help people with problems with VLC, because VLC is not our software (even though it uses our library for its RTSP client implementation).


> Have you a test case which might help find the reason why this no longer works?

You should instead run our "testRTSPClient" demo application (see <http://www.live555.com/liveMedia/#testProgs>), or "openRTSP" <http://www.live555.com/openRTSP/>.  Either of these applications will show the RTSP protocol exchange between our client software and your server; this should tell you what's going wrong.

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/20121130/463da9cc/attachment.html>

From keith.thornton at zeiss.com  Fri Nov 30 07:02:04 2012
From: keith.thornton at zeiss.com (Keith Thornton)
Date: Fri, 30 Nov 2012 16:02:04 +0100
Subject: [Live-devel] Antwort: Re: WG: problem with rtp streaming after
 upgrading from VLC 2.0.3 to VLC 2.0.4
In-Reply-To: <D00AA6A1-7B5E-43A7-BDE9-F5154DC3E2B1@live555.com>
References: <OF5A70945D.2E70F0CA-ONC1257AC6.0037EF60-C1257AC6.0037FD93@LocalDomain>
 <D00AA6A1-7B5E-43A7-BDE9-F5154DC3E2B1@live555.com>
Message-ID: <OFEAB762A8.4B720BAD-ONC1257AC6.00524B82-C1257AC6.005295FA@LocalDomain>

> I can no longer stream RTP from my embedded gstreamer server to VLC. 
> A bug report exists at VLC (#7786) but the developer answering the 
> bug report closed it saying that the problem is in the used live555 
libraries.
> The bug reporter claims that the live555 library changed from VLC 2.
> 0.3 (2011.12.23) to VLC 2.0.4 (2012.09.13)
> The VLC developer(Courmisch) also thought that the Reporter had a 
> faulty SDP file. II am experiencing the same problem but other than 
> having updated from VLC 2.0.3 to VLC 2.0.4, nothing has changed.
> 
> It's difficult for us to help people with problems with VLC, because
> VLC is not our software (even though it uses our library for its 
> RTSP client implementation).
> 
> Have you a test case which might help find the reason why this no 
> longer works?
> 
> You should instead run our "testRTSPClient" demo application (see <
> http://www.live555.com/liveMedia/#testProgs>), or "openRTSP" <
> http://www.live555.com/openRTSP/>.  Either of these applications 
> will show the RTSP protocol exchange between our client software and
> your server; this should tell you what's going wrong.
unfortunately this won't help because I am not using rtsp. We are loading 
the sdp file in the VLC client using media/open. This configures the rtp 
client to receive the rtp stream via udp. Here is an example sdp file


> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/ 
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel



---------------------------------------- 
This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121130/c3cffd2a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.sdp
Type: application/octet-stream
Size: 253 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121130/c3cffd2a/attachment.obj>

From finlayson at live555.com  Fri Nov 30 11:40:20 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 30 Nov 2012 11:40:20 -0800
Subject: [Live-devel] Antwort: Re: WG: problem with rtp streaming after
	upgrading from VLC 2.0.3 to VLC 2.0.4
In-Reply-To: <OFEAB762A8.4B720BAD-ONC1257AC6.00524B82-C1257AC6.005295FA@LocalDomain>
References: <OF5A70945D.2E70F0CA-ONC1257AC6.0037EF60-C1257AC6.0037FD93@LocalDomain>
 <D00AA6A1-7B5E-43A7-BDE9-F5154DC3E2B1@live555.com>
 <OFEAB762A8.4B720BAD-ONC1257AC6.00524B82-C1257AC6.005295FA@LocalDomain>
Message-ID: <48ABD26D-D6E3-4761-A488-8C3479B5F9A2@live555.com>

> unfortunately this won't help because I am not using rtsp. We are loading the sdp file in the VLC client using media/open. This configures the rtp client to receive the rtp stream via udp. Here is an example sdp file

SDP files are usually used for receiving *multicast* streams, not unicast streams (like yours).  Unicast streams are best set up using the RTSP protocol, because that provides the client with extra information (e.g., server port numbers, for RTCP, which tells the server when the client remains alive) and extra control (e.g., the ability for the client to stop the streaming whenever it wants).  So, if your server supports RTSP, then you should use it.

Nonetheless, receiving a unicast stream using a SDP file *can* work, but should be considered a hack.  Unfortunately, although this hack worked with earlier versions of VLC, it inadvertently stopped working in the version (2012.09.13) of the "LIVE555 Streaming Media" software that's used by VLC version 2.0.4.  However, it will probably work again with a more recent version of the LIVE555 software (version 2012.10.12 or later).

So, your choices are as follows:
1/ Use RTSP, if your server supports it.
2/ Stream via multicast (if you have multicast connectivity between your server and client(s)).  Of course, if you do this, you'd change your SDP file to use multicast addresses (in the SDP "c=" lines).
3/ Rebuild the VLC application yourself to use the latest version of the "LIVE555 Streaming Media" software.
4/ Wait until the VLC developers release their own newer version of the VLC application binary (which will probably also use a newer version of the LIVE55 code).


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/20121130/10715e81/attachment-0001.html>

From tim at eworker.co.uk  Fri Nov 30 08:00:19 2012
From: tim at eworker.co.uk (Tim Cannell)
Date: Fri, 30 Nov 2012 17:00:19 +0100
Subject: [Live-devel] Incomplete decoded image data
Message-ID: <CALKzL+GPVYbFVRPTZeTzqKPYjnEBR+qnFDkSvwadbHGEa3uQ9Q@mail.gmail.com>

I am using live555 source code (analyze_seq_parameter_set_data()
and analyze_vui_parameters() ) to parse the sps from streamed h264
video from an ip camera, and then decoding the video using CUDA 4.2
and separately also using ffmpeg.

Similar still images from the resulting decoder outputs are attached.
Everything works fine except for some missing information/corruption
at the bottom of the picture which seems to manifest itself
differently between the two decoders.

The ip camera feed is handled perfectly by VLC so despite my best
attempts to ensure that their are no buffer overruns or truncations
the conclusion I draw is that ther is an error in my live555 borrowed
code.

Apologoes for the vague nature of this post but I am hoping that
someone might identify an obvious problem from the attached images.

Many thanks

-- 
Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipcam_live555_ffmpeg_decode.png
Type: image/png
Size: 582859 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121130/80d9d0b4/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipcam_live555_cuda_decode.png
Type: image/png
Size: 351451 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121130/80d9d0b4/attachment-0003.png>

From finlayson at live555.com  Fri Nov 30 12:01:59 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 30 Nov 2012 12:01:59 -0800
Subject: [Live-devel] Incomplete decoded image data
In-Reply-To: <CALKzL+GPVYbFVRPTZeTzqKPYjnEBR+qnFDkSvwadbHGEa3uQ9Q@mail.gmail.com>
References: <CALKzL+GPVYbFVRPTZeTzqKPYjnEBR+qnFDkSvwadbHGEa3uQ9Q@mail.gmail.com>
Message-ID: <4AC300EE-AAA6-470D-89F0-A902A5C23233@live555.com>

> the conclusion I draw is that ther is an error in my live555 borrowed
> code.

If the only difference between your two systems is the decoder that you use, then that's a rather strange conclusion to draw.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/



From shaman.lab.x11 at gmail.com  Thu Nov 29 23:33:42 2012
From: shaman.lab.x11 at gmail.com (=?KOI8-R?B?88XSx8XKIOLB09TSwcvP1w==?=)
Date: Fri, 30 Nov 2012 11:33:42 +0400
Subject: [Live-devel] live555proxy as dll library.
 System.AccessViolationException when server closing
In-Reply-To: <67FC9387-D958-42CD-A27F-027887FEF7A4@live555.com>
References: <CAA0p+4NwoE_V4HSzJzSjwhi2=uxUS=gQXSsGKQ1Mf4_36e=qeQ@mail.gmail.com>
 <52162EF4-4F44-4E91-951D-52E5EFF12605@live555.com>
 <CAA0p+4OV9RNdpvHGv9=n_y+kwWeYZL7WzEd4S9ivZavD3jQbsA@mail.gmail.com>
 <CAA0p+4NUc4N7iqXyxR2Nj=MwuDDt4+TDa5ogQuQg0jWHZuDoUg@mail.gmail.com>
 <CAD2BB47-4C4D-4181-9442-78A9DD2A181D@live555.com>
 <CAA0p+4Omd8R_eeCb4+KZ7pdq2xXwYoti_+4srVc2qxkvc53hpw@mail.gmail.com>
 <B7AE4A7E-F3DB-4715-BFD5-7BBA83240B98@live555.com>
 <654B95A6-DA84-48B5-927E-047643B345AD@live555.com>
 <CAA0p+4PfpO-4zM-sAEwfce1N-X+D=1PkbNXZtW1qAQoQAce7jw@mail.gmail.com>
 <CAA0p+4MrO+3oEiGr1thoRq=g1-RLR0_HS-y1xcUY8+idK_d02w@mail.gmail.com>
 <67FC9387-D958-42CD-A27F-027887FEF7A4@live555.com>
Message-ID: <CAA0p+4NP4jU-69+2ouQnPBy0On=WxMymfT2QAXv4nRA+J2Su-Q@mail.gmail.com>

Great, It works :)
There is still one error when we have a connected clients and we do
Media::close(...) for server.

 "live555proxyDLLNative.dll!RTSPClient::handleAlternativeRequestByte1(unsigned
char requestByte)  Line 1205 + 0x27 bytes C++
  live555proxyDLLNative.dll!RTSPClient::handleAlternativeRequestByte(void *
rtspClient, unsigned char requestByte)  Line 1196 C++
  live555proxyDLLNative.dll!SocketDescriptor::~SocketDescriptor()  Line 348
+ 0x14 bytes C++
  live555proxyDLLNative.dll!SocketDescriptor::`scalar deleting
destructor'()  + 0xf bytes C++
  live555proxyDLLNative.dll!SocketDescriptor::deregisterRTPInterface(unsigned
char streamChannelId)  Line 391 + 0x20 bytes C++
  live555proxyDLLNative.dll!deregisterSocket(UsageEnvironment & env, int
sockNum, unsigned char streamChannelId)  Line 159 C++
  live555proxyDLLNative.dll!RTPInterface::stopNetworkReading()  Line 274 +
0x1d bytes C++
  live555proxyDLLNative.dll!RTCPInstance::~RTCPInstance()  Line 185 C++
  live555proxyDLLNative.dll!RTCPInstance::`scalar deleting destructor'()  +
0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 151 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!MediaSubsession::deInitiate()  Line 807 + 0xf
bytes C++
  live555proxyDLLNative.dll!MediaSubsession::~MediaSubsession()  Line 602
C++
  live555proxyDLLNative.dll!MediaSubsession::`scalar deleting destructor'()
 + 0xf bytes C++
  live555proxyDLLNative.dll!MediaSession::~MediaSession()  Line 82 + 0x23
bytes C++
  live555proxyDLLNative.dll!MediaSession::`scalar deleting destructor'()  +
0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 151 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!ProxyServerMediaSession::~ProxyServerMediaSession()
 Line 91 + 0xc bytes C++
  live555proxyDLLNative.dll!ProxyServerMediaSession::`scalar deleting
destructor'()  + 0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 151 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!RTSPServer::removeServerMediaSession(ServerMediaSession
* serverMediaSession)  Line 74 + 0x9 bytes C++
  live555proxyDLLNative.dll!RTSPServer::~RTSPServer()  Line 260 C++
  live555proxyDLLNative.dll!RTSPServer::`scalar deleting destructor'()  +
0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 151 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!DoLoop()  Line 50 + 0xc bytes C++"
There is call RTSPClient::handleAlternativeRequestByte1(...) for a
destroyed RTSPClient object.
Destructor call stack for this object:
       "live555proxyDLLNative.dll!RTSPClient::~RTSPClient()  Line 328 C++
  live555proxyDLLNative.dll!ProxyRTSPClient::~ProxyRTSPClient()  Line 206 +
0xf bytes C++
  live555proxyDLLNative.dll!ProxyRTSPClient::`scalar deleting destructor'()
 + 0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 151 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!ProxyServerMediaSession::~ProxyServerMediaSession()
 Line 90 + 0xc bytes C++
  live555proxyDLLNative.dll!ProxyServerMediaSession::`scalar deleting
destructor'()  + 0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 151 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!RTSPServer::removeServerMediaSession(ServerMediaSession
* serverMediaSession)  Line 74 + 0x9 bytes C++
  live555proxyDLLNative.dll!RTSPServer::~RTSPServer()  Line 260 C++
  live555proxyDLLNative.dll!RTSPServer::`scalar deleting destructor'()  +
0xf bytes C++
  live555proxyDLLNative.dll!MediaLookupTable::remove(const char * name)
 Line 151 + 0x21 bytes C++
  live555proxyDLLNative.dll!Medium::close(UsageEnvironment & env, const
char * name)  Line 54 C++
  live555proxyDLLNative.dll!Medium::close(Medium * medium)  Line 59 + 0x17
bytes C++
  live555proxyDLLNative.dll!DoLoop()  Line 50 + 0xc bytes C++"


2012/11/29 Ross Finlayson <finlayson at live555.com>

> I found that in ProxyServerMediaSubSession.cpp:339 for
> fClientMediaSubsession destructor has already been called, although further
> we call fClientMediaSubsession.rtcpInstance(), which return 0x00000000.
>
>
> Sergei,
>
> Thanks again.  I have installed another new version (2012.11.29) of the
> code that should fix this bug.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> 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/20121130/38c38390/attachment.html>

From finlayson at live555.com  Fri Nov 30 12:21:31 2012
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 30 Nov 2012 12:21:31 -0800
Subject: [Live-devel] live555proxy as dll library.
	System.AccessViolationException when server closing
In-Reply-To: <CAA0p+4NP4jU-69+2ouQnPBy0On=WxMymfT2QAXv4nRA+J2Su-Q@mail.gmail.com>
References: <CAA0p+4NwoE_V4HSzJzSjwhi2=uxUS=gQXSsGKQ1Mf4_36e=qeQ@mail.gmail.com>
 <52162EF4-4F44-4E91-951D-52E5EFF12605@live555.com>
 <CAA0p+4OV9RNdpvHGv9=n_y+kwWeYZL7WzEd4S9ivZavD3jQbsA@mail.gmail.com>
 <CAA0p+4NUc4N7iqXyxR2Nj=MwuDDt4+TDa5ogQuQg0jWHZuDoUg@mail.gmail.com>
 <CAD2BB47-4C4D-4181-9442-78A9DD2A181D@live555.com>
 <CAA0p+4Omd8R_eeCb4+KZ7pdq2xXwYoti_+4srVc2qxkvc53hpw@mail.gmail.com>
 <B7AE4A7E-F3DB-4715-BFD5-7BBA83240B98@live555.com>
 <654B95A6-DA84-48B5-927E-047643B345AD@live555.com>
 <CAA0p+4PfpO-4zM-sAEwfce1N-X+D=1PkbNXZtW1qAQoQAce7jw@mail.gmail.com>
 <CAA0p+4MrO+3oEiGr1thoRq=g1-RLR0_HS-y1xcUY8+idK_d02w@mail.gmail.com>
 <67FC9387-D958-42CD-A27F-027887FEF7A4@live555.com>
 <CAA0p+4NP4jU-69+2ouQnPBy0On=WxMymfT2QAXv4nRA+J2Su-Q@mail.gmail.com>
Message-ID: <6B878E83-18F9-4CE8-A591-BF42175CC261@live555.com>

> There is still one error when we have a connected clients and we do Media::close(...) for server.
(And when the proxy is streaming from the back-end server via RTP-over-TCP.)

Thanks.  I've just installed a new version (2012.11.30) of the "LIVE555 Streaming Media" code that should fix this.


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/20121130/cdba889b/attachment.html>