From a.nemec at atlas.cz  Sun Dec  1 04:14:39 2013
From: a.nemec at atlas.cz (=?utf-8?q?Alexandr_N=C4=9Bmec?=)
Date: Sun, 01 Dec 2013 13:14:39 +0100
Subject: [Live-devel] =?utf-8?q?RFC_2435_compliance?=
In-Reply-To: <OF01FDD9AA.8F9FFE77-ON85257C32.0069C50B-85257C32.006B6087@belden.com>
References: <20131125084544.4B50941E@atlas.cz>,
 <7FBD1C75-1872-48DA-9183-C3188B86F372@live555.com>,
 <20131125121259.38ED5867@atlas.cz>
 <OF01FDD9AA.8F9FFE77-ON85257C32.0069C50B-85257C32.006B6087@belden.com>
Message-ID: <20131201131439.71CCEB60@atlas.cz>

Hi Guy,
?
thanks for your posting. I understand your point, but I still think there is a problem?with the RFC. Yes, appendix A says, that you can use the example code to compute a quantization table only (zigzag does not really matter), nothing wrong here. But later, in Appendix B it says (comment before MakeHeaders) that you can use the MakeTables routine from Appendix A to generate the quantization tables lqt and cqt as input for the MakeHeaders routine. Then, in MakeHeaders (MakeQuantHeader)?"memcpy" is used to insert quantization table data into the JPEG header. And because Appendix B also says that MakeHeaders can be used to "generate a JPEG copressed image in interchange format", following these rules and instructions will lead to a corrupted JPEG image.
?
So what I want to say, it is just not possible to take all the RFC example code "as is" for a working implementation.
?
Best regards
?
Alex
______________________________________________________________
> Od: <Guy.Bonneau at miranda.com>
> Komu: "LIVE555 Streaming Media - development & use" <live-devel at ns.live555.com>
> Datum: 29.11.2013 20:35
> P?edm?t: Re: [Live-devel] RFC 2435 compliance
>
There is no issue with the RFC 2435 AppendixA neither with the live555 procedure to scale a quantization table witha Q factor. ?Both are correct.. If you read the header of AppendixA it clearly states the reason of the example code : ?"The following code can be used to create a quantization table froma Q factor..." Now when you recompute the quantization table froma selected Q factor your only scale the 64 quantization values by the samefactor. Doing the procedure on zigzag order on doing it on "standard"non-zigzag order doesn't matter. It will yield the same "scaled quantizationfactor". 

Jpeg encoding/decoding of spectral component of thepicture operate on block of 64 values. Those value must be processed inzigzag order. If you use a zigzaged table then the encoding/decoding onlyincrement the index of the quantization value in the table to get the goodquantization value. However if you use a non-zigzag table then the encoding/decodingmust find and pick-up the good quantization inside the table. This is upto the implementation of the code.

Guy Bonneau

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

From john95018 at gmail.com  Sun Dec  1 08:48:28 2013
From: john95018 at gmail.com (john dicostanzo)
Date: Sun, 1 Dec 2013 22:18:28 +0530
Subject: [Live-devel] Client Session
Message-ID: <CAJqr0gD35n+DQ1ofWFSD9s1btZi3i2AhQ1t-KCgTOec=v-4dmQ@mail.gmail.com>

HI,
I am using testOndeandRtspServer,i want to know that how many clients it
can handle at same time???

Thanks & Regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131201/c0d5980b/attachment.html>

From finlayson at live555.com  Sun Dec  1 19:45:53 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 2 Dec 2013 13:45:53 +1000
Subject: [Live-devel] Client Session
In-Reply-To: <CAJqr0gD35n+DQ1ofWFSD9s1btZi3i2AhQ1t-KCgTOec=v-4dmQ@mail.gmail.com>
References: <CAJqr0gD35n+DQ1ofWFSD9s1btZi3i2AhQ1t-KCgTOec=v-4dmQ@mail.gmail.com>
Message-ID: <EC8038AC-CD18-43B2-9ACD-5FFF18F72A3F@live555.com>

> I am using testOndeandRtspServer,i want to know that how many clients it can handle at same time???

This is explained in the FAQ that everyone is asked to read before posting to the mailing list:
	http://www.live555.com/liveMedia/faq.html


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/20131202/d084896c/attachment.html>

From finlayson at live555.com  Sun Dec  1 22:12:51 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 2 Dec 2013 16:12:51 +1000
Subject: [Live-devel] Liveness times out
In-Reply-To: <529A35A4.9010100@vivint.com>
References: <529A35A4.9010100@vivint.com>
Message-ID: <E59AA182-D1AB-4EBF-87BA-B04B486299BA@live555.com>

> If there are no clients (sessions) connected to the rtsp proxy, would a 
> DESCRIBE command keep alive the camera better than an OPTIONS?

No.


> at times the liveness timer exceeds the timeout

That should not happen, because the code computes the timer by choosing a random time in the interval [timeout/2, timeout-1).  (See "ProxyServerMediaSession.cpp", line 338.)  So the timer interval should be at least 1 second less than the 'timeout' interval.  (And I don't see how the event loop could ever be 1 second or more late to handle a timed event.)

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/20131202/0e437f83/attachment.html>

From brilliantov at byterg.ru  Mon Dec  2 02:37:15 2013
From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich)
Date: Mon, 02 Dec 2013 14:37:15 +0400
Subject: [Live-devel] RTP MJPEG: block network packets without data
Message-ID: <529C62DB.9070206@byterg.ru>

Hello!
I use live555 2013.11.29 on board with FreeScale iMX53 CPU.
Unfortunally periodically I see packets without data, I use wireshark,
it contained only MJPEG header (Main header and Quantization table
gheader), please see attache (bad_mjpeg.txt (4 kB), good_mjpeg.txt (10
kB)). As result this packages, I think, I see line on image bottom.
How can I block sending this packets?
Thank you and excuse me for my bad english.

-- 
Best regards,
Brilliantov Kirill Vladimirovich
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bad_mjpeg.txt
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131202/3e645d59/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: good_mjpeg.txt
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131202/3e645d59/attachment-0003.txt>

From finlayson at live555.com  Mon Dec  2 18:51:39 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 3 Dec 2013 12:51:39 +1000
Subject: [Live-devel] RTP MJPEG: block network packets without data
In-Reply-To: <529C62DB.9070206@byterg.ru>
References: <529C62DB.9070206@byterg.ru>
Message-ID: <9079CCA9-C476-48BF-8201-2894EEA18C51@live555.com>

> I use live555 2013.11.29 on board with FreeScale iMX53 CPU.
> Unfortunally periodically I see packets without data, I use wireshark,
> it contained only MJPEG header (Main header and Quantization table
> gheader), please see attache (bad_mjpeg.txt (4 kB), good_mjpeg.txt (10
> kB)). As result this packages, I think, I see line on image bottom.
> How can I block sending this packets?

The problem here is your data source class - i.e., your subclass of "JPEGVideoSource" that is generating JPEG frames.  For some reason it is occasionally delivering a 0-length frame.  You need to fix the bug (in your own code) that is causing this 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/20131203/45565360/attachment.html>

From antohi.ionel at gmail.com  Mon Dec  2 17:37:25 2013
From: antohi.ionel at gmail.com (Antohi Ionel)
Date: Tue, 3 Dec 2013 03:37:25 +0200
Subject: [Live-devel] Streaming server set-up
Message-ID: <6B820548-E01F-42AD-ACCB-1774A5F482CE@gmail.com>

Hello, 
I have a question about possibility of configuration.
I have a hosting server whit root command, where I built-in your streaming server.
In my cause - I have a slow internet connection - and cant stream directly from my own internet at home. I fink I can configure my server (my hosting server) with a good internet connection to stream my video. And the question :

Can I configure the server to receive my stream, for example from a VLC (on windows) to my followers directly through my hosting server. On a schematic view its look like this :

MyPC ( connect to server [IP:Port] ) > Server( Receive my stream and broadcast to my followers )  < TheFollowers ( connect to my server through VLC and watch my stream )   

if is that possible please give me an example how to configure that.
thx.

Sorry for my bad English.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131203/acccea91/attachment.html>

From finlayson at live555.com  Mon Dec  2 19:12:28 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 3 Dec 2013 13:12:28 +1000
Subject: [Live-devel] Streaming server set-up
In-Reply-To: <6B820548-E01F-42AD-ACCB-1774A5F482CE@gmail.com>
References: <6B820548-E01F-42AD-ACCB-1774A5F482CE@gmail.com>
Message-ID: <E7836F34-8591-422E-8C5B-51E441C68669@live555.com>

Yes, you can do this using our "LIVE555 Proxy Server" (run on your hosting server), connecting to a (regular) RTSP server, running on your home network. See http://www.live555.com/proxyServer/

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/20131203/03e7e1e5/attachment.html>

From Giridhara.Kalkere at honeywell.com  Mon Dec  2 21:39:48 2013
From: Giridhara.Kalkere at honeywell.com (Kalkere, Giridhara(IE10))
Date: Tue, 3 Dec 2013 05:39:48 +0000
Subject: [Live-devel] MPEG-TS in LIVE media.
In-Reply-To: <5CB52840-CB2A-4556-A3ED-41CA08DE32F1@live555.com>
References: <955512E27CA4E9478883ACDCA9CA40C699FC91@IE1AEX3007.global.ds.honeywell.com>
 <5CB52840-CB2A-4556-A3ED-41CA08DE32F1@live555.com>
Message-ID: <955512E27CA4E9478883ACDCA9CA40C60159F1EB@IE1AEX3007.global.ds.honeywell.com>

Ross,

Thank you very much for your suggestion.
The testH264VideoToTransportStream application reads and in input file (h264) and converts it into .ts file. That's great.

But I need to connect to an IP camera which provides me H264/MPEG stream. instead of file  I want to provide this live stream of frames and create the .ts files of 1sec each. So If record for 1 minute I want to see 60 .ts files. In the given folder.
Now I have a mechanism to connect to a camera and a buffer manager which receives frames and creates a 1 second raw video files (without any container). Is there any way I can improve this to create .ts files.

Your suggestions are helping us to improve our designs. Much appreciate your inputs on this.

Thanks and Regards,
Giri

From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Thursday, November 14, 2013 11:20 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] MPEG-TS in LIVE media.

We are using the LIVE555 framework to stream a camera and store the video streams in raw format. Whenever required we convert it into the .mp4 and play it on the clients (IOS/android devices).
Now I was thinking of storing the camera video (MPEG/H264) in small chunks of .ts files.

Note our "openRTSP" demo application - which saves a H.264 RTSP/RTP stream into a H.264 Video Elementary Stream file.  Note also our "testH264VideoToTransportStream" demo application, which converts a H.264 Video Elementary Stream file into a Transport Stream file.  Note also that you can combine these two applications, using a pipe.  See
            http://lists.live555.com/pipermail/live-devel/2013-November/017695.html

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/20131203/503e00ee/attachment.html>

From finlayson at live555.com  Tue Dec  3 15:07:16 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 4 Dec 2013 09:07:16 +1000
Subject: [Live-devel] MPEG-TS in LIVE media.
In-Reply-To: <955512E27CA4E9478883ACDCA9CA40C60159F1EB@IE1AEX3007.global.ds.honeywell.com>
References: <955512E27CA4E9478883ACDCA9CA40C699FC91@IE1AEX3007.global.ds.honeywell.com>
 <5CB52840-CB2A-4556-A3ED-41CA08DE32F1@live555.com>
 <955512E27CA4E9478883ACDCA9CA40C60159F1EB@IE1AEX3007.global.ds.honeywell.com>
Message-ID: <20852BC5-5E25-47DD-AEC8-2202C69FE7C0@live555.com>

> Thank you very much for your suggestion.
> The testH264VideoToTransportStream application reads and in input file (h264) and converts it into .ts file. That?s great.
>  
> But I need to connect to an IP camera which provides me H264/MPEG stream. instead of file  I want to provide this live stream of frames and create the .ts files of 1sec each. So If record for 1 minute I want to see 60 .ts files. In the given folder.

I've already told you (even though you appeared to ignore my advice!) how you can use our tools to read from a H.264/RTSP/RTP stream, and convert the incoming data to a (single) Transport Stream.  And I'm sure you can find other tools (made by other companies) that can break up a single input Transport Stream into multiple Transport Stream files - each 1 second long.

In any case, I can no longer help you for free on this mailing list.  If your management is interested in hiring me as a consultant to help you with your project, then please tell them to contact me (via separate email).


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/20131204/ef6612f7/attachment-0001.html>

From brilliantov at byterg.ru  Mon Dec  2 23:40:31 2013
From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich)
Date: Tue, 03 Dec 2013 11:40:31 +0400
Subject: [Live-devel] RTP MJPEG: block network packets without data
Message-ID: <529D8AEF.9010607@byterg.ru>

Hello, Ross!
Thank you for your answer, you right, I modify data source class and, I
think, problem solved.

Class Frame is sublass FramedSource.
void Frame::doGetNextFrame()
{
    fFrameSize = 0;
    fNumTruncatedBytes = 0;

    get data code

    if (fFrameSize)
        FramedSource::afterGetting(this);
    else
        doGetNextFrame();

}

But I not sure what this method optimal.

-- 
Best regards,
Brilliantov Kirill Vladimirovich


From Guy.Bonneau at miranda.com  Tue Dec  3 18:54:10 2013
From: Guy.Bonneau at miranda.com (Guy.Bonneau at miranda.com)
Date: Tue, 3 Dec 2013 21:54:10 -0500
Subject: [Live-devel] RFC 2435 compliance
In-Reply-To: <20131201131439.71CCEB60@atlas.cz>
References: <20131125084544.4B50941E@atlas.cz>,
 <7FBD1C75-1872-48DA-9183-C3188B86F372@live555.com>,
 <20131125121259.38ED5867@atlas.cz>
 <OF01FDD9AA.8F9FFE77-ON85257C32.0069C50B-85257C32.006B6087@belden.com>
 <20131201131439.71CCEB60@atlas.cz>
Message-ID: <OF7A7FFA0C.09AF3EE4-ON85257C37.000FB34F-85257C37.00100D84@belden.com>

I didn't looked at appendix B. But given that at page 7 of the RFC it is 
stated: "...Each table is an array of 64 values given in zig-zag order, 
identical to the format used in a JFIF DQT marker segment..." then I agree 
that it couldn't be possible to use all the code of the RFC specification. 
The fact that the quantization table is not zig-zag ordered lead to 
confusion.

Guy



From:   Alexandr N?mec <a.nemec at atlas.cz>
To:     LIVE555 Streaming Media - development & use 
<live-devel at ns.live555.com>, 
Date:   2013-12-01 18:42
Subject:        Re: [Live-devel] RFC 2435 compliance
Sent by:        live-devel-bounces at ns.live555.com



Hi Guy,
 
thanks for your posting. I understand your point, but I still think there 
is a problem with the RFC. Yes, appendix A says, that you can use the 
example code to compute a quantization table only (zigzag does not really 
matter), nothing wrong here. But later, in Appendix B it says (comment 
before MakeHeaders) that you can use the MakeTables routine from Appendix 
A to generate the quantization tables lqt and cqt as input for the 
MakeHeaders routine. Then, in MakeHeaders (MakeQuantHeader) "memcpy" is 
used to insert quantization table data into the JPEG header. And because 
Appendix B also says that MakeHeaders can be used to "generate a JPEG 
copressed image in interchange format", following these rules and 
instructions will lead to a corrupted JPEG image.
 
So what I want to say, it is just not possible to take all the RFC example 
code "as is" for a working implementation.
 
Best regards
 
Alex
______________________________________________________________
> Od: <Guy.Bonneau at miranda.com>
> Komu: "LIVE555 Streaming Media - development & use" 
<live-devel at ns.live555.com>
> Datum: 29.11.2013 20:35
> P?edm?t: Re: [Live-devel] RFC 2435 compliance
>
There is no issue with the RFC 2435 AppendixA neither with the live555 
procedure to scale a quantization table witha Q factor.  Both are 
correct.. If you read the header of AppendixA it clearly states the reason 
of the example code :  "The following code can be used to create a 
quantization table froma Q factor..." Now when you recompute the 
quantization table froma selected Q factor your only scale the 64 
quantization values by the samefactor. Doing the procedure on zigzag order 
on doing it on "standard"non-zigzag order doesn't matter. It will yield 
the same "scaled quantizationfactor". 

Jpeg encoding/decoding of spectral component of thepicture operate on 
block of 64 values. Those value must be processed inzigzag order. If you 
use a zigzaged table then the encoding/decoding onlyincrement the index of 
the quantization value in the table to get the goodquantization value. 
However if you use a non-zigzag table then the encoding/decodingmust find 
and pick-up the good quantization inside the table. This is upto the 
implementation of the code.

Guy Bonneau_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131203/e051e204/attachment.html>

From finlayson at live555.com  Tue Dec  3 18:59:38 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 4 Dec 2013 12:59:38 +1000
Subject: [Live-devel] RTP MJPEG: block network packets without data
In-Reply-To: <529D8AEF.9010607@byterg.ru>
References: <529D8AEF.9010607@byterg.ru>
Message-ID: <F9D5E334-882A-477E-8C6E-0FB54C717503@live555.com>

> Thank you for your answer, you right, I modify data source class and, I
> think, problem solved.
> 
> Class Frame is sublass FramedSource.
> void Frame::doGetNextFrame()
> {
>    fFrameSize = 0;
>    fNumTruncatedBytes = 0;
> 
>    get data code
> 
>    if (fFrameSize)
>        FramedSource::afterGetting(this);
>    else
>        doGetNextFrame();
> 
> }
> 
> But I not sure what this method optimal.

The problem with this is that you're making (potentially) infinite recursive calls.  If the next frame doesn't become available 'soon', you'll overflow the call stack.  It'd be better to turn this into a loop - i.e.:

void Frame::doGetNextFrame()
{
   fFrameSize = 0;
   fNumTruncatedBytes = 0;

  do {
     get data code
  } while (fFrameSize == 0);

   FramedSource::afterGetting(this);
}

But even this is suboptimal, because it chews up CPU time (in the loop) when no frame is available.  During that time, you won't be returning to the event loop to handle other events.  It'd be better to do asynchronous I/O, e.g, as illustrated in our "DeviceSource.cpp" example 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/20131204/7c7928aa/attachment.html>

From oopdeveloper at hotmail.com  Tue Dec  3 18:49:22 2013
From: oopdeveloper at hotmail.com (Michael)
Date: Tue, 3 Dec 2013 21:49:22 -0500
Subject: [Live-devel] getNormalPlayTime returning negative value
Message-ID: <BLU0-SMTP102D3B9482406B745D12CBFC9D40@phx.gbl>

I was performing the timestamping using gettimeofday as the timestamps, but
before temporarily queuing the samples.  Once I moved the timestamping to
the track's deliverFrame method the problem was resolved.

Thanks for your help.


(First, when replying to a mailing list digest, please use a proper
"Subject:" line.  (In this case, I've corrected it for you.))

I suspect that the cause of your problem is that your H.264 video source
object - on your server - is setting incorrect "fPresentationTime" values.
It's important that these "fPresentationTime" values be ***aligned with
wall-clock time*** - i.e., the time that you would get by calling
"gettimeofday()".  (The reason for this is that our RTCP implementation uses
"gettimeofday()" times.)

The server's clock doesn't have to be in sync with the rest of the world
(i.e., via the Network Time Protocol (NTP)).  But it's important that the
"fPresentationTime" values be aligned with the server's clock.


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



From cmatsuura at vivint.com  Tue Dec  3 22:45:40 2013
From: cmatsuura at vivint.com (Craig Matsuura)
Date: Tue, 3 Dec 2013 23:45:40 -0700
Subject: [Live-devel] All client streams slow down when using two live
 proxies connected together.
In-Reply-To: <52964C0E.6050002@vivint.com>
References: <52964C0E.6050002@vivint.com>
Message-ID: <529ECF94.102@vivint.com>

So after some digging it appears the slow down I see when using TCP is due to a slow connection to the proxy. See the code in RTPInterface.cpp.

In the function RTPInterface::sendRTPorRTCPPacketOverTCP.

The first send of the header is non-blocking, the second send is blocking ( the last parameter on sendDataOverTCP is set to True, which forces a blocking send). It also causes a problem with a duplicate data being sent again, we see this on the client side.  Most clients seem to handle this but if your client is based off of the reference source (osrtspserver) it will fail.  It seems that a EAGAIN can still occur even if the data was sent.  I would guess the send must have succeed in this case?

So I see two issues:
1. The blocking call to the second send in sendDataOverTCP to send the data after the header can block for significant amount of time if the connection is slow. (slowing the entire event loop)
2. The second send must fail with EAGAIN, but still the data must have been sent.

I think send on a non-blocking socket can send paritial and you must check to see how much was sent and only send what is left over?

Craig



On 11/27/2013 12:46 PM, Craig Matsuura wrote:
Hi Ross,

I have a question.  Running two live555proxyServers and clients.  Using both openRTSP and gstreamer as clients.

Here is my setup.

 *   live proxy 1 (openRTSP 172.16.10.100) connect to camera
 *   Client 1 (172.16.10.100) connected to live proxy 1 (172.16.10.100)
 *   live proxy 2 (192.168.3.250) connect to live proxy 1
 *   Client 2 (gstream client 192.168.3.25) connect to live proxy 2

Both client 1 and client 2 slow down, when client 2 connects.  Is there a setting or configuration I can use to solve this problem.  slow down is much worse with client 2 is a gst playbin2.  We have seen this on other types of clients connecting TCP (as client 2).

We have a configuration where we need a proxy at once source and a proxy at a different source.  We want to use the same code base from live555.  We initial had different implementations, one based on live555 and another based on a different rtsp server, and did not have and slow down issues, but had other problems.

Below are the outputs and calling parameters on the proxies and openRTSP (client).

Thanks,.
Craig


Client are connecting via TCP (-t).
------------------------------------

192.168.3.250> ./openRTSP -V -t -Q -d 10  rtsp://192.168.3.250:8554/Video
Opened URL "rtsp://192.168.3.250:8554/Video"<rtsp://192.168.3.250:8554/Video>, returning a SDP description:
v=0
o=- 1385580361225980 1 IN IP4 192.168.3.250
s=LIVE555 Streaming Media v2013.11.26
i=LIVE555 Streaming Media v2013.11.26
t=0 0
a=tool:LIVE555 Streaming Media v2013.11.26
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:LIVE555 Streaming Media v2013.11.26
a=x-qt-text-inf:LIVE555 Streaming Media v2013.11.26
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:50
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=64401F;sprop-parameter-sets=J2RAH6wsagFAFumoKDAqAAAH0gAB1MAo,KO4EYsA=
a=control:track1

Created receiver for "video/H264" subsession (client ports 39104-39105)
Setup "video/H264" subsession (client ports 39104-39105)
Created output file: "video-H264-1"
Started playing session
Receiving streamed data (for up to 10.000000 seconds)...
begin_QOS_statistics
subsession      video/H264
num_packets_received    290
num_packets_lost        0
elapsed_measurement_time        10.001134
kBytes_received_total   372.718000
measurement_sampling_interval_ms        1000
kbits_per_second_min    0.000000
kbits_per_second_ave    298.140591
kbits_per_second_max    1154.382976
packet_loss_percentage_min      0.000000
packet_loss_percentage_ave      0.000000
packet_loss_percentage_max      0.000000
inter_packet_gap_ms_min 0.002000
inter_packet_gap_ms_ave 26.072645
inter_packet_gap_ms_max 2007.246000
end_QOS_statistics

First live Proxy on pointed to second live proxy (Note 192.168.3.216 is port forward from the 172.16.10.100)
------------------------------------------------------------------------------------------------------------

192.168.3.250> ./live555ProxyServer.x86  rtsp://192.168.3.216/Video
LIVE555 Proxy Server
        (LIVE555 Streaming Media library version 2013.11.26)

RTSP stream, proxying the stream "rtsp://192.168.3.216/Video"<rtsp://192.168.3.216/Video>
        Play this stream using the URL: rtsp://192.168.3.250:8554/Video

(We use port 8000 for optional RTSP-over-HTTP tunneling.)


Second live Proxy pointed to camera to stream
---------------------------------------------

root at touchlink-847e405d04f4:~# ./live555ProxyServer -V rtsp://172.16.10.101:554/
live.sdpADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

LIVE555 Proxy Server
        (LIVE555 Streaming Media library version 2013.11.26)

Opening connection to 172.16.10.101, port 554...
RTSP stream, proxying the stream "rtsp://172.16.10.101:554/live.sdp"<rtsp://172.16.10.101:554/live.sdp>
        Play this stream using the URL: rtsp://172.16.10.100/Video

(We use port 80 for optional RTSP-over-HTTP tunneling.)
...remote connection opened
Sending request: DESCRIBE rtsp://172.16.10.101:554/live.sdp RTSP/1.0
CSeq: 2
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26)
Accept: application/sdp


Received 510 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK
CSeq: 2
Date: Wed, 27 Nov 2013 12:25:5 GMT
Content-Base: rtsp://172.16.10.101/live.sdp/
Content-Type: application/sdp
Content-Length: 348

v=0
o=RTSP 1385555105 945 IN IP4 0.0.0.0
s=RTSP server
c=IN IP4 0.0.0.0
t=0 0
a=charset:Shift_JIS
a=range:npt=0-
a=control:*
a=etag:1234567890
m=video 0 RTP/AVP 98
b=AS:0
a=rtpmap:98 H264/90000
a=control:trackID=1
a=fmtp:98 packetization-mode=1; profile-level-id=64401f; sprop-parameter-sets=J2RAH6wsagFAFumoKDAqAAAH0gAB1MAo,KO4EYsA=

ProxyServerMediaSession["rtsp://172.16.10.101/live.sdp/"<rtsp://172.16.10.101/live.sdp/>] added new "ProxyServerMediaSubsession" for RTP/video/H264 track
Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0
CSeq: 3
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26)


Received 145 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 3
Date: Wed, 27 Nov 2013 12:25:35 GMT
Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN


ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 0)
        Initiated: ProxyServerMediaSubsession["H264"]
ProxyServerMediaSubsession["H264"]::createNewRTPSink()
ProxyServerMediaSubsession["H264"]::closeStreamSource()
ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 3097014589)
Sending request: SETUP rtsp://172.16.10.101/live.sdp/trackID=1 RTSP/1.0
CSeq: 4
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26)
Transport: RTP/AVP;unicast;client_port=56926-56927


ProxyServerMediaSubsession["H264"]::createNewRTPSink()
Received 169 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK
CSeq: 4
Date: Wed, 27 Nov 2013 12:25:43 GMT
Session: 15618451;timeout=70
Transport: RTP/AVP;unicast;client_port=56926-56927;server_port=5580-5581


ProxyRTSPClient["rtsp://172.16.10.101/live.sdp/"<rtsp://172.16.10.101/live.sdp/>]::continueAfterSETUP(): head codec: H264; numSubsessions 1
        queue:  H264
Sending request: PLAY rtsp://172.16.10.101/live.sdp/ RTSP/1.0
CSeq: 5
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26)
Session: 15618451


Received 201 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK
CSeq: 5
Date: Wed, 27 Nov 2013 12:25:43 GMT
Session: 15618451;timeout=70
RTP-Info: url=rtsp://172.16.10.101/live.sdp/trackID=1;seq=0;rtptime=0
Range: npt=0-
RTCP-Interval: 250


Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0
CSeq: 6
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26)
Session: 15618451


Received 144 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 6
Date: Wed, 27 Nov 2013 12:26:3 GMT
Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN


Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0
CSeq: 7
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26)
Session: 15618451


Received 145 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 7
Date: Wed, 27 Nov 2013 12:26:41 GMT
Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN


Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0
CSeq: 8
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26)
Session: 15618451


Received 145 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 8
Date: Wed, 27 Nov 2013 12:27:35 GMT
Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN


Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0
CSeq: 9
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26)
Session: 15618451


Received 145 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 9
Date: Wed, 27 Nov 2013 12:28:27 GMT
Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN


Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0
CSeq: 10
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26)
Session: 15618451


Received 145 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 10
Date: Wed, 27 Nov 2013 12:29:1 GMT
Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN


Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0
CSeq: 11
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26)
Session: 15618451


Received 145 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 11
Date: Wed, 27 Nov 2013 12:30:1 GMT
Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN


Sending request: OPTIONS rtsp://172.16.10.101/live.sdp/ RTSP/1.0
CSeq: 12
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.11.26)
Session: 15618451


Received 146 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 12
Date: Wed, 27 Nov 2013 12:30:40 GMT
Public: OPTIONS, DESCRIBE, PLAY, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN


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

From finlayson at live555.com  Tue Dec  3 23:52:06 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 4 Dec 2013 17:52:06 +1000
Subject: [Live-devel] All client streams slow down when using two live
	proxies connected together.
In-Reply-To: <529ECF94.102@vivint.com>
References: <52964C0E.6050002@vivint.com> <529ECF94.102@vivint.com>
Message-ID: <77E7CF37-B611-49E0-AEA4-8DA7F988A15F@live555.com>

(First, please remember to trim your quoted text when replying)

The existing code is correct; see
	http://lists.live555.com/pipermail/live-devel/2013-June/017137.html
(when someone asked about this same code back in June.)

Note, in particular:
	"Your write operation is blocking because your stream is - at least temporarily - exceeding the capacity of your network.  To avoid this, you need a slower stream, or a faster network."


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/20131204/18a549ed/attachment.html>

From finlayson at live555.com  Wed Dec  4 13:52:17 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 5 Dec 2013 07:52:17 +1000
Subject: [Live-devel] All client streams slow down when using two live
	proxies connected together.
In-Reply-To: <529ECF94.102@vivint.com>
References: <52964C0E.6050002@vivint.com> <529ECF94.102@vivint.com>
Message-ID: <F8E32CB5-4A71-4843-96C9-CF0A0B3B9EA7@live555.com>

In your previous message, you mentioned the possibility - in the "RTPInterface::sendDataOverTCP()" function - of the "send()" call succeeding in delivering partial (but not complete) data.  I have had no other reports of this ever happening, but - on looking at the code - I realized that the code was not allowing for this possibility.

So, I have now released a new version of the code (2013.12.04) that should properly handle this possibility.  Please upgrade to this new version (but also stop streaming over slow networks; you shouldn't be putting yourself in this situation to begin with!).

BTW, you also said:
> Most clients seem to handle this but if your client is based off of the reference source (osrtspserver) it will fail.

What is "osrtspserver"?  I have never heard of this.  In any case, the RTSP (and RTP/RTCP) protocol is defined by an IETF RFC, and does not have a 'reference source'.  Whatever "osrtspserver" is, it is no more legitimate than any other implementation.


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/20131205/b6f8fd6f/attachment.html>

From cmatsuura at vivint.com  Wed Dec  4 00:35:44 2013
From: cmatsuura at vivint.com (Craig Matsuura)
Date: Wed, 4 Dec 2013 01:35:44 -0700
Subject: [Live-devel] All client streams slow down when using two live
 proxies connected together.
In-Reply-To: <77E7CF37-B611-49E0-AEA4-8DA7F988A15F@live555.com>
References: <52964C0E.6050002@vivint.com> <529ECF94.102@vivint.com>
 <77E7CF37-B611-49E0-AEA4-8DA7F988A15F@live555.com>
Message-ID: <529EE960.7000800@vivint.com>

Could this be handled in the select on a writeset, and when the socket can write it writes the header followed by the data.  (I assume the data must come in one seq write?)  This way the event loop can still process up to the point of the send?

Thanks,
Craig

On 12/04/2013 12:52 AM, Ross Finlayson wrote:
(First, please remember to trim your quoted text when replying)

The existing code is correct; see
http://lists.live555.com/pipermail/live-devel/2013-June/017137.html
(when someone asked about this same code back in June.)

Note, in particular:
"Your write operation is blocking because your stream is - at least temporarily - exceeding the capacity of your network.  To avoid this, you need a slower stream, or a faster network."


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/20131204/8eb1a352/attachment.html>

From maksqwe1 at ukr.net  Wed Dec  4 06:25:16 2013
From: maksqwe1 at ukr.net (maks)
Date: Wed, 04 Dec 2013 16:25:16 +0200
Subject: [Live-devel] Several typos
Message-ID: <1386166993.81770806.7p207kng@frv34.ukr.net>

liveMedia\RTSPClient.cpp 916

while (line[paramIndex] != '\0' && (line[paramIndex] == ' ' || line[paramIndex] == '\t')) ++paramIndex;
if (&line[paramIndex] == '\0') return False;

I think should be:
if (line[paramIndex] == '\0') return False;

---------------------------------
liveMedia\MediaSession.cpp 484

if (strcmp(codecName, "MPA") == 0
   || strcmp(codecName, "MPA-ROBUST") == 0
   || strcmp(codecName, "X-MP3-DRAFT-00")) return 90000;

Forgot to add "== 0":
   || strcmp(codecName, "X-MP3-DRAFT-00") == 0) return 90000;

From finlayson at live555.com  Wed Dec  4 14:25:53 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 5 Dec 2013 08:25:53 +1000
Subject: [Live-devel] Several typos
In-Reply-To: <1386166993.81770806.7p207kng@frv34.ukr.net>
References: <1386166993.81770806.7p207kng@frv34.ukr.net>
Message-ID: <E83852BC-29FD-4725-B415-97E98B7CCC6F@live555.com>

Thanks for the report.  I have included these fixes in the latest version of the code (2013.12.04).

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/20131205/8818da23/attachment.html>

From finlayson at live555.com  Wed Dec  4 14:29:08 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 5 Dec 2013 08:29:08 +1000
Subject: [Live-devel] All client streams slow down when using two live
	proxies connected together.
In-Reply-To: <529EE960.7000800@vivint.com>
References: <52964C0E.6050002@vivint.com> <529ECF94.102@vivint.com>
 <77E7CF37-B611-49E0-AEA4-8DA7F988A15F@live555.com>
 <529EE960.7000800@vivint.com>
Message-ID: <69164B65-57E7-4060-A6A9-2FF2212ACBBA@live555.com>

> Could this be handled in the select on a writeset, and when the socket can write it writes the header followed by the data.  (I assume the data must come in one seq write?)  This way the event loop can still process up to the point of the send?

No, there's no way that the code could be updated easily to do these writes asynchronously.  The code was designed for the common case - sending datagrams - where this type of error isn't an issue.  In any case, it wouldn't really overcome your basic problem: That the bitrate of your input stream (when replicated and transmitted to multiple clients) is exceeding the capacity of your network.

Once again, you need either a slower stream, or a faster network.  (Or you can perhaps alleviate the problem by not streaming over TCP.)


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/20131205/724d1601/attachment.html>

From tayeb.dotnet at gmail.com  Wed Dec  4 08:51:15 2013
From: tayeb.dotnet at gmail.com (Tayeb Meftah)
Date: Wed, 4 Dec 2013 17:51:15 +0100
Subject: [Live-devel] RTSP Progressive streaming
Message-ID: <3633F0FC4CA348D9B31E2C9C88D75BDD@worksc08f920f1>

Hello,
how can i create a multi biterate RTSP stream?
i want my client's to be able to chouse the most related stream while on Wifi,3G,GPRS.
thank,
Tayeb Meftah
Voice of the blind T Broadcast Freedom
http://www.vobradio.org
Phone:447559762242
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131204/639726c1/attachment-0001.html>

From cmatsuura at vivint.com  Wed Dec  4 16:05:54 2013
From: cmatsuura at vivint.com (Craig Matsuura)
Date: Wed, 4 Dec 2013 17:05:54 -0700
Subject: [Live-devel] All client streams slow down when using two live
 proxies connected together.
In-Reply-To: <F8E32CB5-4A71-4843-96C9-CF0A0B3B9EA7@live555.com>
References: <52964C0E.6050002@vivint.com> <529ECF94.102@vivint.com>
 <F8E32CB5-4A71-4843-96C9-CF0A0B3B9EA7@live555.com>
Message-ID: <529FC362.3060101@vivint.com>

Thanks for taking a look at my findings.  I appreciate you taking the time to address the issue.  I will download the latest code.

FYI, the osrtpserver (according to my colleague) is a reference implementation of the rtsp spec.  I honestly like the live555.  Thanks again for all your hard work.

Craig


On 12/04/2013 02:52 PM, Ross Finlayson wrote:
In your previous message, you mentioned the possibility - in the "RTPInterface::sendDataOverTCP()" function - of the "send()" call succeeding in delivering partial (but not complete) data.  I have had no other reports of this ever happening, but - on looking at the code - I realized that the code was not allowing for this possibility.

So, I have now released a new version of the code (2013.12.04) that should properly handle this possibility.  Please upgrade to this new version (but also stop streaming over slow networks; you shouldn't be putting yourself in this situation to begin with!).

BTW, you also said:
Most clients seem to handle this but if your client is based off of the reference source (osrtspserver) it will fail.

What is "osrtspserver"?  I have never heard of this.  In any case, the RTSP (and RTP/RTCP) protocol is defined by an IETF RFC, and does not have a 'reference source'.  Whatever "osrtspserver" is, it is no more legitimate than any other implementation.


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/20131204/c1f3f727/attachment.html>

From finlayson at live555.com  Thu Dec  5 17:57:35 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 6 Dec 2013 11:57:35 +1000
Subject: [Live-devel] All client streams slow down when using two live
	proxies connected together.
In-Reply-To: <529FC362.3060101@vivint.com>
References: <52964C0E.6050002@vivint.com> <529ECF94.102@vivint.com>
 <F8E32CB5-4A71-4843-96C9-CF0A0B3B9EA7@live555.com>
 <529FC362.3060101@vivint.com>
Message-ID: <EB89839A-CA17-4AAC-B540-52FC6E70E830@live555.com>

> FYI, the osrtpserver (according to my colleague) is a reference implementation of the rtsp spec.

Once again, because RTSP is defined solely by an IETF RFC document, there's no such thing as a "reference implementation" of RTSP.  Whatever "osrtpserver" or "osrtspserver" happens to be (a Google search for both produced no results!), it has no special status 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/20131206/c33a9352/attachment.html>

From brilliantov at byterg.ru  Thu Dec  5 06:54:55 2013
From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich)
Date: Thu, 05 Dec 2013 18:54:55 +0400
Subject: [Live-devel] FileSink work in infinity loop with continuePlaying()
Message-ID: <52A093BF.8060402@byterg.ru>

Hello!
I use live555 2013.12.04 on board with FreeScale iMX53 CPU.
Class File is subclass Filesink, I rewtite void
File::afterGettingFrame(unsigned frameSize, unsigned numTruncatedBytes,
struct timeval presentationTime);
Unfortunally if I use continuePlaying() function in it programm work in
infinity loop, but if I not use continuePlaying() programm saved only
one frame.
Programm is very simple:
// create FramedSource subclass
frame = new Frame(env, SEM_NAME);
// create FileSink subclass
file = File::createNew(env, frame, pwd, MAX_SHARED_SIZE, true, cfg);
// running stream via this->startPlaying(frame, NULL, NULL);
file->start();
// main loop
env->taskScheduler().doEventLoop(&is_stop);

Output without continuePlaying():
virtual void File::afterGettingFrame(unsigned int, unsigned int, timeval)
Starting write file FTP-server // otput after startPlaying()
^CStopping write file to FTP-server //output after stopPlaying()

Output with continuePlaying():
virtual void File::afterGettingFrame(unsigned int, unsigned int, timeval)
virtual void File::afterGettingFrame(unsigned int, unsigned int, timeval)
...........
virtual void File::afterGettingFrame(unsigned int, unsigned int, timeval)
virtual void File::afterGettingFrame(unsigned int, unsigned int, timeval)

How should I rewrite my class for solve this problem?

Thank you and excuse me for my bad english.

-- 
Best regards,
Brilliantov Kirill Vladimirovich


From cmatsuura at vivint.com  Thu Dec  5 21:32:02 2013
From: cmatsuura at vivint.com (Craig Matsuura)
Date: Thu, 5 Dec 2013 22:32:02 -0700
Subject: [Live-devel] All client streams slow down when using two live
 proxies connected together.
In-Reply-To: <EB89839A-CA17-4AAC-B540-52FC6E70E830@live555.com>
References: <52964C0E.6050002@vivint.com> <529ECF94.102@vivint.com>
 <F8E32CB5-4A71-4843-96C9-CF0A0B3B9EA7@live555.com>
 <529FC362.3060101@vivint.com>
 <EB89839A-CA17-4AAC-B540-52FC6E70E830@live555.com>
Message-ID: <52A16152.8080906@vivint.com>

Just an FYI.  I found it here:

http://sourceforge.net/projects/rtsp/

Thanks,
Craig


On 12/05/2013 06:57 PM, Ross Finlayson wrote:
FYI, the osrtpserver (according to my colleague) is a reference implementation of the rtsp spec.

Once again, because RTSP is defined solely by an IETF RFC document, there's no such thing as a "reference implementation" of RTSP.  Whatever "osrtpserver" or "osrtspserver" happens to be (a Google search for both produced no results!), it has no special status 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/20131205/1f86a3e4/attachment.html>

From finlayson at live555.com  Sat Dec  7 17:18:39 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 8 Dec 2013 11:18:39 +1000
Subject: [Live-devel] RTSP Progressive streaming
In-Reply-To: <3633F0FC4CA348D9B31E2C9C88D75BDD@worksc08f920f1>
References: <3633F0FC4CA348D9B31E2C9C88D75BDD@worksc08f920f1>
Message-ID: <AF8055D5-1153-4985-A7A8-D3E1AB1E9AC0@live555.com>

> i want my client's to be able to chouse the most related stream while on Wifi,3G,GPRS.

The way to do this is to have multiple "ServerMediaSession" objects (therefore, with different names) - one for each bitrate that you want to support.  The clients would chose the bitrate they want by requesting the appropriate-named 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/20131208/6e9288c0/attachment.html>

From A.Kovacs at Noldus.NL  Mon Dec  9 07:07:05 2013
From: A.Kovacs at Noldus.NL (Adrian Kovacs)
Date: Mon, 9 Dec 2013 15:07:05 +0000
Subject: [Live-devel] RTSPClient reconnection
Message-ID: <C9AAF036A53AE84D8BF086502C885060548D0215@NIT-VS01.noldusbv.local>

Hi,



I would like to handle the event, when the connection to RTSP server lost and the connection is restored. I can detect, when the connection is lost with sending a command to RSTP server and check the response result code.



RTSPClient* pClient;

pClient->sendOptionsCommand(CheckResponse, NULL);



void CheckResponse(RTSPClient* pRTSPClient, int resultCode, char* resString)

{

    if (resultCode < 0)

    {

        //connection lost

    }

}



I can also detect, when the connection restored, when the result code again becomes 0. The problem is that I don't get frames anymore after connection restored. I debugged why this happens, and I noticed, that in BasicTaskScheduler::SingleStep (line 138) the socket is not readable.



The question is that can I somehow get frames again with the active event loop, or should I clear everything and start a new event loop after reconnection?



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

From finlayson at live555.com  Mon Dec  9 07:53:35 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 10 Dec 2013 04:53:35 +1300
Subject: [Live-devel] RTSPClient reconnection
In-Reply-To: <C9AAF036A53AE84D8BF086502C885060548D0215@NIT-VS01.noldusbv.local>
References: <C9AAF036A53AE84D8BF086502C885060548D0215@NIT-VS01.noldusbv.local>
Message-ID: <0ADEAAAC-AF9A-4D1C-AD67-9DB7640606D7@live555.com>

> I would like to handle the event, when the connection to RTSP server lost and the connection is restored. I can detect, when the connection is lost with sending a command to RSTP server and check the response result code.

Unfortunately, once the connection to the server is lost, the existing "RTSPClient" object - and its connection to the server - will no longer be useful.  In this case, you will need to close (i.e., destroy) the current "RTSPClient" object, along with the "MediaSession" object that it's using, and any "MediaSink" objects that it's outputting to.  Then you will need to create a new "RTSPClient" object all over again, and send new "DESCRIBE", "SETUP", PLAY" commands.

The easiest way to do this is to simply exit the current process (i.e., by calling "exit(0);"), and then create a new process (e.g., command) that creates a new "RTSPClient" object, etc.

But if you don't want to do this, then you'll need to explicitly call "Medium::close()" on the "MediaSession" object, "MediaSink" objects, and finally the "RTSPClient" object.


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/20131210/7fb2e078/attachment.html>

From cmatsuura at vivint.com  Mon Dec  9 10:10:01 2013
From: cmatsuura at vivint.com (Craig Matsuura)
Date: Mon, 9 Dec 2013 11:10:01 -0700
Subject: [Live-devel] RTSPClient reconnection
In-Reply-To: <C9AAF036A53AE84D8BF086502C885060548D0215@NIT-VS01.noldusbv.local>
References: <C9AAF036A53AE84D8BF086502C885060548D0215@NIT-VS01.noldusbv.local>
Message-ID: <52A60779.3090502@vivint.com>

I believe the ProxyServerMediaSession.cpp has an example of resetting the client connected to a server on result codes returned via OPTION command.  See the continueAfterLivenessCommand() and continueAfterOPTIONS().

Craig

On 12/09/2013 08:07 AM, Adrian Kovacs wrote:

Hi,



I would like to handle the event, when the connection to RTSP server lost and the connection is restored. I can detect, when the connection is lost with sending a command to RSTP server and check the response result code.



RTSPClient* pClient;

pClient->sendOptionsCommand(CheckResponse, NULL);



void CheckResponse(RTSPClient* pRTSPClient, int resultCode, char* resString)

{

    if (resultCode < 0)

    {

        //connection lost

    }

}



I can also detect, when the connection restored, when the result code again becomes 0. The problem is that I don't get frames anymore after connection restored. I debugged why this happens, and I noticed, that in BasicTaskScheduler::SingleStep (line 138) the socket is not readable.



The question is that can I somehow get frames again with the active event loop, or should I clear everything and start a new event loop after reconnection?



Adrian

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

From richard.l at live.cn  Mon Dec  9 00:44:50 2013
From: richard.l at live.cn (=?gb2312?B?wdbTwNXC?=)
Date: Mon, 9 Dec 2013 08:44:50 +0000
Subject: [Live-devel] I found a critical potential error in file
	MatroskaFileParser.cpp
Message-ID: <BAY177-W3169B51F3EBB2C5C8836AFEAD30@phx.gbl>

Hi,
 
I found a critical potential error in file "MatroskaFileParser.cpp", but I don't know how to inform the author to fix it. The error is in line 29 (the build of Dec. 5, 2013), the warning like below:
 
matroskafileparser.cpp(29): warning C4355: 'this' : used in base member initializer list
 
the relevant codes as below:
 
MatroskaFileParser::MatroskaFileParser(MatroskaFile& ourFile, FramedSource* inputSource,
           FramedSource::onCloseFunc* onEndFunc, void* onEndClientData,
           MatroskaDemux* ourDemux)
  : StreamParser(inputSource, onEndFunc, onEndClientData, continueParsing, this),
    fOurFile(ourFile), fInputSource(inputSource),
    fOnEndFunc(onEndFunc), fOnEndClientData(onEndClientData),
    fOurDemux(ourDemux),
    fCurOffsetInFile(0), fSavedCurOffsetInFile(0), fLimitOffsetInFile(0),
    fNumHeaderBytesToSkip(0), fClusterTimecode(0), fBlockTimecode(0),
    fFrameSizesWithinBlock(NULL),
    fPresentationTimeOffset(0.0) {
  if (ourDemux == NULL) {
    // Initialization
    fCurrentParseState = PARSING_START_OF_FILE;
    continueParsing();
  } else {
    fCurrentParseState = LOOKING_FOR_CLUSTER;
    // In this case, parsing (of track data) doesn't start until a client starts reading from a track.
  }
}
 
See the blue line(forth line), the "this" pointer of derived class "MatroskaFileParser" was passed to base class "StreamParser" to initialize the base class, this will cause undefined errors.
 
If who can contact the author, please forward this mail. Thanks a lot in advance.
 
 
 
Best Regards,
Richard
 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131209/fc8a1451/attachment.html>

From finlayson at live555.com  Mon Dec  9 13:19:20 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 10 Dec 2013 10:19:20 +1300
Subject: [Live-devel] I found a critical potential error in file
	MatroskaFileParser.cpp
In-Reply-To: <BAY177-W3169B51F3EBB2C5C8836AFEAD30@phx.gbl>
References: <BAY177-W3169B51F3EBB2C5C8836AFEAD30@phx.gbl>
Message-ID: <7F6C09B5-D27B-4C77-A89D-BCB9E2A64666@live555.com>

> I found a critical potential error in file "MatroskaFileParser.cpp", but I don't know how to inform the author to fix it. The error is in line 29 (the build of Dec. 5, 2013), the warning like below:
>  
> matroskafileparser.cpp(29): warning C4355: 'this' : used in base member initializer list

No, this is not a "critical potential error".  It's not even an "error".  It is a compiler *warning* (usually given by some old versions of Microsoft's Visual C++ compiler).

But there is nothing wrong with the code, and I don't know why your compiler is 'warning' you about it.  There is nothing for you to worry about 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/20131210/e8b24292/attachment-0001.html>

From warren at etr-usa.com  Mon Dec  9 16:22:22 2013
From: warren at etr-usa.com (Warren Young)
Date: Mon, 09 Dec 2013 17:22:22 -0700
Subject: [Live-devel] I found a critical potential error in file
	MatroskaFileParser.cpp
In-Reply-To: <7F6C09B5-D27B-4C77-A89D-BCB9E2A64666@live555.com>
References: <BAY177-W3169B51F3EBB2C5C8836AFEAD30@phx.gbl>
 <7F6C09B5-D27B-4C77-A89D-BCB9E2A64666@live555.com>
Message-ID: <52A65EBE.5030900@etr-usa.com>

On 12/9/2013 14:19, Ross Finlayson wrote:
>
> No, this is not a "critical potential error".  It's not even an "error".
>   It is a compiler *warning* (usually given by some old versions of
> Microsoft's Visual C++ compiler).

I don't think VC++ is wholly wrong to warn about this.  The object isn't 
completely constructed when the initializer list is processed, but 
'this' is assumed to point to a constructed object.

If all the parent ctor does with the value is hold it for use *after* 
all the ctors run, it's fine.

If the base ctor dereferences the pointer, though, it's a potential bug.

From bbischan at watchtower-security.com  Tue Dec 10 06:15:31 2013
From: bbischan at watchtower-security.com (Bob Bischan)
Date: Tue, 10 Dec 2013 08:15:31 -0600
Subject: [Live-devel] ProxyServer (Proposed Option)
Message-ID: <CACv1yZ9CX=k-_RLnErCoFMDHxub3nuJu=VeeY39s1=V4-eU+pQ@mail.gmail.com>

I would like to propose the addition of a new option to ProxyServer. The
proposed option would be to add the ability to use the SET_PARAMETER
command for streams that are running on ProxyServer.

This is option is being proposed for an application/user specific need,
however, there may be other use cases / implementations that could benefit
from this functionality.

Desired Functionality:

Have an option for PorxyServer to send a SET_PARAMETER command with a user
defined message in the body to an existing back-end server whenever a new
client connection is initiated with a ProxyServer stream.

Example Use Case:

Axis cameras with H264 (Ver 5.x firmware) have an API option that provides
the ability to force an I-frame during an existing session using the
SET_PARAMETER command. In this particular case a SET_PARAMETER command is
sent with the following option in the body:

Renew-Stream: yes

As mentioned, this proposal is obviously for a specific use case and may or
may not have a broad enough appeal to warrant addition to the live555
library. With that said, if there is anyone on this mailing-list interested
in taking on a project to subclass this type of functionality I would be
very interested in an off-line discussion.

Ross,

If this is something that is of interest or merits inclusion into "Live555
Streaming Media"
I would be more than glad to support another "Funded Project".


Thanks,

Bob

-- 

Bob Bischan

Manager (Operations/Software Development)

*WATCHTOWER SECURITY, INC.*

2418 Northline Industrial Drive
Maryland Heights, MISSOURI 63043

314 427 4586 office

314 330 9001 cell

314 427 8823 fax

www.watchtower-security.com

*?Protecting your community and those you value most.?*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131210/f33ba2ca/attachment.html>

From w.bekker at vdgsecurity.com  Wed Dec 11 00:27:22 2013
From: w.bekker at vdgsecurity.com (Wim Bekker)
Date: Wed, 11 Dec 2013 09:27:22 +0100
Subject: [Live-devel] What is the preferred way of terminating an RTSP
 server connection
In-Reply-To: <CE75E3D4-C0C1-4BC9-8C49-976820898183@live555.com>
References: <CAA1YYewoR13qMA3mT3Q_H8NoE7LTPFVvXEbHQV_BTcO45U80hw@mail.gmail.com>
 <C7559139-CAB3-488A-96F6-D9921845990C@live555.com>
 <CAA1YYew8sdaXnMik66YPgacSO9=685U3KqDLbca3D=YYcSZsfg@mail.gmail.com>
 <CE75E3D4-C0C1-4BC9-8C49-976820898183@live555.com>
Message-ID: <CAA1YYezkFBtpnwBYWGDY430_haFXBW0JaSRiCM8-5wtiSHRvEQ@mail.gmail.com>

2013/11/22 Ross Finlayson <finlayson at live555.com>

> There's no easy way to terminate (from the server) just 'some'
>> connections.  (What criterion would you use to decide which connections you
>> want to terminate??)
>>
>> However, you can terminate *all* connections for a given stream by calling
>> RTSPServer::closeAllClientSessionsForServerMediaSession()
>>
>> Plus, of course, if you delete the entire "RTSPServer" object - by
>> calling "Medium::close(pointer-to-your-RTSPServer-object);" - then *all*
>> connections to the server (and all resources used by the server) will be
>> reclaimed.
>>
>
> Ok thanks. What about stopGettingFrames in FramedSource? I'll try that one
> because I have easy access to that object.
>
>
> (I assume that you're referring to the data source object for your
> stream?)  Calling "stopGettingFrames()" on that object will stop data (and
> thus RTP packets) from flowing, but it won't tear down any connections to
> clients.
>
> You haven't said anything about *which* connections you want to terminate,
> and why.  If you're worried only about terminating connections to 'dead'
> clients (i.e., clients that just disappear, without sending a RTSP
> "TEARDOWN"), then you don't need to worry.  The server will automatically
> close (and reclaim resources for) those connections after a period of time
> (by default, 65 seconds).
>

Tx, I've been away for a while, see if I can pick this up again.

The given setup is this: I have a video server and an rstp server. Clients
request a particular video stream from the rtsp server. The rtsp server
then request that stream from the video server and sends incoming frames to
the client. There's also a controller application. This application gets
information from the rtsp server and uses that to instruct the client
application to get particular video. If the client should not retrieve
video anymore, the controller instructs the client for that. If the
controller can not reach the client to stop streaming it needs to tell the
server to stop streaming. Although this is not normal usage it is very
important that the video stream is stopped.

It's easy to stop the stream, but it would be nice to close the connection
also.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131211/ebfe8be9/attachment.html>

From Giridhara.Kalkere at honeywell.com  Wed Dec 11 07:52:51 2013
From: Giridhara.Kalkere at honeywell.com (Kalkere, Giridhara(IE10))
Date: Wed, 11 Dec 2013 15:52:51 +0000
Subject: [Live-devel] MPEG-TS in LIVE media.
In-Reply-To: <20852BC5-5E25-47DD-AEC8-2202C69FE7C0@live555.com>
References: <955512E27CA4E9478883ACDCA9CA40C699FC91@IE1AEX3007.global.ds.honeywell.com>
 <5CB52840-CB2A-4556-A3ED-41CA08DE32F1@live555.com>
 <955512E27CA4E9478883ACDCA9CA40C60159F1EB@IE1AEX3007.global.ds.honeywell.com>
 <20852BC5-5E25-47DD-AEC8-2202C69FE7C0@live555.com>
Message-ID: <955512E27CA4E9478883ACDCA9CA40C6015A15E6@IE1AEX3007.global.ds.honeywell.com>

Dear Ross,

Thank you very much for all your advice and suggestions. I have looked at the link you gave in other mail.
Its great example to play around cameras and video streams. It helped a lot to understand the whole concept.

I have one quick question for you and your suggestion and advice will help to solve my major design problem in a great way.

I used testH264VideoToTransportStream along with openRTSP to record a H264 video stream to .ts file and I can able to play the file in any player.

I am trying to use the same to record a camera which streams MPEG4 video but the out.ts is created with 0bytes file. Means nothing recorded.
Is there any other way or examples available in the LIVE555 framework?

Thanks and Regards,
Giri


From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Wednesday, December 04, 2013 4:37 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] MPEG-TS in LIVE media.

Thank you very much for your suggestion.
The testH264VideoToTransportStream application reads and in input file (h264) and converts it into .ts file. That's great.

But I need to connect to an IP camera which provides me H264/MPEG stream. instead of file  I want to provide this live stream of frames and create the .ts files of 1sec each. So If record for 1 minute I want to see 60 .ts files. In the given folder.

I've already told you (even though you appeared to ignore my advice!) how you can use our tools to read from a H.264/RTSP/RTP stream, and convert the incoming data to a (single) Transport Stream.  And I'm sure you can find other tools (made by other companies) that can break up a single input Transport Stream into multiple Transport Stream files - each 1 second long.

In any case, I can no longer help you for free on this mailing list.  If your management is interested in hiring me as a consultant to help you with your project, then please tell them to contact me (via separate email).

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/20131211/fe835aa6/attachment-0001.html>

From phuocpham at ssu.ac.kr  Wed Dec 11 03:48:44 2013
From: phuocpham at ssu.ac.kr (=?EUC-KR?B?xsq53ceq?=)
Date: Wed, 11 Dec 2013 20:48:44 +0900 (KST)
Subject: [Live-devel] =?euc-kr?q?Errors_when_streaming_HD_H=2E264_using_Li?=
	=?euc-kr?q?ve555?=
Message-ID: <52a8540a3f95_@_imoxion.com>

Hi experts,

I am using VLC to playback H.264 (720p and 1080p) streaming from live555 with the I frame's size is about 100000 kbytes then I get errors. Some first frames arrivate at the VLC player and are displayed broken. After 4 or 5 seconds the VLC player refreshes the screen and after that it works fine. The H.264 file I used to test live555 saved from an IP camera that does not get errors when playing back at VLC player.
Here is the link to the image show the errors.
http://s1208.photobucket.com/user/phuocpham09t/media/VLC.png.html

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

From finlayson at live555.com  Wed Dec 11 08:40:03 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 12 Dec 2013 05:40:03 +1300
Subject: [Live-devel] Errors when streaming HD H.264 using Live555
In-Reply-To: <52a8540a3f95_@_imoxion.com>
References: <52a8540a3f95_@_imoxion.com>
Message-ID: <A53CE4B6-1AFE-4E4C-90C3-B11BC045B9B0@live555.com>

VLC is not our software, and problems with VLC should be posted on a VLC mailing list - not here.  However, in this case, I know the answer to your question.

Your problem is that your stream's I-frames are too large.  VLC uses an initial buffer size of 100,000 bytes when receiving data.  If a data frame (in this case, your stream's first I-frame) is larger than this, then the remaining data will be truncated (i.e., lost).  VLC recovers from this by doubling the size of the buffer for receiving future frames, but it cannot recover the data that was lost from the first I-frame.

The solution is to not send very large I-frames as single NAL units.  Instead, you should encode these I-frames into multiple 'slice' NAL units.  (Alternatively, if you can't do that, then try to encode I-frame NAL units to be smaller than 100,000 bytes.)


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/20131212/2755c1ba/attachment.html>

From bbischan at watchtower-security.com  Wed Dec 11 14:05:09 2013
From: bbischan at watchtower-security.com (Bob Bischan)
Date: Wed, 11 Dec 2013 16:05:09 -0600
Subject: [Live-devel] QuickTime and RTCP RR packets.
In-Reply-To: <527A3416.8070905@cubitech.co.uk>
References: <527A0B3F.1090204@cubitech.co.uk>
 <AF26AF0D-E7C1-4101-9B87-91FADE2AC805@live555.com>
 <527A3416.8070905@cubitech.co.uk>
Message-ID: <CACv1yZ_OkEEPTz6BNJpueukcvvec08JgHrUZKkVEXZ2wjaARUw@mail.gmail.com>

I wanted to pass on some additional information and findings on this topic.

With RTSP-over-HTTP It appears that If you provide a timeout value..ie
"timeout=60" in the SETUP Response, the QuickTime player will send OPTIONS
requests back to RTSPServer to indicate it's liveness.

Before modifying RTSPServer.cpp to provide this timeout value I was having
the same problems as described in this thread. With this change the
QuickTime player does not timeout anymore!

The best option is for Apple to fix their bug, but this may be a work
around for those that want to use Quicktime.


Bob



On Wed, Nov 6, 2013 at 6:20 AM, Ken Ferguson <ken.ferguson at cubitech.co.uk>wrote:

>   The issue I am seeing is that when QuickTime uses RTSP-over-HTTP it
> appears not to send RTCP Receiver Report packets.
>
>
>  Yes, this is a bug with QuickTime Player; it's separate from the bug that
> I noted back in 2007, and occurs only if RTSP-over-HTTP streaming is being
> used.
>
>  You can try submitting a bug to Apple (I already informed a colleague
> high up in Apple about this problem, back in January 2013), but I wouldn't
> hold my breath waiting for them to fix this, as QuickTime Player does not
> appear to be a priority for Apple these days.
>
>  Instead, I suggest using VLC as a client (it has an option
> (Preferences->Interface->Show All->Demuxers->RTP/RTSP) that tells it to
> request RTSP-over-HTTP streaming).
>
>  Hi Ross,
>
> Thank you for the swift reply.  It's good to know at least.
>
> I will at least submit a bug to Apple about it.  One can only hope that
> one day it will get fixed.
>
> I've already tested with VLC and confirmed that it works.  Unfortunately
> however it isn't an option at the moment as we're actually using the
> QuickTime plugin in a web browser and would prefer not to use anything else
> simply because of it's installed base.  I guess that's a decision we may
> have to revisit :)
>
> Thanks again,
>
> Ken.
>
> _______________________________________________
> 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/20131211/9e509821/attachment.html>

From Anton.Chmelev at transas.com  Thu Dec 12 05:45:47 2013
From: Anton.Chmelev at transas.com (Chmelev, Anton)
Date: Thu, 12 Dec 2013 13:45:47 +0000
Subject: [Live-devel] Framerate in the file is 4X the original
Message-ID: <532656B720FE4E48A88D9D98B1194166BBD04410@VOITV-EXCH-BE02.transas.com>

Hello Ross,

I stream the video from the camera, and in the resulting file framerate is 4X the original.
Eg. camera provides 30 FPS, in the file I get around 120, which results in "slow-mo" playback.

Tried to save .avi, .mp4, .mov using openRTSP, same thing.
Kindly advise, where to look, what to check.


Best regards,
Anton Chmelev
Senior Software Development Engineer
______________________________
[TRANSAS_logo_email]
Transas Technologies
Maly pr. V.O., 54-4,
St. Petersburg, Russia, 199178

Phone: +7 (812) 325 3131
Anton.Chmelev at transas.com
www.transas.com<http://www.transas.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131212/09c9606a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1466 bytes
Desc: image002.png
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131212/09c9606a/attachment.png>

From finlayson at live555.com  Thu Dec 12 19:00:20 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 13 Dec 2013 16:00:20 +1300
Subject: [Live-devel] I found a critical potential error in file
	MatroskaFileParser.cpp
In-Reply-To: <52A65EBE.5030900@etr-usa.com>
References: <BAY177-W3169B51F3EBB2C5C8836AFEAD30@phx.gbl>
 <7F6C09B5-D27B-4C77-A89D-BCB9E2A64666@live555.com>
 <52A65EBE.5030900@etr-usa.com>
Message-ID: <E67B75C8-E9D3-43F6-8643-AB970F21D7F9@live555.com>

>> No, this is not a "critical potential error".  It's not even an "error".
>>  It is a compiler *warning* (usually given by some old versions of
>> Microsoft's Visual C++ compiler).
> 
> I don't think VC++ is wholly wrong to warn about this.  The object isn't completely constructed when the initializer list is processed, but 'this' is assumed to point to a constructed object.
> 
> If all the parent ctor does with the value is hold it for use *after* all the ctors run, it's fine.

Yes, and that is what we do.


> If the base ctor dereferences the pointer, though, it's a potential bug.

The only real danger is if the base-class constructor tries to access member fields in the derived class - but the only way that could really happen would be if the base-class constructor were to explicitly cast the pointer into that of the derived class, and then try to dereference it.  Even calling a virtual function wouldn't cause a problem, because (being in a constructor) the base-class function would end up being called instead.

So, IMHO, this (old) compiler is being a bit anal-retentive about issuing a warning here.  In any case, it's not an 'error' 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/20131213/7e2854ed/attachment-0001.html>

From cmatsuura at vivint.com  Mon Dec  9 16:53:24 2013
From: cmatsuura at vivint.com (Craig Matsuura)
Date: Mon, 9 Dec 2013 17:53:24 -0700
Subject: [Live-devel] sub-classing ProxyServerMediaSession
In-Reply-To: <7F6C09B5-D27B-4C77-A89D-BCB9E2A64666@live555.com>
References: <BAY177-W3169B51F3EBB2C5C8836AFEAD30@phx.gbl>
 <7F6C09B5-D27B-4C77-A89D-BCB9E2A64666@live555.com>
Message-ID: <52A66604.2040704@vivint.com>

One working on sub classing ProxyServerMediaSession and also sub classing ProxyRTSPClient.  I have overridden the createNewProxyRTSPClient().  The problem I'm having is the createNewProxyRTSPClient() is called from the constructor of the ProxyServerMediaSession, and the method I just overrode is not being called.

According to the following post this is a know limitation with C++.

http://www.codeproject.com/Tips/641610/Be-Careful-with-Virtual-Method

I can modify the source directly, but thought I would ask first as I did a bunch of work to derive from the ProxyServerMediaSession and ProxyRTSPClient.

In the ProxyServerMediaSession.hh
protected:
  ProxyServerMediaSession(UsageEnvironment& env, RTSPServer* ourRTSPServer,
              char const* inputStreamURL, char const* streamName,
              char const* username, char const* password,
              portNumBits tunnelOverHTTPPortNum, int verbosityLevel, int socketNumToServer);

  // If you subclass "ProxyRTSPClient", then you should also subclass "ProxyServerMediaSession" and redefine this virtual function
  // in order to create new objects of your "ProxyRTSPClient" subclass:
  virtual ProxyRTSPClient* createNewProxyRTSPClient(char const* rtspURL, char const* username, char const* password,
                            portNumBits tunnelOverHTTPPortNum, int verbosityLevel, int socketNumToServer);

===========

In the ProxyServerMediaSession.cpp
ProxyServerMediaSession::ProxyServerMediaSession(UsageEnvironment& env, RTSPServer* ourRTSPServer,
                         char const* inputStreamURL, char const* streamName,
                         char const* username, char const* password,
                         portNumBits tunnelOverHTTPPortNum, int verbosityLevel, int socketNumToServer)
  : ServerMediaSession(env, streamName, NULL, NULL, False, NULL),
    describeCompletedFlag(0), fOurRTSPServer(ourRTSPServer), fClientMediaSession(NULL),
    fVerbosityLevel(verbosityLevel), fPresentationTimeSessionNormalizer(new PresentationTimeSessionNormalizer(envir())) {
  // Open a RTSP connection to the input stream, and send a "DESCRIBE" command.
  // We'll use the SDP description in the response to set ourselves up.
  fProxyRTSPClient = createNewProxyRTSPClient(inputStreamURL, username, password, tunnelOverHTTPPortNum,
                          verbosityLevel > 0 ? verbosityLevel-1 : verbosityLevel, socketNumToServer);
  ProxyRTSPClient::sendDESCRIBE(fProxyRTSPClient);
}

If I override the createNewProxyRTSPClient, and instanciate the new sub-class the ProxySErverMediaSession version of the createNewProxyRTSPClient is called, not my overriden version.


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

From finlayson at live555.com  Thu Dec 12 23:46:59 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 13 Dec 2013 20:46:59 +1300
Subject: [Live-devel] sub-classing ProxyServerMediaSession
In-Reply-To: <52A66604.2040704@vivint.com>
References: <BAY177-W3169B51F3EBB2C5C8836AFEAD30@phx.gbl>
 <7F6C09B5-D27B-4C77-A89D-BCB9E2A64666@live555.com>
 <52A66604.2040704@vivint.com>
Message-ID: <BD571F9D-098E-4B7A-B982-D86EF364F6BF@live555.com>


On Dec 10, 2013, at 1:53 PM, Craig Matsuura <cmatsuura at vivint.com> wrote:

> One working on sub classing ProxyServerMediaSession and also sub classing ProxyRTSPClient.  I have overridden the createNewProxyRTSPClient().  The problem I'm having is the createNewProxyRTSPClient() is called from the constructor of the ProxyServerMediaSession, and the method I just overrode is not being called.

Yes, you're right.  This 'virtual function' method of creating an object of your own custom subclass of "ProxyRTSPClient" won't work, because it's being called from a constructor.  I'll have to come up with some other mechanism for doing this.  Stay tuned...


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/20131213/0199eb07/attachment.html>

From phuocpham at ssu.ac.kr  Fri Dec 13 01:26:24 2013
From: phuocpham at ssu.ac.kr (=?EUC-KR?B?xsq53ceq?=)
Date: Fri, 13 Dec 2013 18:26:24 +0900 (KST)
Subject: [Live-devel]
	=?euc-kr?q?Errors_when_streaming_HD_H=2E264_using_Li?=
	=?euc-kr?q?ve555?=
Message-ID: <52aad30c3fda_@_imoxion.com>

Hi Ross, thank you for your response,

All our boards IPNC DM368, DM8148 that use Live555 for streaming commit that problem. But when I use VLC to playback the HD H.264 from a streaming board I don't get that kinda error. (Actually I don't know what kind of streaming libraries they use inside ). When I use RTSPClient to retrieve and save that stream to a .h264 file and use live555 to stream out that file over rtsp, at the client side I also use VLC player to playback then the errors happen. I don't know but are you sure this problem is not caused by Live555?

BTW, I read the VLC source code then I find out that they have  a module call 'access->mms->mmstu.h' which is used to initially retrieve data from the server has a buffer of 100000 bytes. I increase that buffer to have enough room for incoming I-frames. But it doesn't help me out. Do you have any ideas?

I appreciate your help.


Re: [Live-devel] Errors when streaming HD H.264 using Live555


VLC is not our software, and problems with VLC should be posted on a VLC mailing list - not here.  However, in this case, I know the answer to your question.


Your problem is that your stream's I-frames are too large.  VLC uses an initial buffer size of 100,000 bytes when receiving data.  If a data frame (in this case, your stream's first I-frame) is larger than this, then the remaining data will be truncated (i.e., lost).  VLC recovers from this by doubling the size of the buffer for receiving future frames, but it cannot recover the data that was lost from the first I-frame.


The solution is to not send very large I-frames as single NAL units.  Instead, you should encode these I-frames into multiple 'slice' NAL units.  (Alternatively, if you can't do that, then try to encode I-frame NAL units to be smaller than 100,000 bytes.)



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/20131213/de06582b/attachment.html>

From finlayson at live555.com  Fri Dec 13 16:05:34 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 14 Dec 2013 13:05:34 +1300
Subject: [Live-devel] ProxyServer (Proposed Option)
In-Reply-To: <CACv1yZ9CX=k-_RLnErCoFMDHxub3nuJu=VeeY39s1=V4-eU+pQ@mail.gmail.com>
References: <CACv1yZ9CX=k-_RLnErCoFMDHxub3nuJu=VeeY39s1=V4-eU+pQ@mail.gmail.com>
Message-ID: <4F8B98D5-7898-4E31-A938-826F60C8124B@live555.com>

> Have an option for PorxyServer to send a SET_PARAMETER command with a user defined message in the body to an existing back-end server whenever a new client connection is initiated with a ProxyServer stream.

No, this isn't possible with the current proxy server implementation, because the proxy server code has no knowledge of any front-end client connections (other than the first), nor any front-end client disconnections (other than the last).

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/20131214/894d7974/attachment.html>

From gilles.chanteperdrix at xenomai.org  Sat Dec 14 04:13:38 2013
From: gilles.chanteperdrix at xenomai.org (Gilles Chanteperdrix)
Date: Sat, 14 Dec 2013 13:13:38 +0100
Subject: [Live-devel] [vlc] RTSP client in vlc 2.1
In-Reply-To: <238AAC36-B12B-48B7-84DA-90C944751920@live555.com>
References: <52AC1BF4.7080905@xenomai.org>
 <238AAC36-B12B-48B7-84DA-90C944751920@live555.com>
Message-ID: <52AC4B72.5080606@xenomai.org>

On 12/14/2013 11:43 AM, Ross Finlayson wrote:
>> Problem 1: sub-titles streaming.
>> 
>> When playing the following URL: 
>> rtsp://xenomai.org:8554/video-tests/hd-fast.mp4
>> 
>> The playback works nicely, but when enabling a sub-title track,
>> the playback suddenly stops. After inspection of the RTSP dialog,
>> here is what happens. When starting playback, vlc sends a SETUP for
>> every track, then sends a global PLAY. When the user selects a
>> sub-title track, it sends a TEARDOWN for every sub-title track,
>> then a SETUP only for the selected track. At this point live555
>> (which is what I use for the RTSP server) refuses to setup the
>> track and returns a 404 error, which causes vlc to stop playback.
> 
> Gilles,
> 
> The real problem here seems to be that the LIVE555 code (which you're
> using as your server) is behaving unexpectedly.  Because of this, the
> best place to discuss this problem is the
> "live-devel at lists.live555.com" mailing list (see
> <http://www.live555.com/liveMedia/faq.html#mailing-list-address> for
> more information) - rather than a VLC mailing list.
> 
> If there's a problem with the LIVE555 server code, then the proper
> solution would be for us (Live Networks, Inc. - the developer of that
> code) to fix that code, rather than asking VLC to change its
> behavior.

Ok, following up on live555 mailing list.

Well, I know how to "fix" this in live555 code:
diff --git a/liveMedia/RTSPServer.cpp b/liveMedia/RTSPServer.cpp
index 693df25..5cebc04 100644
--- a/liveMedia/RTSPServer.cpp
+++ b/liveMedia/RTSPServer.cpp
@@ -1796,7 +1796,6 @@ void RTSPServer::RTSPClientSession
        || subsession == fStreamStates[i].subsession) {
       if (fStreamStates[i].subsession != NULL) {
        fStreamStates[i].subsession->deleteStream(fOurSessionId, fStreamStates[i].streamToken);
-       fStreamStates[i].subsession = NULL;
       }
     }
   }

What I have doubts about, is what vlc does: after the SETUP, it sends a PLAY
starting from NPT 0.0, but with a recorded stream, it does not make sense,
the server then has no reason to send the sub-titles track synchronized
with the other tracks, it only happens to work (in my case), because the
tracks all retrieve frames from the same demuxer, so basically, the sub-titles
do not really start from NPT 0.0. But this looks fragile to me.

Let me seize this opportunity to explain a bit on what I am working:
a server based on live555 for RTSP streaming, but on ffmpeg for demuxing, which
allows to stream about any media file and have uniform functionalities, for 
instance seeking for any type of files, like .ts without index, weird .avi
and so on. Following live555 FAQ, I have used live555 as a library as much as
possible, however I have done some modifications to live555 which could be 
submitted as patches to this list if you are interested:
- Groupsock: when a receiving interface address is defined, bind all sockets
to it, and skip the "send to ourself a multicast packet" trick; this is to
accomodate the situation of an RTSP server running on a machine with multiple
interface with internet connectivity but where we want to use only one interface;
- RTP/RTCP use the "feedface"/first receiver report to fix the client ports
if NAT is running without "conntrack_rtsp";
- MultiFrameRTPSink: implement bitrate limiting, in order to allow streaming 
from a machine with high-speed connectivity to another machine with high-speed
connectivity going through a path with a "weak-link" with slow connectivity
(typically, from an internet address to my personal PC through a DSL line)
- H264VideoRTPSink: apply frame duration to the last RTP packet instead of the
first;
- VorbisAudioRTPSink: fix memory corruption error (detected by valgrind);
- Theora: implement RTPSink based on RFC draft (found in ffmpeg sources).

I would also like to say that live555 is really a great project to work with,
not being a C++ fan myself, I appreciate the minimalist approach live555 took.

Regards.

-- 
                                                                Gilles.

From gilles.chanteperdrix at xenomai.org  Sat Dec 14 06:59:11 2013
From: gilles.chanteperdrix at xenomai.org (Gilles Chanteperdrix)
Date: Sat, 14 Dec 2013 15:59:11 +0100
Subject: [Live-devel] [vlc] RTSP client in vlc 2.1
In-Reply-To: <52AC4B72.5080606@xenomai.org>
References: <52AC1BF4.7080905@xenomai.org>
 <238AAC36-B12B-48B7-84DA-90C944751920@live555.com>
 <52AC4B72.5080606@xenomai.org>
Message-ID: <52AC723F.2070905@xenomai.org>

On 12/14/2013 01:13 PM, Gilles Chanteperdrix wrote:
> Let me seize this opportunity to explain a bit on what I am working:
> a server based on live555 for RTSP streaming, but on ffmpeg for demuxing, which
> allows to stream about any media file and have uniform functionalities, for 
> instance seeking for any type of files, like .ts without index, weird .avi
> and so on.

You can see the server in action at:
http://xenomai.org/video-tests/

To start playing an RTSP stream, click on "video stream" or "audio
stream" in the "Description" column.

-- 
                                                                Gilles.

From finlayson at live555.com  Sat Dec 14 08:40:46 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 15 Dec 2013 05:40:46 +1300
Subject: [Live-devel] [vlc] RTSP client in vlc 2.1
In-Reply-To: <52AC4B72.5080606@xenomai.org>
References: <52AC1BF4.7080905@xenomai.org>
 <238AAC36-B12B-48B7-84DA-90C944751920@live555.com>
 <52AC4B72.5080606@xenomai.org>
Message-ID: <4D9762DC-54CC-4EDF-AC27-94EF27D397AD@live555.com>

> Well, I know how to "fix" this in live555 code:
> diff --git a/liveMedia/RTSPServer.cpp b/liveMedia/RTSPServer.cpp
> index 693df25..5cebc04 100644
> --- a/liveMedia/RTSPServer.cpp
> +++ b/liveMedia/RTSPServer.cpp
> @@ -1796,7 +1796,6 @@ void RTSPServer::RTSPClientSession
>        || subsession == fStreamStates[i].subsession) {
>       if (fStreamStates[i].subsession != NULL) {
>        fStreamStates[i].subsession->deleteStream(fOurSessionId, fStreamStates[i].streamToken);
> -       fStreamStates[i].subsession = NULL;
>       }
>     }
>   }

Unfortunately we can't do this, because it breaks the subsequent 'optimization' - at the end of the "handleCmd_TEARDOWN()" function.  I.e., in the normal case, when an *entire* stream is torn down (using either a single aggregate "TEARDOWN" command, or via individual "TEARDOWN"s for each track), we immediately reclaim the "RTSPClientSession" structure.  (I don't want to rely upon the 'client liveness timeout' mechanism for this, because some people have disabled this mechanism, to allow for (broken) RTSP clients that don't send RTCP "RR" packets.)

But, more generally, the server code assumes, in several places, that a stream - once 'torn down' - cannot be resurrected via another "SETUP" within the same session (i.e., using the same session id).  This seems reasonable  - and consistent with the wording in the RTSP specification, which describes the "TEARDOWN" command as being one that ends a RTSP session.  So I don't want to change this behavior in our server code.

So this means, that - upon reflection - what VLC is doing is wrong.  Rather than sending a "TEARDOWN" for all subtitle tracks, and then doing a subsequent "SETUP" for the subtitle track that the user wants, it should instead just send a "TEARDOWN" for all subtitle tracks *except* the one that the user wants (and then not send another "SETUP").  (I'll follow up on the VLC developers' mailing list about this.)


> I have done some modifications to live555 which could be 
> submitted as patches to this list if you are interested:

> - VorbisAudioRTPSink: fix memory corruption error (detected by valgrind);

Yes please - I'm very much interested in this!

> - Theora: implement RTPSink based on RFC draft (found in ffmpeg sources).

This might also be useful.  Thanks.

> - H264VideoRTPSink: apply frame duration to the last RTP packet instead of the
> first;

Are you referring to the "H264FUAFragmenter" code (that automatically fragments large NAL units into smaller NAL fragments, for transmission)?  Yes, lets see what you've done here; it might be fixing a bug.


However, I don't think I can make the other changes that you mentioned:

> - Groupsock: when a receiving interface address is defined, bind all sockets
> to it, and skip the "send to ourself a multicast packet" trick; this is to
> accomodate the situation of an RTSP server running on a machine with multiple
> interface with internet connectivity but where we want to use only one interface;

Unfortunately I don't want to remove the 'send ourself a multicast packet' trick, because it's often the only reliable way that a host can figure out its own IP address.  Note, though, that if you have multiple interfaces, and want to use one in particular, then you can do so simply by ensuring that the interface that you want is the one on which IP multicast routing is enabled - i.e., it has a route for 224/8

> - RTP/RTCP use the "feedface"/first receiver report to fix the client ports
> if NAT is running without "conntrack_rtsp";

This seems like a security risk - i.e., it would allow an attacker to send the server a bogus initial packet, in order to 'hijack' the stream's traffic.

> - MultiFrameRTPSink: implement bitrate limiting, in order to allow streaming 
> from a machine with high-speed connectivity to another machine with high-speed
> connectivity going through a path with a "weak-link" with slow connectivity
> (typically, from an internet address to my personal PC through a DSL line)

How are you figuring out that 'bitrate limiting' is needed?  By using feedback in RTCP "RR" reports (i.e., using the "RTPTransmissionStats" database)?  In any case, I don't see how this can be done in "MultiFramedRTPSink" as a general mechanism, because the choice of which outgoing packets to skip should really be codec dependent.  I.e., some frames (especially 'key' frames) are more important to send than others, and the "MultiFramedRTPSink" code - being codec independent - can't know 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/20131215/ed621f1d/attachment.html>

From gilles.chanteperdrix at xenomai.org  Sat Dec 14 09:18:22 2013
From: gilles.chanteperdrix at xenomai.org (Gilles Chanteperdrix)
Date: Sat, 14 Dec 2013 18:18:22 +0100
Subject: [Live-devel] [vlc] RTSP client in vlc 2.1
In-Reply-To: <4D9762DC-54CC-4EDF-AC27-94EF27D397AD@live555.com>
References: <52AC1BF4.7080905@xenomai.org>
 <238AAC36-B12B-48B7-84DA-90C944751920@live555.com>
 <52AC4B72.5080606@xenomai.org>
 <4D9762DC-54CC-4EDF-AC27-94EF27D397AD@live555.com>
Message-ID: <52AC92DE.2000201@xenomai.org>

On 12/14/2013 05:40 PM, Ross Finlayson wrote:
> Unfortunately we can't do this, because it breaks the subsequent
> 'optimization' - at the end of the "handleCmd_TEARDOWN()" function.
> I.e., in the normal case, when an *entire* stream is torn down (using
> either a single aggregate "TEARDOWN" command, or via individual
> "TEARDOWN"s for each track), we immediately reclaim the
> "RTSPClientSession" structure.  (I don't want to rely upon the
> 'client liveness timeout' mechanism for this, because some people
> have disabled this mechanism, to allow for (broken) RTSP clients that
> don't send RTCP "RR" packets.)

Well, it seems to me the NULL pointer can be replaced with a Boolean flag.
So that the subsession pointer remains valid, but we can know if the
track has been set up or not.

>> I have done some modifications to live555 which could be submitted
>> as patches to this list if you are interested:
> 
>> - VorbisAudioRTPSink: fix memory corruption error (detected by
>> valgrind);
> 
> Yes please - I'm very much interested in this!

The thing is: I have not very well understood the error :-). I have 
disabled the code which packs several Vorbis frames into one packet, 
and the bug disappeared... I know exactly what stream causes the bug 
though.

> 
>> - Theora: implement RTPSink based on RFC draft (found in ffmpeg
>> sources).
> 
> This might also be useful.  Thanks.

Ok, will send.

> 
>> - H264VideoRTPSink: apply frame duration to the last RTP packet
>> instead of the first;
> 
> Are you referring to the "H264FUAFragmenter" code (that automatically
> fragments large NAL units into smaller NAL fragments, for
> transmission)?  Yes, lets see what you've done here; it might be
> fixing a bug.

It is not really a bug, it is just that the server sends the first RTP
packet, then pauses for duration, then sends the remaining packets, just
before starting the next frame. The patch is very simple:

diff --git a/liveMedia/H264VideoRTPSink.cpp b/liveMedia/H264VideoRTPSink.cpp
index 574610e..4bdfba1 100644
--- a/liveMedia/H264VideoRTPSink.cpp
+++ b/liveMedia/H264VideoRTPSink.cpp
@@ -276,6 +276,7 @@ void H264FUAFragmenter::doGetNextFrame() {
     if (fCurDataOffset >= fNumValidDataBytes) {
       // We're done with this data.  Reset the pointers for receiving new data:
       fNumValidDataBytes = fCurDataOffset = 1;
+      fDurationInMicroseconds = fSavedDuration;
     }
 
     // Complete delivery to the client:
@@ -299,7 +300,7 @@ void H264FUAFragmenter::afterGettingFrame1(unsigned frameSize,
   fNumValidDataBytes += frameSize;
   fSaveNumTruncatedBytes = numTruncatedBytes;
   fPresentationTime = presentationTime;
-  fDurationInMicroseconds = durationInMicroseconds;
+  fSavedDuration = durationInMicroseconds;
 
   // Deliver data to the client:
   doGetNextFrame();


diff --git a/liveMedia/include/H264VideoRTPSink.hh b/liveMedia/include/H264VideoRTPSink.hh
index fcb2fe5..64ce7bc 100644
--- a/liveMedia/include/H264VideoRTPSink.hh
+++ b/liveMedia/include/H264VideoRTPSink.hh
@@ -108,6 +108,7 @@ private:
   unsigned fCurDataOffset;
   unsigned fSaveNumTruncatedBytes;
   Boolean fLastFragmentCompletedNALUnit;
+  unsigned fSavedDuration;
 };
 
 
> 
> 
> However, I don't think I can make the other changes that you
> mentioned:
> 
>> - Groupsock: when a receiving interface address is defined, bind
>> all sockets to it, and skip the "send to ourself a multicast
>> packet" trick; this is to accomodate the situation of an RTSP
>> server running on a machine with multiple interface with internet
>> connectivity but where we want to use only one interface;
> 
> Unfortunately I don't want to remove the 'send ourself a multicast
> packet' trick, because it's often the only reliable way that a host
> can figure out its own IP address.  Note, though, that if you have
> multiple interfaces, and want to use one in particular, then you can
> do so simply by ensuring that the interface that you want is the one
> on which IP multicast routing is enabled - i.e., it has a route for
> 224/8

The point is: if the application has set ReceivingInterfaceAddr, 
we pretty much know what is our IP address: it is ReceivingInterfaceAddr.

> 
>> - RTP/RTCP use the "feedface"/first receiver report to fix the
>> client ports if NAT is running without "conntrack_rtsp";
> 
> This seems like a security risk - i.e., it would allow an attacker to
> send the server a bogus initial packet, in order to 'hijack' the
> stream's traffic.

I tried to implement this carefully, if I receive the feedface packet
or the first receiver report on the port which was negotiated, I do not
take any other changes into account. I would have to check for RTCP.
That said, it fixes a case where the user does not receive any stream, 
so, he will not see that his session is hijacked :-).

> 
>> - MultiFrameRTPSink: implement bitrate limiting, in order to allow
>> streaming from a machine with high-speed connectivity to another
>> machine with high-speed connectivity going through a path with a
>> "weak-link" with slow connectivity (typically, from an internet
>> address to my personal PC through a DSL line)
> 
> How are you figuring out that 'bitrate limiting' is needed?  By using
> feedback in RTCP "RR" reports (i.e., using the "RTPTransmissionStats"
> database)?  In any case, I don't see how this can be done in
> "MultiFramedRTPSink" as a general mechanism, because the choice of
> which outgoing packets to skip should really be codec dependent.
> I.e., some frames (especially 'key' frames) are more important to
> send than others, and the "MultiFramedRTPSink" code - being codec
> independent - can't know this.

I am always limiting bitrate. The source gives me the limit. I have used
this patch in two contexts:
- when streaming from a file, the bitrate can be computed precisely by 
reading ahead in the file;
- when streaming from a hardware encoder configured with constant bitrate,
I set the limit to a bit above the constant bitrate.

The idea is to always spread packets in time to avoid accumulation in
intermediary network equipments. This reduces greatly the UDP packets
loss.

Regards.


-- 
                                                                Gilles.

From gilles.chanteperdrix at xenomai.org  Sat Dec 14 11:19:43 2013
From: gilles.chanteperdrix at xenomai.org (Gilles Chanteperdrix)
Date: Sat, 14 Dec 2013 20:19:43 +0100
Subject: [Live-devel] [PATCH] Add Theora RTP Sink
Message-ID: <1387048783-13405-1-git-send-email-gilles.chanteperdrix@xenomai.org>

---
 liveMedia/TheoraVideoRTPSink.cpp        |  184 +++++++++++++++++++++++++++++++
 liveMedia/include/TheoraVideoRTPSink.hh |   59 ++++++++++
 2 files changed, 243 insertions(+)
 create mode 100644 liveMedia/TheoraVideoRTPSink.cpp
 create mode 100644 liveMedia/include/TheoraVideoRTPSink.hh

diff --git a/liveMedia/TheoraVideoRTPSink.cpp b/liveMedia/TheoraVideoRTPSink.cpp
new file mode 100644
index 0000000..855b70a
--- /dev/null
+++ b/liveMedia/TheoraVideoRTPSink.cpp
@@ -0,0 +1,184 @@
+/*
+ * Theora Video RTP packetizer
+ * Copied from live555's VorbisAudioRTPSink
+ */
+
+#include "TheoraVideoRTPSink.hh"
+#include "Base64.hh"
+
+TheoraVideoRTPSink::TheoraVideoRTPSink(UsageEnvironment& env, Groupsock* RTPgs,
+				       u_int8_t rtpPayloadFormat,
+				       u_int32_t rtpTimestampFrequency,
+				       unsigned width, unsigned height, enum PixFmt pf,
+				       u_int8_t* identificationHeader, unsigned identificationHeaderSize,
+				       u_int8_t* commentHeader, unsigned commentHeaderSize,
+				       u_int8_t* setupHeader, unsigned setupHeaderSize,
+				       u_int32_t identField)
+  : VideoRTPSink(env, RTPgs, rtpPayloadFormat, rtpTimestampFrequency, "theora"),
+    fIdent(identField), fFmtpSDPLine(NULL) {
+  static const char *pf_to_str[] = {
+    "YCbCr-4:2:0",
+    "YCbCr-4:2:2",
+    "YCbCr-4:4:4",
+  };
+
+  // Create packed configuration headers, and encode this data into a "a=fmtp:" SDP line that we'll use to describe it:
+
+  // First, count how many headers (<=3) are included, and how many bytes will be used to encode these headers' sizes:
+  unsigned numHeaders = 0;
+  unsigned sizeSize[2]; // The number of bytes used to encode the lengths of the first two headers (but not the length of the 3rd)
+  sizeSize[0] = sizeSize[1] = 0;
+  if (identificationHeaderSize > 0) {
+    sizeSize[numHeaders++] = identificationHeaderSize < 128 ? 1 : identificationHeaderSize < 16384 ? 2 : 3;
+  }
+  if (commentHeaderSize > 0) {
+    sizeSize[numHeaders++] = commentHeaderSize < 128 ? 1 : commentHeaderSize < 16384 ? 2 : 3;
+  }
+  if (setupHeaderSize > 0) {
+    ++numHeaders;
+  } else {
+    sizeSize[1] = 0; // We have at most two headers, so the second one's length isn't encoded
+  }
+  if (numHeaders == 0) return; // With no headers, we can't set up a configuration
+  if (numHeaders == 1) sizeSize[0] = 0; // With only one header, its length isn't encoded
+
+  // Then figure out the size of the packed configuration headers, and allocate space for this:
+  unsigned length = identificationHeaderSize + commentHeaderSize + setupHeaderSize; // The "length" field in the packed headers
+  if (length > (unsigned)0xFFFF) return; // too big for a 16-bit field; we can't handle this
+  unsigned packedHeadersSize
+    = 4 // "Number of packed headers" field
+    + 3 // "ident" field
+    + 2 // "length" field
+    + 1 // "n. of headers" field
+    + sizeSize[0] + sizeSize[1] // "length1" and "length2" (if present) fields
+    + length;
+  u_int8_t* packedHeaders = new u_int8_t[packedHeadersSize];
+  if (packedHeaders == NULL) return;
+
+  // Fill in the 'packed headers':
+  u_int8_t* p = packedHeaders;
+  *p++ = 0; *p++ = 0; *p++ = 0; *p++ = 1; // "Number of packed headers": 1
+  *p++ = fIdent>>16; *p++ = fIdent>>8; *p++ = fIdent; // "Ident" (24 bits)
+  *p++ = length>>8; *p++ = length; // "length" (16 bits)
+  *p++ = numHeaders-1; // "n. of headers"
+  if (numHeaders > 1) {
+    // Fill in the "length1" header:
+    unsigned length1 = identificationHeaderSize > 0 ? identificationHeaderSize : commentHeaderSize;
+    if (length1 >= 16384) {
+      *p++ = 0x80; // flag, but no more, because we know length1 <= 32767
+    }
+    if (length1 >= 128) {
+      *p++ = 0x80|((length1&0x3F80)>>7); // flag + the second 7 bits
+    }
+    *p++ = length1&0x7F; // the low 7 bits
+
+    if (numHeaders > 2) { // numHeaders == 3
+      // Fill in the "length2" header (for the 'Comment' header):
+      unsigned length2 = commentHeaderSize;
+      if (length2 >= 16384) {
+	*p++ = 0x80; // flag, but no more, because we know length2 <= 32767
+      }
+      if (length2 >= 128) {
+	*p++ = 0x80|((length2&0x3F80)>>7); // flag + the second 7 bits
+      }
+      *p++ = length2&0x7F; // the low 7 bits
+    }
+  }
+  // Copy each header:
+  if (identificationHeader != NULL) memmove(p, identificationHeader, identificationHeaderSize); p += identificationHeaderSize;
+  if (commentHeader != NULL) memmove(p, commentHeader, commentHeaderSize); p += commentHeaderSize;
+  if (setupHeader != NULL) memmove(p, setupHeader, setupHeaderSize);
+
+  // Having set up the 'packed configuration headers', Base-64-encode this, and put it in our "a=fmtp:" SDP line:
+  char* base64PackedHeaders = base64Encode((char const*)packedHeaders, packedHeadersSize);
+  delete[] packedHeaders;
+
+  if (asprintf(&fFmtpSDPLine, "a=fmtp:%d sampling=%s;width=%u;height=%u;delivery-method=out_band/rtsp;configuration=%s\r\n", rtpPayloadType(), pf_to_str[pf], width, height, base64PackedHeaders) < 0)
+	  fFmtpSDPLine = NULL;
+  delete[] base64PackedHeaders;
+}
+
+TheoraVideoRTPSink::~TheoraVideoRTPSink() {
+  free(fFmtpSDPLine);
+}
+
+TheoraVideoRTPSink*
+TheoraVideoRTPSink::createNew(UsageEnvironment& env, Groupsock* RTPgs,
+			      u_int8_t rtpPayloadFormat, u_int32_t rtpTimestampFrequency,
+			      unsigned width, unsigned height, enum PixFmt pf,
+			      u_int8_t* identificationHeader, unsigned identificationHeaderSize,
+			      u_int8_t* commentHeader, unsigned commentHeaderSize,
+			      u_int8_t* setupHeader, unsigned setupHeaderSize,
+			      u_int32_t identField) {
+  return new TheoraVideoRTPSink(env, RTPgs,
+				rtpPayloadFormat, rtpTimestampFrequency,
+				width, height, pf,
+				identificationHeader, identificationHeaderSize,
+				commentHeader, commentHeaderSize,
+				setupHeader, setupHeaderSize, identField);
+}
+
+char const* TheoraVideoRTPSink::auxSDPLine() {
+  return fFmtpSDPLine;
+}
+
+void TheoraVideoRTPSink
+::doSpecialFrameHandling(unsigned fragmentationOffset,
+			 unsigned char* frameStart,
+			 unsigned numBytesInFrame,
+			 struct timeval framePresentationTime,
+			 unsigned numRemainingBytes) {
+  // Set the 4-byte "payload header", as defined in http://svn.xiph.org/trunk/theora/doc/draft-ietf-avt-rtp-theora-00.txt
+  u_int8_t header[6];
+
+  // The three bytes of the header are our "Ident":
+  header[0] = fIdent>>16; header[1] = fIdent>>8; header[2] = fIdent;
+
+  // The final byte contains the "F", "TDT", and "numPkts" fields:
+  u_int8_t F; // Fragment type
+  if (numRemainingBytes > 0) {
+    if (fragmentationOffset > 0) {
+      F = 2<<6; // continuation fragment
+    } else {
+      F = 1<<6; // start fragment
+    }
+  } else {
+    if (fragmentationOffset > 0) {
+      F = 3<<6; // end fragment
+    } else {
+      F = 0<<6; // not fragmented
+    }
+  }
+  u_int8_t const TDT = 0<<4; // Theora Data Type (always a "Raw Theora payload")
+  u_int8_t numPkts = F == 0 ? (numFramesUsedSoFar() + 1): 0; // set to 0 when we're a fragment
+  header[3] = F|TDT|numPkts;
+
+  // There's also a 2-byte 'frame-specific' header: The length of the
+  // Theora data:
+  header[4] = numBytesInFrame >>8;
+  header[5] = numBytesInFrame;
+  setSpecialHeaderBytes(header, sizeof(header));
+
+  if (numRemainingBytes == 0) {
+    // This packet contains the last (or only) fragment of the frame.
+    // Set the RTP 'M' ('marker') bit:
+    setMarkerBit();
+  }
+
+  // Important: Also call our base class's doSpecialFrameHandling(),
+  // to set the packet's timestamp:
+  MultiFramedRTPSink::doSpecialFrameHandling(fragmentationOffset,
+					     frameStart, numBytesInFrame,
+					     framePresentationTime,
+					     numRemainingBytes);
+}
+
+Boolean TheoraVideoRTPSink::frameCanAppearAfterPacketStart(unsigned char const* /*frameStart*/,
+							   unsigned /*numBytesInFrame*/) const {
+  // Only one frame per packet:
+  return False;
+}
+
+unsigned TheoraVideoRTPSink::specialHeaderSize() const {
+  return 6;
+}
diff --git a/liveMedia/include/TheoraVideoRTPSink.hh b/liveMedia/include/TheoraVideoRTPSink.hh
new file mode 100644
index 0000000..989d383
--- /dev/null
+++ b/liveMedia/include/TheoraVideoRTPSink.hh
@@ -0,0 +1,59 @@
+/*
+ * Theora Video RTP packetizer
+ * Copied from live555's VorbisAudioRTPSink
+ */
+
+#ifndef _THEORA_VIDEO_RTP_SINK_HH
+#define _THEORA_VIDEO_RTP_SINK_HH
+
+#ifndef _VIDEO_RTP_SINK_HH
+#include "VideoRTPSink.hh"
+#endif
+
+class TheoraVideoRTPSink: public VideoRTPSink {
+public:
+  enum PixFmt {
+    YUV420,
+    YUV422,
+    YUV444,
+  };
+
+  static TheoraVideoRTPSink* createNew(UsageEnvironment& env,
+				       Groupsock* RTPgs,
+				       u_int8_t rtpPayloadFormat, u_int32_t rtpTimestampFrequency,
+				       unsigned width, unsigned height, enum  PixFmt pf,
+				       // The following headers provide the 'configuration' information, for the SDP description:
+				       u_int8_t* identificationHeader, unsigned identificationHeaderSize,
+				       u_int8_t* commentHeader, unsigned commentHeaderSize,
+				       u_int8_t* setupHeader, unsigned setupHeaderSize, u_int32_t identField);
+
+protected:
+  TheoraVideoRTPSink(UsageEnvironment& env, Groupsock* RTPgs,
+		     u_int8_t rtpPayloadFormat, u_int32_t rtpTimestampFrequency,
+		     unsigned width, unsigned height, enum  PixFmt pf,
+		     u_int8_t* identificationHeader, unsigned identificationHeaderSize,
+		     u_int8_t* commentHeader, unsigned commentHeaderSize,
+		     u_int8_t* setupHeader, unsigned setupHeaderSize,
+		     u_int32_t identField);
+	// called only by createNew()
+
+  virtual ~TheoraVideoRTPSink();
+
+private: // redefined virtual functions:
+  virtual char const* auxSDPLine(); // for the "a=fmtp:" SDP line
+
+  virtual void doSpecialFrameHandling(unsigned fragmentationOffset,
+				      unsigned char* frameStart,
+				      unsigned numBytesInFrame,
+				      struct timeval framePresentationTime,
+				      unsigned numRemainingBytes);
+  virtual Boolean frameCanAppearAfterPacketStart(unsigned char const* frameStart,
+						 unsigned numBytesInFrame) const;
+  virtual unsigned specialHeaderSize() const;
+
+private:
+  u_int32_t fIdent; // "Ident" field used by this stream.  (Only the low 24 bits of this are used.)
+  char* fFmtpSDPLine;
+};
+
+#endif
-- 
1.7.10.4


From gilles.chanteperdrix at xenomai.org  Sat Dec 14 13:02:13 2013
From: gilles.chanteperdrix at xenomai.org (Gilles Chanteperdrix)
Date: Sat, 14 Dec 2013 22:02:13 +0100
Subject: [Live-devel] [vlc] RTSP client in vlc 2.1
In-Reply-To: <4D9762DC-54CC-4EDF-AC27-94EF27D397AD@live555.com>
References: <52AC1BF4.7080905@xenomai.org>
 <238AAC36-B12B-48B7-84DA-90C944751920@live555.com>
 <52AC4B72.5080606@xenomai.org>
 <4D9762DC-54CC-4EDF-AC27-94EF27D397AD@live555.com>
Message-ID: <52ACC755.5080508@xenomai.org>

On 12/14/2013 05:40 PM, Ross Finlayson wrote:
>> - RTP/RTCP use the "feedface"/first receiver report to fix the
>> client ports if NAT is running without "conntrack_rtsp";
> 
> This seems like a security risk - i.e., it would allow an attacker to
> send the server a bogus initial packet, in order to 'hijack' the
> stream's traffic.

I have checked (and changed a bit the RTCP part of the implementation),
and I believe the security risk only exists if a client is on a NAT
without conntrack_rtsp. Which means that in the case where it did not
work up to now, it now works, but the streams can be hijacked, but I
would say, it is better than nothing.

What I implemented is: between setup and play, the addresses and ports
of the packets received on the RTP socket are noted (the "feedface"
packets). At play time, we check if a packet was received for the
original address and port, if not, we look for a packet from the
original address but a different port, and if found, we use that new port.

For the RTCP, when creating RRHandlerRecord structure, we record what is
the original port for that RRHandler. When we receive a RR, we look for
the RRHandlerRecord, if found, we mark the fact that this
RRHandlerRecord was seen. If not found, it means that we got the port
wrong, so we iterate the lookup table, and look for a record with the
same address and a different port, which has either not be seen, or has
be seen but with a port different from the original port. If we find
such a record, we change the RTCP port number.

This all sounds a bit complicated, but it is not that much, and it seems
to work, and a session can not be hijacked if the ports used are the
negotiated ones.

Are you interested by this code or not?

-- 
                                                                Gilles.

From finlayson at live555.com  Sat Dec 14 17:38:56 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 15 Dec 2013 14:38:56 +1300
Subject: [Live-devel] [vlc] RTSP client in vlc 2.1
In-Reply-To: <52ACC755.5080508@xenomai.org>
References: <52AC1BF4.7080905@xenomai.org>
 <238AAC36-B12B-48B7-84DA-90C944751920@live555.com>
 <52AC4B72.5080606@xenomai.org>
 <4D9762DC-54CC-4EDF-AC27-94EF27D397AD@live555.com>
 <52ACC755.5080508@xenomai.org>
Message-ID: <257CDE0C-404C-4728-BC61-DE2514408030@live555.com>

> Are you interested by this code or not?

Yes, sure.  I'd be interested to see what you've done 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/20131215/a0f33e61/attachment.html>

From finlayson at live555.com  Sat Dec 14 22:48:09 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 15 Dec 2013 19:48:09 +1300
Subject: [Live-devel] sub-classing ProxyServerMediaSession
In-Reply-To: <52A66604.2040704@vivint.com>
References: <BAY177-W3169B51F3EBB2C5C8836AFEAD30@phx.gbl>
 <7F6C09B5-D27B-4C77-A89D-BCB9E2A64666@live555.com>
 <52A66604.2040704@vivint.com>
Message-ID: <0A80EF0A-528B-40CE-AD85-F68078427730@live555.com>


On Dec 10, 2013, at 1:53 PM, Craig Matsuura <cmatsuura at vivint.com> wrote:

> One working on sub classing ProxyServerMediaSession and also sub classing ProxyRTSPClient.  I have overridden the createNewProxyRTSPClient().  The problem I'm having is the createNewProxyRTSPClient() is called from the constructor of the ProxyServerMediaSession, and the method I just overrode is not being called.

FYI, I've just installed a new version (2013.12.15) of the "LIVE555 Streaming Media" software that changes the API for creating a new object of your "ProxyRTSPClient" subclass.

Now, you do the following:
- Define your own subclass of "ProxyRTSPClient", as before
- Define your own function
	ProxyRTSPClient* myCreateNewProxyRTSPClientFunc(ProxyServerMediaSession& ourServerMediaSession,
								char const* rtspURL,
								char const* username, char const* password,
								portNumBits tunnelOverHTTPPortNum, int verbosityLevel,
								int socketNumToServer)
  that returns a new object of your "ProxyRTSPClient" subclass.
- Define your own subclass of "ProxyServerMediaSession".
- In the constructor of your subclass of "ProxyServerMediaSession", pass your new function "myCreateNewProxyRTSPClientFunc" as the final parameter to the constructor of the parent class (i.e., "ProxyServerMediaSession").

(For more details, see "liveMedia/include/ProxyServerMediaSession.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/20131215/42d7b75f/attachment.html>

From finlayson at live555.com  Sat Dec 14 22:53:58 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 15 Dec 2013 19:53:58 +1300
Subject: [Live-devel] FYI: New option to "openRTSP" for writing new files
	periodically
Message-ID: <F5ACADAE-3AF1-4FE9-9625-9A75C218836B@live555.com>

The latest version of the "LIVE555 Streaming Media" software updates the "openRTSP" application to add a new option
	-P <interval-in-seconds>

This option tells "openRTSP" to write new output files every <interval-in-seconds> seconds.  Each output file's name will include the time range (in seconds) that it represents.

For more information, see: http://live555.com/openRTSP/#periodic-file-output

This was a "LIVE555 Funded Project"; many thanks to those who contributed.


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/20131215/dec80252/attachment.html>

From gilles.chanteperdrix at xenomai.org  Sun Dec 15 00:54:01 2013
From: gilles.chanteperdrix at xenomai.org (Gilles Chanteperdrix)
Date: Sun, 15 Dec 2013 09:54:01 +0100
Subject: [Live-devel] [PATCH] RTP/RTCP: use the packets sent by the receiver
	to
Message-ID: <1387097641-21279-1-git-send-email-gilles.chanteperdrix@xenomai.org>

correct port numbers differences due to NAT. This implementation functions
correctly, but may not be the best integration into live architecture.
---
 groupsock/NetAddress.cpp                           |   18 +++++
 groupsock/include/NetAddress.hh                    |    5 +-
 liveMedia/OnDemandServerMediaSubsession.cpp        |   69 ++++++++++++++++++--
 liveMedia/RTCP.cpp                                 |   33 ++++++++++
 liveMedia/include/OnDemandServerMediaSubsession.hh |   17 +++--
 5 files changed, 133 insertions(+), 9 deletions(-)

diff --git a/groupsock/NetAddress.cpp b/groupsock/NetAddress.cpp
index ee2e605..66832dd 100644
--- a/groupsock/NetAddress.cpp
+++ b/groupsock/NetAddress.cpp
@@ -261,6 +261,11 @@ Boolean AddressPortLookupTable::Remove(netAddressBits address1,
   return fTable->Remove((char*)key);
 }
 
+Boolean AddressPortLookupTable::IsEmpty()
+{
+  return fTable->IsEmpty();
+}
+
 AddressPortLookupTable::Iterator::Iterator(AddressPortLookupTable& table)
   : fIter(HashTable::Iterator::create(*(table.fTable))) {
 }
@@ -274,6 +279,19 @@ void* AddressPortLookupTable::Iterator::next() {
   return fIter->next(key);
 }
 
+void* AddressPortLookupTable::Iterator::next(netAddressBits &address1, 
+					netAddressBits &address2,
+					portNumBits &port)
+{
+  const char *key;
+  const int *k;
+  void *v = fIter->next(key);
+  k = (const int *)key;
+  address1 = k[0];
+  address2 = k[1];
+  port = k[2];
+  return v;
+}
 
 ////////// isMulticastAddress() implementation //////////
 
diff --git a/groupsock/include/NetAddress.hh b/groupsock/include/NetAddress.hh
index 5b47c03..21b7588 100644
--- a/groupsock/include/NetAddress.hh
+++ b/groupsock/include/NetAddress.hh
@@ -122,6 +122,7 @@ class AddressPortLookupTable {
 	void* Lookup(netAddressBits address1, netAddressBits address2,
 		     Port port);
 		// Returns 0 if not found
+	Boolean IsEmpty();
 
 	// Used to iterate through the entries in the table
 	class Iterator {
@@ -129,8 +130,10 @@ class AddressPortLookupTable {
 		Iterator(AddressPortLookupTable& table);
 		virtual ~Iterator();
 
-		void* next(); // NULL iff none
+		void *next(); // NULL iff none
 
+		void *next(netAddressBits &address1, netAddressBits &address2,
+			portNumBits &port);
 	    private:
 		HashTable::Iterator* fIter;
 	};
diff --git a/liveMedia/OnDemandServerMediaSubsession.cpp b/liveMedia/OnDemandServerMediaSubsession.cpp
index 978a965..da81a0a 100644
--- a/liveMedia/OnDemandServerMediaSubsession.cpp
+++ b/liveMedia/OnDemandServerMediaSubsession.cpp
@@ -72,6 +72,37 @@ OnDemandServerMediaSubsession::sdpLines() {
   return fSDPLines;
 }
 
+void StreamState::incomingRTP()
+{
+  struct sockaddr_in source;
+  int freei = fDestsCount;
+  unsigned i, id;
+  
+  readSocket(fRTPSink->envir(), fRTPgs->socketNum(), 
+	    (unsigned char *)&id, sizeof(id), source);
+
+  for (i = 0; i < fDestsCount; i++) {
+    if (fDests[i].addr.sin_addr.s_addr == source.sin_addr.s_addr
+	&& fDests[i].addr.sin_port == source.sin_port)
+      return;
+    if (fDests[i].addr.sin_addr.s_addr == 0)
+      freei = i;
+  }
+  i = freei;
+  if (i == fDestsCount) {
+    ++fDestsCount;
+    fDests = (struct Dests_t *)realloc(fDests, fDestsCount * sizeof(*fDests));
+  }
+  fDests[i].id = id;
+  fDests[i].addr = source;
+}
+
+static void _incomingRTP(void *instance, int)
+{
+  StreamState *stream = (StreamState *)instance;
+  stream->incomingRTP();
+}
+
 void OnDemandServerMediaSubsession
 ::getStreamParameters(unsigned clientSessionId,
 		      netAddressBits clientAddress,
@@ -177,9 +208,9 @@ void OnDemandServerMediaSubsession
   // Record these destinations as being for this client session id:
   Destinations* destinations;
   if (tcpSocketNum < 0) { // UDP
-    destinations = new Destinations(destinationAddr, clientRTPPort, clientRTCPPort);
+    destinations = new Destinations(destinationAddr, clientRTPPort, clientRTCPPort, clientSessionId);
   } else { // TCP
-    destinations = new Destinations(tcpSocketNum, rtpChannelId, rtcpChannelId);
+    destinations = new Destinations(tcpSocketNum, rtpChannelId, rtcpChannelId, clientSessionId);
   }
   fDestinationsHashTable->Add((char const*)clientSessionId, destinations);
 }
@@ -415,7 +446,12 @@ StreamState::StreamState(OnDemandServerMediaSubsession& master,
     fServerRTPPort(serverRTPPort), fServerRTCPPort(serverRTCPPort),
     fRTPSink(rtpSink), fUDPSink(udpSink), fStreamDuration(master.duration()),
     fTotalBW(totalBW), fRTCPInstance(NULL) /* created later */,
-    fMediaSource(mediaSource), fStartNPT(0.0), fRTPgs(rtpGS), fRTCPgs(rtcpGS) {
+    fMediaSource(mediaSource), fStartNPT(0.0), fRTPgs(rtpGS), fRTCPgs(rtcpGS), 
+    fDests(NULL), fDestsCount(0) {
+  
+  fRTPSink->envir().taskScheduler().setBackgroundHandling
+    (fRTPgs->socketNum(), SOCKET_READABLE|SOCKET_EXCEPTION,
+      (TaskScheduler::BackgroundHandlerProc *)_incomingRTP, this);
 }
 
 StreamState::~StreamState() {
@@ -455,7 +491,30 @@ void StreamState
   } else {
     // Tell the RTP and RTCP 'groupsocks' about this destination
     // (in case they don't already have it):
-    if (fRTPgs != NULL) fRTPgs->addDestination(dests->addr, dests->rtpPort);
+    if (fRTPgs != NULL) {
+      unsigned i;
+      for (i = 0; i < fDestsCount; i++)
+	if (dests->addr.s_addr == fDests[i].addr.sin_addr.s_addr
+	    && (dests->rtpPort.num() == fDests[i].addr.sin_port ||
+		fDests[i].id == dests->sessionId))
+	  break;
+      if (i == fDestsCount)
+	for (i = 0; i < fDestsCount; i++)
+	  if (dests->addr.s_addr == fDests[i].addr.sin_addr.s_addr)
+	    break;
+      if (i < fDestsCount) {
+	if (dests->rtpPort.num() != fDests[i].addr.sin_port) {
+	  fprintf(stderr, "Received RTP for session %x, "
+		  "with different ports, changing %hu -> %hu\n", 
+		  dests->sessionId, ntohs(dests->rtpPort.num()), 
+		  ntohs(fDests[i].addr.sin_port));
+	  dests->rtpPort = ntohs(fDests[i].addr.sin_port);
+	}
+	fDests[i].addr.sin_addr.s_addr = 0;
+      }
+
+      fRTPgs->addDestination(dests->addr, dests->rtpPort);
+    }
     if (fRTCPgs != NULL) fRTCPgs->addDestination(dests->addr, dests->rtcpPort);
     if (fRTCPInstance != NULL) {
       fRTCPInstance->setSpecificRRHandler(dests->addr.s_addr, dests->rtcpPort,
@@ -519,6 +578,7 @@ void StreamState::endPlaying(Destinations* dests) {
 }
 
 void StreamState::reclaim() {
+  fRTPSink->envir().taskScheduler().turnOffBackgroundReadHandling(fRTPgs->socketNum());
   // Delete allocated media objects
   Medium::close(fRTCPInstance) /* will send a RTCP BYE */; fRTCPInstance = NULL;
   Medium::close(fRTPSink); fRTPSink = NULL;
@@ -529,4 +589,5 @@ void StreamState::reclaim() {
 
   delete fRTPgs; fRTPgs = NULL;
   delete fRTCPgs; fRTCPgs = NULL;
+  free(fDests);
 }
diff --git a/liveMedia/RTCP.cpp b/liveMedia/RTCP.cpp
index fce4624..dfe07d3 100644
--- a/liveMedia/RTCP.cpp
+++ b/liveMedia/RTCP.cpp
@@ -169,6 +169,8 @@ RTCPInstance::RTCPInstance(UsageEnvironment& env, Groupsock* RTCPgs,
 }
 
 struct RRHandlerRecord {
+  portNumBits origPortNum;
+  Boolean seen;
   TaskFunc* rrHandlerTask;
   void* rrHandlerClientData;
 };
@@ -258,6 +260,8 @@ void RTCPInstance
   }
 
   RRHandlerRecord* rrHandler = new RRHandlerRecord;
+  rrHandler->seen = False;
+  rrHandler->origPortNum = fromPort.num();
   rrHandler->rrHandlerTask = handlerTask;
   rrHandler->rrHandlerClientData = clientData;
   if (fSpecificRRHandlerTable == NULL) {
@@ -503,9 +507,38 @@ void RTCPInstance::incomingReportHandler1() {
 	      RRHandlerRecord* rrHandler
 		= (RRHandlerRecord*)(fSpecificRRHandlerTable->Lookup(fromAddr, (~0), fromPort));
 	      if (rrHandler != NULL) {
+		rrHandler->seen = True;
 		if (rrHandler->rrHandlerTask != NULL) {
 		  (*(rrHandler->rrHandlerTask))(rrHandler->rrHandlerClientData);
 		}
+	      } else if (tcpReadStreamSocketNum < 0 && !fIsSSMSource && 
+			!fSpecificRRHandlerTable->IsEmpty()) {
+		AddressPortLookupTable::Iterator i = *fSpecificRRHandlerTable;
+		netAddressBits a1, a2;
+		portNumBits p;
+		while(1) {
+		  RRHandlerRecord *r = (RRHandlerRecord *)i.next(a1, a2, p);
+		  if (r == NULL)
+		    break;
+		  if (a1 != fromAddr)
+		    continue;
+		  if (r->seen && p == r->origPortNum)
+		    continue;
+		  fSpecificRRHandlerTable->Remove(a1, a2, ntohs(p));
+		  fSpecificRRHandlerTable->Add(a1, (~0), fromPort, r);
+
+		  struct in_addr ia1;
+		  ia1.s_addr = a1;
+		  RTCPgs()->removeDestination(ia1, ntohs(p));
+		  RTCPgs()->addDestination(ia1, fromPort);
+		  fprintf(stderr, "RTCP, changing port from %hu to %hu\n",
+			ntohs(p), fromPortNum);
+
+		  r->seen = True;
+		  if (r->rrHandlerTask != NULL)
+		    (*(r->rrHandlerTask))(r->rrHandlerClientData);
+		  break;
+		}
 	      }
 	    }
 
diff --git a/liveMedia/include/OnDemandServerMediaSubsession.hh b/liveMedia/include/OnDemandServerMediaSubsession.hh
index bdfc228..dbd8aa2 100644
--- a/liveMedia/include/OnDemandServerMediaSubsession.hh
+++ b/liveMedia/include/OnDemandServerMediaSubsession.hh
@@ -121,12 +121,14 @@ class Destinations {
 public:
   Destinations(struct in_addr const& destAddr,
                Port const& rtpDestPort,
-               Port const& rtcpDestPort)
-    : isTCP(False), addr(destAddr), rtpPort(rtpDestPort), rtcpPort(rtcpDestPort) {
+	      Port const& rtcpDestPort, unsigned sessionId)
+    : isTCP(False), addr(destAddr), rtpPort(rtpDestPort), rtcpPort(rtcpDestPort),
+      sessionId(sessionId) {
   }
-  Destinations(int tcpSockNum, unsigned char rtpChanId, unsigned char rtcpChanId)
+  Destinations(int tcpSockNum, unsigned char rtpChanId, unsigned char rtcpChanId, unsigned sessionId)
     : isTCP(True), rtpPort(0) /*dummy*/, rtcpPort(0) /*dummy*/,
-      tcpSocketNum(tcpSockNum), rtpChannelId(rtpChanId), rtcpChannelId(rtcpChanId) {
+      tcpSocketNum(tcpSockNum), rtpChannelId(rtpChanId), 
+      rtcpChannelId(rtcpChanId), sessionId(sessionId) {
   }
 
 public:
@@ -136,6 +138,7 @@ public:
   Port rtcpPort;
   int tcpSocketNum;
   unsigned char rtpChannelId, rtcpChannelId;
+  unsigned sessionId;
 };
 
 class StreamState {
@@ -154,6 +157,7 @@ public:
   void pause();
   void endPlaying(Destinations* destinations);
   void reclaim();
+  void incomingRTP();
 
   unsigned& referenceCount() { return fReferenceCount; }
 
@@ -186,6 +190,11 @@ private:
 
   Groupsock* fRTPgs;
   Groupsock* fRTCPgs;
+  struct Dests_t {
+    unsigned id;
+    struct sockaddr_in addr;
+  } *fDests;
+  unsigned fDestsCount;
 };
 
 #endif
-- 
1.7.10.4


From bbischan at watchtower-security.com  Sun Dec 15 08:29:50 2013
From: bbischan at watchtower-security.com (Bob Bischan)
Date: Sun, 15 Dec 2013 10:29:50 -0600
Subject: [Live-devel] ProxyServer (Proposed Option)
In-Reply-To: <4F8B98D5-7898-4E31-A938-826F60C8124B@live555.com>
References: <CACv1yZ9CX=k-_RLnErCoFMDHxub3nuJu=VeeY39s1=V4-eU+pQ@mail.gmail.com>
 <4F8B98D5-7898-4E31-A938-826F60C8124B@live555.com>
Message-ID: <CACv1yZ_z6JWsbQKkUCBxqaaK_0fXPmCWWhHo=gabWB-vt21Jdg@mail.gmail.com>

Ross,

Thanks for the feedback on this topic. It helps knowing what is or is not
possible given the current implementation...I would have spent unnecessary
time and effort pursuing this functionality.

Bob


On Fri, Dec 13, 2013 at 6:05 PM, Ross Finlayson <finlayson at live555.com>wrote:

> Have an option for PorxyServer to send a SET_PARAMETER command with a user
> defined message in the body to an existing back-end server whenever a new
> client connection is initiated with a ProxyServer stream.
>
>
> No, this isn't possible with the current proxy server implementation,
> because the proxy server code has no knowledge of any front-end client
> connections (other than the first), nor any front-end client disconnections
> (other than the last).
>
> 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/20131215/dfc71b58/attachment.html>

From finlayson at live555.com  Sun Dec 15 23:01:31 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 16 Dec 2013 20:01:31 +1300
Subject: [Live-devel] What is the preferred way of terminating an RTSP
	server connection
In-Reply-To: <CAA1YYezkFBtpnwBYWGDY430_haFXBW0JaSRiCM8-5wtiSHRvEQ@mail.gmail.com>
References: <CAA1YYewoR13qMA3mT3Q_H8NoE7LTPFVvXEbHQV_BTcO45U80hw@mail.gmail.com>
 <C7559139-CAB3-488A-96F6-D9921845990C@live555.com>
 <CAA1YYew8sdaXnMik66YPgacSO9=685U3KqDLbca3D=YYcSZsfg@mail.gmail.com>
 <CE75E3D4-C0C1-4BC9-8C49-976820898183@live555.com>
 <CAA1YYezkFBtpnwBYWGDY430_haFXBW0JaSRiCM8-5wtiSHRvEQ@mail.gmail.com>
Message-ID: <12B056B9-0403-4C4F-9173-076887643C6E@live555.com>

> The given setup is this: I have a video server and an rstp server. Clients request a particular video stream from the rtsp server. The rtsp server then request that stream from the video server and sends incoming frames to the client. There's also a controller application. This application gets information from the rtsp server and uses that to instruct the client application to get particular video. If the client should not retrieve video anymore, the controller instructs the client for that. If the controller can not reach the client to stop streaming it needs to tell the server to stop streaming. Although this is not normal usage it is very important that the video stream is stopped.

Because this is a custom server application, it's probably not something that I can help you with for free on this mailing list.  Sorry.

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/20131216/b28492c4/attachment.html>

From fantasyvideo at 126.com  Wed Dec 11 01:44:43 2013
From: fantasyvideo at 126.com (Tony)
Date: Wed, 11 Dec 2013 17:44:43 +0800 (CST)
Subject: [Live-devel] Regarding two video streams in live555
Message-ID: <38785b1c.a704.142e10b4d47.Coremail.fantasyvideo@126.com>

HI,
I need to put two video streams and one audio stream in one rtsp session.
I add the stream by creating subsession, but I found that the two video stream can't play correctly, sometimes one stream would stop  or two streams stopped too.
Is there any setting to set it ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131211/912a20b2/attachment.html>

From richard.l at live.cn  Wed Dec 11 19:37:53 2013
From: richard.l at live.cn (=?gb2312?B?wdbTwNXC?=)
Date: Thu, 12 Dec 2013 03:37:53 +0000
Subject: [Live-devel] How to read a file with ".mp4" ext name and transport
 it via RTP using Live555 ?
Message-ID: <BAY177-W6C1E1DC4FAA0F815CEF63EADC0@phx.gbl>


I want to read a ".mp4" file, and transfer it to stream format, transport it to client via RTP. Also include the decode(client endpoint) progress. I found the LIVE555 only support ".m4e" and ".264". 
 
Please guys, tell me how can I use LIVE555 to do my job ? Thanks in advance ! 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131212/e68e7e5f/attachment.html>

From cmatsuura at vivint.com  Wed Dec 11 23:59:56 2013
From: cmatsuura at vivint.com (Craig Matsuura)
Date: Thu, 12 Dec 2013 00:59:56 -0700
Subject: [Live-devel] pass authentication from uri from the proxy to my
	rtspservers?
In-Reply-To: <A53CE4B6-1AFE-4E4C-90C3-B11BC045B9B0@live555.com>
References: <52a8540a3f95_@_imoxion.com>
 <A53CE4B6-1AFE-4E4C-90C3-B11BC045B9B0@live555.com>
Message-ID: <52A96CFC.8080405@vivint.com>

I want to use the proxy server to connect to cameras in my system.
However I want to pass the user:password
from the url used to access the cameras via the proxy. For example:

If using live555proxyServer and I have a camera stream proxied via the
proxyServer. The stream has some user:password that I want to pass from
the proxied url.

My camera url is rtsp://user:pass at xx.yy.zz.aa:554/Video-0

Instead of providing the user:pass I want to do it at runtime when using
the url from the proxy.

Say the proxy says to use rtsp://1.2.3.4:554/Video, I want to use a
client that provides the user:pass to the url. Like so.

rtsp://user:pass at 1.2.3.4:554/video and the user:pass is passed on to the
rtsp://user:pass at xx.yy.zz.aa:554/Video-0

I know you can provide the user/pass on a commandline. But I want to do
it run time from the url. What can I change or where can I access the
user:pass from the url in the RTSPServer?

Thanks,
Craig



From gilles.chanteperdrix at xenomai.org  Mon Dec 16 01:22:20 2013
From: gilles.chanteperdrix at xenomai.org (Gilles Chanteperdrix)
Date: Mon, 16 Dec 2013 10:22:20 +0100
Subject: [Live-devel] How to read a file with ".mp4" ext name and
 transport it via RTP using Live555 ?
In-Reply-To: <BAY177-W6C1E1DC4FAA0F815CEF63EADC0@phx.gbl>
References: <BAY177-W6C1E1DC4FAA0F815CEF63EADC0@phx.gbl>
Message-ID: <52AEC64C.6030901@xenomai.org>

On 12/12/2013 04:37 AM, ??? wrote:
> 
> I want to read a ".mp4" file, and transfer it to stream format, transport it to client via RTP. Also include the decode(client endpoint) progress. I found the LIVE555 only support ".m4e" and ".264". 
>  
> Please guys, tell me how can I use LIVE555 to do my job ? Thanks in advance ! 		 	   		  

Just rename the file to .mov

-- 
                                                                Gilles.

From finlayson at live555.com  Mon Dec 16 01:39:05 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 16 Dec 2013 22:39:05 +1300
Subject: [Live-devel] Framerate in the file is 4X the original
In-Reply-To: <532656B720FE4E48A88D9D98B1194166BBD04410@VOITV-EXCH-BE02.transas.com>
References: <532656B720FE4E48A88D9D98B1194166BBD04410@VOITV-EXCH-BE02.transas.com>
Message-ID: <C9C01096-1250-40FD-959C-58ED55074064@live555.com>

> I stream the video from the camera, and in the resulting file framerate is 4X the original.
> Eg. camera provides 30 FPS, in the file I get around 120, which results in "slow-mo" playback.
>  
> Tried to save .avi, .mp4, .mov using openRTSP, same thing.
> Kindly advise, where to look, what to check.

The implementation of the "QuickTimeFileSink" class.


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/20131216/8ad07796/attachment-0001.html>

From finlayson at live555.com  Mon Dec 16 01:44:51 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 16 Dec 2013 22:44:51 +1300
Subject: [Live-devel] How to read a file with ".mp4" ext name and
	transport it via RTP using Live555 ?
In-Reply-To: <BAY177-W6C1E1DC4FAA0F815CEF63EADC0@phx.gbl>
References: <BAY177-W6C1E1DC4FAA0F815CEF63EADC0@phx.gbl>
Message-ID: <4C154288-1093-46F7-B462-F48A5AD5AE30@live555.com>

> I want to read a ".mp4" file, and transfer it to stream format, transport it to client via RTP. Also include the decode(client endpoint) progress. I found the LIVE555 only support ".m4e" and ".264". 

No, we also support streaming from Matroska files - i.e., ".mkv" and ".webm" files.

> Please guys, tell me how can I use LIVE555 to do my job ?

You can't.  We don't (and don't have any plans to) support streaming from ".mp4" or ".mov" files.

See also:	http://lists.live555.com/pipermail/live-devel/2013-September/017424.html

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/20131216/8ed8f2ee/attachment.html>

From bbischan at watchtower-security.com  Mon Dec 16 08:57:10 2013
From: bbischan at watchtower-security.com (Bob Bischan)
Date: Mon, 16 Dec 2013 10:57:10 -0600
Subject: [Live-devel] ProxyServer (Quicktime Plugin Causes Crash)
Message-ID: <CACv1yZ8zBiStBetVGufbYybP02a=QKmxtJgD3yn4eRcTZiu3SQ@mail.gmail.com>

I have been testing Quicktime Web plugin for viewing streams from
ProxyServer. There appears to be an issue with this plugin that can cause a
crash of ProxyServer.

The test is being performed using the latest live555 (v2013.12.15) and is
only occurring when using Quicktime Plugin 7.7.4 with google chrome on
Windows 7. I am NOT able to reproduce this problem using IE.

Problems with Quicktime have already been noted on this mailing list, so
I'm passing on my findings for info only and to maybe illustrate a
misbehaving client scenario that may need to be considered for exception
handling.

What I have observed is that initial connection and playing of a stream
from ProxyServer works fine, however, if the browser is refreshed while
playing,  ProxyServer crashes. The debug output suggests that a TEARDOWN is
sent to ProxyServer and then immediately after a PAUSE for the same session
id. At this point Proxy crashes. There is also some debug output that shows
transport negotiation that may be part of the problem.

I have attached debug output for review. Any input or suggestions for
troubleshooting this problem is appreciated.


Thanks,

Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131216/844110da/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug.out
Type: application/octet-stream
Size: 24083 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131216/844110da/attachment-0001.obj>

From finlayson at live555.com  Mon Dec 16 13:08:48 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 17 Dec 2013 10:08:48 +1300
Subject: [Live-devel] ProxyServer (Quicktime Plugin Causes Crash)
In-Reply-To: <CACv1yZ8zBiStBetVGufbYybP02a=QKmxtJgD3yn4eRcTZiu3SQ@mail.gmail.com>
References: <CACv1yZ8zBiStBetVGufbYybP02a=QKmxtJgD3yn4eRcTZiu3SQ@mail.gmail.com>
Message-ID: <76298401-288F-4CC3-8BF2-C1D4410DD15B@live555.com>

Bob,

Thanks for the report.  It was able to help be find and fix a bug in the RTSP server code.

The problem was that the code was not properly handling pipelined requests (in this case, a "PAUSE" followed by a "TEARDOWN") that were being sent Base64-encoded over a RTSP-over-HTTP connection.  (Also, the second pipelined command ("TEARDOWN") happened to (erroneously) start with a NUL character; we now skip over that.)

I've just installed a new version - 2012.12.16 - that should fix 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/20131217/246376f9/attachment.html>

From gilles.chanteperdrix at xenomai.org  Mon Dec 16 13:33:56 2013
From: gilles.chanteperdrix at xenomai.org (Gilles Chanteperdrix)
Date: Mon, 16 Dec 2013 22:33:56 +0100
Subject: [Live-devel] [PATCH] RTSPClient: resend dummy packets when sending
	a per-track PLAY command
Message-ID: <1387229636-5818-1-git-send-email-gilles.chanteperdrix@xenomai.org>

---
 liveMedia/RTSPClient.cpp |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/liveMedia/RTSPClient.cpp b/liveMedia/RTSPClient.cpp
index 77efefd..3e0a42a 100644
--- a/liveMedia/RTSPClient.cpp
+++ b/liveMedia/RTSPClient.cpp
@@ -74,6 +74,15 @@ unsigned RTSPClient::sendPlayCommand(MediaSession& session, responseHandler* res
 unsigned RTSPClient::sendPlayCommand(MediaSubsession& subsession, responseHandler* responseHandler,
                                      double start, double end, float scale,
                                      Authenticator* authenticator) {
+      Groupsock* gs1 = NULL; Groupsock* gs2 = NULL;
+      if (subsession.rtpSource() != NULL) gs1 = subsession.rtpSource()->RTPgs();
+      if (subsession.rtcpInstance() != NULL) gs2 = subsession.rtcpInstance()->RTCPgs();
+      u_int32_t const dummy = 0xFEEDFACE;
+      unsigned const numDummyPackets = 2;
+      for (unsigned i = 0; i < numDummyPackets; ++i) {
+	if (gs1 != NULL) gs1->output(envir(), 255, (unsigned char*)&dummy, sizeof dummy);
+	if (gs2 != NULL) gs2->output(envir(), 255, (unsigned char*)&dummy, sizeof dummy);
+      }
   if (authenticator != NULL) fCurrentAuthenticator = *authenticator;
   return sendRequest(new RequestRecord(++fCSeq, "PLAY", responseHandler, NULL, &subsession, 0, start, end, scale));
 }
-- 
1.7.10.4


From bbischan at watchtower-security.com  Mon Dec 16 15:15:17 2013
From: bbischan at watchtower-security.com (Bob Bischan)
Date: Mon, 16 Dec 2013 17:15:17 -0600
Subject: [Live-devel] ProxyServer (Quicktime Plugin Causes Crash)
In-Reply-To: <76298401-288F-4CC3-8BF2-C1D4410DD15B@live555.com>
References: <CACv1yZ8zBiStBetVGufbYybP02a=QKmxtJgD3yn4eRcTZiu3SQ@mail.gmail.com>
 <76298401-288F-4CC3-8BF2-C1D4410DD15B@live555.com>
Message-ID: <CACv1yZ9MhvuAVMd1azD96GqZ65L3ixwB8CWwSBFikV2_0bqcUw@mail.gmail.com>

So far, no problems running on 2013.12.16. Problem appears fixed!

Thanks,

Bob


On Mon, Dec 16, 2013 at 3:08 PM, Ross Finlayson <finlayson at live555.com>wrote:

> Bob,
>
> Thanks for the report.  It was able to help be find and fix a bug in the
> RTSP server code.
>
> The problem was that the code was not properly handling pipelined requests
> (in this case, a "PAUSE" followed by a "TEARDOWN") that were being sent
> Base64-encoded over a RTSP-over-HTTP connection.  (Also, the second
> pipelined command ("TEARDOWN") happened to (erroneously) start with a NUL
> character; we now skip over that.)
>
> I've just installed a new version - 2012.12.16 - that should fix 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/20131216/45b3e767/attachment.html>

From bbischan at watchtower-security.com  Tue Dec 17 07:32:22 2013
From: bbischan at watchtower-security.com (Bob Bischan)
Date: Tue, 17 Dec 2013 09:32:22 -0600
Subject: [Live-devel] FYI: New option to "openRTSP" for writing new
	files periodically
In-Reply-To: <F5ACADAE-3AF1-4FE9-9625-9A75C218836B@live555.com>
References: <F5ACADAE-3AF1-4FE9-9625-9A75C218836B@live555.com>
Message-ID: <CACv1yZ_58_SbB29-ENg1Fs+ziRpBPsUBnThhNZoF-x3y_vxBYg@mail.gmail.com>

Ross,

Very nice addition to the  "LIVE555 Streaming Media" software ! A quick
test reveals that it works just as anticipated.

I do have a few related comments / suggestions regarding this option, as
well, as openRTSP in general. Your thoughts and input would be much
appreciated.

*File naming convention and output options:*

Would it be possible to add options to openRTSP that provide a flexible
mechanism for specifying file-naming and storage location using a
combination of format specifiers / existing options?

Example Usage:

base_storage_path = /mnt/video
file_output_path =
<base-storage-path>/<stream-suffix>/YYYYMMDD/YYYYMMDD-HHMMSS.mp4
 (.mov,.mkv,.ts....etc)

<stream-suffix> could maybe be a unique_id from a database table of streams
and be supplied when REGISTERING a client.

*Is the Periodic File output option intended to work with -R ?*

I am planning on testing this use case, but there are numerous openRTSP
options and combinations of options that will take some time to evaluate.
Thought it may save some time to simply ask :-)


*Is the  -F <fileName-prefix> option intended to work with all file output
types?  *

I have done a few quick tests and have not seen this work. Again, I will be
be re-verifying my results, but thought I would ask.


Thanks,

Bob





On Sun, Dec 15, 2013 at 12:53 AM, Ross Finlayson <finlayson at live555.com>wrote:

> The latest version of the "LIVE555 Streaming Media" software updates the
> "openRTSP" application to add a new option
> -P <interval-in-seconds>
>
> This option tells "openRTSP" to write new output files every
> <interval-in-seconds> seconds.  Each output file's name will include the
> time range (in seconds) that it represents.
>
> For more information, see:
> http://live555.com/openRTSP/#periodic-file-output
>
> This was a "LIVE555 Funded Project"; many thanks to those who contributed.
>
>
> 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/20131217/6a9afdd5/attachment.html>

From julien at nomadsystems.com.au  Tue Dec 17 08:25:32 2013
From: julien at nomadsystems.com.au (julien@nomadsystems)
Date: Tue, 17 Dec 2013 17:25:32 +0100
Subject: [Live-devel] FYI: New option to "openRTSP" for writing new
 files periodically
In-Reply-To: <CACv1yZ_58_SbB29-ENg1Fs+ziRpBPsUBnThhNZoF-x3y_vxBYg@mail.gmail.com>
References: <F5ACADAE-3AF1-4FE9-9625-9A75C218836B@live555.com>
 <CACv1yZ_58_SbB29-ENg1Fs+ziRpBPsUBnThhNZoF-x3y_vxBYg@mail.gmail.com>
Message-ID: <52B07AFC.2040000@nomadsystems.com.au>

Excellent addition indeed. I've seen so many people requesting this 
feature that it became a must.

As per the "File naming convention and output options", the simpler the 
better. You can always rename and move things around through scripting 
in a later stage, but that's just me.

On Tuesday, 17 December 2013 4:32:22 PM, Bob Bischan wrote:
> Ross,
>
> Very nice addition to the  "LIVE555 Streaming Media" software ! A
> quick test reveals that it works just as anticipated.
>
> I do have a few related comments / suggestions regarding this option,
> as well, as openRTSP in general. Your thoughts and input would be much
> appreciated.
>
> *File naming convention and output options:*
> *
> *
> Would it be possible to add options to openRTSP that provide a
> flexible mechanism for specifying file-naming and storage location
> using a combination of format specifiers / existing options?
>
> Example Usage:
>
> base_storage_path = /mnt/video
> file_output_path =
> <base-storage-path>/<stream-suffix>/YYYYMMDD/YYYYMMDD-HHMMSS.mp4
>  (.mov,.mkv,.ts....etc)
>
> <stream-suffix> could maybe be a unique_id from a database table of
> streams and be supplied when REGISTERING a client.
>
> *Is the Periodic File output option intended to work with -R ?*
> *
> *
> I am planning on testing this use case, but there are numerous
> openRTSP options and combinations of options that will take some time
> to evaluate. Thought it may save some time to simply ask :-)
>
>
> *Is the  -F <fileName-prefix> option intended to work with all file
> output types? *
>
> I have done a few quick tests and have not seen this work. Again, I
> will be be re-verifying my results, but thought I would ask.
>
>
> Thanks,
>
> Bob
>
>
>
>
>
> On Sun, Dec 15, 2013 at 12:53 AM, Ross Finlayson
> <finlayson at live555.com <mailto:finlayson at live555.com>> wrote:
>
>     The latest version of the "LIVE555 Streaming Media" software
>     updates the "openRTSP" application to add a new option
>     -P <interval-in-seconds>
>
>     This option tells "openRTSP" to write new output files every
>     <interval-in-seconds> seconds.  Each output file's name will
>     include the time range (in seconds) that it represents.
>
>     For more information, see:
>     http://live555.com/openRTSP/#periodic-file-output
>
>     This was a "LIVE555 Funded Project"; many thanks to those who
>     contributed.
>
>
>     Ross Finlayson
>     Live Networks, Inc.
>     http://www.live555.com/
>
>
>     _______________________________________________
>     live-devel mailing list
>     live-devel at lists.live555.com <mailto:live-devel at lists.live555.com>
>     http://lists.live555.com/mailman/listinfo/live-devel
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

From robson.nunes at fazion.com.br  Tue Dec 17 06:03:33 2013
From: robson.nunes at fazion.com.br (Robson Nunes)
Date: Tue, 17 Dec 2013 12:03:33 -0200
Subject: [Live-devel] Problems to capture a RTSP
Message-ID: <003101cefb30$c6955340$53bff9c0$@fazion.com.br>

Dear Sir, I'm having problems to capture a RTSP stream (using API LIVE555)
from a camera model ZAVIO F3110 that can be acessed through
rtsp://186.215.116.89:554/pro1.

With the same code I can acess a PELCO camera, but cannot access that ZAVIO.


With the VLC Player though, I can access the same ZAVIO. 

Can someone help me or give me some kind of hint?

 

NOTE: Code used in Annex.

 

 

 

Att

 

 

_______________________________________
Robson Lopes Nunes | Coordenador T?cnico de Sistemas

FAZION 
+55 (48) 3025-5617 
 <mailto:robson.nunes at fazion.com.br> robson.nunes at fazion.com.br
 <http://www.fazion.com.br/> www.fazion.com.br

 <http://www.mobifaz.com/> www.mobifaz.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131217/343d37ca/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libStream.zip
Type: application/x-zip-compressed
Size: 445824 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131217/343d37ca/attachment-0001.bin>

From finlayson at live555.com  Tue Dec 17 10:23:25 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Dec 2013 07:23:25 +1300
Subject: [Live-devel] Problems to capture a RTSP
In-Reply-To: <003101cefb30$c6955340$53bff9c0$@fazion.com.br>
References: <003101cefb30$c6955340$53bff9c0$@fazion.com.br>
Message-ID: <55E373EE-EC86-4E52-9BC1-64BFA23D11A6@live555.com>

> Dear Sir, I'm having problems to capture a RTSP stream (using API LIVE555) from a camera model ZAVIO F3110 that can be acessed through rtsp://186.215.116.89:554/pro1.
> With the same code I can acess a PELCO camera, but cannot access that ZAVIO.
> With the VLC Player though, I can access the same ZAVIO.
> Can someone help me or give me some kind of hint?

I was able to successfully access this stream using either "openRTSP" or "testRTSPClient".

I suspect, however, that you are trying to access the stream using a client application that is behind a firewall that blocks RTP/UDP packets.  To correct this, either fix your firewall, or request RTP-over-TCP streaming.

See http://www.live555.com/liveMedia/faq.html#openRTSP-empty-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/20131218/cde621d8/attachment.html>

From finlayson at live555.com  Tue Dec 17 10:45:46 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Dec 2013 07:45:46 +1300
Subject: [Live-devel] FYI: New option to "openRTSP" for writing new
	files periodically
In-Reply-To: <CACv1yZ_58_SbB29-ENg1Fs+ziRpBPsUBnThhNZoF-x3y_vxBYg@mail.gmail.com>
References: <F5ACADAE-3AF1-4FE9-9625-9A75C218836B@live555.com>
 <CACv1yZ_58_SbB29-ENg1Fs+ziRpBPsUBnThhNZoF-x3y_vxBYg@mail.gmail.com>
Message-ID: <AFC2D912-4098-45CA-8D1C-DF4CFD51E2C4@live555.com>

> File naming convention and output options:
> 
> Would it be possible to add options to openRTSP that provide a flexible mechanism for specifying file-naming and storage location using a combination of format specifiers / existing options? 

It would certainly be 'possible', but it would make an already complex program even more complex.  Remember that "openRTSP" is intended to be used by sophisticated users who know how to - if necessary - use shell scripts (or even customize the source code if necessary).


> Is the Periodic File output option intended to work with -R ?

Yes.  I know of no reason why this won't work.


> Is the  -F <fileName-prefix> option intended to work with all file output types?  

It *was* intended to, but I discovered that it currently doesn't work with the "-q", "-4", or "-i" options (i.e., for generating ".mov", ".mp4", or ".avi" files).  This will be fixed 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/20131218/547b57b3/attachment.html>

From finlayson at live555.com  Tue Dec 17 10:49:13 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Dec 2013 07:49:13 +1300
Subject: [Live-devel] FYI: New option to "openRTSP" for writing new
	files periodically
In-Reply-To: <52B07AFC.2040000@nomadsystems.com.au>
References: <F5ACADAE-3AF1-4FE9-9625-9A75C218836B@live555.com>
 <CACv1yZ_58_SbB29-ENg1Fs+ziRpBPsUBnThhNZoF-x3y_vxBYg@mail.gmail.com>
 <52B07AFC.2040000@nomadsystems.com.au>
Message-ID: <045FBE78-3184-41FA-84B9-62F69E1C8185@live555.com>

> Excellent addition indeed. I've seen so many people requesting this feature that it became a must.

There's nothing in this software that's a "must".  Please don't ever forget that this software (and the support in this mailing list) is provided - for free - as an optional and voluntary service.  Providing free software (and support) is not our business model :-)


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/20131218/3ae1e591/attachment.html>

From robson.nunes at fazion.com.br  Tue Dec 17 11:00:12 2013
From: robson.nunes at fazion.com.br (Robson Nunes)
Date: Tue, 17 Dec 2013 17:00:12 -0200
Subject: [Live-devel] RES:  Problems to capture a RTSP
In-Reply-To: <55E373EE-EC86-4E52-9BC1-64BFA23D11A6@live555.com>
References: <003101cefb30$c6955340$53bff9c0$@fazion.com.br>
 <55E373EE-EC86-4E52-9BC1-64BFA23D11A6@live555.com>
Message-ID: <000601cefb5a$37971640$a6c542c0$@fazion.com.br>

Good afternoon Mr. Finlayson, thanks for responding, but I've verified the
firewall 3 times already, executed TELNET on port 554 and seems ok. Through
VLC works nicely, but not on the application. I'm trying to configure a new
project to run the playCommon.cpp and testRTSPClient.cpp, but i'm not being
able to make it on Visual Studio 2012. Could you help me out, please?

 

Best Regards

 

De: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] Em nome de Ross Finlayson
Enviada em: ter?a-feira, 17 de dezembro de 2013 16:23
Para: LIVE555 Streaming Media - development & use
Assunto: Re: [Live-devel] Problems to capture a RTSP

 

Dear Sir, I'm having problems to capture a RTSP stream (using API LIVE555)
from a camera model ZAVIO F3110 that can be acessed through
<rtsp://186.215.116.89:554/pro1> rtsp://186.215.116.89:554/pro1.

With the same code I can acess a PELCO camera, but cannot access that ZAVIO.

With the VLC Player though, I can access the same ZAVIO.

Can someone help me or give me some kind of hint?

 

I was able to successfully access this stream using either "openRTSP" or
"testRTSPClient".

 

I suspect, however, that you are trying to access the stream using a client
application that is behind a firewall that blocks RTP/UDP packets.  To
correct this, either fix your firewall, or request RTP-over-TCP streaming.

 

See http://www.live555.com/liveMedia/faq.html#openRTSP-empty-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/20131217/9a02f2ce/attachment.html>

From cmatsuura at vivint.com  Tue Dec 17 07:57:10 2013
From: cmatsuura at vivint.com (Craig Matsuura)
Date: Tue, 17 Dec 2013 08:57:10 -0700
Subject: [Live-devel] sub-classing ProxyServerMediaSession
In-Reply-To: <0A80EF0A-528B-40CE-AD85-F68078427730@live555.com>
References: <BAY177-W3169B51F3EBB2C5C8836AFEAD30@phx.gbl>
 <7F6C09B5-D27B-4C77-A89D-BCB9E2A64666@live555.com>
 <52A66604.2040704@vivint.com>
 <0A80EF0A-528B-40CE-AD85-F68078427730@live555.com>
Message-ID: <52B07456.9080509@vivint.com>

Is there a reason DEBUG is left on in RTSPServer.cpp?

#include <GroupsockHelper.hh>

#define DEBUG 1 //#####@@@@@
////////// RTSPServer implementation //////////

RTSPServer*
RTSPServer::createNew(UsageEnvironment& env, Port ourPort,

Thanks,
Craig

On 12/14/2013 11:48 PM, Ross Finlayson wrote:

On Dec 10, 2013, at 1:53 PM, Craig Matsuura <cmatsuura at vivint.com<mailto:cmatsuura at vivint.com>> wrote:

One working on sub classing ProxyServerMediaSession and also sub classing ProxyRTSPClient.  I have overridden the createNewProxyRTSPClient().  The problem I'm having is the createNewProxyRTSPClient() is called from the constructor of the ProxyServerMediaSession, and the method I just overrode is not being called.

FYI, I've just installed a new version (2013.12.15) of the "LIVE555 Streaming Media" software that changes the API for creating a new object of your "ProxyRTSPClient" subclass.

Now, you do the following:
- Define your own subclass of "ProxyRTSPClient", as before
- Define your own function
ProxyRTSPClient* myCreateNewProxyRTSPClientFunc(ProxyServerMediaSession& ourServerMediaSession,
char const* rtspURL,
char const* username, char const* password,
portNumBits tunnelOverHTTPPortNum, int verbosityLevel,
int socketNumToServer)
  that returns a new object of your "ProxyRTSPClient" subclass.
- Define your own subclass of "ProxyServerMediaSession".
- In the constructor of your subclass of "ProxyServerMediaSession", pass your new function "myCreateNewProxyRTSPClientFunc" as the final parameter to the constructor of the parent class (i.e., "ProxyServerMediaSession").

(For more details, see "liveMedia/include/ProxyServerMediaSession.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/20131217/55bcc7e2/attachment-0001.html>

From finlayson at live555.com  Tue Dec 17 11:25:43 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Dec 2013 08:25:43 +1300
Subject: [Live-devel] sub-classing ProxyServerMediaSession
In-Reply-To: <52B07456.9080509@vivint.com>
References: <BAY177-W3169B51F3EBB2C5C8836AFEAD30@phx.gbl>
 <7F6C09B5-D27B-4C77-A89D-BCB9E2A64666@live555.com>
 <52A66604.2040704@vivint.com>
 <0A80EF0A-528B-40CE-AD85-F68078427730@live555.com>
 <52B07456.9080509@vivint.com>
Message-ID: <694D5D77-68AA-4EBD-8E1E-0445A227469D@live555.com>


On Dec 18, 2013, at 4:57 AM, Craig Matsuura <cmatsuura at vivint.com> wrote:

> Is there a reason DEBUG is left on in RTSPServer.cpp?

It was a mistake; fixed now.  Thanks for letting us know.


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/20131218/47a006b6/attachment.html>

From finlayson at live555.com  Tue Dec 17 11:42:10 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Dec 2013 08:42:10 +1300
Subject: [Live-devel] RES:  Problems to capture a RTSP
In-Reply-To: <000601cefb5a$37971640$a6c542c0$@fazion.com.br>
References: <003101cefb30$c6955340$53bff9c0$@fazion.com.br>
 <55E373EE-EC86-4E52-9BC1-64BFA23D11A6@live555.com>
 <000601cefb5a$37971640$a6c542c0$@fazion.com.br>
Message-ID: <394DF1EC-C057-4422-BAFC-BE2B044FA02F@live555.com>

> Good afternoon Mr. Finlayson, thanks for responding, but I've verified the firewall 3 times already, executed TELNET on port 554 and seems ok.

Does
	openRTSP -n rtsp://186.215.116.89:554/pro1
work OK for you?

If it does, then the problem must be in your code.

If it doesn't work, then try instead:
	openRTSP -n -t rtsp://186.215.116.89:554/pro1

If that *does* work (but running "openRTSP" without the "-t" option *doesn't* work), then the problem must be - as explained in the FAQ entry - that you have a firewall that is blocking RTP/UDP packets.
	

> Through VLC works nicely

That's because VLC first requests regular RTP/UDP streaming and then - if not packets are received in several seconds - automatically tries another request, this time requesting RTP-over-TCP streaming.


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/20131218/acaa39a3/attachment.html>

From bbischan at watchtower-security.com  Tue Dec 17 11:45:47 2013
From: bbischan at watchtower-security.com (Bob Bischan)
Date: Tue, 17 Dec 2013 13:45:47 -0600
Subject: [Live-devel] FYI: New option to "openRTSP" for writing new
	files periodically
In-Reply-To: <AFC2D912-4098-45CA-8D1C-DF4CFD51E2C4@live555.com>
References: <F5ACADAE-3AF1-4FE9-9625-9A75C218836B@live555.com>
 <CACv1yZ_58_SbB29-ENg1Fs+ziRpBPsUBnThhNZoF-x3y_vxBYg@mail.gmail.com>
 <AFC2D912-4098-45CA-8D1C-DF4CFD51E2C4@live555.com>
Message-ID: <CACv1yZ_dFfeJzR_mZwXq31ZFWFKodLi8G9ybHE6AUB=J_kg_VQ@mail.gmail.com>

Ross,

Thanks for your reply.

Shell scripting is within my reach...I'll explore ways to handle files
using those tools.

Bob


On Tue, Dec 17, 2013 at 12:45 PM, Ross Finlayson <finlayson at live555.com>wrote:

> *File naming convention and output options:*
>
> Would it be possible to add options to openRTSP that provide a flexible
> mechanism for specifying file-naming and storage location using a
> combination of format specifiers / existing options?
>
>
> It would certainly be 'possible', but it would make an already complex
> program even more complex.  Remember that "openRTSP" is intended to be used
> by sophisticated users who know how to - if necessary - use shell scripts
> (or even customize the source code if necessary).
>
>
> *Is the Periodic File output option intended to work with -R ?*
>
>
> Yes.  I know of no reason why this won't work.
>
>
> *Is the  -F <fileName-prefix> option intended to work with all file output
> types?  *
>
>
> It *was* intended to, but I discovered that it currently doesn't work with
> the "-q", "-4", or "-i" options (i.e., for generating ".mov", ".mp4", or
> ".avi" files).  This will be fixed in the next release of the software.
>
>
> 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/20131217/e3efd3d6/attachment.html>

From warren at etr-usa.com  Tue Dec 17 12:44:16 2013
From: warren at etr-usa.com (Warren Young)
Date: Tue, 17 Dec 2013 13:44:16 -0700
Subject: [Live-devel] RES:  Problems to capture a RTSP
In-Reply-To: <000601cefb5a$37971640$a6c542c0$@fazion.com.br>
References: <003101cefb30$c6955340$53bff9c0$@fazion.com.br>
 <55E373EE-EC86-4E52-9BC1-64BFA23D11A6@live555.com>
 <000601cefb5a$37971640$a6c542c0$@fazion.com.br>
Message-ID: <52B0B7A0.2080600@etr-usa.com>

On 12/17/2013 12:00, Robson Nunes wrote:
> i'm not being able to make it on Visual Studio
> 2012. Could you help me out, please?

Toggle the checkbox.  You know, the one over there.  In that dialog.

Since I'm feeling generous, I will also give some specific advice in 
response to your nonspecific question:

It will probably be easier to build Live555 under Cygwin than work out 
how to create Visual Studio project files, purely because Live555 ships 
with a Cygwin configuration.

MinGW should also work for the same reason, but since Live555 comes from 
the *ix world, I'd expect Live555 to work better under Cygwin.

From eric.hoffmann at thalesgroup.com  Wed Dec 18 05:32:06 2013
From: eric.hoffmann at thalesgroup.com (HOFFMANN Eric)
Date: Wed, 18 Dec 2013 14:32:06 +0100
Subject: [Live-devel] mkv streaming in loop
Message-ID: <31838_1387373528_52B1A3D8_31838_6867_1_8AF751CD48F5A14AADA5E935BB6A406501EC35974B62@THSONEA01CMS03P.one.grp>

Hi ross,
I need to stream a mkv in a loop, i know that I need to write my own ByteStreamFileSource subclass, problem is, its very difficult to "pass" it to MatroskaFile without a lot of code duplication (MatroskaFileServerDemux and MatroskaFile), is it not possible to allow some ByteStreamFileSource interface passing rather than automatically create one in MatroskaFile?

Best regards

eric


[@@ THALES GROUP INTERNAL @@]

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

From tayeb.dotnet at gmail.com  Sun Dec 15 11:47:00 2013
From: tayeb.dotnet at gmail.com (Tayeb Meftah)
Date: Sun, 15 Dec 2013 20:47:00 +0100
Subject: [Live-devel] SDP File distribution over Live555 RTSP Server
Message-ID: <182CAADCA45A4CE09AFCD6F0DC0A3E0A@worksc08f920f1>

Hello,
it's legal (technicaly) to distribute SDP files using Live555 RTSP Server and not (MEDIA) files?
the sdp file may contain a multicast or a unicast path to another rtp stream
thank
Tayeb Meftah
Voice of the blind T Broadcast Freedom
http://www.vobradio.org
Phone:447559762242
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131215/da21dcd9/attachment-0001.html>

From fantasyvideo at 126.com  Sun Dec 15 23:11:48 2013
From: fantasyvideo at 126.com (Tony)
Date: Mon, 16 Dec 2013 15:11:48 +0800 (CST)
Subject: [Live-devel] Regarding the timestamp of device source
Message-ID: <3c259425.df61.142fa3f1a62.Coremail.fantasyvideo@126.com>

Hi, Ross,
I saw the DeviceSource code in live555 project.
I found that the the fPresentationTime would be set by gettimeofday when doGetNextFrame is called.
I remembered you said the fPresentationTime must be same at the first time,        So how should it sync audio and video? 

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

From brilliantov at byterg.ru  Sun Dec 15 23:29:48 2013
From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich)
Date: Mon, 16 Dec 2013 11:29:48 +0400
Subject: [Live-devel] Increase BANK_SIZE question
Message-ID: <52AEABEC.5090502@byterg.ru>

Hello!
I use live555 2013.12.15 on board with FreeScale iMX53 CPU.
Now I add H263 support to may programm, unfortunally programm stopped
with follow message: StreamParser internal error (150000 + 1 > 150000).
I found with message in liveMedia/StreamParser.cpp with follow comment:
// If this happens, it means that we have too much saved parser state.
// To fix this, increase BANK_SIZE as appropriate.
That I should consider when I increase BANK_SIZE?

-- 
Best regards,
Brilliantov Kirill Vladimirovich


From bbischan at watchtower-security.com  Wed Dec 18 09:50:33 2013
From: bbischan at watchtower-security.com (Bob Bischan)
Date: Wed, 18 Dec 2013 11:50:33 -0600
Subject: [Live-devel] openRTSP (File Output / Session Timeout)
Message-ID: <CACv1yZ97EcfVNTgD22ABp7O59=UbJ+Y0LYEOCzH3K6MjsSF4hA@mail.gmail.com>

I have a quick question regarding the expected behavior of openRTSP client
w/ file output when connection to the server is lost due to reboot, loss of
connectivity...etc.

What I have seen with both "stdout" and "Periodic" file output is that the
client never reconnects to the server if that stream is lost....ie I reboot
the camera. openRTSP continues to run under both file output methods with
no additional output to console.

Periodic file output continues to run and create files, however, files
created after reboot are empty.

Stdout continues to run and after kill -HUP is sent the file is intact and
playable, but there is no recorded video from the time of camera reboot.

Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131218/1f1c1582/attachment.html>

From maksqwe1 at ukr.net  Tue Dec 17 09:01:48 2013
From: maksqwe1 at ukr.net (maks)
Date: Tue, 17 Dec 2013 19:01:48 +0200
Subject: [Live-devel] MSVC 2005+ compilation
Message-ID: <1387299196.72289569.qn4rlsix@frv34.ukr.net>

When I compile liveMedia using MSVC 2012 I got error:
"mp3streamstate.cpp(412): error C4996: 'fileno': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _fileno. See online help for details"

---------------
MSDN(http://msdn.microsoft.com/en-us/library/ms235384.aspx):
The following POSIX names for functions are deprecated. In most cases, prepending an underscore character gives the standard equivalent name. Note that some functions have more secure versions ("_s" suffix).

This POSIX function is deprecated beginning in Visual C++ 2005. Use the ISO C++ conformant _fileno instead.
---------------

mp3streamstate.cpp has:
#if defined(__WIN32__) || defined(_WIN32)
#define snprintf _snprintf
#endif

Fix, add check for msvc version:
#if defined(__WIN32__) || defined(_WIN32)
#define snprintf _snprintf
#if _MSC_VER >= 1400 // 1400 == vs2005
#define fileno _fileno
#endif
#endif




From finlayson at live555.com  Wed Dec 18 13:18:13 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 19 Dec 2013 10:18:13 +1300
Subject: [Live-devel] MSVC 2005+ compilation
In-Reply-To: <1387299196.72289569.qn4rlsix@frv34.ukr.net>
References: <1387299196.72289569.qn4rlsix@frv34.ukr.net>
Message-ID: <0E7A1053-E56E-4DBC-8041-84057C984C39@live555.com>

> Fix, add check for msvc version:
> #if defined(__WIN32__) || defined(_WIN32)
> #define snprintf _snprintf
> #if _MSC_VER >= 1400 // 1400 == vs2005
> #define fileno _fileno
> #endif
> #endif

Thanks.  This change 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/20131219/bd6a0dc2/attachment.html>

From finlayson at live555.com  Wed Dec 18 16:32:43 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 19 Dec 2013 13:32:43 +1300
Subject: [Live-devel] pass authentication from uri from the proxy to my
	rtspservers?
In-Reply-To: <52A96CFC.8080405@vivint.com>
References: <52a8540a3f95_@_imoxion.com>
 <A53CE4B6-1AFE-4E4C-90C3-B11BC045B9B0@live555.com>
 <52A96CFC.8080405@vivint.com>
Message-ID: <9C5EAB7D-549C-4A37-A1CB-9CA21BEBD07D@live555.com>

Note that whatever authentication that the proxy server uses to authenticate 'front-end' streams is completely independent of whatever authentication the 'back-end' stream requires.  You can have authentication on the front-end stream, but not the back-end stream, or vice-versa.

Note also that because the proxy server accesses the back-end stream (using "DESCRIBE") before the first front-end client connects, it makes no sense to talk about using any information from the front-end client to authenticate the back-end stream.

Also, if you want to customize the authentication mechanism, and you're feeling adventurish, you can subclass "RTSPServer" and redefine one or both of the virtual functions "specialClientAccessCheck()" and "specialClientUserAccessCheck()".  You're on you own here though...


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/20131219/42517820/attachment.html>

From gilles.chanteperdrix at xenomai.org  Wed Dec 18 22:48:16 2013
From: gilles.chanteperdrix at xenomai.org (Gilles Chanteperdrix)
Date: Thu, 19 Dec 2013 07:48:16 +0100
Subject: [Live-devel] Clock drift compensation
Message-ID: <52B296B0.8030807@xenomai.org>


Hi,

when using live555 as a server, and vlc as a client (so using live555 as
well) over long periods of time, with a server which is not running ntp,
I observed the following phenomenon: depending on which clock (the
server's or the client's) is running faster, either vlc stops or it
plays images with a big latencies, like 10 seconds.

>From what I understand of live555 code, the presentation time output by
live555 on the client side, is essentially a server clock timestamp, and
I believe the phenomenon observed with vlc is due to the drift between
the server clock and the client clock.

>From what I understand of RTP/RTCP, I believe this drift could be
compensated by comparing the NTP timestamp in RTCP sender reports, with
the actual client time when the RTCP sender report is received,
potentially averaging over a few reports to mitigate network jitter.

Now, the question is: what is the best place to implement this? In the
application? Or in live555 server or client code?

Thanks in advance.
Regards.

-- 
                                                                Gilles.

From cmkim at n3n.co.kr  Wed Dec 18 22:44:57 2013
From: cmkim at n3n.co.kr (ChanMin Kim)
Date: Thu, 19 Dec 2013 15:44:57 +0900
Subject: [Live-devel] MediaSession fRTPSocket double free bug fix
Message-ID: <CABuR=3sM=HT2yqc7-jVSnL-pdc02tFhyi18Y88z3kpTwSyHo=Q@mail.gmail.com>

from 'liveMedia/MediaSession.cpp'

------------------------
} else {
 // We couldn't create the RTCP socket (perhaps that port number's
already in use elsewhere?)
 delete fRTCPSocket;

 // Record the first socket in our table, and keep trying:
 unsigned key = (unsigned)fClientPortNum;
------------------------

There must be  fRTCPSocket = NULL; after delete.

One scenario double free could happen is as follows:
1. 'delete fRTCPSocket;' from the above was called
2. getSourcePort() have failed
3. delete fRTCPSocket again outside the while loop.

The scenario actually happened to me.

From finlayson at live555.com  Sat Dec 21 08:49:43 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 22 Dec 2013 05:49:43 +1300
Subject: [Live-devel] MediaSession fRTPSocket double free bug fix
In-Reply-To: <CABuR=3sM=HT2yqc7-jVSnL-pdc02tFhyi18Y88z3kpTwSyHo=Q@mail.gmail.com>
References: <CABuR=3sM=HT2yqc7-jVSnL-pdc02tFhyi18Y88z3kpTwSyHo=Q@mail.gmail.com>
Message-ID: <E1FC8CBB-254E-4B4D-9BA2-A891B94E29C9@live555.com>

ChanMin,

Thank you for reporting this.  I have just installed a new version (2013.12.21) of the "LIVE555 Streaming Media" software that fixes 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/20131222/30795f09/attachment-0001.html>

From finlayson at live555.com  Mon Dec 23 09:59:27 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 24 Dec 2013 06:59:27 +1300
Subject: [Live-devel] mkv streaming in loop
In-Reply-To: <31838_1387373528_52B1A3D8_31838_6867_1_8AF751CD48F5A14AADA5E935BB6A406501EC35974B62@THSONEA01CMS03P.one.grp>
References: <31838_1387373528_52B1A3D8_31838_6867_1_8AF751CD48F5A14AADA5E935BB6A406501EC35974B62@THSONEA01CMS03P.one.grp>
Message-ID: <08720947-997A-4AAA-B291-F82DC725E402@live555.com>

> I need to stream a mkv in a loop, i know that I need to write my own ByteStreamFileSource subclass

No, I don't recommend doing things this way.

Rather than defining a new class that would sit 'below' MatroskaFile (because, as you discovered, this would require a lot of code duplication), I recommend that you instead define a new class (a subclass of "FramedFilter", perhaps) that would sit *above* "MatroskaFile".

In particular, your new class would - when needed - create a new "MatroskaFile" object (to start reading from the underlying file all over again, and create demuxed track(s)).  When calling "getNextFrame()" on the demuxed track(s), it would set an appropriate 'onCloseFunc' that would be called when the end of the underlying file is reached.  At that point, you would just close the existing "MatroskaFile", and create a new one.

You should be able to do this without modifying (or duplicating) any of the "Matroska*" 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/20131224/ebe53f8c/attachment.html>

From finlayson at live555.com  Mon Dec 23 10:02:55 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 24 Dec 2013 07:02:55 +1300
Subject: [Live-devel] SDP File distribution over Live555 RTSP Server
In-Reply-To: <182CAADCA45A4CE09AFCD6F0DC0A3E0A@worksc08f920f1>
References: <182CAADCA45A4CE09AFCD6F0DC0A3E0A@worksc08f920f1>
Message-ID: <1B3E57F4-47BD-4B69-A601-16BF50BA0E68@live555.com>

> it's legal (technicaly) to distribute SDP files using Live555 RTSP Server and not (MEDIA) files?

Sorry, but I don't understand your question.  The "LIVE555 Media Server" does not 'distribute files'.  It returns a SDP description - in response to a RTSP "DESCRIBE" command.  But what was your question again?

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/20131224/299684ea/attachment.html>

From finlayson at live555.com  Mon Dec 23 16:15:00 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 24 Dec 2013 13:15:00 +1300
Subject: [Live-devel] Regarding the timestamp of device source
In-Reply-To: <3c259425.df61.142fa3f1a62.Coremail.fantasyvideo@126.com>
References: <3c259425.df61.142fa3f1a62.Coremail.fantasyvideo@126.com>
Message-ID: <9D170780-02F4-45DA-8702-385ED94DD516@live555.com>

> 	I saw the DeviceSource code in live555 project.
> 	I found that the the fPresentationTime would be set by gettimeofday when doGetNextFrame is called.
> 	I remembered you said the fPresentationTime must be same at the first time,        So how should it sync audio and video? 

If the "fPresentationTime" value is accurate, and aligned with 'wall clock time' (the time that you'd get by calling "gettimeofday()"), then audio/video synchronization will happen automatically - see http://www.live555.com/liveMedia/faq.html#separate-rtp-streams

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/20131224/8f49d296/attachment.html>

From finlayson at live555.com  Mon Dec 23 16:34:34 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 24 Dec 2013 13:34:34 +1300
Subject: [Live-devel] openRTSP (File Output / Session Timeout)
In-Reply-To: <CACv1yZ97EcfVNTgD22ABp7O59=UbJ+Y0LYEOCzH3K6MjsSF4hA@mail.gmail.com>
References: <CACv1yZ97EcfVNTgD22ABp7O59=UbJ+Y0LYEOCzH3K6MjsSF4hA@mail.gmail.com>
Message-ID: <831C4B6E-0CE8-4A3B-80BE-5B214E452090@live555.com>

> I have a quick question regarding the expected behavior of openRTSP client w/ file output when connection to the server is lost due to reboot, loss of connectivity...etc.

The rest of your message didn't contain a question :-)  However...

The only reliable way for a client to detect when a server 'dies' is to notice that RTP packets from the server stop arriving.  (Note that a TCP connection can stay alive for a long time after the remote end dies, so you can't reliably detect this from the TCP connection.)

You can detect this in "openRTSP" using the "-D <maximum-inter-packet-gap>" option; see http://www.live555.com/openRTSP/#playing-time

Note, however, that "openRTSP" uses a single connection only, and does not - by itself - attempt to reconnect to a dead server.  If you want to do that, you'll need to run "openRTSP" a separate time, e.g. from a shell script.


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/20131224/2214d02d/attachment.html>

From finlayson at live555.com  Mon Dec 23 18:42:38 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 24 Dec 2013 15:42:38 +1300
Subject: [Live-devel] Clock drift compensation
In-Reply-To: <52B296B0.8030807@xenomai.org>
References: <52B296B0.8030807@xenomai.org>
Message-ID: <BBC5101F-5229-4A77-95CB-41D90F0CEB5B@live555.com>

> when using live555 as a server, and vlc as a client (so using live555 as
> well) over long periods of time, with a server which is not running ntp,
> I observed the following phenomenon: depending on which clock (the
> server's or the client's) is running faster, either vlc stops or it
> plays images with a big latencies, like 10 seconds.
> 
>> From what I understand of live555 code, the presentation time output by
> live555 on the client side, is essentially a server clock timestamp

That's correct.


> and
> I believe the phenomenon observed with vlc is due to the drift between
> the server clock and the client clock.

Perhaps, but it's something that you should be able to figure out for sure (see below); not just "believe".


> From what I understand of RTP/RTCP, I believe this drift could be
> compensated by comparing the NTP timestamp in RTCP sender reports, with
> the actual client time when the RTCP sender report is received,
> potentially averaging over a few reports to mitigate network jitter.

No, although you're sort of on the right track (because the RTCP "SR" arrival times can be used to compute the network 'jitter' (see RFC 3550) - and FYI in LIVE555 this jitter computation is made available to clients via the "RTPReceptionStats" database).

The way for a client to detect (and compensate for) the drift between the server and client clocks is to monitor the size of the client's playout buffer.

If the playout buffer keeps increasing over time, then the server's clock is faster than the client's.  The client can compensate for this by playing out frames faster, or perhaps by dropping frames occasionally.

If the playout buffer keeps emptying - despite starting at a reasonably large level (to allow for network jitter) - then the server's clock is slower than the client's.  The client can compensate this for playing out frames slower, or perhaps by duplicating frames occasionally.


> Now, the question is: what is the best place to implement this? In the application?

Yes - in the media player application (in particular, by monitoring its playout buffer).  But do you really want to bother with this?  VLC is only one of the many media players out there (and you've already dealt with their developers :-).  I thought your project was to develop a server?


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/20131224/37ea2cf5/attachment.html>

From brilliantov at byterg.ru  Thu Dec 19 00:05:34 2013
From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich)
Date: Thu, 19 Dec 2013 12:05:34 +0400
Subject: [Live-devel] Sometimes uSecondsToGo in MultiFramedRTPSink is too big
Message-ID: <52B2A8CE.9020008@byterg.ru>

Hello!
I use live555 2013.12.15 on board with FreeScale iMX53 CPU.
I have very strange problem - sometimes RTP stream stopped after first
frame, I very long time search reason this and found it in
MultiFramedRTPSink.cpp.

This hack solve my problem:
--- live/liveMedia/MultiFramedRTPSink.cpp.org   2013-12-19
11:22:56.899966475 +0400
+++ live/liveMedia/MultiFramedRTPSink.cpp       2013-12-19
11:24:32.522972693 +0400
@@ -404,7 +404,8 @@
     }

     // Delay this amount of time:
-    nextTask() =
envir().taskScheduler().scheduleDelayedTask(uSecondsToGo,
(TaskFunc*)sendNext, this);
+    //FIXME: sometimes uSecondsToGo can be very big, e.g. 1420587564
+    nextTask() =
envir().taskScheduler().scheduleDelayedTask(/*uSecondsToGo*/0,
(TaskFunc*)sendNext, this);
   }
 }

Thank you and excuse me for my bad english.

-- 
Best regards,
Brilliantov Kirill Vladimirovich


From fantasyvideo at 126.com  Thu Dec 19 02:35:28 2013
From: fantasyvideo at 126.com (Tony)
Date: Thu, 19 Dec 2013 18:35:28 +0800 (CST)
Subject: [Live-devel] A bug of h264 rtp packet's timestamp
Message-ID: <33e99f42.14e1c.1430a6ca27a.Coremail.fantasyvideo@126.com>

HI, Ross
Here the code of compute next fPresentationTime.
  // Note that the presentation time for the next NAL unit will be different:  
            struct timeval& nextPT = usingSource()->fNextPresentationTime; // alias  
            nextPT = usingSource()->fPresentationTime;  
            double nextFraction = nextPT.tv_usec / 1000000.0  
                    + 1 / usingSource()->fFrameRate;  
            unsigned nextSecsIncrement = (long) nextFraction;  
            nextPT.tv_sec += (long) nextSecsIncrement;  
            nextPT.tv_usec = (long) ((nextFraction - nextSecsIncrement)  
                    * 1000000);  
   As you know, if live555 can't get framerate from sps, then the framerate would be 25fps.
   But if the framerate is variable or not 25, it would be wrong. The timestamp increment shouldn't be 3600.
   So could you check it ? THANKS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131219/f6bc0b00/attachment.html>

From bbischan at watchtower-security.com  Mon Dec 23 19:30:36 2013
From: bbischan at watchtower-security.com (Bob Bischan)
Date: Mon, 23 Dec 2013 21:30:36 -0600
Subject: [Live-devel] openRTSP (File Output / Session Timeout)
In-Reply-To: <831C4B6E-0CE8-4A3B-80BE-5B214E452090@live555.com>
References: <CACv1yZ97EcfVNTgD22ABp7O59=UbJ+Y0LYEOCzH3K6MjsSF4hA@mail.gmail.com>
 <831C4B6E-0CE8-4A3B-80BE-5B214E452090@live555.com>
Message-ID: <CACv1yZ_xopNZoP9RJSGo_3U0Pp2gBy2v5d2J64WNLGUfPKiGXQ@mail.gmail.com>

Ross,

Thanks for your reply....despite the absence of an actual question :-)  A
few days after posting the email to the list, I discovered that this had
been "asked and answered".

ProxyServer seems to handle reconnect scenarios pretty well. Would your
implementation of RTSPClient in ProxyServer be a good model for how to add
this functionality for client applications?

Have you considered adding file sink and output options to ProxyServer?

Bob


On Mon, Dec 23, 2013 at 6:34 PM, Ross Finlayson <finlayson at live555.com>wrote:

> I have a quick question regarding the expected behavior of openRTSP client
> w/ file output when connection to the server is lost due to reboot, loss of
> connectivity...etc.
>
>
> The rest of your message didn't contain a question :-)  However...
>
> The only reliable way for a client to detect when a server 'dies' is to
> notice that RTP packets from the server stop arriving.  (Note that a TCP
> connection can stay alive for a long time after the remote end dies, so you
> can't reliably detect this from the TCP connection.)
>
> You can detect this in "openRTSP" using the "-D
> <maximum-inter-packet-gap>" option; see
> http://www.live555.com/openRTSP/#playing-time
>
> Note, however, that "openRTSP" uses a single connection only, and does not
> - by itself - attempt to reconnect to a dead server.  If you want to do
> that, you'll need to run "openRTSP" a separate time, e.g. from a shell
> script.
>
>
> 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/20131223/fe0cc3ba/attachment.html>

From finlayson at live555.com  Tue Dec 24 02:18:17 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 24 Dec 2013 23:18:17 +1300
Subject: [Live-devel] A bug of h264 rtp packet's timestamp
In-Reply-To: <33e99f42.14e1c.1430a6ca27a.Coremail.fantasyvideo@126.com>
References: <33e99f42.14e1c.1430a6ca27a.Coremail.fantasyvideo@126.com>
Message-ID: <2F6322A5-1DFF-4317-98B7-F5A8D9E54B83@live555.com>

No, there's no bug here.  If there's no frame rate specified in the SPS NAL unit (or if no SPS NAL unit is present), then the "H264VideoStreamFramer" code (which reads from a continuous byte stream - e.g., from a file) has no possible way of knowing what frame rate to use.  In this case, it has to just 'guess' a frame rate.

If your stream does not specify a frame rate (in SPS NAL units), then you should not use the "H264VideoStreamFramer" class at all.  (However, if your stream consists of discrete NAL units (i.e., one at a time), then you should use the "H264VideoStreamDiscreteFramer" class instead.  In this case, the frame rate is determined automatically from the rate of arrival of source NAL units.)

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/20131224/1e598ed3/attachment-0001.html>

From finlayson at live555.com  Tue Dec 24 02:23:01 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 24 Dec 2013 23:23:01 +1300
Subject: [Live-devel] openRTSP (File Output / Session Timeout)
In-Reply-To: <CACv1yZ_xopNZoP9RJSGo_3U0Pp2gBy2v5d2J64WNLGUfPKiGXQ@mail.gmail.com>
References: <CACv1yZ97EcfVNTgD22ABp7O59=UbJ+Y0LYEOCzH3K6MjsSF4hA@mail.gmail.com>
 <831C4B6E-0CE8-4A3B-80BE-5B214E452090@live555.com>
 <CACv1yZ_xopNZoP9RJSGo_3U0Pp2gBy2v5d2J64WNLGUfPKiGXQ@mail.gmail.com>
Message-ID: <90D7B53E-0639-46E5-B1F1-0E7D353E5EB6@live555.com>

> ProxyServer seems to handle reconnect scenarios pretty well. Would your implementation of RTSPClient in ProxyServer be a good model for how to add this functionality for client applications?

It depends upon what client application you have in mind, but I imagine so...


> Have you considered adding file sink and output options to ProxyServer?    

No, because it would be unnecessary (and unnecessarily complicate the proxy server code).  Instead, you can simply have a 'file writing' client (such as "openRTSP") connect to the proxy server (or the back-end server).

In any case, the "LIVE555 Proxy Server" project has now concluded, and I'm not planning on making any more changes to it (other than bug fixes) in the future.

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/20131224/b480278f/attachment-0001.html>

From finlayson at live555.com  Tue Dec 24 10:58:37 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 24 Dec 2013 10:58:37 -0800
Subject: [Live-devel] Sometimes uSecondsToGo in MultiFramedRTPSink is
	too big
In-Reply-To: <52B2A8CE.9020008@byterg.ru>
References: <52B2A8CE.9020008@byterg.ru>
Message-ID: <5F1A5365-161E-4815-A1EA-29AB1CD8E96A@live555.com>

> +    //FIXME: sometimes uSecondsToGo can be very big, e.g. 1420587564

The value of "uSecondsToGo" depends upon the value of the "durationInMicroseconds" parameter.  The only way that it can be 'very big' is if the "durationInMicroseconds" parameter (passed by the upstream object) was incorrect.

There is no known bug here.

(Also, a reminder that if you modify the supplied 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/20131224/e99dfa9e/attachment.html>

From louis_latreille at hotmail.com  Fri Dec 20 15:21:08 2013
From: louis_latreille at hotmail.com (Louis Latreille)
Date: Fri, 20 Dec 2013 23:21:08 +0000
Subject: [Live-devel] Error with mp3 streaming
Message-ID: <BLU173-W4CB14C59BE7E8B0A3197E9EC40@phx.gbl>

Hi,
I am completely new the music and video streaming, and I probably am doing something wrong.
I tried the test program testMP3Streamer and testMP3Receiver to understand how the library works.
When I started the streamer, with the test.mp3 input that worked on any media player, it seems to start streaming properly, but when I open the receiver, it connects on the stream, but plays odd sounds, something like if the stream was not decoded correctly.
Any thoughts? 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131220/c0243f10/attachment.html>

From john95018 at gmail.com  Mon Dec 23 08:08:23 2013
From: john95018 at gmail.com (john dicostanzo)
Date: Mon, 23 Dec 2013 21:38:23 +0530
Subject: [Live-devel] Regarding testOndemandRtspserver test app....
Message-ID: <CAJqr0gCyCJzc+aAWsGegOLJS2gWYTRsRUfebyU7gy8Kutu0LRw@mail.gmail.com>

HI Ross,

I am using testOnDemandRtspServer application and at the end i wand to
delete
the objects of TaskScheduler and UsageEnvironment,but these classes have
protected destructor.so how can i free memory for these classes.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131223/9a6c85c4/attachment.html>

From gilles.chanteperdrix at xenomai.org  Wed Dec 25 03:36:44 2013
From: gilles.chanteperdrix at xenomai.org (Gilles Chanteperdrix)
Date: Wed, 25 Dec 2013 12:36:44 +0100
Subject: [Live-devel] Clock drift compensation
In-Reply-To: <BBC5101F-5229-4A77-95CB-41D90F0CEB5B@live555.com>
References: <52B296B0.8030807@xenomai.org>
 <BBC5101F-5229-4A77-95CB-41D90F0CEB5B@live555.com>
Message-ID: <52BAC34C.1000708@xenomai.org>

On 12/24/2013 03:42 AM, Ross Finlayson wrote:
> No, although you're sort of on the right track (because the RTCP "SR"
> arrival times can be used to compute the network 'jitter' (see RFC
> 3550) - and FYI in LIVE555 this jitter computation is made available
> to clients via the "RTPReceptionStats" database).
> 
> The way for a client to detect (and compensate for) the drift between
> the server and client clocks is to monitor the size of the client's
> playout buffer.
> 
> If the playout buffer keeps increasing over time, then the server's
> clock is faster than the client's.  The client can compensate for
> this by playing out frames faster, or perhaps by dropping frames
> occasionally.
> 
> If the playout buffer keeps emptying - despite starting at a
> reasonably large level (to allow for network jitter) - then the
> server's clock is slower than the client's.  The client can
> compensate this for playing out frames slower, or perhaps by
> duplicating frames occasionally.

Makes sense, Ok.

> 
> 
>> Now, the question is: what is the best place to implement this? In
>> the application?
> 
> Yes - in the media player application (in particular, by monitoring
> its playout buffer).  But do you really want to bother with this?
> VLC is only one of the many media players out there (and you've
> already dealt with their developers :-).  I thought your project was
> to develop a server?

This is a separate project. The server is almost finished anyway.

Thanks.


-- 
                                                                Gilles.

From fantasyvideo at 126.com  Mon Dec 23 22:44:49 2013
From: fantasyvideo at 126.com (Tony)
Date: Tue, 24 Dec 2013 14:44:49 +0800 (CST)
Subject: [Live-devel] The SR live555 sent doesn't contain any information
 about npt and rtp
Message-ID: <6a615103.26e9c.14323594313.Coremail.fantasyvideo@126.com>

Hi Ross,
I checked the rtcp live555 sent to client, it only contains SSRC, no rtp and npt information.
       Does I need to create RTCP instance apparently?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131224/6a1ebbd3/attachment.html>

From fantasyvideo at 126.com  Tue Dec 24 01:46:32 2013
From: fantasyvideo at 126.com (Tony)
Date: Tue, 24 Dec 2013 17:46:32 +0800 (CST)
Subject: [Live-devel] Regarding the timestamp of device source
In-Reply-To: <9D170780-02F4-45DA-8702-385ED94DD516@live555.com>
References: <3c259425.df61.142fa3f1a62.Coremail.fantasyvideo@126.com>
 <9D170780-02F4-45DA-8702-385ED94DD516@live555.com>
Message-ID: <72420f8e.2db65.14323ffa2b5.Coremail.fantasyvideo@126.com>

but unfortunately, vlc also shows that the g711 audio is late.






At 2013-12-24 08:15:00,"Ross Finlayson" <finlayson at live555.com> wrote:

I saw the DeviceSource code in live555 project.
I found that the the fPresentationTime would be set by gettimeofday when doGetNextFrame is called.
I remembered you said the fPresentationTime must be same at the first time,        So how should it sync audio and video? 


If the "fPresentationTime" value is accurate, and aligned with 'wall clock time' (the time that you'd get by calling "gettimeofday()"), then audio/video synchronization will happen automatically - see http://www.live555.com/liveMedia/faq.html#separate-rtp-streams


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/20131224/032520fb/attachment.html>

From finlayson at live555.com  Thu Dec 26 17:42:36 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 26 Dec 2013 17:42:36 -0800
Subject: [Live-devel] Error with mp3 streaming
In-Reply-To: <BLU173-W4CB14C59BE7E8B0A3197E9EC40@phx.gbl>
References: <BLU173-W4CB14C59BE7E8B0A3197E9EC40@phx.gbl>
Message-ID: <FF96628E-1871-4881-92B4-B8A5804DCDDA@live555.com>

> I am completely new the music and video streaming, and I probably am doing something wrong.
> 
> I tried the test program testMP3Streamer and testMP3Receiver to understand how the library works.
> 
> When I started the streamer, with the test.mp3 input that worked on any media player, it seems to start streaming properly, but when I open the receiver, it connects on the stream, but plays odd sounds, something like if the stream was not decoded correctly.

Note that our software doesn't include any codec (i.e., encoding or decoding software).  So, in particular, the "testMP3Receiver" application outputs (to 'stdout') encoded MP3 frames, but does *not* decode them.

To actually 'play' the received video, you'll need to feed the data into a separate MP3 decoder.


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/20131226/3d67be44/attachment-0001.html>

From finlayson at live555.com  Thu Dec 26 18:50:19 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 26 Dec 2013 18:50:19 -0800
Subject: [Live-devel] Regarding testOndemandRtspserver test app....
In-Reply-To: <CAJqr0gCyCJzc+aAWsGegOLJS2gWYTRsRUfebyU7gy8Kutu0LRw@mail.gmail.com>
References: <CAJqr0gCyCJzc+aAWsGegOLJS2gWYTRsRUfebyU7gy8Kutu0LRw@mail.gmail.com>
Message-ID: <841C16C0-30B8-4442-AD36-28548AF87DC3@live555.com>

> I am using testOnDemandRtspServer application and at the end i wand to delete 
> the objects of TaskScheduler and UsageEnvironment,but these classes have protected destructor.so how can i free memory for these classes.

The simplest way to do this is to simply call
	exit(0);
to exit the process.

But if (for some reason) you don't want to do this, you can reclaim these objects (of course, after you've reclaimed the server object itself) by doing:
    env->reclaim(); env = NULL;
    delete scheduler; scheduler = NULL;


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/20131226/60871994/attachment.html>

From brilliantov at byterg.ru  Thu Dec 26 06:21:00 2013
From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich)
Date: Thu, 26 Dec 2013 18:21:00 +0400
Subject: [Live-devel] changeDestinationParameters work only one time
Message-ID: <52BC3B4C.6040404@byterg.ru>

Hello!
I use live555 2013.12.21 on board with FreeScale iMX53 CPU.
For change RTP-stream destination I try use
changeDestinationParameters() function from Groupsock class.
Strange, but it work only one time.
How can I change RTP-stream network parameters (address, port and TTL)
on fly without restart programm?
Thank you and excuse me for my bad english.

-- 
Best regards,
Brilliantov Kirill Vladimirovich


From finlayson at live555.com  Fri Dec 27 21:36:54 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 27 Dec 2013 21:36:54 -0800
Subject: [Live-devel] The SR live555 sent doesn't contain any
	information about npt and rtp
In-Reply-To: <6a615103.26e9c.14323594313.Coremail.fantasyvideo@126.com>
References: <6a615103.26e9c.14323594313.Coremail.fantasyvideo@126.com>
Message-ID: <4BD9265E-B85E-42C0-9C8F-FB02FC8FBA63@live555.com>

> 	I checked the rtcp live555 sent to client, it only contains SSRC, no rtp and npt information.

No, you're wrong.

>        Does I need to create RTCP instance apparently?

How many times do I need to explain this to you?  If you're using the supplied RTSP server code, or the supplied RTSP client code, then you don't need to create "RTCPInstance" objects yourself.  They will be created (at both the server end, and the client end) automatically, which will give you audio/video synchronization (as explained in the FAQ).

This will be your last posting on this topic.

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/20131227/27cdbbef/attachment.html>

From finlayson at live555.com  Fri Dec 27 21:37:28 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 27 Dec 2013 21:37:28 -0800
Subject: [Live-devel] Regarding the timestamp of device source
In-Reply-To: <72420f8e.2db65.14323ffa2b5.Coremail.fantasyvideo@126.com>
References: <3c259425.df61.142fa3f1a62.Coremail.fantasyvideo@126.com>
 <9D170780-02F4-45DA-8702-385ED94DD516@live555.com>
 <72420f8e.2db65.14323ffa2b5.Coremail.fantasyvideo@126.com>
Message-ID: <B151CB01-B0F5-432C-8075-9C481497D090@live555.com>

> but unfortunately, vlc also shows that the g711 audio is late.

VLC is not our software.  You should be testing your server using "testRTSPClient" first.

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/20131227/e685e231/attachment.html>

From fantasyvideo at 126.com  Fri Dec 27 00:28:03 2013
From: fantasyvideo at 126.com (Tony)
Date: Fri, 27 Dec 2013 16:28:03 +0800 (CST)
Subject: [Live-devel] Should user release live555 resource?
Message-ID: <74690999.7ce2.143332adc1f.Coremail.fantasyvideo@126.com>

I checked the code about TaskScheduler and Environment, RtspServer,  it seems that no interface is stop the rtsp server or exit the event loop when my application exits.
Should I force it to exit?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131227/d9e52699/attachment.html>

From ssingh at neurosoft.in  Sat Dec 28 18:42:13 2013
From: ssingh at neurosoft.in (ssingh at neurosoft.in)
Date: Sun, 29 Dec 2013 08:12:13 +0530
Subject: [Live-devel] Disconnection after some time
Message-ID: <36ad28fb2dfaa7859ae01acb1f95f799@neurosoft.in>

Hi,

I am using live555 to create a unicast streaming server. I am using VLC 
as client to test the server. I observed that after few hours VLC thinks 
the connection is dropped and hence stops rendering video and audio. I 
debugged it and found that streaming server is sending SR but is not 
getting any RR. I tested it with another client and that client also 
gets disconnected after some time. If I reinitialize VLC or that client 
streaming resumes. I think there is something I am doing wrong in my 
server. Normally how does any client keep the connection alive?

Do I need to do something to keep this connection alive.

-Caduceus

From finlayson at live555.com  Sun Dec 29 00:19:13 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 29 Dec 2013 00:19:13 -0800
Subject: [Live-devel] Should user release live555 resource?
In-Reply-To: <74690999.7ce2.143332adc1f.Coremail.fantasyvideo@126.com>
References: <74690999.7ce2.143332adc1f.Coremail.fantasyvideo@126.com>
Message-ID: <E9FB86E2-B002-4DC0-BACC-095A9F76772C@live555.com>

> I checked the code about TaskScheduler and Environment, RtspServer,  it seems that no interface is stop the rtsp server or exit the event loop when my application exits.
> Should I force it to exit?

You can just call
	exit(0);
The operating system will take care of reclaiming all resources.


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/20131229/4428672e/attachment.html>

From finlayson at live555.com  Sun Dec 29 19:49:49 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 29 Dec 2013 19:49:49 -0800
Subject: [Live-devel] Disconnection after some time
In-Reply-To: <36ad28fb2dfaa7859ae01acb1f95f799@neurosoft.in>
References: <36ad28fb2dfaa7859ae01acb1f95f799@neurosoft.in>
Message-ID: <49EBBBE3-06B8-4C20-A519-C2168CC5833E@live555.com>

> I am using live555 to create a unicast streaming server. I am using VLC as client to test the server.

That's a mistake.  VLC is not our software (even though it uses our library for its RTSP/RTP client implementation).  Instead, you should first test your server using our own "testRTSPClient" or "openRTSP" client applications.


> I observed that after few hours VLC thinks the connection is dropped and hence stops rendering video and audio. I debugged it and found that streaming server is sending SR but is not getting any RR.

VLC should be sending periodic "RR" packets back to your server.  If, however, you find that "testRTSPClient" and "openRTSP" are working OK, but VLC is not, then the place to report this would be 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/20131229/0a4a9954/attachment-0001.html>

From m.plischke at q-mex.net  Tue Dec 31 00:28:54 2013
From: m.plischke at q-mex.net (Plischke, Markus)
Date: Tue, 31 Dec 2013 08:28:54 +0000
Subject: [Live-devel] playSIP and stdout file not readable
Message-ID: <3FC03CA30C03394AAF917070DDED2E53BA492F@cas.qmsx10.de>

Hi,

ich have a little problem with playSIP. My goal ist o call a asterisk server in the same network and be member in a confbridge an record everything.
So far, everything is working except reading the recording:

Command:
/usr/local/bin/playSIP -a -A 8 -u user secret sip:3 at 172.16.16.53:5060 > /root/test.alaw

SIP Log:
Sending request: INVITE sip:3 at 172.16.16.53:5060 SIP/2.0
From: user <sip:user at 172.16.16.30>;tag=2320758990
Via: SIP/2.0/UDP 172.16.16.30:55880
Max-Forwards: 70
To: sip:3 at 172.16.16.53:5060
Contact: sip:user at 172.16.16.30:55880
Call-ID: 362181582 at 172.16.16.30
CSeq: 1 INVITE
Content-Type: application/sdp
User-Agent: playSIP (LIVE555 Streaming Media v2013.12.29)
Content-Length: 115

v=0
o=- 362181582 0 IN IP4 172.16.16.30
s=playSIP session
c=IN IP4 172.16.16.30
t=0 0
m=audio 8000 RTP/AVP 8

Received INVITE response: SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.16.16.30:55880;received=172.16.16.30;rport=55880
From: user <sip:user at 172.16.16.30>;tag=2320758990
To: sip:3 at 172.16.16.53:5060
Call-ID: 362181582 at 172.16.16.30
CSeq: 1 INVITE
Server: Asterisk PBX 11.2-cert1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:3 at 172.16.16.53:5060>
Content-Length: 0


Received INVITE response: SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.16.30:55880;received=172.16.16.30;rport=55880
From: user <sip:user at 172.16.16.30>;tag=2320758990
To: sip:3 at 172.16.16.53:5060;tag=as0fde14b4
Call-ID: 362181582 at 172.16.16.30
CSeq: 1 INVITE
Server: Asterisk PBX 11.2-cert1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:3 at 172.16.16.53:5060>
Content-Type: application/sdp
Content-Length: 210

v=0
o=root 1879260998 1879260998 IN IP4 172.16.16.53
s=Asterisk PBX 11.2-cert1
c=IN IP4 172.16.16.53
t=0 0
m=audio 15144 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

Opened URL "sip:3 at 172.16.16.53:5060", returning a SDP description:
v=0
o=- 362181582 0 IN IP4 172.16.16.30
s=playSIP session
c=IN IP4 172.16.16.30
t=0 0
m=audio 8000 RTP/AVP 8

Created receiver for "audio/PCMA" subsession (client ports 8000-8001)
Setup "audio/PCMA" subsession (client ports 8000-8001)
Outputting data from the "audio/PCMA" subsession to "stdout"
Sending request: ACK sip:3 at 172.16.16.53:5060 SIP/2.0
From: user <sip:user at 172.16.16.30>;tag=2320758990
Via: SIP/2.0/UDP 172.16.16.30:55880
Max-Forwards: 70
To: sip:3 at 172.16.16.53:5060;tag=as0fde14b4
Call-ID: 362181582 at 172.16.16.30
CSeq: 1 ACK
Content-Length: 0


Started playing session
Receiving streamed data (signal with "kill -HUP 17755" or "kill -USR1 17755" to terminate)...

If i cancelt he recording, the file cant be played with nothing:

server ~ # ffprobe test.alaw
ffprobe version 1.0.8 Copyright (c) 2007-2013 the FFmpeg developers
  built on Dec 30 2013 15:28:54 with gcc 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5)
  configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --mandir=/usr/share/man --enable-shared --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --ar=x86_64-pc-linux-gnu-ar --optflags='-march=corei7 -O2 -pipe' --extra-cflags='-march=corei7 -O2 -pipe' --extra-cxxflags='-march=corei7 -O2 -pipe' --disable-static --enable-gpl --enable-postproc --enable-avfilter --enable-avresample --disable-stripping --disable-debug --disable-doc --disable-vaapi --disable-vdpau --disable-ffplay --enable-libmp3lame --enable-libtheora --disable-indev=v4l2 --disable-indev=alsa --disable-indev=oss --disable-indev=jack --disable-outdev=alsa --disable-outdev=oss --disable-outdev=sdl --enable-libvorbis --disable-amd3dnow --disable-amd3dnowext --disable-altivec --disable-avx --disable-mmxext --disable-vis --disable-neon --cpu=corei7 --enable-hardcoded-tables
  libavutil      51. 73.101 / 51. 73.101
  libavcodec     54. 59.100 / 54. 59.100
  libavformat    54. 29.104 / 54. 29.104
  libavdevice    54.  2.101 / 54.  2.101
  libavfilter     3. 17.100 /  3. 17.100
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
test.alaw: Invalid data found when processing input
server~ # file test.alaw
test.alaw: ISO-8859 text, with very long lines, with no line terminators

ffpeg supports the PCMA Codec.

What im doing wrong?

Regards
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131231/1669ed34/attachment.html>

From finlayson at live555.com  Tue Dec 31 00:45:40 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 31 Dec 2013 00:45:40 -0800
Subject: [Live-devel] playSIP and stdout file not readable
In-Reply-To: <3FC03CA30C03394AAF917070DDED2E53BA492F@cas.qmsx10.de>
References: <3FC03CA30C03394AAF917070DDED2E53BA492F@cas.qmsx10.de>
Message-ID: <0656B427-E0D9-4279-BC23-1177A374B437@live555.com>

You appear to be receiving the audio correctly, so I suspect your problem is simply that you are not decoding it properly.

The data in your file ("test.alaw") should be PCM a-law audio, 1 channel, with a sampling frequency of 8000 Hz.  You probably need to tell "ffmpeg" explicitly what kind of data this is; it probably won't be able to 'guess' the data type otherwise.


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/20131231/9360a984/attachment.html>

From m.plischke at q-mex.net  Tue Dec 31 01:04:10 2013
From: m.plischke at q-mex.net (Plischke, Markus)
Date: Tue, 31 Dec 2013 09:04:10 +0000
Subject: [Live-devel] playSIP and stdout file not readable
In-Reply-To: <0656B427-E0D9-4279-BC23-1177A374B437@live555.com>
References: <3FC03CA30C03394AAF917070DDED2E53BA492F@cas.qmsx10.de>
 <0656B427-E0D9-4279-BC23-1177A374B437@live555.com>
Message-ID: <3FC03CA30C03394AAF917070DDED2E53BA4DEE@cas.qmsx10.de>

Hi Ross,

thanks for you incredible fast answer:

ffmpeg -i test.alaw -acodec pcm_alaw -ar 8000 -ac 1 bla.mp3
ffmpeg version 1.0.8 Copyright (c) 2000-2013 the FFmpeg developers
  built on Dec 30 2013 15:28:54 with gcc 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5)
  configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --mandir=/usr/share/man --enable-shared --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --ar=x86_64-pc-linux-gnu-ar --optflags='-march=corei7 -O2 -pipe' --extra-cflags='-march=corei7 -O2 -pipe' --extra-cxxflags='-march=corei7 -O2 -pipe' --disable-static --enable-gpl --enable-postproc --enable-avfilter --enable-avresample --disable-stripping --disable-debug --disable-doc --disable-vaapi --disable-vdpau --disable-ffplay --enable-libmp3lame --enable-libtheora --disable-indev=v4l2 --disable-indev=alsa --disable-indev=oss --disable-indev=jack --disable-outdev=alsa --disable-outdev=oss --disable-outdev=sdl --enable-libvorbis --disable-amd3dnow --disable-amd3dnowext --disable-altivec --disable-avx --disable-mmxext --disable-vis --disable-neon --cpu=corei7 --enable-hardcoded-tables
  libavutil      51. 73.101 / 51. 73.101
  libavcodec     54. 59.100 / 54. 59.100
  libavformat    54. 29.104 / 54. 29.104
  libavdevice    54.  2.101 / 54.  2.101
  libavfilter     3. 17.100 /  3. 17.100
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
test.alaw: Invalid data found when processing input

Changed nothing, for example VLC also cant play the file, and vlc can play everything.

Von: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Im Auftrag von Ross Finlayson
Gesendet: Dienstag, 31. Dezember 2013 09:46
An: LIVE555 Streaming Media - development & use
Betreff: Re: [Live-devel] playSIP and stdout file not readable

You appear to be receiving the audio correctly, so I suspect your problem is simply that you are not decoding it properly.

The data in your file ("test.alaw") should be PCM a-law audio, 1 channel, with a sampling frequency of 8000 Hz.  You probably need to tell "ffmpeg" explicitly what kind of data this is; it probably won't be able to 'guess' the data type otherwise.

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/20131231/fad1933f/attachment-0001.html>

From finlayson at live555.com  Tue Dec 31 01:19:07 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 31 Dec 2013 01:19:07 -0800
Subject: [Live-devel] playSIP and stdout file not readable
In-Reply-To: <3FC03CA30C03394AAF917070DDED2E53BA4DEE@cas.qmsx10.de>
References: <3FC03CA30C03394AAF917070DDED2E53BA492F@cas.qmsx10.de>
 <0656B427-E0D9-4279-BC23-1177A374B437@live555.com>
 <3FC03CA30C03394AAF917070DDED2E53BA4DEE@cas.qmsx10.de>
Message-ID: <2B74DFBF-0BD2-47D1-BCF7-F414388AE1A3@live555.com>

First, I assume that your file is non-empty - i.e., you actually received data :-)

Assuming that your file is non-empty, then it *should* be containing PCM a-law audio, because that's what the server (Asterisk) reported.  The fact that VLC (which uses the LIVE555 RTSP/RTP client library) was able to decode and play the stream confirms this.  So the problem must be with the way that you are (trying to) decode it.  I'm not an expert on "ffmpeg", unfortunately (but perhaps someone else on this mailing list might be able to help you).


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/20131231/6765226e/attachment.html>

From finlayson at live555.com  Tue Dec 31 01:21:30 2013
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 31 Dec 2013 01:21:30 -0800
Subject: [Live-devel] playSIP and stdout file not readable
In-Reply-To: <2B74DFBF-0BD2-47D1-BCF7-F414388AE1A3@live555.com>
References: <3FC03CA30C03394AAF917070DDED2E53BA492F@cas.qmsx10.de>
 <0656B427-E0D9-4279-BC23-1177A374B437@live555.com>
 <3FC03CA30C03394AAF917070DDED2E53BA4DEE@cas.qmsx10.de>
 <2B74DFBF-0BD2-47D1-BCF7-F414388AE1A3@live555.com>
Message-ID: <39C064C7-0A13-4277-93F1-6FFAAAFE867C@live555.com>

Oops, I misread your last email.  No, of course VLC can't play the stream, because VLC doesn't include a SIP client.  So forget that...

But the fact remains that the data that you're receiving *should* contain PCM a-law audio (1 channel, 8 bits-per-sample, 8000 Hz), because that's what your server reported.


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/20131231/87585789/attachment.html>

From m.plischke at q-mex.net  Tue Dec 31 01:30:47 2013
From: m.plischke at q-mex.net (Plischke, Markus)
Date: Tue, 31 Dec 2013 09:30:47 +0000
Subject: [Live-devel] playSIP and stdout file not readable
In-Reply-To: <2B74DFBF-0BD2-47D1-BCF7-F414388AE1A3@live555.com>
References: <3FC03CA30C03394AAF917070DDED2E53BA492F@cas.qmsx10.de>
 <0656B427-E0D9-4279-BC23-1177A374B437@live555.com>
 <3FC03CA30C03394AAF917070DDED2E53BA4DEE@cas.qmsx10.de>
 <2B74DFBF-0BD2-47D1-BCF7-F414388AE1A3@live555.com>
Message-ID: <3FC03CA30C03394AAF917070DDED2E53BA4E78@cas.qmsx10.de>

The file isnt empty:
-rw-r--r--  1 root root 487200 Dec 31 09:18 test.alaw

I think you got me wrong, VLC CANT play the file.
If i try to open it, it is 0 seconds long.

Regards
Markus


Von: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Im Auftrag von Ross Finlayson
Gesendet: Dienstag, 31. Dezember 2013 10:19
An: LIVE555 Streaming Media - development & use
Betreff: Re: [Live-devel] playSIP and stdout file not readable

First, I assume that your file is non-empty - i.e., you actually received data :-)

Assuming that your file is non-empty, then it *should* be containing PCM a-law audio, because that's what the server (Asterisk) reported.  The fact that VLC (which uses the LIVE555 RTSP/RTP client library) was able to decode and play the stream confirms this.  So the problem must be with the way that you are (trying to) decode it.  I'm not an expert on "ffmpeg", unfortunately (but perhaps someone else on this mailing list might be able to help you).

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/20131231/f5156a29/attachment.html>