From galaxy at novosun.com  Fri Jan  1 21:27:50 2010
From: galaxy at novosun.com (Kam Wai-ip)
Date: Sat, 2 Jan 2010 13:27:50 +0800
Subject: [Live-devel] How to close a serverMediaSession and its subsessions
Message-ID: <3e8c80351001012127g73105830vc1e60df0a525da3b@mail.gmail.com>

Dear all
This problem confused me for quite awhile, I cannot find a right way to
close a serverMediaSession dynamically. What I need is, I want to keep the
stream server running and close one of the many sessions.
What I am doing now is simply do the following code
    m_RTSP->RemoveServerMediaSession(sms);
    sms->Close();
However, this code works only when the session does not have any refernced
client, but I need it to be closed whenever I ask it to close, without
waiting for all its clients to stop.
Moreover, I check your mailist, some said I also need to do
   Medium::close(source);
But since I create my own serverMediaSubsession inherited from
OnDemandServerMediaSubsession, and I did not find the reference of the
framedSource, so do u mean I need to reference the framedSource(s) on my own
code??
So the three questions are
  What is the correct way to close the serverMediaSession?
  How can I force a serverMediaSession and its subsessions to be closed
whenever I want it to close, without the clients sending stop signal?
  How can I get the framedSource(s) of the subsession, (I did not use
PassiveServerMediaSubsession)?

  Thanks for your time!!
                                                                  Wai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100102/1b564399/attachment.html>

From finlayson at live555.com  Fri Jan  1 22:15:28 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 1 Jan 2010 22:15:28 -0800
Subject: [Live-devel] How to close a serverMediaSession and its
 subsessions
In-Reply-To: <3e8c80351001012127g73105830vc1e60df0a525da3b@mail.gmail.com>
References: <3e8c80351001012127g73105830vc1e60df0a525da3b@mail.gmail.com>
Message-ID: <f06240801c7649312822b@[66.80.62.44]>

>This problem confused me for quite awhile, I cannot find a right way 
>to close a serverMediaSession dynamically. What I need is, I want to 
>keep the stream server running and close one of the many sessions.
>What I am doing now is simply do the following code
>     m_RTSP->RemoveServerMediaSession(sms);

Correct.

>     sms->Close();

No, there's no such function.


>However, this code works only when the session does not have any 
>refernced client, but I need it to be closed whenever I ask it to 
>close, without waiting for all its clients to stop.

There's currently no way in the code to do this (other than having 
the client send a RTSP "TEARDOWN" command).
-- 

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

From galaxy at novosun.com  Sun Jan  3 19:34:19 2010
From: galaxy at novosun.com (Kam Wai-ip)
Date: Mon, 4 Jan 2010 11:34:19 +0800
Subject: [Live-devel] How to close a serverMediaSession and its
	subsessions
In-Reply-To: <f06240801c7649312822b@66.80.62.44>
References: <3e8c80351001012127g73105830vc1e60df0a525da3b@mail.gmail.com>
	<f06240801c7649312822b@66.80.62.44>
Message-ID: <3e8c80351001031934u7f0084ck8cfc2ed8f5739c61@mail.gmail.com>

Dear Ross
  Thanks for your help.

On Sat, Jan 2, 2010 at 2:15 PM, Ross Finlayson <finlayson at live555.com>wrote:

> This problem confused me for quite awhile, I cannot find a right way to
>> close a serverMediaSession dynamically. What I need is, I want to keep the
>> stream server running and close one of the many sessions.
>> What I am doing now is simply do the following code
>>    m_RTSP->RemoveServerMediaSession(sms);
>>
>
> Correct.
>
>     sms->Close();
>>
>
> No, there's no such function.
>
>
>
>  However, this code works only when the session does not have any refernced
>> client, but I need it to be closed whenever I ask it to close, without
>> waiting for all its clients to stop.
>>
>
> There's currently no way in the code to do this (other than having the
> client send a RTSP "TEARDOWN" command).
> --
>
> 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/20100104/9145c2bc/attachment.html>

From tamira at optibase.com  Mon Jan  4 02:03:06 2010
From: tamira at optibase.com (Tamir Adari)
Date: Mon, 4 Jan 2010 12:03:06 +0200
Subject: [Live-devel] H.264 support trick-mode
References: <ABA79CDFCBDF904C80FD512CAFA64EE0846F14@ltde3k>
	<f06240812c616c9957133@[66.80.62.44]>
Message-ID: <ABA79CDFCBDF904C80FD512CAFA64EE0AB8987@ltde3k>

Hi,

 

It's been a while since my last query.

Any update on the "trick play" for H.264 transport?

Do you have estimation when it will be supported?

 

Thanks,

_________________________

Tamir Adari

Software System Architect

Optibase Ltd.

Tel: 972-9-9709121

________________________________

From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: 24 April, 2009 4:50 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H.264 support trick-mode

 

	It seems that the live555 media server supports H.264 multiplexed as transport (.ts).

	Please update it in: <http://www.live555.com/mediaServer/#about <http://www.live555.com/mediaServer/#about> >

 

There's nothing to update on that page.  We support the streaming of MPEG Transport Stream files, regardless of what they happen to contain.

 

However, I have now updated the '"Trick Play' support" web page - http://www.live555.com/liveMedia/transport-stream-trick-play.html - to make clear that we currently support these 'trick play' operations only on Transport Stream files that contain MPEG-1 or MPEG-2 video - not MPEG-4 (including H.264) video.

 

 

	Is there a plan to support it in the near future for trick-mode as well?


Yes.

	 Any scheduled date for this?

 

No.

-- 


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

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

From rose.roo at sidc.com.tw  Tue Jan  5 01:03:15 2010
From: rose.roo at sidc.com.tw (=?UTF-8?B?Iue+hee/jOS+gShSUiki?=)
Date: Tue, 05 Jan 2010 17:03:15 +0800
Subject: [Live-devel] RTSP trick play, extra PES packet issue...
Message-ID: <4B430053.6070707@sidc.com.tw>

Afternoon Ross Finlayson from live network :

Please visit our FTP site with following account information

    * IP: "60.250.38.86"
    * Username: "live555"
    * Password: "live555"
    * Path: "/"

There are some MPEG2 TS files, and each one was :

   1. Mermaid.ts
          * Original MPEG2 TS file
   2. Mermaid.tsx
          * Index of #1
   3. Mermaid_FF2x_openRTSP.ts
          * FF 2x, generated from openRTSP
          * FF from 00:15 to 01:15
          * The result was almost like #4, except some broken frame
   4. Mermaid_FF2x_test.ts
          * FF 2x, generated from testMPEG2TransportStreamTrickPlay
          * FF 2x from 0:15
   5. Mermaid_FF8x_test.ts
          * FF 8x, generated from testMPEG2TransportStreamTrickPlay
          * FF 8x from 0:15
   6. Mermaid_RW2x_openRTSP.ts
          * RW 2x, generated from openRTSP
          * RW 2x from 01:15 to 00:15
          * The result was almost like #7, except some broken frame
   7. Mermaid_RW2x_test.ts
          * RW 2x, generated from testMPEG2TransportStreamTrickPlay
          * RW 2x from 01:15 to 00:00
   8. Mermaid_RW8x_test.ts
          * RW 8x, generated from testMPEG2TransportStreamTrickPlay
          * RW 8x from 01:15 to 00:00

FYR.

But also, would like to ask some questions...

After analyzed packet with WireShark(tm), we found that LIVE555 will send an
extra PES head packet in each UDP packet, and let 7 TS packet become 6 
TS packet.
(to fit maximum size of 1 UDP packet)
And that caused decoder (VIA's MPEG2 SDK, with CX700M chip) can't work,
so that picture was frozen...

We'll try to push VIA if they can solve their SDK to keep it work.
But also:

   1. What reason let the extra PES packet there ?
   2. Is that possible I can modify the source code to remove it ?
          * If so, which .cpp file should I looked for ?


Any suggestions are welcome~_~

RR @ 2010/01/05
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100105/bced53c9/attachment.html>

From finlayson at live555.com  Tue Jan  5 01:23:41 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 5 Jan 2010 01:23:41 -0800
Subject: [Live-devel] RTSP trick play, extra PES packet issue...
In-Reply-To: <4B430053.6070707@sidc.com.tw>
References: <4B430053.6070707@sidc.com.tw>
Message-ID: <f06240805c768b3ae3350@[66.80.62.44]>

>There are some MPEG2 TS files, and each one was :
>
>1.	Mermaid.ts
>Original MPEG2 TS file
>2.	Mermaid.tsx
>Index of #1
>3.	Mermaid_FF2x_openRTSP.ts
>FF 2x, generated from openRTSP
>FF from 00:15 to 01:15
>The result was almost like #4, except some broken frame
>4.	Mermaid_FF2x_test.ts
>FF 2x, generated from testMPEG2TransportStreamTrickPlay
>FF 2x from 0:15
>5.	Mermaid_FF8x_test.ts
>FF 8x, generated from testMPEG2TransportStreamTrickPlay
>FF 8x from 0:15
>6.	Mermaid_RW2x_openRTSP.ts
>RW 2x, generated from openRTSP
>RW 2x from 01:15 to 00:15
>The result was almost like #7, except some broken frame
>7.	Mermaid_RW2x_test.ts
>RW 2x, generated from testMPEG2TransportStreamTrickPlay
>RW 2x from 01:15 to 00:00
>8.	Mermaid_RW8x_test.ts
>RW 8x, generated from testMPEG2TransportStreamTrickPlay
>RW 8x from 01:15 to 00:00
>FYR.
>
>But also, would like to ask some questions...
>
>After analyzed packet with WireShark(tm), we found that LIVE555 will send an
>extra PES head packet in each UDP packet

Our Transport Stream RTP streaming code will transmit exactly the 
Transport Stream data that it was given (plus RTP headers, of 
course).  Therefore, if you are seeing extra PES header data in the 
network packets, then this data must have been present in the 
Transport Stream data that's being streamed.  Therefore this extra 
PES header data will (most likely) also be in at least some of the 
".ts" files that you list above.

To make it easier for me to track down your problem, could you please 
say which of the seven ".ts" files that you list above contain this 
extra PES header data?
-- 

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/20100105/e48cf1eb/attachment.html>

From vikasjkmcs2005 at yahoo.co.in  Tue Jan  5 23:01:40 2010
From: vikasjkmcs2005 at yahoo.co.in (vikas srivastava)
Date: Tue, 5 Jan 2010 23:01:40 -0800 (PST)
Subject: [Live-devel] RTSP to UDP
Message-ID: <748883.75160.qm@web95308.mail.in2.yahoo.com>

Hi Ross,

?? I am new to your Live555 library so do you have any sample code from receiving in RTSP and then re streaming over UDP.I got
sample code for receiving in RTSP but how again re stream it over UDP or RTSP instead of saving to file , did't get. 


Thanks
Vikas


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100105/bacc43ec/attachment.html>

From finlayson at live555.com  Wed Jan  6 00:28:39 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 6 Jan 2010 00:28:39 -0800
Subject: [Live-devel] RTSP to UDP
In-Reply-To: <748883.75160.qm@web95308.mail.in2.yahoo.com>
References: <748883.75160.qm@web95308.mail.in2.yahoo.com>
Message-ID: <f06240801c769fa15df50@[66.80.62.44]>

>    I am new to your Live555 library so do you have any sample code 
>from receiving in RTSP and then re streaming over UDP.

No.

>I got
>sample code for receiving in RTSP but how again re stream it over 
>UDP or RTSP instead of saving to file

You could do this by using a "RTPSink" object instead of a "FileSink".
-- 

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

From rose.roo at sidc.com.tw  Wed Jan  6 02:02:11 2010
From: rose.roo at sidc.com.tw (=?UTF-8?B?Iue+hee/jOS+gShSUiki?=)
Date: Wed, 06 Jan 2010 18:02:11 +0800
Subject: [Live-devel] RTSP trick play, extra PES packet issue...
Message-ID: <4B445FA3.2040006@sidc.com.tw>

Afternoon Ross Finlayson from live network :

Please visit our FTP site with following account information

    * IP: "60.250.38.86"
    * Username: "live555"
    * Password: "live555"
    * Path: "/"


We had tested Live555 as RTSP server, and another RTSP server named 
"Streaming 21" (We called it as S21 below)
There are some more files added in our FTP site, and each new one is :

   1. SiDC_RTSP_LIVE555.gif
          * Screen shot of #2, between normal play and FF2x play
   2. SiDC_RTSP_LIVE555.pcap
          * WIRESHARK <http://www.wireshark.org/download.html> captured
            packet, that's our own RTSP client playback MPEG2 TS from
            Live555
   3. SiDC_RTSP_S21.gif
          * Screen shot of #4, between normal play and FF2x play
   4. SiDC_RTSP_S21.pcap
          * WIRESHARK <http://www.wireshark.org/download.html> captured
            packet, that's our own RTSP client playback MPEG2 TS from S21

FYR.
The all packet(s) (from Live555 or from Streaming 21) ware sent to VIA's 
MPEG decoder to played MPEG2 video back.
Here are situations:

    * Our own RTSP client start to request Live555 to play Mermaid.ts
          o Video playing...
    * Our own RTSP client send FF2x to Live555
          o Video picture was frozen
    * Our own RTSP client send normal play to Live555
          o Video picture just continued playing in normal

    * Our own RTSP client start to request S21 to play Mermaid.ts
          o Video playing...
    * Our own RTSP client sendFF2x to S21
          o Video picture playing in fast forward mode
    * Our own RTSP client send normal play to S21
          o Video picture just continued playing in normal

After our own RTSP client sent a FF2x command to Live555, Live555 is 
begin to send fast forwarded data packet(s).
But according to file "SiDC_RTSP_LIVE555.pcap", Live555 will send an 
extra PES header packet in each 6 TS packets.
(But if)
That cause VIA's MPEG2 decoder failed to parse, and result is video 
picture froze...

Still would like to know :

   1. What reason let the extra PES header packet there ?
   2. Is that possible we can modify the source code to remove it ?
          * If so, which .cpp file should we looked for ?


~very thanks for your help~

RR @ 2010/01/06
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100106/5830810a/attachment.html>

From gbonneau at miranda.com  Wed Jan  6 06:11:14 2010
From: gbonneau at miranda.com (BONNEAU Guy)
Date: Wed, 6 Jan 2010 09:11:14 -0500
Subject: [Live-devel] Multiple Network Adapter
Message-ID: <6353CA579307224BAFDE9495906E691603B93A50@ca-ops-mail>

If you have a system with multiple NIC interfaces is there a method or
some standard way to tell the live555 library to which NIC (IP address)
to bind the sockets created for the RTP streaming? Or I need to modify
the code of the library to change the default behavior which seems to be
(in groupsockhelper.cpp): 

// By default, use INADDR_ANY for the sending and receiving interfaces:
netAddressBits SendingInterfaceAddr   = INADDR_ANY;
netAddressBits ReceivingInterfaceAddr = INADDR_ANY;

Thanks
GB

From finlayson at live555.com  Wed Jan  6 02:46:38 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 6 Jan 2010 02:46:38 -0800
Subject: [Live-devel] RTSP trick play, extra PES packet issue...
In-Reply-To: <4B445FA3.2040006@sidc.com.tw>
References: <4B445FA3.2040006@sidc.com.tw>
Message-ID: <f06240802c76a19ad4706@[66.80.62.44]>

>Still would like to know :
>
>1.	What reason let the extra PES header packet there ?

And I would still like to know:
	Which (if any) of the Transport Stream files on your FTP site 
contain this extra PES header data?  As I noted in my last message, 
our code transmits Transport Stream data 'as is', so any extra PES 
header data is probably also present in (at least some of) these 
files themselves.

I'm not going to take a look at this (alleged) bug unless you tell me 
specifically which file(s) on your FTP site contain this extra PES 
header data (and where).
-- 

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/20100106/55ce939e/attachment.html>

From a.nemec at atlas.cz  Wed Jan  6 05:30:39 2010
From: a.nemec at atlas.cz (=?utf-8?B?TsSbbWVjIEFsZXhhbmRy?=)
Date: Wed, 06 Jan 2010 13:30:39 GMT
Subject: [Live-devel] parseGeneralConfigStr
Message-ID: <465ac1cc67e94bfdbdeaf9219eb98e5e@03ad07a700e144e1a7e7cdd213f77bb5>

An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100106/80f7125b/attachment.html>
-------------- next part --------------
Dear all,
why does the parseGeneralConfigStr function (used for parsing the MPEG4 configuration header) return one more byte than I would expect?
Having a configuration string C the resulting byte array should have strlen(C)/2 bytes. Of course, if strlen(C) is odd (which should normally not be the case) it is safe to calculate the number of bytes as (strlen(C)+1)/2 which gives the same result for even numbers. But in the code the number of bytes is calculated as configSize = (strlen(configStr)+1)/2 + 1, which seems to leave one byte in the resulting byte array untouched filled with garbage. We discovered this issue after comparing the MPEG4 configuration bytes from live555 code with the data that we parsed out manually of a MPEG4 bitstream. MPEG4 decoders will not complain about this garbage byte, but I am correct that the last byte produced by the parseGeneralConfigStr function does not belong to the configuration header or am I completely wrong?
Thanks
Alex

From finlayson at live555.com  Wed Jan  6 08:43:57 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 6 Jan 2010 08:43:57 -0800
Subject: [Live-devel] Multiple Network Adapter
In-Reply-To: <6353CA579307224BAFDE9495906E691603B93A50@ca-ops-mail>
References: <6353CA579307224BAFDE9495906E691603B93A50@ca-ops-mail>
Message-ID: <f06240803c76a6ca71bc9@[66.80.62.44]>

>If you have a system with multiple NIC interfaces is there a method or
>some standard way to tell the live555 library to which NIC (IP address)
>to bind the sockets created for the RTP streaming? Or I need to modify
>the code of the library to change the default behavior which seems to be
>(in groupsockhelper.cpp):
>
>// By default, use INADDR_ANY for the sending and receiving interfaces:
>netAddressBits SendingInterfaceAddr   = INADDR_ANY;
>netAddressBits ReceivingInterfaceAddr = INADDR_ANY;

Those are global variables; not constants.  So you don't need to 
change the library code at all to change their values; just do so at 
the start of your application - e.g.
	ReceivingInterfaceAddre = our_inet_addr("10.0.1.2");
-- 

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

From gbonneau at miranda.com  Wed Jan  6 09:25:25 2010
From: gbonneau at miranda.com (BONNEAU Guy)
Date: Wed, 6 Jan 2010 12:25:25 -0500
Subject: [Live-devel] Multiple Network Adapter
In-Reply-To: <f06240803c76a6ca71bc9@[66.80.62.44]>
References: <6353CA579307224BAFDE9495906E691603B93A50@ca-ops-mail>
	<f06240803c76a6ca71bc9@[66.80.62.44]>
Message-ID: <6353CA579307224BAFDE9495906E691603B93C3E@ca-ops-mail>

Yes, indeed !

However even thought that this is not officially supported the library
works well using careful multi-threaded instance of the task scheduler
object (see a post dated 2009-12-11). If you want each thread to have an
independent NIC I'm afraid this could cause a potential issue because
each thread might mess with those global variables. 

Putting those variables in the socket object and adding a constructor to
create the socket with a specific NIC would make the library much more
thread safe.

Thanks for the suggestion.
GB

>-----Original Message-----
>From: live-devel-bounces at ns.live555.com [mailto:live-devel-
>bounces at ns.live555.com] On Behalf Of Ross Finlayson
>Sent: Wednesday, January 6, 2010 11:44
>To: LIVE555 Streaming Media - development & use
>Subject: Re: [Live-devel] Multiple Network Adapter
>
>>If you have a system with multiple NIC interfaces is there a method or
>>some standard way to tell the live555 library to which NIC (IP
address)
>>to bind the sockets created for the RTP streaming? Or I need to modify
>>the code of the library to change the default behavior which seems to
>be
>>(in groupsockhelper.cpp):
>>
>>// By default, use INADDR_ANY for the sending and receiving
interfaces:
>>netAddressBits SendingInterfaceAddr   = INADDR_ANY;
>>netAddressBits ReceivingInterfaceAddr = INADDR_ANY;
>
>Those are global variables; not constants.  So you don't need to
>change the library code at all to change their values; just do so at
>the start of your application - e.g.
>	ReceivingInterfaceAddre = our_inet_addr("10.0.1.2");
>--
>
>Ross Finlayson
>Live Networks, Inc.
>http://www.live555.com/
>_______________________________________________
>live-devel mailing list
>live-devel at lists.live555.com
>http://lists.live555.com/mailman/listinfo/live-devel

From gbonneau at miranda.com  Wed Jan  6 12:55:42 2010
From: gbonneau at miranda.com (BONNEAU Guy)
Date: Wed, 6 Jan 2010 15:55:42 -0500
Subject: [Live-devel] TrackId= Vs track in a=control:<track-id>
Message-ID: <6353CA579307224BAFDE9495906E691603C297A5@ca-ops-mail>

I have an RTSP client (not live555) that complains of the
a=control:track format used by the RTSP server (live555 application)
implementation of the live555 library. When I change the code of the
library to use a=control:trackID= the RTSP client doesn`t complain
anymore. The examples in the RTSP specification use the format
a=control:trackID=. I googled trying to find what is the issue without
success. May be both format are legal and the issue is with the RTSP
client but I cannot find any information on the WEB regarding this.
Anyone could shed some light about this issue?

 

Thanks

GB

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

From lanlantao at gmail.com  Wed Jan  6 13:02:46 2010
From: lanlantao at gmail.com (Tao Wu)
Date: Wed, 6 Jan 2010 15:02:46 -0600
Subject: [Live-devel] Private data in H264 RTP/RTSP stream
Message-ID: <712d99b31001061302j570ea62cm58eab896727b621d@mail.gmail.com>

Hi,

I want to add some use private data (like camera locations, etc)
periodically to H264 video stream. This rate of these private data is very
slow, like 10Kbps.
One way (A) is to create a separate "faked" video stream for the
transmission using libmedia's rtp/rtsp library. Since rtp/rtsp does not care
about the contend of the video streams, it is doable. But the con of this
approach is losing the synchronization of the private data and video stream,
which is important for us.
The other way (B) is to "attach" these private data to H264 streams at the
server side, and "remove" them at a customized client. The con of it is the
compatibility. Standard video player might crash. Is there any way (frame
definition) in H264 standard that allows standard video player to "drop"
these attached private data (frame)?
Thanks for any comment.

Best Regards,
Tao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100106/1f0db52f/attachment.html>

From robert_pletscher at yahoo.com  Wed Jan  6 18:39:20 2010
From: robert_pletscher at yahoo.com (Robert Pletscher)
Date: Wed, 6 Jan 2010 18:39:20 -0800 (PST)
Subject: [Live-devel] stream part of a video file
Message-ID: <338311.30050.qm@web53605.mail.re2.yahoo.com>

I'm working on a project based on live555, where we want to enable the user to play a part of the recorded video, for instance for a 60 minutes video, the user may choose to play it from 0:20 to 0:40. How can this be accomplished, to only stream the part the user wants to see?
I'm looking forward to hearing from you soon.

Yours,

Robert

*************************************************
Robert Pletscher
mobile: +86-136-2111 5464
mail to: Robert_Pletscher at yahoo.com


      

From finlayson at live555.com  Wed Jan  6 19:36:20 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 6 Jan 2010 19:36:20 -0800
Subject: [Live-devel] parseGeneralConfigStr
Message-ID: <f06240801c76b06ef233f@[66.80.62.44]>

>why does the parseGeneralConfigStr function (used for parsing the 
>MPEG4 configuration header) return one more byte than I would expect?

Thanks - you've identified a bug in the code.  That extra byte should 
not be there (this code was mistakenly copied from 
"parseStreamMuxConfigStr()", which *does* require an extra byte).

This bug will be fixed in the next release of the code.
-- 

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

From vikasjkmcs2005 at yahoo.co.in  Wed Jan  6 19:56:21 2010
From: vikasjkmcs2005 at yahoo.co.in (vikas srivastava)
Date: Thu, 7 Jan 2010 09:26:21 +0530 (IST)
Subject: [Live-devel] Is this correct code
Message-ID: <605581.39875.qm@web95315.mail.in2.yahoo.com>

Hi Ross,

?????? I am using your Live555 and facing some difficulties , i am receiving stream over rtp and saving to file , following is the code

int
?
TaskScheduler* scheduler = BasicTaskScheduler::createNew();
UsageEnvironment*env = BasicUsageEnvironment::createNew(*scheduler);
?main(intargc, char** argv) {
FileSink* fileSink;//Dot specify codecfileSink =FileSink::createNew(*env, 
?"test");
//**********************For RTP Stream receiving **************************sessionAddress.s_addr = our_inet_addr(sessionAddressStr);
Groupsock rtpGroupsock(*env, sessionAddress, rtpPort, ttl);
Groupsock rtcpGroupsock(*env, sessionAddress, rtcpPort, ttl);
source = MPEG1or2VideoRTPSource::createNew(*env, &rtpGroupsock); charconst* sessionAddressStr= "10.69.169.149";constunsignedshortrtpPortNum = 8888;constunsignedshortrtcpPortNum = rtpPortNum+1;constunsignedcharttl = 2;structin_addr sessionAddress;constPort rtpPort(rtpPortNum);constPort rtcpPort(rtcpPortNum);constunsignedestimatedSessionBandwidth = 160; // in kbps; for RTCP b/w sharegethostname((
CNAME[maxCNAMElen] = constunsignedmaxCNAMElen = 100;unsignedcharCNAME[maxCNAMElen+1];char*)CNAME, maxCNAMElen);'\0'; // just in caseRTCPInstance* rtcpInstance=RTCPInstance::createNew(*env, &rtcpGroupsock,
estimatedSessionBandwidth, CNAME,
NULL 
?fileSink->startPlaying(*source, afterPlaying, NULL);
env->taskScheduler().doEventLoop();return0;
?
}
?voidafterPlaying(void* /*clientData*/) {//Medium::close(videoSource);//For RTPMedium::close(source);
}
?
this code never give any error but still not saving inside file , file size is?always to zero .
Pls help me out wht might be the reason.
?
Thaanks
Vikas/* we're a client */, source);


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100107/80a1e157/attachment.html>

From rose.roo at sidc.com.tw  Wed Jan  6 21:34:29 2010
From: rose.roo at sidc.com.tw (=?UTF-8?B?Iue+hee/jOS+gShSUiki?=)
Date: Thu, 07 Jan 2010 13:34:29 +0800
Subject: [Live-devel] RTSP trick play, extra PES packet issue...
Message-ID: <4B457265.80701@sidc.com.tw>

Hi Ross Finlayson from live network :

Ross Finlayson says:

    I'm not going to take a look at this (alleged) bug unless you tell me 
    specifically which file(s) on your FTP site contain this extra PES 
    header data (and where).


Sorry that's my fault, I forget to notify you about that...
Please visit our FTP site with following account information

    * IP: "60.250.38.86"
    * Username: "live555"
    * Password: "live555"
    * Path: "/"

The original Transport Stream file that we're using on Live555 & 
Streaming 21,
is "*Mermaid.ts*", at */original_TS/* of our FTP site now, and will put 
some other TS file soon.

I'm not very good in English reading, but I'll do my best to understand 
what you really meaning,
and much thanks for your help~


RR @ 2010/01/07
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100107/19a73999/attachment-0001.html>

From robert_pletscher at yahoo.com  Wed Jan  6 23:17:09 2010
From: robert_pletscher at yahoo.com (Robert Pletscher)
Date: Wed, 6 Jan 2010 23:17:09 -0800 (PST)
Subject: [Live-devel] save mpeg 1 file using openRTSP
Message-ID: <764805.39745.qm@web53603.mail.re2.yahoo.com>

I'm writing to ask if it is possible to save an mpeg 1 file from the stream received using openRTSP and how this can be implemented. I haven't seen this possibility in the example code. Furthermore, I would like to know if it is possible to have the mpeg 1 file stored in memory instead of in a file to directly save it in a database without saving it to disk first.
I'm looking forward to hearing from you soon.

Yours,

Robert

*************************************************
Robert Pletscher
mobile: +86-136-2111 5464
mail to: Robert_Pletscher at yahoo.com


      

From rose.roo at sidc.com.tw  Wed Jan  6 23:24:50 2010
From: rose.roo at sidc.com.tw (=?UTF-8?B?Iue+hee/jOS+gShSUiki?=)
Date: Thu, 07 Jan 2010 15:24:50 +0800
Subject: [Live-devel] RTSP trick play, extra PES packet issue...
Message-ID: <4B458C42.80005@sidc.com.tw>

Afternoon Ross Finlayson from live network :

I had put 1 more Transport Stream file on our FTP site.
Now we have 2 TS files there...
"Mermaid.ts" & "ChronoCross.ts", FYR.

Please visit our FTP site with following account information

    * IP: "60.250.38.86"
    * Username: "live555"
    * Password: "live555"
    * Path: "/original_TS/"


Let me try to express our situation again...

   1. We used "Mermaid.ts"*** as Transport Stream source, streaming it
      via Live555 (RTSP).
   2. The RTSP client is our own RTSP player.
   3. Using Wireshark to capture packet(s) from Live555 to RTSP client,
      for analysis.

**** *(The "Mermaid.ts" is in our FTP site, which located on 
"/original_TS/")

In same time period of "Mermaid.ts", for example, 00:15 ~ 01:15

    * Play it in normal play mode
          o The packet(s) Live555 send are normal TS packet
    * Play it in FF2x mode
          o The packet(s) Live555 send comes with much extra PES header
            packet



I'm not sure if it is a bug, if you need us to present more information 
to make it clear, please tell me.
I'll done it as best as I can do.

Much thanks for your help~ ^_^

RR @ 2010/01/07
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100107/161c57c0/attachment.html>

From vikasjkmcs2005 at yahoo.co.in  Thu Jan  7 00:53:24 2010
From: vikasjkmcs2005 at yahoo.co.in (vikas srivastava)
Date: Thu, 7 Jan 2010 14:23:24 +0530 (IST)
Subject: [Live-devel] Saved H.264 file doent Play
Message-ID: <918642.85622.qm@web95316.mail.in2.yahoo.com>

Hi Ross,

??????????I am receiving stream from server which sends stream in H.264 format over RTSP , i used your openRTSP to save the stream but? saved file doent show Video (I used VLC) , but when i received stream in MPeg1 or 2 format then i could see the file with VLC play.

????????? What is problem with H.264 format , i saw you are using sperate H264VideoFileSink class.So where might be the problem , with the stream or openRTSP.

Thanks
Vikas????????? ?

________________________________

The INTERNET now has a personality. YOURS! See your Yahoo! Homepage.


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100107/a2ebb232/attachment.html>

From finlayson at live555.com  Thu Jan  7 02:17:46 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 7 Jan 2010 02:17:46 -0800
Subject: [Live-devel] Saved H.264 file doent Play
In-Reply-To: <918642.85622.qm@web95316.mail.in2.yahoo.com>
References: <918642.85622.qm@web95316.mail.in2.yahoo.com>
Message-ID: <f06240802c76b65114e1c@[66.80.62.44]>

>           I am receiving stream from server which sends stream in 
>H.264 format over RTSP , i used your openRTSP to save the stream but 
>saved file doent show Video (I used VLC) , but when i received 
>stream in MPeg1 or 2 format then i could see the file with VLC play.

This is a problem with VLC; it doesn't play H.264 format files.

However, VLC is not our software, and this is not a VLC mailing list.
-- 

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

From finlayson at live555.com  Thu Jan  7 02:35:42 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 7 Jan 2010 02:35:42 -0800
Subject: [Live-devel] TrackId= Vs track in a=control:<track-id>
In-Reply-To: <6353CA579307224BAFDE9495906E691603C297A5@ca-ops-mail>
References: <6353CA579307224BAFDE9495906E691603C297A5@ca-ops-mail>
Message-ID: <f06240803c76b66ebbd3f@[66.80.62.44]>

>I have an RTSP client (not live555) that complains of the 
>a=control:track format used by the RTSP server (live555 application) 
>implementation of the live555 library. When I change the code of the 
>library to use a=control:trackID= the RTSP client doesn`t complain 
>anymore. The examples in the RTSP specification use the format 
>a=control:trackID=.

Actually, the RTSP specification (RFC 2326) uses several different 
example track names - "audio.en", "audio", "video", "streamid=0", 
"movie.aud", "movie.vid", "trackID=1", "trackID=2".  All are legal, 
as is "track<n>", which is what our server uses.

If your client assumes that a track name - specified by the server - 
will be in one particular form only, then it's broken, and should be 
fixed.
-- 

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

From finlayson at live555.com  Thu Jan  7 02:40:24 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 7 Jan 2010 02:40:24 -0800
Subject: [Live-devel] stream part of a video file
In-Reply-To: <338311.30050.qm@web53605.mail.re2.yahoo.com>
References: <338311.30050.qm@web53605.mail.re2.yahoo.com>
Message-ID: <f06240804c76b6a40853d@[66.80.62.44]>

>I'm working on a project based on live555, where we want to enable 
>the user to play a part of the recorded video, for instance for a 60 
>minutes video, the user may choose to play it from 0:20 to 0:40. How 
>can this be accomplished, to only stream the part the user wants to 
>see?

This is easy to do.  Look at how the "openRTSP" code implements the
	-s <initial-seek-time>
and
	-d <duration>
options, e.g.
	openRTSP -s 20 -d 20 rtsp://url
-- 

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

From gbonneau at miranda.com  Thu Jan  7 06:58:43 2010
From: gbonneau at miranda.com (BONNEAU Guy)
Date: Thu, 7 Jan 2010 09:58:43 -0500
Subject: [Live-devel] TrackId= Vs track in a=control:<track-id>
In-Reply-To: <f06240803c76b66ebbd3f@[66.80.62.44]>
References: <6353CA579307224BAFDE9495906E691603C297A5@ca-ops-mail>
	<f06240803c76b66ebbd3f@[66.80.62.44]>
Message-ID: <6353CA579307224BAFDE9495906E691603C2994F@ca-ops-mail>

Yes you're right! I dug out the RTSP specification and I have to agree
with your comment ! I'll check that with the vendor of the RTSP client.

BTW while digging in the specification RFC 2326 I found that section 3.4
says that the session Identifiers MUST be chosen randomly and MUST be at
least eight octets long to make guessing it more difficult. Yet a fast
look at the live555 library code seems to show that is doesn't choose a
random session ID and is not at least 8 octets long. Could you please
comment.

Thanks
GB

>-----Original Message-----
>From: live-devel-bounces at ns.live555.com [mailto:live-devel-
>bounces at ns.live555.com] On Behalf Of Ross Finlayson
>Sent: Thursday, January 7, 2010 5:36
>To: LIVE555 Streaming Media - development & use
>Subject: Re: [Live-devel] TrackId= Vs track in a=control:<track-id>
>
>>I have an RTSP client (not live555) that complains of the
>>a=control:track format used by the RTSP server (live555 application)
>>implementation of the live555 library. When I change the code of the
>>library to use a=control:trackID= the RTSP client doesn`t complain
>>anymore. The examples in the RTSP specification use the format
>>a=control:trackID=.
>
>Actually, the RTSP specification (RFC 2326) uses several different
>example track names - "audio.en", "audio", "video", "streamid=0",
>"movie.aud", "movie.vid", "trackID=1", "trackID=2".  All are legal,
>as is "track<n>", which is what our server uses.
>
>If your client assumes that a track name - specified by the server -
>will be in one particular form only, then it's broken, and should be
>fixed.
>--
>
>Ross Finlayson
>Live Networks, Inc.
>http://www.live555.com/
>_______________________________________________
>live-devel mailing list
>live-devel at lists.live555.com
>http://lists.live555.com/mailman/listinfo/live-devel

From a.nemec at atlas.cz  Thu Jan  7 23:17:44 2010
From: a.nemec at atlas.cz (=?utf-8?B?TsSbbWVjIEFsZXhhbmRy?=)
Date: Fri, 08 Jan 2010 07:17:44 GMT
Subject: [Live-devel] parseGeneralConfigStr
Message-ID: <a728df7596be42e4b5921734b8bd5cc8@50bcafbb18994c7fa8b49ce3dca6ac07>

Hi Ross,

1. Thanks for your reply. Just for anybody who wants to receive the correct mpeg4 configuration header, the solution is simple.

One must replace

configSize = (strlen(configStr)+1)/2 + 1;

with

configSize = (strlen(configStr)+1)/2;

to receive the correct length. Next (to prevent a NULL return value) the i variable must only be incremented on parseSuccess.

parseSuccess = getByte(configStr, config[i++]);

can be replaced with

parseSuccess = getByte(configStr, config[i]);
if (parseSuccess) i++;

Then the correct mpeg4 configuration header will be returned.

2. I have a second question about live555 stability in long run tests. We plan to use live555 (the client side) to receive and record streams from cameras with built-in RTSP servers. I am not aware of any other RTSP/RTP implementation that we could use, I think there are not many of them out there for the client side (GPL or commercial) or did I overlook any robust RTSP/RTP implementations? What we plan to do is to use a camera to monitor a building construction for example saving one image per minute to be able to make a fast running presentation video after one year showing how the building has been constructed. So we need the RTSP client to run very stable for long running periods (maybe a year). Even a minimal memory leak would be a problem. Does anybody have experience with running RTSP client for very long time to receive media? Are there any known stability problems or memory leaks or whatever on the client side? Thanks for any comment.

Best regards
Alex

>---------------------------------------------------------
>Od: Ross Finlayson
>P?ijato: 7.1.2010 7:49:55
>P?edm?t: Re: [Live-devel] parseGeneralConfigStr
>
>>why does the parseGeneralConfigStr function (used for parsing the 
>
>>MPEG4 configuration header) return one more byte than I would expect?
>
>
>
>Thanks - you've identified a bug in the code.  That extra byte should 
>
>not be there (this code was mistakenly copied from 
>
>"parseStreamMuxConfigStr()", which *does* require an extra byte).
>
>
>
>This bug will be fixed in the next release of the code.
>
>-- 
>
>
>
>Ross Finlayson
>
>Live Networks, Inc.
>
>http://www.live555.com/
>
>_______________________________________________
>
>live-devel mailing list
>
>live-devel at lists.live555.com
>
>http://lists.live555.com/mailman/listinfo/live-devel
>
>
>
>

From finlayson at live555.com  Thu Jan  7 23:30:44 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 7 Jan 2010 23:30:44 -0800
Subject: [Live-devel] parseGeneralConfigStr
In-Reply-To: <a728df7596be42e4b5921734b8bd5cc8@50bcafbb18994c7fa8b49ce3dca6ac07>
References: <a728df7596be42e4b5921734b8bd5cc8@50bcafbb18994c7fa8b49ce3dca6ac07>
Message-ID: <f06240800c76c8f5260cf@[66.80.62.44]>

>Hi Ross, 1. Thanks for your reply. Just for anybody who wants to 
>receive the correct mpeg4 configuration header, the solution is 
>simple. One must replace

No, it's even easier: Replace your current version of the code with 
the latest version (2010.01.07), which fixes the bug.
-- 

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

From finlayson at live555.com  Fri Jan  8 01:56:31 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 8 Jan 2010 01:56:31 -0800
Subject: [Live-devel] TrackId= Vs track in a=control:<track-id>
In-Reply-To: <6353CA579307224BAFDE9495906E691603C2994F@ca-ops-mail>
References: <6353CA579307224BAFDE9495906E691603C297A5@ca-ops-mail>
	<f06240803c76b66ebbd3f@[66.80.62.44]>
	<6353CA579307224BAFDE9495906E691603C2994F@ca-ops-mail>
Message-ID: <f06240801c76cb0ff4548@[66.80.62.44]>

>BTW while digging in the specification RFC 2326 I found that section 3.4
>says that the session Identifiers MUST be chosen randomly and MUST be at
>least eight octets long to make guessing it more difficult. Yet a fast
>look at the live555 library code seems to show that is doesn't choose a
>random session ID and is not at least 8 octets long.

Thanks for the 'heads up'.  This will be fixed in the next release of the code.
-- 

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

From a.nemec at atlas.cz  Fri Jan  8 10:20:04 2010
From: a.nemec at atlas.cz (=?utf-8?B?TsSbbWVjIEFsZXhhbmRy?=)
Date: Fri, 08 Jan 2010 18:20:04 GMT
Subject: [Live-devel] live555 and VLC question
Message-ID: <dbff67ea337142918ba6c8292e1b36e6@c9c9e8942ca5421a8cd82eb39e69c364>

An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100108/6db8df78/attachment.html>
-------------- next part --------------
Dear all,
we have downloaded the VLC player and we realized the live555 code is used in it (well, we are new to the scene). We studied the VLC code but it is not obvious to us, what parts of live555 streaming media library the VLC player is using. We thought that the VLC player uses live555 code whenever it needs to contact a RTSP server and to receive data via RTP. But there seem to be other code files in the VLC project covering the RTSP and RTP implementations. So what is the relation here? We just want to make this clear to be able to understand both code packages (live555 and VLC correctly).
Thanks
Alex

From finlayson at live555.com  Fri Jan  8 12:53:25 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 8 Jan 2010 12:53:25 -0800
Subject: [Live-devel] parseGeneralConfigStr
Message-ID: <f06240804c76d4bbbbcac@[66.80.62.44]>

>2. I have a second question about live555 stability in long run 
>tests. We plan to use live555 (the client side) to receive and 
>record streams from cameras with built-in RTSP servers. I am not 
>aware of any other RTSP/RTP implementation that we could use, I 
>think there are not many of them out there for the client side (GPL 
>or commercial) or did I overlook any robust RTSP/RTP 
>implementations? What we plan to do is to use a camera to monitor a 
>building construction for example saving one image per minute to be 
>able to make a fast running presentation video after one year 
>showing how the building has been constructed. So we need the RTSP 
>client to run very stable for long running periods (maybe a year). 
>Even a minimal memory leak would be a problem. Does anybody have 
>experience with running RTSP client for very long time to receive 
>media? Are there any known stability problems or memory leaks or 
>whatever on the client side?

I know of no memory leaks that would prevent you from doing this. 
Note, though, that if you plan on creating/running one RTSP session 
per minute (as opposed to having just a single RTSP session that 
stays connected for a whole year), then you will need to create a new 
"RTSPClient" object for each session, and then reclaim it (along with 
the corresponding "MediaSession", "RTPSink", "RTCPInstance", and 
"groupsock" objects) afterwards.  See the "openRTSP" code for hints 
on how to do this.
-- 

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

From jnoring at logitech.com  Fri Jan  8 13:22:29 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Fri, 8 Jan 2010 13:22:29 -0800
Subject: [Live-devel] live555 and VLC question
In-Reply-To: <dbff67ea337142918ba6c8292e1b36e6@c9c9e8942ca5421a8cd82eb39e69c364>
References: <dbff67ea337142918ba6c8292e1b36e6@c9c9e8942ca5421a8cd82eb39e69c364>
Message-ID: <988ed6931001081322v2bfe076fmb1d09f40ad0f5af1@mail.gmail.com>

2010/1/8 N?mec Alexandr <a.nemec at atlas.cz>

> Dear all,
> we have downloaded the VLC player and we realized the live555 code is used
> in it (well, we are new to the scene). We studied the VLC code but it is not
> obvious to us, what parts of live555 streaming media library the VLC player
> is using. We thought that the VLC player uses live555 code whenever it needs
> to contact a RTSP server and to receive data via RTP. But there seem to be
> other code files in the VLC project covering the RTSP and RTP
> implementations. So what is the relation here? We just want to make this
> clear to be able to understand both code packages (live555 and VLC
> correctly).
> Thanks
>

I haven't looked at VLC, but for a lot of media types in Live555, you have
to subclass some generic type and make your own media sinks/sources.  So my
guess would be they're subclassing Live555 classes for custom protocols, or
protocols that often require subclassing (e.g. H264).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100108/80c3a9fa/attachment.html>

From xtophe at chewa.net  Fri Jan  8 13:27:13 2010
From: xtophe at chewa.net (Christophe Mutricy)
Date: Fri, 8 Jan 2010 22:27:13 +0100
Subject: [Live-devel] live555 and VLC question
In-Reply-To: <dbff67ea337142918ba6c8292e1b36e6@c9c9e8942ca5421a8cd82eb39e69c364>
References: <dbff67ea337142918ba6c8292e1b36e6@c9c9e8942ca5421a8cd82eb39e69c364>
Message-ID: <20100108212713.GL9083@chewa.net>

Le Fri 08 Jan 10 ? 18:20 +0000, N?mec Alexandr a ?crit :

> we have downloaded the VLC player  and we realized the live555 code is
> used in it  (well, we are new  to the scene). We studied  the VLC code
> but it  is not obvious  to us, what  parts of live555  streaming media
> library the VLC  player is using. We thought that  the VLC player uses
> live555 code whenever it needs to contact a RTSP server and to receive
> data via RTP. But there seem to be other code files in the VLC project
> covering the  RTSP and  RTP implementations. So  what is  the relation
> here? We just  want to make this  clear to be able  to understand both
> code packages (live555 and VLC correctly).

VLC questions would be better answered on vlc mailing list.

VLC uses liblivemedia for rtsp except for Real's rtsp dialect


-- 
Xtophe

From finlayson at live555.com  Fri Jan  8 13:46:19 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 8 Jan 2010 13:46:19 -0800
Subject: [Live-devel] live555 and VLC question
In-Reply-To: <dbff67ea337142918ba6c8292e1b36e6@c9c9e8942ca5421a8cd82eb39e69c364>
References: <dbff67ea337142918ba6c8292e1b36e6@c9c9e8942ca5421a8cd82eb39e69c364>
Message-ID: <f06240805c76d57f399a7@[66.80.62.44]>

>we have downloaded the VLC player and we realized the live555 code 
>is used in it (well, we are new to the scene). We studied the VLC 
>code but it is not obvious to us, what parts of live555 streaming 
>media library the VLC player is using. We thought that the VLC 
>player uses live555 code whenever it needs to contact a RTSP server 
>and to receive data via RTP. But there seem to be other code files 
>in the VLC project covering the RTSP and RTP implementations. So 
>what is the relation here? We just want to make this clear to be 
>able to understand both code packages (live555 and VLC correctly).

VLC uses our ("LIVE555 Streaming Media") code when acting as a RTSP 
client, but also implements a RTSP server, and uses its own code for 
that.
-- 

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

From matt at schuckmannacres.com  Fri Jan  8 14:55:27 2010
From: matt at schuckmannacres.com (Matt Schuckmannn)
Date: Fri, 08 Jan 2010 14:55:27 -0800
Subject: [Live-devel] Problem with NTP timestamps in SR packets with Flir
	A320 camera source
Message-ID: <4B47B7DF.2010001@schuckmannacres.com>

I'm using the livemedia library to receive a MPEG4 stream from a Flir 
Thermocam A320 infrared camera.
The problem I'm seeing is the presentation times coming from the 
afterGettingFrame callback start out reasonable then jump way ahead to 
sometime around 2038 after the first SR packet is received.

In tracking this down I believe that the Flir camera is at fault here 
and I've contacted there tech support. What I think is happening is the 
Flir camera is reverseing the seconds and microseconds values in the NTP 
time stamp field of the SR packet (i.e. it is placing the seconds value 
in the LSW and the microseconds in the MSW. Below is a SR packet from 
the camera (as reported by the LiveMedia library)

I just wanted to verify if I'm correct or see if anybody else has 
experienced this problem or if there might have been any recent fixes to 
the SR receiving code of liveMedia that I might be missing.

Here is the first RTCP packet I see from the Flir camera, after 
LiveMedia receives this packet the presentation times become very very 
wrong.

80c806 18b8cc55 018f60 0000 1b4e8250 00190 03e80 81ca09 18b8cc55 1e6361 
6d657261 40302e30 2e302e30 2067 52545020 312e300 0000

Assuming that I'm correct and that Flir is unwilling to correct their 
code can you make any suggestions on how I could work around this in my 
code?

Thank you,
Matt Schuckmann

From finlayson at live555.com  Fri Jan  8 16:30:20 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 8 Jan 2010 16:30:20 -0800
Subject: [Live-devel] Problem with NTP timestamps in SR packets with
 Flir A320 camera source
In-Reply-To: <4B47B7DF.2010001@schuckmannacres.com>
References: <4B47B7DF.2010001@schuckmannacres.com>
Message-ID: <f06240806c76d7b6dc830@[66.80.62.44]>

>I just wanted to verify if I'm correct or see if anybody else has 
>experienced this problem or if there might have been any recent 
>fixes to the SR receiving code of liveMedia that I might be missing.

No.  The RTCP reception/presentation-time-setting code has not 
changed in months (years?), and works well.


>Here is the first RTCP packet I see from the Flir camera, after 
>LiveMedia receives this packet the presentation times become very 
>very wrong.
>
>80c806 18b8cc55 018f60 0000 1b4e8250 00190 03e80 81ca09 18b8cc55 
>1e6361 6d657261 40302e30 2e302e30 2067 52545020 312e300 0000

Please fix this output so that each number is a 8-hex-digit number 
(representing a 32-bit word, in big-endian order).  Then resend the 
new (proper) output to the mailing list.  The output you gave here is 
wrong, because the first two bits of a valid RTCP packet (which we 
check for in the code) must be "10" (the RTCP version number). 
Therefore, the first word in your RTCP packet *might* have been
	8000c806
but could not have been
	80c806
-- 

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

From matt at schuckmannacres.com  Fri Jan  8 16:45:26 2010
From: matt at schuckmannacres.com (Matt Schuckmannn)
Date: Fri, 08 Jan 2010 16:45:26 -0800
Subject: [Live-devel] Problem with NTP timestamps in SR packets with
 Flir A320 camera source
In-Reply-To: <4B47B7DF.2010001@schuckmannacres.com>
References: <4B47B7DF.2010001@schuckmannacres.com>
Message-ID: <4B47D1A6.90601@schuckmannacres.com>

Ok it's been a long day, I now get it.

For anybody else using this camera here is what is happening.

The NTP seconds and microseconds values are not reversed they are fine 
and if I'd have looked at more than one SR packet in sequence I'd have 
seen that from the beginning.
The problem is the camera is using the time since the camera was last 
rebooted for the NTP time values in the SR reports (which in my case was 
about 30 hours and now is about 10 min). I believe it is using this 
because the camera is on a closed network with no SNTP time server to 
correct it. This is kind of sad because the camera does have it's own 
clock that stays correct between power cycles that would be much better 
to use in the absence of a SNTP time server.

I don't know if this points to a bug in the SR handling code in 
LiveMedia.  In RTPReceptionStats::noteIncomingSR() 0x83AA7E80 is always 
subtracted from theNTP seconds value and this caused the reported 
presentation time value to wrap around and report something way out in 
the future (around 2038).

I really don't know if there is anything better that you could do here, 
probably not.

Thanks for listening,
Matt S.


Matt Schuckmannn wrote:
> I'm using the livemedia library to receive a MPEG4 stream from a Flir 
> Thermocam A320 infrared camera.
> The problem I'm seeing is the presentation times coming from the 
> afterGettingFrame callback start out reasonable then jump way ahead to 
> sometime around 2038 after the first SR packet is received.
>
> In tracking this down I believe that the Flir camera is at fault here 
> and I've contacted there tech support. What I think is happening is 
> the Flir camera is reverseing the seconds and microseconds values in 
> the NTP time stamp field of the SR packet (i.e. it is placing the 
> seconds value in the LSW and the microseconds in the MSW. Below is a 
> SR packet from the camera (as reported by the LiveMedia library)
>
> I just wanted to verify if I'm correct or see if anybody else has 
> experienced this problem or if there might have been any recent fixes 
> to the SR receiving code of liveMedia that I might be missing.
>
> Here is the first RTCP packet I see from the Flir camera, after 
> LiveMedia receives this packet the presentation times become very very 
> wrong.
>
> 80c806 18b8cc55 018f60 0000 1b4e8250 00190 03e80 81ca09 18b8cc55 
> 1e6361 6d657261 40302e30 2e302e30 2067 52545020 312e300 0000
>
> Assuming that I'm correct and that Flir is unwilling to correct their 
> code can you make any suggestions on how I could work around this in 
> my code?
>
> Thank you,
> Matt Schuckmann
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

From finlayson at live555.com  Sat Jan  9 02:02:46 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 9 Jan 2010 02:02:46 -0800
Subject: [Live-devel] Problem with NTP timestamps in SR packets with
 Flir A320 camera source
In-Reply-To: <4B47D1A6.90601@schuckmannacres.com>
References: <4B47B7DF.2010001@schuckmannacres.com>
	<4B47D1A6.90601@schuckmannacres.com>
Message-ID: <f0624080bc76e035817d0@[66.80.62.44]>

>The problem is the camera is using the time since the camera was 
>last rebooted for the NTP time values in the SR reports (which in my 
>case was about 30 hours and now is about 10 min).

This is legal (although unusual).  The NTP timestamps don't have to 
actually be set to the 'true' time using the NTP protocol.

>I don't know if this points to a bug in the SR handling code in LiveMedia.

No.

>   In RTPReceptionStats::noteIncomingSR() 0x83AA7E80 is always 
>subtracted from theNTP seconds value and this caused the reported 
>presentation time value to wrap around and report something way out 
>in the future (around 2038).

That's fine.  The presentation times are still valid, even though 
they don't correspond to the 'true' time.  Just remember to have your 
client call "RTPSource::hasBeenSynchronizedUsingRTCP()" to check when 
the presentation times have become RTCP-synced, and compensate 
accordingly.

-- 

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

From linkfanel at yahoo.fr  Mon Jan 11 01:05:57 2010
From: linkfanel at yahoo.fr (Pierre Ynard)
Date: Mon, 11 Jan 2010 10:05:57 +0100
Subject: [Live-devel] Build breakage
Message-ID: <20100111090557.GA19397@via.ecp.fr>

Hello,

The latest version fails to build for me with the error:

DVVideoStreamFramer.cpp: In constructor 'DVVideoStreamFramer::DVVideoStreamFramer(UsageEnvironment&, FramedSource*)':
DVVideoStreamFramer.cpp:30: error: 'gettimeofday' was not declared in this scope

It is fixed by adding an "#include <sys/time.h>".

Regards,

-- 
Pierre Ynard
"Une ?me dans un corps, c'est comme un dessin sur une feuille de papier."

From finlayson at live555.com  Mon Jan 11 01:24:49 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 11 Jan 2010 01:24:49 -0800
Subject: [Live-devel] Build breakage
In-Reply-To: <20100111090557.GA19397@via.ecp.fr>
References: <20100111090557.GA19397@via.ecp.fr>
Message-ID: <f06240800c7709e9d4e25@[66.80.62.44]>

>The latest version fails to build for me with the error:
>
>DVVideoStreamFramer.cpp: In constructor 
>'DVVideoStreamFramer::DVVideoStreamFramer(UsageEnvironment&, 
>FramedSource*)':
>DVVideoStreamFramer.cpp:30: error: 'gettimeofday' was not declared 
>in this scope
>
>It is fixed by adding an "#include <sys/time.h>".

Thanks.  I have now installed a new version of the software that fixes this.
-- 

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

From cristina.gil at sumenor.com  Mon Jan 11 09:01:56 2010
From: cristina.gil at sumenor.com (Cristina Gil)
Date: Mon, 11 Jan 2010 18:01:56 +0100
Subject: [Live-devel] howto get NAL size?
Message-ID: <C73860066F504FC086276A454CEEED75@SUMENORSCS.LOCAL>

Hello, 

 

Im trying to get with H.264 over http, ive been following the RFC3984, and
the IP_Video_ISO_IEC_14496_Part10 document.

I get the both "packetization-mode=1" and
"sprop-parameter-sets=Z0IAMuKQFAey, aM48gA==" parameters. 

What do i need if i want to play the video from stream i get? I think I need
to identify the frame type (IDR, I-frame and P-frame) by reading the NAL
header but Im just a newbie..

[1.] How can i get the NAL size and the NAL header size so i can read them?
[2.] Can I use I decoder to play the video? Which and what do I need to play
it?

[3.] How can I get the image type and the image data from the stream?



I hope you can help me. Thanks for it. 

Cristina Gil 
Dpto.Desarrollo 
 <mailto:cristina.gil at sumenor.com> cristina.gil at sumenor.com 



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


 Oficinas
 C/ Mendibile 4 BIS, Dpto. A
 48940 - LEIOA - BIZKAIA
 Tel: 902 540 601 / 944 004 310
 Fax: 944 800 055 

 Taller
 B? Zubiate, S/N Nave 1 Pabell?n A
 48330 - LEMOA - BIZKAIA
 Tel: 946 312 007
 Fax: 946 313 828 

 




Antes de imprimir este mensaje, aseg?rese de que es necesario. El medio
ambiente est? en nuestra mano 

 



AVISO LEGAL
La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100111/63668e5e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 5310 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100111/63668e5e/attachment-0002.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1994 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100111/63668e5e/attachment-0003.jpe>

From rose.roo at sidc.com.tw  Mon Jan 11 22:06:24 2010
From: rose.roo at sidc.com.tw (=?UTF-8?B?Iue+hee/jOS+gShSUiki?=)
Date: Tue, 12 Jan 2010 14:06:24 +0800
Subject: [Live-devel] RTSP trick play, extra PES packet issue...
Message-ID: <4B4C1160.90401@sidc.com.tw>

Afternoon Ross Finlayson from live network :

I had 2 Transport Stream file, "Mermaid.ts" & "ChronoCross.ts" on our 
FTP site.
That's source that we tested to streaming, and comes with extra PES 
header packet...

Please visit our FTP site with following account information

    * IP: "60.250.38.86"
    * Username: "live555"
    * Password: "live555"
    * Path: "/original_TS/"

Hope you tested them already.

Any suggestion is welcome~

RR @ 2010/01/12
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100112/1a580b3a/attachment.html>

From loemaster at freenet.de  Tue Jan 12 10:49:36 2010
From: loemaster at freenet.de (Jan Szczepanski)
Date: Tue, 12 Jan 2010 19:49:36 +0100
Subject: [Live-devel] Using other IP Adress
Message-ID: <0caccadcf2062c259b7930143b29b08c@email.freenet.de>

Hi everyone,
?
I have some problems using the liveMedia Server for streaming the Frames coming from my camera.
When I start the liveMedia server he uses my local IP adress, but I wanna stream from the camera IP adress, what can I do to change that ?
?
with best regards
Jan Szczepanski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100112/82ce9ba6/attachment.html>

From anliuhuhot at hotmail.com  Tue Jan 12 20:21:15 2010
From: anliuhuhot at hotmail.com (HuStephen)
Date: Wed, 13 Jan 2010 12:21:15 +0800
Subject: [Live-devel] multiple instances
Message-ID: <SNT134-w25F05DDECB0D0519F263B2DE6B0@phx.gbl>


Hi Ross,            

                                                                                        

I have a stream client,  I using it connect to one Live Media Server or one testOnDemandRTSPServer for 10 instances.
10 instances are 10 threads in client. 
10 threads are almost started at the same time in the client.
very quickly. the interval is very short. (I think connecting the server almost at the same time.)
but the server appeared "Unhandled exception in testOnDemandRTSPServer.exe: 0xC0000005: Access Violation " in Visual C++ .
break at "char const* auxSDPLine = fDummyRTPSink->auxSDPLine();" in MPEG4VideoFileServerMediaSubsession.cpp.

 

The server also appeared "Segmentation fault" in linux environment.

 

They easily appear when the server never be connected.
If the server once be connected, they appear difficult.
If the interval is not very short, they didn't appear.

Would you like to help me to solve this problem?

 

Thanks,
Stephen

 		 	   		  
_________________________________________________________________
MSN????????????????25???????????2010?????????
http://kaba.msn.com.cn/?k=1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100113/ddedd1da/attachment.html>

From alpharoot at gmail.com  Tue Jan 12 22:42:47 2010
From: alpharoot at gmail.com (alpharoot)
Date: Wed, 13 Jan 2010 14:42:47 +0800
Subject: [Live-devel] Streaming RTSP over TCP doesn't work
Message-ID: <5b42f1311001122242m655537f2o69289b49c386eea5@mail.gmail.com>

Hi,
I am trying to stream video data over TCP instead of UDP (because many
UDP packets lost in my network) but failed.

The rtsp server is the one in testProgs like testMPEG1or2VideoStreamer
(actually I wrote my own application based on the test programs). The
client is VLC player for MS Windows. I am sure in UDP mode everything
is fine because I can use VLC to receive and play rtsp streams. Then I
modified VLC configurations to enable RTSP-over-TCP. I am sure VLC
configuration is correct because it can play rtsp-over-tcp streams
from some test sites.

But with this configuration VLC can't play Live555 streams. Also I
used openRTSP with "-t" option to test the stream and got errors (the
error messages are pasted below).

Does the live555 test programe need to be modified or configured to
support RTSP-over-TCP? Does anyone in the list have a successful
experience?

Thanks.

Below is the ./openRTSP log:
=============================
...
<snipped>
...
Created receiver for "video/MP4V-ES" subsession (client ports 8888-8889)
Sending request: SETUP rtsp://192.168.0.131/testStream/track1 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: ./openRTSP (LIVE555 Streaming Media v2009.11.12)


Received SETUP response: RTSP/1.0 461 Unsupported Transport
CSeq: 3
Date: Thu, Jan 01 1970 04:13:57 GMT


Failed to setup "video/MP4V-ES" subsession: SETUP: cannot handle
response: RTSP/1.0 461 Unsupported Transport

-- 
Bill

From finlayson at live555.com  Wed Jan 13 01:02:54 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 13 Jan 2010 01:02:54 -0800
Subject: [Live-devel] Streaming RTSP over TCP doesn't work
In-Reply-To: <5b42f1311001122242m655537f2o69289b49c386eea5@mail.gmail.com>
References: <5b42f1311001122242m655537f2o69289b49c386eea5@mail.gmail.com>
Message-ID: <f06240800c7733b9c047d@[66.80.62.44]>

>The rtsp server is the one in testProgs like testMPEG1or2VideoStreamer
>(actually I wrote my own application based on the test programs).

In general, once you've made changes to the supplied code, you can't 
expect support (especially with a "@gmail.com" email address :-), but 
in this case the problem is obvious:


>Received SETUP response: RTSP/1.0 461 Unsupported Transport

Our RTSP server implementation returns this error in exactly one 
situation: The client is requesting TCP-streaming of a multicast 
stream.  That makes no sense.  If you want to support RTP-over-TCP 
streaming, then it has to be for a unicast stream, not multicast.
-- 

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

From alpharoot at gmail.com  Wed Jan 13 04:38:40 2010
From: alpharoot at gmail.com (alpharoot)
Date: Wed, 13 Jan 2010 20:38:40 +0800
Subject: [Live-devel] Streaming RTSP over TCP doesn't work
In-Reply-To: <f06240800c7733b9c047d@66.80.62.44>
References: <5b42f1311001122242m655537f2o69289b49c386eea5@mail.gmail.com>
	<f06240800c7733b9c047d@66.80.62.44>
Message-ID: <5b42f1311001130438j6d7b09f5r621390a00cb397e7@mail.gmail.com>

On 1/13/10, Ross Finlayson <finlayson at live555.com> wrote:
> > The rtsp server is the one in testProgs like testMPEG1or2VideoStreamer
> > (actually I wrote my own application based on the test programs).
> >
>
> In general, once you've made changes to the supplied code, you can't expect
> support (especially with a "@gmail.com" email address :-), but in this case
> the problem is obvious:
>
Sure. I'll only report problems that can be reproduced by the test
programs which are not modified. And this is the case.

> > Received SETUP response: RTSP/1.0 461 Unsupported Transport
> >
>
> Our RTSP server implementation returns this error in exactly one situation:
> The client is requesting TCP-streaming of a multicast stream.  That makes no
> sense.  If you want to support RTP-over-TCP streaming, then it has to be for
> a unicast stream, not multicast.
Now the question is why the RTSP server always tries to output
multicast stream. Looking at the code in
PassiveServerMediaSubsession.getStreamParameters(), the stream type is
hardcoded as multicast by the line "isMulticast = True;". Is it
intended or it's a bug?

This problem can be workarounded by setting "isMulticast = False;" in
PassiveServerMediaSubsession.getStreamParameters().

-- 
Bill

From finlayson at live555.com  Wed Jan 13 06:09:29 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 13 Jan 2010 06:09:29 -0800
Subject: [Live-devel] Streaming RTSP over TCP doesn't work
In-Reply-To: <5b42f1311001130438j6d7b09f5r621390a00cb397e7@mail.gmail.com>
References: <5b42f1311001122242m655537f2o69289b49c386eea5@mail.gmail.com>
	<f06240800c7733b9c047d@66.80.62.44>
	<5b42f1311001130438j6d7b09f5r621390a00cb397e7@mail.gmail.com>
Message-ID: <f06240801c77382235fe9@[66.80.62.44]>

>  > Our RTSP server implementation returns this error in exactly one situation:
>>  The client is requesting TCP-streaming of a multicast stream.  That makes no
>>  sense.  If you want to support RTP-over-TCP streaming, then it has to be for
>>  a unicast stream, not multicast.
>Now the question is why the RTSP server always tries to output
>multicast stream. Looking at the code in
>PassiveServerMediaSubsession.getStreamParameters(), the stream type is
>hardcoded as multicast by the line "isMulticast = True;". Is it
>intended or it's a bug?

Yes, the "PassiveServerMediaSubsession" class is intended for 
multicast streams.  (I suppose it *could*, in principle, be 
subclassed for use with a 'passive' unicast stream, but such a stream 
could be received by only one client - defined in advance - so a RTSP 
server for such a stream wouldn't be very useful.)

To stream via unicast, you should use a subclass of 
"OnDemandServerMediaSubsession" - either an existing subclass (see, 
for example, one of those that are used by "testOnDemandRTSPServer"), 
or one that you would define yourself.
-- 

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

From debargha.mukherjee at hp.com  Wed Jan 13 14:13:13 2010
From: debargha.mukherjee at hp.com (Mukherjee, Debargha)
Date: Wed, 13 Jan 2010 22:13:13 +0000
Subject: [Live-devel] Audio drift with live source
In-Reply-To: <f06240804c75086e9fc11@[66.80.62.44]>
References: <73833378E80044458EC175FF8C1E63D5824575750A@GVW0433EXB.americas.hpqcorp.ne
	t> <f06240804c75086e9fc11@[66.80.62.44]>
Message-ID: <73833378E80044458EC175FF8C1E63D58246F4AD02@GVW0433EXB.americas.hpqcorp.net>

Hi Ross,

Having explored the issue further, I have narrowed down the problem, but not quite solved it yet. Any hints or help would be appreciated. 

I am using MP2 audio encoding for which the compressed framesize is supposed to be 576 bytes (sampling rate is 32 KHz, single channel). However, occasionally fMaxSize in deliverFrame() is less than 576. It is 240 or so. When that happens, I write only 240 bytes to fTo, and assign fFrameSize to 240 instead of 576. It seems that these truncated frames are simply not being handled properly by RTPSink. In fact, they are not getting transmitted by RTPSink at all, and in addition they are causing a timestamp drift which builds up over time. 

Is my handling of the case where fMaxSize  is < 576 correct. If not, what should be the right way? Also, is there a way to prevent this case from happening?

Best Regards,
Debargha.

-----Original Message-----
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Thursday, December 17, 2009 5:19 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Audio drift with live source

>In my implementation of deliverFrame() function in the classes for 
>the sources, I read uncompressed audio and video from ring buffers 
>(which are filled by another thread), compress them, and then fill 
>the buffers accordingly before calling 
>FramedSource::afterGetting(this). I also set fPresentationTime using 
>gettimeofday(&fPresentationTime, NULL); and set 
>fDurationInMicroseconds to 1000000/30 for video and the audio frame 
>duration for audio.

If "fPresentationTime" is set properly (to accurate 
wall-clock-synchronized presentation times) for both the audio and 
video frames, then VLC should be synchronizing them properly at the 
receiving end.  (This is assuming, of course, that RTCP "SR" packets 
from the server are also reaching the client - which they should.)

So, I suggest taking a closer look at the setting of 
"fPresentationTime" - for both audio and video frames - and making 
sure that they are accurate.

Also, in principle, because you are reading from a live source 
(rather than from a prerecorded file), you need not set 
"fDurationInMicroseconds" (and so it will get set to its default 
value of 0).  However, this would mean that the situation that you 
describe below will become the norm:

>Occasionally, when the deliverFrame() function tries to read from 
>the ring buffers, it does not find data available. Then I call 
>envir().taskScheduler().scheduleDelayedTask(...) with a small delay 
>interval and return.

This is OK, provided that (once again) you are setting the 
presentation time properly.  Ideally, you should be recording the 
presentation time (obtained by calling "gettimeofday()") at the time 
that the data is encoded, not at the time that it gets read from your 
ring buffer by your "FramedSource" subclass.
-- 

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

From finlayson at live555.com  Wed Jan 13 15:10:49 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 13 Jan 2010 15:10:49 -0800
Subject: [Live-devel] Audio drift with live source
Message-ID: <f06240803c774030a53ca@[66.80.62.44]>

>I am using MP2 audio encoding for which the compressed framesize is 
>supposed to be 576 bytes (sampling rate is 32 KHz, single channel). 
>However, occasionally fMaxSize in deliverFrame() is less than 576. 
>It is 240 or so. When that happens, I write only 240 bytes to fTo, 
>and assign fFrameSize to 240 instead of 576. It seems that these 
>truncated frames are simply not being handled properly by RTPSink. 
>In fact, they are not getting transmitted by RTPSink at all, and in 
>addition they are causing a timestamp drift which builds up over 
>time.
>
>Is my handling of the case where fMaxSize  is < 576 correct. If not, 
>what should be the right way?

Truncated data is just that - truncated (i.e., lost).  If this 
happens (because of a too-small buffer), then it's an error.  It's 
not something that our software tries to 'correct'.

So, your solution is to figure out why your downstream object's 
buffer is getting too small, and then to fix that.

You haven't said what your downstream object is.  Is it a 
"MPEG1or2AudioRTPSink"?  Is it a "MPEG1or2AudioStreamFramer"?  Or is 
it some other class that you wrote yourself?

Also, because you're encoding and streaming MPEG audio, I suggest 
that you take a look at the "wis-streamer" code 
<http://www.live555.com/wis-streamer/>, which also does this (plus 
lots of other things).  In particular, you may find it useful to look 
at the code for "MPEGAudioEncoder" (in particular, its implementation 
of "doGetNextFrame()").
-- 

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

From smurthi3 at gatech.edu  Wed Jan 13 15:09:14 2010
From: smurthi3 at gatech.edu (smurthi3 at gatech.edu)
Date: Wed, 13 Jan 2010 18:09:14 -0500 (EST)
Subject: [Live-devel] Packet loss recovery implementation
In-Reply-To: <940516538.1472971263424140211.JavaMail.root@mail4.gatech.edu>
Message-ID: <862547683.1473071263424154742.JavaMail.root@mail4.gatech.edu>

Hi All,

I have attempted to implement a packet loss mechanism; its description is given below. I am facing some problems with it, both in terms of testing and the logic behind the implementation. Please give me your opinions and inputs on how to make this more efficient and robust.

Implementation Logic:

Server:
- Every time a packet is sent, add the packet to a database (a std::map) with sequence number as key so that in case of a packet loss, the lost packet can be identified using the sequence number and retransmitted from the database. Along with the packet, information about the retry attempts and the time it was sent is also recorded. 
- The ACKs are piggybacked from the client on RTCP feedback packets. The server parses the ACK info when it parses the RTCP packet and then proceeds to the next step. Thus feedbacks are received from the client in RTCP packet intervals.  
- The server receives info from the client that says which are the sequence numbers received by the client in this intermission. The server then clears those seq numbers from the data base and attempts to resend the packets that still remain in the map (subject to the condition that the number of retry attempts < 5; if the number is > 5, it erases the packet from the map).
- If the time elapsed between sending of a packet and receipt of its ACK is > threshold time (which should ideally be the RTT), then the packet is retransmitted and its retry count value incremented. 

Client:
- For every packet that is received by the client, the sequence number info is parsed. Once it is checked that the packet is OK, this seq number is added to a std::vector (ackVector).
- When the next RTCP packet is built, the ackVector is added to the RTCP packet and transmitted along with it. The ackVector thus provides info about all the packets received between the previous RTCP packet and now. 


Issues: 
- The threshold time has to ideally be the RTT. But since the time taken for the ACKs is the RTCP interval, the server is forced to keep that as the threshold value. Is there any way to work around this?
- There is considerable delay in processing the map functions at the server, I am not sure but I think this adversely affects the performance of the server. Any way I can improve this?
- My biggest issue is with testing the implementation against losses. The code provides a method to introduce losses, but this function could also drop the retransmitted packets. How do I check if the retransmissions are happening correctly?
- RFC 4588 (http://tools.ietf.org/html/rfc4588) mentions that retransmitted packets must not have the same sequence numbers as the original packets as this could corrupt the QoS statistics. In that case, how do I retransmit an old packet, but with a new sequence number? And if I don't do this, how do I make sure the QoS statistics give the correct results?

All inputs will be highly appreciated.

Thanks. 

From alpharoot at gmail.com  Wed Jan 13 23:21:48 2010
From: alpharoot at gmail.com (alpharoot)
Date: Thu, 14 Jan 2010 15:21:48 +0800
Subject: [Live-devel] Streaming RTSP over TCP doesn't work
In-Reply-To: <f06240801c77382235fe9@66.80.62.44>
References: <5b42f1311001122242m655537f2o69289b49c386eea5@mail.gmail.com>
	<f06240800c7733b9c047d@66.80.62.44>
	<5b42f1311001130438j6d7b09f5r621390a00cb397e7@mail.gmail.com>
	<f06240801c77382235fe9@66.80.62.44>
Message-ID: <5b42f1311001132321n79eb296ey8cf95e83c2f9eb1d@mail.gmail.com>

On 1/13/10, Ross Finlayson <finlayson at live555.com> wrote:
> > Now the question is why the RTSP server always tries to output
> > multicast stream. Looking at the code in
> > PassiveServerMediaSubsession.getStreamParameters(), the
> stream type is
> > hardcoded as multicast by the line "isMulticast = True;". Is it
> > intended or it's a bug?
> >
>
> Yes, the "PassiveServerMediaSubsession" class is intended for multicast
> streams.  (I suppose it *could*, in principle, be subclassed for use with a
> 'passive' unicast stream, but such a stream could be received by only one
> client - defined in advance - so a RTSP server for such a stream wouldn't be
> very useful.)
OK. More investigations on the program indicated that the video data
is still streamed over UDP although "-t" option is specified when
running openRTSP.  I believe big changes need to be made to support
TCP and it still has one-client limitations as you mentioned.

> To stream via unicast, you should use a subclass of
> "OnDemandServerMediaSubsession" - either an existing
> subclass (see, for example, one of those that are used by
> "testOnDemandRTSPServer"), or one that you would define yourself.
>
Thanks for pointing it out. I did quick test on
testOnDemandRTSPServer. The test program openRTSP can recieve data
with RTP-over-TCP, but VLC player failed. Looks like VLC player
connected to the server successfully but doesn't play the video. I'll
look into this issue but is this a known issue?

-- 
Bill

From rob.krakora at gmail.com  Thu Jan 14 10:10:14 2010
From: rob.krakora at gmail.com (Robert Krakora)
Date: Thu, 14 Jan 2010 13:10:14 -0500
Subject: [Live-devel] RTSP MediaSession.cpp patch for RTP/RTCP for multicast
In-Reply-To: <b24e53351001141005p60a8452gf6298f47f88d2788@mail.gmail.com>
References: <b24e53351001141005p60a8452gf6298f47f88d2788@mail.gmail.com>
Message-ID: <b24e53351001141010n3613c158s8bf2e7d200c6fcd2@mail.gmail.com>

Hello,

I am using VLC 0.9.10 with live555 snapshot live.2010.01.13.tar.gz to
receive and decode multicast content from an Axis 213 PTZ camera (version
4.35.1 firmware).  However, I kept getting the following error about 60% of
the time when trying to invoke it from the command line:

[root at mediaport102 ~]# export DISPLAY=:0.0; vlc -vvvvv --noosd --fullscreen
--m4v-fps 30 --rtsp-mcast -I rc --no-audio rtsp://
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp
VLC media player 0.9.10 Grishenko
[00000001] main libvlc debug: VLC media player - version 0.9.10 Grishenko -
(c) 1996-2009 the VideoLAN team
[00000001] main libvlc debug: libvlc was configured with ../configure
'--prefix=/usr' '--libdir=/usr/lib64' '--with-live555-tree=/usr/lib64/live'
'--enable-run-as-root' '--enable-debug' 'LDFLAGS=-L/usr/lib64'
LibVLC has detected an unusable buggy GNU/libc version.
Please update to version 2.8 or newer.
[00000001] main libvlc debug: translation test: code is "C"
[00000001] main libvlc debug: checking builtin modules
[00000001] main libvlc debug: checking plugin modules
[00000001] main libvlc debug: loading plugins cache file
/root/.cache/vlc/plugins-04081e.dat
[00000001] main libvlc debug: recursively browsing `/usr/lib64/vlc'
[00000001] main libvlc debug: module bank initialized, found 259 modules
[00000001] main libvlc warning: Unable to get HAL device properties
[00000001] main libvlc debug: opening config file (/root/.config/vlc/vlcrc)
[00000001] main libvlc debug: CPU has capabilities 486 586 MMX 3DNow! MMXEXT
SSE SSE2 FPU
[00000001] main libvlc debug: looking for memcpy module: 4 candidates
[00000001] main libvlc debug: using memcpy module "memcpymmxext"
[00000686] main interaction debug: thread 1098783040 (Interaction control)
created at priority 0 (../../src/interface/interaction.c:382)
[00000686] main interaction debug: thread started
[00000688] main input debug: Creating an input for 'Media Library'
[00000688] main input debug: Input is a meta file: disabling unneeded
options
[00000688] main input debug:
`file/xspf-open:///root/.local/share/vlc/ml.xspf' gives access `file' demux
`xspf-open' path `/root/.local/share/vlc/ml.xspf'
[00000688] main input debug: creating access 'file'
path='/root/.local/share/vlc/ml.xspf'
[00000689] main access debug: looking for access module: 3 candidates
[00000689] access_file access debug: opening file
`/root/.local/share/vlc/ml.xspf'
[00000689] main access debug: using access module "access_file"
[00000689] main access debug: TIMER module_Need() : 0.467 ms - Total 0.467
ms / 1 intvls (Avg 0.467 ms)
[00000690] main stream debug: Using AStream*Stream
[00000690] main stream debug: pre-buffering...
[00000690] main stream debug: received first data for our buffer
[00000688] main input debug: creating demux: access='file' demux='xspf-open'
path='/root/.local/share/vlc/ml.xspf'
[00000691] main demux debug: looking for demux module: 1 candidate
[00000691] playlist demux debug: using XSPF playlist reader
[00000691] main demux debug: using demux module "playlist"
[00000691] main demux debug: TIMER module_Need() : 1.042 ms - Total 1.042 ms
/ 1 intvls (Avg 1.042 ms)
[00000688] main input debug:
`file/xspf-open:///root/.local/share/vlc/ml.xspf' successfully opened
[00000692] main xml debug: looking for xml module: 2 candidates
[00000692] main xml debug: using xml module "xml"
[00000692] main xml debug: TIMER module_Need() : 0.855 ms - Total 0.855 ms /
1 intvls (Avg 0.855 ms)
[00000691] playlist demux debug: parsed 0 tracks successfully
[00000692] main xml debug: removing module "xml"
[00000688] main input debug: EOF reached
[00000688] main input debug: control type=1
[00000691] main demux debug: removing module "playlist"
[00000689] main access debug: removing module "access_file"
[00000688] main input debug: Destroying the input for 'Media Library'
[00000688] main input debug: TIMER input launching for 'Media Library' :
11.250 ms - Total 11.250 ms / 1 intvls (Avg 11.250 ms)
[00000693] main preparser debug: waiting for thread initialization
[00000693] main preparser debug: thread started
[00000693] main preparser debug: thread 1085921600 (preparser) created at
priority 0 (../../src/playlist/thread.c:79)
[00000694] main fetcher debug: waiting for thread initialization
[00000694] main fetcher debug: thread started
[00000694] main fetcher debug: thread 1109272896 (fetcher) created at
priority 0 (../../src/playlist/thread.c:108)
[00000687] main playlist debug: waiting for thread initialization
[00000687] main playlist debug: thread started
[00000687] main playlist debug: thread 1119762752 (playlist) created at
priority 0 (../../src/playlist/thread.c:117)
[00000695] main interface debug: looking for interface module: 1 candidate
[00000687] main playlist debug: rebuilding array of current - root Playlist
[00000687] main playlist debug: rebuild done - 0 items, index -1
[00000695] main interface debug: using interface module "hotkeys"
[00000695] main interface debug: TIMER module_Need() : 0.772 ms - Total
0.772 ms / 1 intvls (Avg 0.772 ms)
[00000695] main interface debug: thread 1130252608 (interface) created at
priority 0 (../../src/interface/interface.c:168)
[00000696] main interface debug: looking for interface module: 1 candidate
[00000695] main interface debug: thread started
[00000696] main interface debug: using interface module "inhibit"
[00000696] main interface debug: TIMER module_Need() : 112.259 ms - Total
112.259 ms / 1 intvls (Avg 112.259 ms)
[00000696] main interface debug: thread 1140742464 (interface) created at
priority 0 (../../src/interface/interface.c:168)
[00000697] main interface debug: looking for interface module: 1 candidate
[00000697] main interface debug: using interface module "screensaver"
[00000697] main interface debug: TIMER module_Need() : 0.116 ms - Total
0.116 ms / 1 intvls (Avg 0.116 ms)
[00000697] main interface debug: thread 1151232320 (interface) created at
priority 0 (../../src/interface/interface.c:168)
[00000687] main playlist debug: adding item `rtsp://
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp' ( rtsp://
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp )
[00000698] main interface debug: looking for interface module: 18 candidates
[00000698] main interface debug: using interface module "signals"
[00000698] main interface debug: TIMER module_Need() : 0.095 ms - Total
0.095 ms / 1 intvls (Avg 0.095 ms)
[00000698] main interface debug: thread 1172212032 (interface) created at
priority 0 (../../src/interface/interface.c:168)
[00000699] main interface debug: looking for interface module: 18 candidates
Remote control interface initialized. Type `help' for help.
[00000699] main interface debug: using interface module "rc"
[00000699] main interface debug: TIMER module_Need() : 0.296 ms - Total
0.296 ms / 1 intvls (Avg 0.296 ms)
[00000696] main interface debug: thread started
[00000687] main playlist debug: rebuilding array of current - root Playlist
[00000687] main playlist debug: rebuild done - 1 items, index -1
[00000697] main interface debug: thread started
[00000698] main interface debug: thread started
[00000699] main interface debug: thread 1182701888 (interface) created at
priority 0 (../../src/interface/interface.c:168)
[00000687] main playlist debug: starting new item
[00000687] main playlist debug: processing request item null node Playlist
skip 0
[00000687] main playlist debug: creating new input thread
[00000700] main input debug: Creating an input for 'rtsp://
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp'
[00000699] main interface debug: thread started
[00000700] main input debug: thread started
[00000700] main input debug: waiting for thread initialization
[00000700] main input debug: `rtsp://
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp' gives access `rtsp'
demux `' path `dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp'
[00000700] main input debug: creating demux: access='rtsp' demux='' path='
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp'
[00000701] main demux debug: looking for access_demux module: 1 candidate
[00000700] main input debug: thread 1193191744 (input) created at priority
10 (../../src/input/input.c:370)
Sending request: OPTIONS rtsp://172.19.3.223:554/mpeg4/media.amp RTSP/1.0
CSeq: 1
User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.27)


Received OPTIONS response: RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN


Sending request: DESCRIBE rtsp://172.19.3.223:554/mpeg4/media.amp RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.27)


Received DESCRIBE response: RTSP/1.0 401 Unauthorized
CSeq: 2
WWW-Authenticate: Basic realm="/"


Sending request: DESCRIBE rtsp://172.19.3.223:554/mpeg4/media.amp RTSP/1.0
CSeq: 3
Accept: application/sdp
Authorization: Basic ZGNhbXBiZWxsOm1zZHZpZGVv
User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.27)


Received DESCRIBE response: RTSP/1.0 200 OK
CSeq: 3
Content-Base: rtsp://172.19.3.223:554/mpeg4/media.amp/
Content-Type: application/sdp
Content-Length: 696


Need to read 696 extra bytes
Read 696 extra bytes: v=0
o=- 18951009734492 18951009734498 IN IP4 172.19.3.223
s=Media Presentation
e=NONE
c=IN IP4 0.0.0.0
b=AS:8000
t=0 0
a=control:*
a=range:npt=now-
a=mpeg4-iod:
"data:application/mpeg4-iod;base64,AoDUAE8BAf/1AQOAbwABQFBkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBUjBCR3dVZkF4Y0F5U1FBWlFRTklCRUVrK0FBZWhJQUFIb1NBQVlCQkE9PQQNAQUABAAAAAAAAAAAAAYJAQAAAAAAAAAAAzoAAkA2ZGF0YTphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTWVFTSVVFVUZQd0E9BBICDQAAAgAAAAAAAAAABQMAAEAGCQEAAAAAAAAAAA=="
m=video 0 RTP/AVP 96
b=AS:8000
a=framerate:30
a=control:trackID=1
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=245;
config=000001B0F5000001B509000001000000012008D49D88032516043C14440F;
a=mpeg4-esid:201

[00000701] live555 demux debug: RTP subsession 'video/MP4V-ES'
Sending request: SETUP rtsp://172.19.3.223:554/mpeg4/media.amp/trackID=1RTSP/1.0
CSeq: 4
Transport: RTP/AVP;multicast;client_port=36916-36917
Authorization: Basic ZGNhbXBiZWxsOm1zZHZpZGVv
User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.27)


Received SETUP response: RTSP/1.0 200 OK
CSeq: 4
Session: 1886570945;timeout=60
Transport:
RTP/AVP;multicast;destination=239.209.84.157;ttl=5;port=50000-50001;mode="PLAY"


[00000700] main input debug: selecting program id=0
[00000701] live555 demux debug: setup start: 0 stop:0
Sending request: PLAY rtsp://172.19.3.223:554/mpeg4/media.amp/ RTSP/1.0
CSeq: 5
Session: 1886570945
Range: npt=0.000-
Authorization: Basic ZGNhbXBiZWxsOm1zZHZpZGVv
User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.27)


Received PLAY response: RTSP/1.0 200 OK
CSeq: 5
Session: 1886570945
Range: npt=now-
RTP-Info: url=trackID=1;seq=7996;rtptime=3557386590


[00000701] live555 demux debug: We have a timeout of 60 seconds
[00000702] main generic debug: waiting for thread initialization
[00000702] main generic debug: thread started
[00000702] main generic debug: thread 1203681600 (liveMedia-timeout) created
at priority 0 (../../../modules/demux/live555.cpp:1055)
[00000701] live555 demux debug: spawned timeout thread
[00000701] live555 demux debug: play start: 0 stop:0
[00000701] main demux debug: using access_demux module "live555"
[00000701] main demux debug: TIMER module_Need() : 89.912 ms - Total 89.912
ms / 1 intvls (Avg 89.912 ms)
[00000703] main decoder debug: looking for decoder module: 26 candidates
[00000703] avcodec decoder debug: libavcodec initialized (interface 3412992
)
[00000703] avcodec decoder debug: using direct rendering
[00000703] avcodec decoder debug: ffmpeg codec (MPEG-4 Video) started
[00000703] main decoder debug: using decoder module "avcodec"
[00000703] main decoder debug: TIMER module_Need() : 14.274 ms - Total
14.274 ms / 1 intvls (Avg 14.274 ms)
[00000703] main decoder debug: thread 1214171456 (decoder) created at
priority 0 (../../src/input/decoder.c:217)
[00000700] main input debug: `rtsp://
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp' successfully opened
BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor
[00000703] main decoder debug: thread started

By turning on debugging I was able to ascertain that the problem was that
the fd_set socket handle mask for the 'select()' call was not getting
updated when RTP and RTCP sockets were closed and reopened with different
file descriptor values because of a multicast address/port changed flagged
by the RTSP stack.  Below is the diff between the 'stock' file and modified
file and attached is an attempted patch.  The patch does work, but there may
or may not be some other pitfalls that are not readily apparent to me.

[root at devkrakora live-latest]# diff -uN live/liveMedia/MediaSession.cpp
live.modified/liveMedia/MediaSession.cpp
--- live/liveMedia/MediaSession.cpp     2010-01-13 02:19:35.000000000 -0500
+++ live.modified/liveMedia/MediaSession.cpp    2010-01-14
20:44:35.000000000 -0500
@@ -976,21 +976,38 @@
   netAddressBits destAddress = connectionEndpointAddress();
   if (destAddress == 0) destAddress = defaultDestAddress;
   struct in_addr destAddr; destAddr.s_addr = destAddress;
-
+
   // The destination TTL remains unchanged:
   int destTTL = ~0; // means: don't change

   if (fRTPSocket != NULL) {
+    fRTPSource->stopGettingFrames();
     Port destPort(serverPortNum);
     fRTPSocket->changeDestinationParameters(destAddr, destPort, destTTL);
   }
   if (fRTCPSocket != NULL && !isSSM()) {
     // Note: For SSM sessions, the dest address for RTCP was already set.
+    if (fRTCPInstance != NULL) {
+      Medium::close(fRTCPInstance); fRTCPInstance = NULL;
+    }
     Port destPort(serverPortNum+1);
-    fRTCPSocket->
+    fRTCPSocket->
       changeDestinationParameters(destAddr, destPort, destTTL);
-  }
-}
+    // Finally, create our RTCP instance. (It starts running automatically)
+    if (fRTPSource != NULL) {
+      unsigned totSessionBandwidth = 500; // HACK - later get from SDP#####
+      fRTCPInstance = RTCPInstance::createNew(env(), fRTCPSocket,
+                                              totSessionBandwidth,
+                                              (unsigned char const*)
+                                              fParent.CNAME(),
+                                              NULL /* we're a client */,
+                                              fRTPSource);
+      if (fRTCPInstance == NULL) {
+        env().setResultMsg("Failed to create RTCP instance");
+      }
+    }
+  }
+}

 double MediaSubsession::getNormalPlayTime(struct timeval const&
presentationTime) {
   // First, check whether our "RTPSource" object has already been
synchronized using RTCP.
[root at devkrakora live-latest]#




-- 
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100114/2ed4c3d9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.MediaSession.cpp
Type: application/octet-stream
Size: 1892 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100114/2ed4c3d9/attachment-0001.obj>

From jnoring at logitech.com  Thu Jan 14 17:58:40 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Thu, 14 Jan 2010 17:58:40 -0800
Subject: [Live-devel] RTSPClient blocking/non-blocking bug?
Message-ID: <988ed6931001141758n2eaa444fm5aa379211389b305@mail.gmail.com>

I was reviewing the code in RTSPClient::openConnectionFromUrl(), and I had a
question about the codepath involving setting a timeout.  In particular,
this code:

//Start change for timeout on connect

      /*
      if (connect(fInputSocketNum, (struct sockaddr*)&remoteName, sizeof
remoteName)
      != 0) {
      envir().setResultErrMsg("
connect() failed: ");
      break;
      */
      fd_set set;
      FD_ZERO(&set);
      timeval tvout = {0,0};
      if (timeout > 0) {
          FD_SET((unsigned)fInputSocketNum, &set);
          tvout.tv_sec = timeout;
          tvout.tv_usec = 0;
          makeSocketNonBlocking(fInputSocketNum);
      }
      if (connect(fInputSocketNum, (struct sockaddr*) &remoteName, sizeof
remoteName) != 0)
      {
          if (envir().getErrno() != EINPROGRESS && envir().getErrno() !=
EWOULDBLOCK)
          {
              envir().setResultErrMsg("connect() failed: ");
              break;
          }
          if (timeout > 0 && (select(fInputSocketNum + 1, NULL, &set, NULL,
&tvout) <= 0))
          {
              envir().setResultErrMsg("select/connect() failed: ");
              break;
          }
          /*
          errno = 0;
          if (getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &len) < 0 || errno
!= 0 )
          {
          break;
          }
          */
          //End change for timeout on connect
      }

...I see that if timeout > 0, then fInputSocketNum is set to a non-blocking
socket (i.e. makeSocketNonBlocking).  Shouldn't this get set back to a
blocking socket once this connect attempt is completed?

(it may be that this happens somewhere else, but my quick checks through the
code didn't reveal any such code)

If this is an issue, I have code I can submit that will set the socket back
to blocking.

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

From robert_pletscher at yahoo.com  Fri Jan 15 01:34:40 2010
From: robert_pletscher at yahoo.com (Robert Pletscher)
Date: Fri, 15 Jan 2010 01:34:40 -0800 (PST)
Subject: [Live-devel] how to get the RTP packages
Message-ID: <817786.10620.qm@web53606.mail.re2.yahoo.com>

I'm writing to ask how I can get the RTP packages in order to store them in a database.
I'm looking forward to hearing from you soon.

Yours,

Robert

*************************************************
Robert Pletscher
mobile: +86-136-2111 5464
mail to: Robert_Pletscher at yahoo.com


      

From finlayson at live555.com  Fri Jan 15 06:33:35 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 15 Jan 2010 06:33:35 -0800
Subject: [Live-devel] RTSPClient blocking/non-blocking bug?
In-Reply-To: <988ed6931001141758n2eaa444fm5aa379211389b305@mail.gmail.com>
References: <988ed6931001141758n2eaa444fm5aa379211389b305@mail.gmail.com>
Message-ID: <f06240801c7762d273391@[66.80.62.44]>

>...I see that if timeout > 0, then fInputSocketNum is set to a 
>non-blocking socket (i.e. makeSocketNonBlocking).  Shouldn't this 
>get set back to a blocking socket once this connect attempt is 
>completed? 
>
>(it may be that this happens somewhere else, but my quick checks 
>through the code didn't reveal any such code)
>
>If this is an issue, I have code I can submit that will set the 
>socket back to blocking.

Yes, please submit a patch.  Thanks.
-- 

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

From SRawling at pelco.com  Fri Jan 15 08:46:53 2010
From: SRawling at pelco.com (Rawling, Stuart)
Date: Fri, 15 Jan 2010 08:46:53 -0800
Subject: [Live-devel] How to transfer a new RTP Payload type.
In-Reply-To: <f06240802c69618fdc72e@[66.80.62.44]>
Message-ID: <C775DBFD.2563D%SRawling@pelco.com>

Ross,

I was looking into a similar problem as the OP here.  It seems that having
the ability to add additional payload types dynamically would be a useful
feature of the live555 library.  This would be much more preferable than
having to change the library source code to add a payload.  I have a couple
of ideas how this could be done.  Would you be interested in reviewing a
proposed patch?

Regards,
Stuart


On 7/29/09 8:24 AM, "Ross Finlayson" <finlayson at live555.com> wrote:

>> >3. My query is how can I receive that new type of metadata payload.Below is
>> >the method you sent me :
>> >
>>>> >>>You would need to define and implement two new classes:
>> >
>>>> >>>1/ A new subclass of "MultiFramedRTPSink", for sending RTP packets in
>>>> >>>the new payload format.
>>>> >>>2/ A new subclass of "MultiFramedRTPSource", for receiving RTP
>>>> >  >>packets in the new payload format.
> 
> 
> Sorry, I forgot to mention a 3rd thing that you need to do:
> 3/ Modify "MediaSubsession::initiate()" so that it recognizes the SDP
> description for your payload type, and creates an appropriate
> "RTPSource" subclass.  For an example of how to do this, search for
> "H264" in "liveMedia/MediaSession.cpp".
> 
> --
> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
> 



This transmission is intended only for use by the intended
recipient(s). If you are not an intended recipient you should not read, disclose copy, circulate or in any other way use the information contained in this transmission. The information contained in this transmission may be confidential and/or privileged. If you have received this transmission in error, please notify the sender immediately and delete this transmission including any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100115/9a557e51/attachment.html>

From finlayson at live555.com  Fri Jan 15 14:39:38 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 15 Jan 2010 14:39:38 -0800
Subject: [Live-devel] How to transfer a new RTP Payload type.
In-Reply-To: <C775DBFD.2563D%SRawling@pelco.com>
References: <C775DBFD.2563D%SRawling@pelco.com>
Message-ID: <f06240803c7769e8fd07a@[66.80.62.44]>

>I was looking into a similar problem as the OP here.  It seems that 
>having the ability to add additional payload types dynamically would 
>be a useful feature of the live555 library.  This would be much more 
>preferable than having to change the library source code to add a 
>payload.  I have a couple of ideas how this could be done.  Would 
>you be interested in reviewing a proposed patch?

Yes, sure.  Note, though, that doing this in a clean and general way 
may be nontrivial, because the parameter lists for each "RTPSource"s 
"createNew()" function can differ.  It's going to be difficult to do 
this in a generic way for all payload types; some will probably have 
to remain 'hard coded'.
-- 

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

From finlayson at live555.com  Fri Jan 15 14:46:54 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 15 Jan 2010 14:46:54 -0800
Subject: [Live-devel] RTSP MediaSession.cpp patch for RTP/RTCP for
 multicast
Message-ID: <f06240804c776a0d959d4@[66.80.62.44]>

>I am using VLC 0.9.10 with live555 snapshot live.2010.01.13.tar.gz

Are you sure?  VLC disagrees:

>User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.27)

Nonetheless, the problem you describe applies even to newer versions:

>BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor
>[00000703] main decoder debug: thread started
>
>By turning on debugging I was able to ascertain that the problem was 
>that the fd_set socket handle mask for the 'select()' call was not 
>getting updated when RTP and RTCP sockets were closed and reopened 
>with different file descriptor values because of a multicast 
>address/port changed flagged by the RTSP stack.

Yes, you're right - you identified a bug.  (This arose because your 
server is doing something rather unusual (but still legal): define 
the destination multicast address in the RTSP "SETUP" response.)

The problem was our implementation of the "changePort()" function.  I 
have now changed this so that it calls "bind()" directly, rather than 
indirectly via closing and reopening sockets.

I have installed a new version (2010.01.15) of the code that - I hope 
fixes this problem.
-- 

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

From SRawling at pelco.com  Fri Jan 15 15:46:24 2010
From: SRawling at pelco.com (Rawling, Stuart)
Date: Fri, 15 Jan 2010 15:46:24 -0800
Subject: [Live-devel] How to transfer a new RTP Payload type.
In-Reply-To: <f06240803c7769e8fd07a@[66.80.62.44]>
Message-ID: <C7763E50.25709%SRawling@pelco.com>

I agree, but thought perhaps we could defined list of parameters, probably
based of what SimpleRTPSink uses.   If people on this list have an opinion,
please feel free to contribute to what the parameters could be.

Regards,
Stuart


On 1/15/10 2:39 PM, "Ross Finlayson" <finlayson at live555.com> wrote:

>> >I was looking into a similar problem as the OP here.  It seems that
>> >having the ability to add additional payload types dynamically would
>> >be a useful feature of the live555 library.  This would be much more
>> >preferable than having to change the library source code to add a
>> >payload.  I have a couple of ideas how this could be done.  Would
>> >you be interested in reviewing a proposed patch?
> 
> Yes, sure.  Note, though, that doing this in a clean and general way
> may be nontrivial, because the parameter lists for each "RTPSource"s
> "createNew()" function can differ.  It's going to be difficult to do
> this in a generic way for all payload types; some will probably have
> to remain 'hard coded'.



This transmission is intended only for use by the intended
recipient(s). If you are not an intended recipient you should not read, disclose copy, circulate or in any other way use the information contained in this transmission. The information contained in this transmission may be confidential and/or privileged. If you have received this transmission in error, please notify the sender immediately and delete this transmission including any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100115/dc273096/attachment.html>

From rob.krakora at gmail.com  Fri Jan 15 15:23:08 2010
From: rob.krakora at gmail.com (Robert Krakora)
Date: Fri, 15 Jan 2010 18:23:08 -0500
Subject: [Live-devel] RTSP MediaSession.cpp patch for RTP/RTCP for
	multicast
In-Reply-To: <f06240804c776a0d959d4@66.80.62.44>
References: <f06240804c776a0d959d4@66.80.62.44>
Message-ID: <b24e53351001151523j4651f639v1b5a4eaffc2c241f@mail.gmail.com>

Ross:

I duplicated the problem first with v2009.07.27 and then with v2010.01.13.
I am sorry if I was a bit misleading.  I will test you fix out tonight.
Thanks for your quick response.

On Fri, Jan 15, 2010 at 5:46 PM, Ross Finlayson <finlayson at live555.com>wrote:

> I am using VLC 0.9.10 with live555 snapshot live.2010.01.13.tar.gz
>>
>
> Are you sure?  VLC disagrees:
>
> User-Agent: VLC media player (LIVE555 Streaming Media v2009.07.27)
>>
>
> Nonetheless, the problem you describe applies even to newer versions:
>
> BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor
>> [00000703] main decoder debug: thread started
>>
>> By turning on debugging I was able to ascertain that the problem was that
>> the fd_set socket handle mask for the 'select()' call was not getting
>> updated when RTP and RTCP sockets were closed and reopened with different
>> file descriptor values because of a multicast address/port changed flagged
>> by the RTSP stack.
>>
>
> Yes, you're right - you identified a bug.  (This arose because your server
> is doing something rather unusual (but still legal): define the destination
> multicast address in the RTSP "SETUP" response.)
>
> The problem was our implementation of the "changePort()" function.  I have
> now changed this so that it calls "bind()" directly, rather than indirectly
> via closing and reopening sockets.
>
> I have installed a new version (2010.01.15) of the code that - I hope fixes
> this problem.
> --
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>



-- 
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100115/0c77000e/attachment-0001.html>

From ben at decadent.org.uk  Fri Jan 15 19:00:17 2010
From: ben at decadent.org.uk (Ben Hutchings)
Date: Sat, 16 Jan 2010 03:00:17 +0000
Subject: [Live-devel] Build failure in liveMedia 2010.01.15
Message-ID: <1263610818.17815.131.camel@localhost>

This release added a call to sprintf() in groupsock/NetInterface.cpp,
which may or may not include <stdio.h> depending on the C++
implementation.  Using Debian's package of gcc 4.4, it doesn't, and
sprintf() is not declared.  I think groupsock/NetInterface.cpp should
include <stdio.h> directly.

Other than that, I'm very pleased to see DV support completed.  Thanks,
Ross!

Ben.

-- 
Ben Hutchings
I'm not a reverse psychological virus.  Please don't copy me into your sig.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100116/68b51dac/attachment.bin>

From finlayson at live555.com  Fri Jan 15 19:07:14 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 15 Jan 2010 19:07:14 -0800
Subject: [Live-devel] Build failure in liveMedia 2010.01.15
In-Reply-To: <1263610818.17815.131.camel@localhost>
References: <1263610818.17815.131.camel@localhost>
Message-ID: <f06240806c776ddc8be22@[66.80.62.44]>

>This release added a call to sprintf() in groupsock/NetInterface.cpp,
>which may or may not include <stdio.h> depending on the C++
>implementation.  Using Debian's package of gcc 4.4, it doesn't, and
>sprintf() is not declared.  I think groupsock/NetInterface.cpp should
>include <stdio.h> directly.

OK, fixed now.  Thanks for the note.
-- 

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

From amreddy103 at gmail.com  Fri Jan 15 20:02:33 2010
From: amreddy103 at gmail.com (Madhusudhan Reddy)
Date: Sat, 16 Jan 2010 09:32:33 +0530
Subject: [Live-devel] Support of Packed AMR frames in Live555 RTP stack
Message-ID: <258724eb1001152002l3e371a15r588fbc2348500ff9@mail.gmail.com>

Hi,

I am using live555 for as RTSP server and streaming files with AMR encoded
audio. It seems like Live555 is not supporting Packed AMR frames (more than
one AMR frame in one RTP packet). Please correct if i am not using it
properly. I checked the source code as well and i am able to stream my own
files and as well live streams.

If my understanding is correct, any plan to add packed AMR support in near
future? If not i can plan to implement for Live555.

Thanks,
A.M.Reddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100116/add4bdfc/attachment.html>

From anliuhuhot at hotmail.com  Fri Jan 15 20:08:52 2010
From: anliuhuhot at hotmail.com (HuStephen)
Date: Sat, 16 Jan 2010 12:08:52 +0800
Subject: [Live-devel] multiple instances
Message-ID: <SNT134-w302A6A88023BA9E49F434BDE680@phx.gbl>


 

I think this is a bug of live555 library.

Because I connected to some video server that's not live555 server, didn't appear this.
 

Regards,

Stephen

 


From: anliuhuhot at hotmail.com
To: live-devel at lists.live555.com
Subject: multiple instances
Date: Wed, 13 Jan 2010 12:21:15 +0800



Hi Ross,            
                                                                                        
I have a stream client,  I using it connect to one Live Media Server or one testOnDemandRTSPServer for 10 instances.
10 instances are 10 threads in client. 
10 threads are almost started at the same time in the client.
very quickly. the interval is very short. (I think connecting the server almost at the same time.)
but the server appeared "Unhandled exception in testOnDemandRTSPServer.exe: 0xC0000005: Access Violation " in Visual C++ .
break at "char const* auxSDPLine = fDummyRTPSink->auxSDPLine();" in MPEG4VideoFileServerMediaSubsession.cpp.
 
The server also appeared "Segmentation fault" in linux environment.
 
They easily appear when the server never be connected.
If the server once be connected, they appear difficult.
If the interval is not very short, they didn't appear.
Would you like to help me to solve this problem?
 
Thanks,
Stephen




????? Windows Live Messenger ???????? ????? 		 	   		  
_________________________________________________________________
SkyDrive????????????????????????!
http://www.windowslive.cn/campaigns/e-magazine/ngmchina/?a=c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100116/f5e44d6b/attachment.html>

From finlayson at live555.com  Sat Jan 16 00:22:05 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 16 Jan 2010 00:22:05 -0800
Subject: [Live-devel] Support of Packed AMR frames in Live555 RTP stack
In-Reply-To: <258724eb1001152002l3e371a15r588fbc2348500ff9@mail.gmail.com>
References: <258724eb1001152002l3e371a15r588fbc2348500ff9@mail.gmail.com>
Message-ID: <f06240800c777271c37af@[66.80.62.44]>

>I am using live555 for as RTSP server and streaming files with AMR 
>encoded audio. It seems like Live555 is not supporting Packed AMR 
>frames (more than one AMR frame in one RTP packet).

That's correct.  As noted in "liveMedia/AMRAudioRTPSink.cpp":

	// NOTE: At present, this is just a limited implementation, supporting:
	// octet-alignment only; no interleaving; no frame CRC; no 
robust-sorting.

>If my understanding is correct, any plan to add packed AMR support 
>in near future?

No - sorry.

>  If not i can plan to implement for Live555.

Of course.  This software is Open Source.
-- 

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

From finlayson at live555.com  Sat Jan 16 05:56:42 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 16 Jan 2010 05:56:42 -0800
Subject: [Live-devel] RTSP trick play, extra PES packet issue...
In-Reply-To: <4B4C1160.90401@sidc.com.tw>
References: <4B4C1160.90401@sidc.com.tw>
Message-ID: <f06240800c77775254644@[66.80.62.44]>

>I had 2 Transport Stream file, "Mermaid.ts" & "ChronoCross.ts" on 
>our FTP site.
>That's source that we tested to streaming, and comes with extra PES 
>header packet...
>
>Please visit our FTP site with following account information
>
>IP: "60.250.38.86"
>Username: "live555"
>Password: "live555"
>Path: "/original_TS/"
>Hope you tested them already.

No, because you have not answered my question.

For the last time: Please tell me:
1/ Which Transport Stream files on your FTP site contain extra PES header data?
2/ An example - in one of these files - of exactly where this extra 
PES header data is (i.e., a range of byte positions within the file).

If you don't tell me this, I will not be able to investigate your 
problem (and you will not be allowed to post 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/20100116/80e275f0/attachment.html>

From a.nemec at atlas.cz  Sat Jan 16 07:21:56 2010
From: a.nemec at atlas.cz (=?utf-8?B?TsSbbWVjIEFsZXhhbmRy?=)
Date: Sat, 16 Jan 2010 15:21:56 GMT
Subject: [Live-devel] Blocking socket
Message-ID: <61d3e50cc670429380aed0b0043eb314@b41c66570f1c406da65809e0d448e3de>

An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100116/a1f0ff0f/attachment.html>
-------------- next part --------------
Hi all,
somebody posted a suggestion that the socket (when using timeout in the RTSP client) must be set back to blocking. Is this already corrected in the current code release and is it necessary to do so, what are the consequences when the socket is not set back to blocking?
Best regards
Alex

From jnoring at logitech.com  Sat Jan 16 14:53:40 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Sat, 16 Jan 2010 14:53:40 -0800
Subject: [Live-devel] Blocking socket
In-Reply-To: <61d3e50cc670429380aed0b0043eb314@b41c66570f1c406da65809e0d448e3de>
References: <61d3e50cc670429380aed0b0043eb314@b41c66570f1c406da65809e0d448e3de>
Message-ID: <988ed6931001161453g5e0c081fr9844adc428bdf73d@mail.gmail.com>

2010/1/16 N?mec Alexandr <a.nemec at atlas.cz>

> Hi all,
> somebody posted a suggestion that the socket (when using timeout in the
> RTSP client) must be set back to blocking. Is this already corrected in the
> current code release and is it necessary to do so, what are the consequences
> when the socket is not set back to blocking?
>

I wondered the same thing, so I tracked down the change, which seems to have
originated from the VLC project in October, 2008:

http://mailman.videolan.org/pipermail/vlc-devel/2008-October/051390.html

Looking at the original patch, it's pretty clear that the author forgot to
set the socket back to be blocking.  But considering that this issue has
been present for well over a year, I have to wonder whether or not the
RTSPClient even needs to be run on a blocking socket. (Ross, you know the
most about this, so I'd be interested to hear your take on things).

FWIW, I haven't tested this patch yet (been busy), but here's the changes
you'd need to revert the socket to blocking.  In GroupsockHelper.h and .cpp:

Boolean makeSocketBlocking(int sock);

Boolean makeSocketBlocking(int sock) {
#if defined(__WIN32__) || defined(_WIN32) || defined(IMN_PIM)
  unsigned long arg = 0;
  return ioctlsocket(sock, FIONBIO, &arg) == 0;
#elif defined(VXWORKS)
  int arg = 0;
  return ioctl(sock, FIONBIO, (int)&arg) == 0;
#else
  int curFlags = fcntl(sock, F_GETFL, 0);
  return fcntl(sock, F_SETFL, curFlags&(~O_NONBLOCK)) >= 0;
#endif
}

...and in RTSPClient.cpp,

fd_set set;
      FD_ZERO(&set);
      timeval tvout = {0,0};
      if (timeout > 0) {
          FD_SET((unsigned)fInputSocketNum, &set);
          tvout.tv_sec = timeout;
          tvout.tv_usec = 0;
          makeSocketNonBlocking(fInputSocketNum);
      }
      if (connect(fInputSocketNum, (struct sockaddr*) &remoteName, sizeof
remoteName) != 0) {
          if (envir().getErrno() != EINPROGRESS && envir().getErrno() !=
EWOULDBLOCK) {
              envir().setResultErrMsg("connect() failed: ");
              break;
          }
          if (timeout > 0 && (select(fInputSocketNum + 1, NULL, &set, NULL,
&tvout) <= 0)) {
              envir().setResultErrMsg("select/connect() failed: ");
              break;
          }
      }
      // If we set our socket to non-blocking, put it back in blocking mode
now.
      if( timeout > 0 ){
          makeSocketBlocking(fInputSocketNum);
      }

I'll probably get a chance to try these out sometime next week, on both
Win32 and embedded linux, so I can vouch for those platforms.  I have no
idea if the VXWORKS code is correct (I did review it with a coworker who
thought it looked good), and no way of testing that platform.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100116/2c38cb87/attachment-0001.html>

From ziyad.sharaf at gmail.com  Sat Jan 16 18:52:52 2010
From: ziyad.sharaf at gmail.com (ziyad sharafudheen)
Date: Sun, 17 Jan 2010 08:22:52 +0530
Subject: [Live-devel] Play a file in loop
Message-ID: <8eb8e71d1001161852h74284c4axa4f33c4b81cbac8f@mail.gmail.com>

Hi,

I am using live555 media server for RTSP streaming.

Is there any option for the media server to play a video in loop (i.e. start
again once the video file ends). Now, i could see once the end of file
reaches a teardown request is initiated and client has to re-issue the
request.

I could not find an option to enable this option if present.

Regards
ziyad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100117/053d1f6c/attachment.html>

From ziyad.sharaf at gmail.com  Sat Jan 16 18:58:17 2010
From: ziyad.sharaf at gmail.com (ziyad sharafudheen)
Date: Sun, 17 Jan 2010 08:28:17 +0530
Subject: [Live-devel] HTTP Tunneling support
Message-ID: <8eb8e71d1001161858w632bd787lb08dc8ae1f89cf54@mail.gmail.com>

Hi,

I am using live555 media server for Video on demand streaming with trick
mode as a requirement.

Is there a support for http tunneling where the rtsp and transport packets
are transmitted over http (so that it can bypass proxy servers and
firewalls)

Also, will trick mode (forward and reverse play) present for media formats
other than mpeg2 ts

Regards
Ziyad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100117/8543d40c/attachment.html>

From finlayson at live555.com  Sat Jan 16 21:39:17 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 16 Jan 2010 21:39:17 -0800
Subject: [Live-devel] Blocking socket
Message-ID: <f06240803c77852f67f53@[66.80.62.44]>

>Looking at the original patch, it's pretty clear that the author 
>forgot to set the socket back to be blocking.  But considering that 
>this issue has been present for well over a year, I have to wonder 
>whether or not the RTSPClient even needs to be run on a blocking 
>socket. (Ross, you know the most about this, so I'd be interested to 
>hear your take on things).

I'm not planning on doing much with the existing "RTSPClient" code, 
because this code will soon be significantly overhauled so that it 
does I/O asynchronously, using the event loop, rather than the 
current blocking-with-timeout model (which doesn't fit with the 
event-driven model of the rest of the library's code).  This change 
will also eliminate the need for a "timeout" parameter (although the 
existing API will probably kept - as an option - for a while, for 
backwards compatibility).

Fixing "RTSPClient" is high priority (second only to fixing the 
problems with RTP-over-TCP).
-- 

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

From finlayson at live555.com  Sat Jan 16 21:54:50 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 16 Jan 2010 21:54:50 -0800
Subject: [Live-devel] HTTP Tunneling support
In-Reply-To: <8eb8e71d1001161858w632bd787lb08dc8ae1f89cf54@mail.gmail.com>
References: <8eb8e71d1001161858w632bd787lb08dc8ae1f89cf54@mail.gmail.com>
Message-ID: <f06240804c7785636427f@[66.80.62.44]>

>Is there a support for http tunneling where the rtsp and transport 
>packets are transmitted over http (so that it can bypass proxy 
>servers and firewalls)

RTSP/RTP/RTCP-over-HTTP is currently supported for clients, but not 
(yet) for servers.


>Also, will trick mode (forward and reverse play) present for media 
>formats other than mpeg2 ts

Please read the FAQ!
-- 

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

From finlayson at live555.com  Sat Jan 16 22:37:26 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 16 Jan 2010 22:37:26 -0800
Subject: [Live-devel] Play a file in loop
In-Reply-To: <8eb8e71d1001161852h74284c4axa4f33c4b81cbac8f@mail.gmail.com>
References: <8eb8e71d1001161852h74284c4axa4f33c4b81cbac8f@mail.gmail.com>
Message-ID: <f06240805c778605da3af@[66.80.62.44]>

>I am using live555 media server for RTSP streaming.
>
>Is there any option for the media server to play a video in loop 
>(i.e. start again once the video file ends).

No.  You would have to implement this yourself (e.g., by subclassing 
"ByteStreamFileSource", and changing the way that the 
"doGetNextFrame()" virtual function handles EOF).
-- 

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

From robert_pletscher at yahoo.com  Sun Jan 17 17:45:10 2010
From: robert_pletscher at yahoo.com (Robert Pletscher)
Date: Sun, 17 Jan 2010 17:45:10 -0800 (PST)
Subject: [Live-devel] how to get the RTP packages
In-Reply-To: <mailman.2505.1263603659.870.live-devel@lists.live555.com>
Message-ID: <393028.92177.qm@web53607.mail.re2.yahoo.com>

> 
> I'm writing to ask how I can get the RTP packages in order
> to store them in a database.
> I'm looking forward to hearing from you soon.

I'm sorry, I was not specific enough. I have already seen how this can be done for UDP, but the transport protocol we are using is TCP, I haven't figure out yet how to get the RTP packages when using TCP as a transport protocol.

*************************************************
Robert Pletscher
mobile: +86-136-2111 5464
mail to: Robert_Pletscher at yahoo.com


      

From robert_pletscher at yahoo.com  Sun Jan 17 21:45:32 2010
From: robert_pletscher at yahoo.com (Robert Pletscher)
Date: Sun, 17 Jan 2010 21:45:32 -0800 (PST)
Subject: [Live-devel] how to get the RTP packages
In-Reply-To: <mailman.2505.1263603659.870.live-devel@lists.live555.com>
Message-ID: <55915.4320.qm@web53607.mail.re2.yahoo.com>

> 
> I'm writing to ask how I can get the RTP packages in order
> to store them in a database.
> I'm looking forward to hearing from you soon.
> 

I know from the mail list archive that if using UDP as the transport protocol, to get the RTP packages, the change below will do the job:

if (strcmp(fProtocolName, "UDP") == 0) {
on line 656 of "MediaSession.cpp" to
if (True) {

How can I implement this for the TCP protocol? Do I have to write a "BasicTCPSource" class like the BasicUDPSource class and insert the code for using this class in the live555 code?
I'm looking forward to hearing from you soon.

Yours,

Robert

*************************************************
Robert Pletscher
mobile: +86-136-2111 5464
mail to: Robert_Pletscher at yahoo.com


      

From finlayson at live555.com  Sun Jan 17 22:48:51 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 17 Jan 2010 22:48:51 -0800
Subject: [Live-devel] how to get the RTP packages
In-Reply-To: <55915.4320.qm@web53607.mail.re2.yahoo.com>
References: <55915.4320.qm@web53607.mail.re2.yahoo.com>
Message-ID: <f06240802c779b3025f02@[66.80.62.44]>

The "LIVE555 Streaming Media" is intended for experienced, 
professional systems software developers, who have a solid background 
with, and understanding of Internet protocols in general, and 
RTP/RTCP in particular.  It's clear from your messages (plus the fact 
that you use a "@yahoo.com" email address) that you have only a 
limited understanding of what RTP is, and how it is used.  I'm sorry 
if I sound rude, but this software is probably not for you.

I suggest that you learn (a lot) more about the RTP protocol - and 
how it is used - before trying to dive into this software.
-- 

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

From rose.roo at sidc.com.tw  Mon Jan 18 03:59:12 2010
From: rose.roo at sidc.com.tw (=?UTF-8?B?Iue+hee/jOS+gShSUiki?=)
Date: Mon, 18 Jan 2010 19:59:12 +0800
Subject: [Live-devel] RTSP trick play, extra PES packet issue...
Message-ID: <4B544D10.5050507@sidc.com.tw>

God evening Ross Finlayson from live network :

First of all, I have to say sorry to misunderstanding what you really 
asked before.
Let me say sorry again~ that's my fault...

> 1/ Which Transport Stream files on your FTP site contain extra PES header data?

*These 2 files below(on our FTP site) ware contain extra PES header data*

    * Mermaid_FF2x_test.ts
    * Mermaid_FF8x_test.ts

Please visit our FTP site with following account information to download 
them

    * IP: "60.250.38.86"
    * Username: "live555"
    * Password: "live555"
    * Path: "/"

And, if you would like to take original Transport Stream file to 
compare, I had also put it on our FTP site,
here is the path and file name
"/Original_TS/Mermaid.ts"

> 2/ An example - in one of these files - of exactly where this extra 
> PES header data is (i.e., a range of byte positions within the file).

*ALL range of byte positions ware the extra PES header.*

For example, if we put "Mermaid_FF2x_test.ts" into live555's directory, 
and run a RTSP client
to request live555 to streaming "Mermaid_FF2x_test.ts" in normal play mode,
then the RTSP client will receive nothing but PES header.



Hope I didn't misunderstanding what you asked this time,
we really need your help and suggestions.

RR @ 2010/01/18
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100118/c00d886e/attachment.html>

From keith at green-light.ca  Mon Jan 18 16:53:12 2010
From: keith at green-light.ca (Keith Page)
Date: Mon, 18 Jan 2010 16:53:12 -0800
Subject: [Live-devel] Request to Fix inconsistent timestamps in openrtsp
Message-ID: <4B550278.9040800@green-light.ca>

We currently use live555 as a module for vlc to record two camera 
streams and one audio onto a mosaic canvas. All media sources are ntp 
synced so the time stamps coming are in lock step, our video streams are 
able to stay in perfect sync, our audio however is always off by 4 - 8 
seconds.

The beginning of the muxing in vlc suffers from starts and stops while 
RTCP occurs. The time stamps being fed into vlc from openRTSP starts as 
actual unix time stamps, once a RTCP is received from the media source 
openRTSP changes to an arbitrarily number, this inconsistency ( going 
from normal unix epoch time stamp to a random one )  causes vlc to reset 
it's PTS gap and it throw out frames until it detect the problem and 
reset its PTS gap.

I read somewhere in the forums that this was a known issue and a better 
way would be for openRTSP to pick an arbitrary seed for all streams at 
start and determine a proper offset for each stream from that one seed. 
This would ensure we're counting in a consistent fashion from the 
initial setup and through the first RCTP sync from the media source.

It's my understanding that by fixing this here in openRTSP this will fix 
our problem in vlc and will create a better library for other media 
players using openRTSP. I could very well be mistaken. However if upon 
review of our problem and what we're trying to accomplish this proves to 
be correct our company would pay to have this fixed properly for the 
benefit of everyone.

Our goal is to end up with a library that allows us to take these two 
video streams and one audio stream, which are all time stamped properly 
themselves and have them stay in sync after the mux.

Please let me know if you have any further questions and if you can help.
Keith



From finlayson at live555.com  Mon Jan 18 17:03:56 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 18 Jan 2010 17:03:56 -0800
Subject: [Live-devel] Request to Fix inconsistent timestamps in openrtsp
In-Reply-To: <4B550278.9040800@green-light.ca>
References: <4B550278.9040800@green-light.ca>
Message-ID: <f06240808c77ab3e4ff00@[66.80.62.44]>

>The beginning of the muxing in vlc suffers from starts and stops 
>while RTCP occurs. The time stamps being fed into vlc from openRTSP 
>starts as actual unix time stamps, once a RTCP is received from the 
>media source openRTSP changes to an arbitrarily number

This is normal, and expected; there's no bug here.  It's because the 
first few presentation times - before RTCP synchronization occurs - 
are just 'guesses' made by the receiving code (based on the 
receiver's 'wall clock' and the RTP timestamp).  However, once RTCP 
synchronization occurs, all subsequent presentation times will be 
accurate.  (Depending upon the server, these presentation times - 
after RTCP synchronization has occurred - might not necessarily look 
like current Unix timestamps, but they *will be* accurate, and in 
sync with other substreams, unless of course your server is broken.)

This means is that a receiver should be prepared for the fact that 
the first few presentation times (until RTCP synchronization starts) 
will not be accurate.  The code, however, can check this by calling 
"RTPSource:: hasBeenSynchronizedUsingRTCP()".  If this returns False, 
then the presentation times are not accurate, and should be treated 
with 'a grain of salt'.  However, once the call to returns True, then 
the presentation times (from then on) will be accurate.

Note, however, that this is *already* implemented in VLC (in its 
"live555" demux module), so I don't know why you're trying to 
reinvent the wheel here.  You should be able to just use VLC 'as is'.
-- 

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

From keith at green-light.ca  Mon Jan 18 17:45:50 2010
From: keith at green-light.ca (Keith Page)
Date: Mon, 18 Jan 2010 17:45:50 -0800
Subject: [Live-devel] Request to Fix inconsistent timestamps in openrtsp
In-Reply-To: <f06240808c77ab3e4ff00@[66.80.62.44]>
References: <4B550278.9040800@green-light.ca>
	<f06240808c77ab3e4ff00@[66.80.62.44]>
Message-ID: <4B550ECE.2020508@green-light.ca>

The problem I experience with VLC is that it takes the first set of 
presentation stamps as it's seed. When the new PTS stamps start coming 
in it detects that the numbers are way off from before, outside it's 
tolerance and throws an error saying PTS GAP, resetting clock, it then 
rebuffers. While that buffering takes place it throws out the frames 
coming in, leaving a blank section of the final muxed video. Once the 
buffer has refilled it is then fine on  per stream basis. During this 
process the video streams are able to stay in sync within a few ms but 
the audio is now all defunct and off by 4 - 8 seconds. The result is the 
first 30 second of video is pretty much junk and has to be cut off, and 
the audio through out the entire video is delayed as stated before.

I have tried playing with the code myself in vlc but have not had 
success getting a proper result out of it, it's beyond my ability to 
resolve. Though i thought if we could get a stream of stable PTS from 
openRTSP this problem would go away from VLC's point of view. VLC's code 
currently looks for the RTCP and then reset all it's counters once it's 
seen and throws out it's current buffer and rebuilds a new one.

So we aren't trying to re-invent any wheel, we are running into a 
problem with the current wheel not working in this situation,  that I 
thought could be fixed here by uniforming the PTS through the RTCP sync.

Could openRTSP not simply calculate an offset after the RCTP packet and 
adjust each subsequent packet by that offset to keep the whole PTS 
stream consistent? What would be the downside to doing this?

Thanks
Keith

On 10-01-18 5:03 PM, Ross Finlayson wrote:
>> The beginning of the muxing in vlc suffers from starts and stops 
>> while RTCP occurs. The time stamps being fed into vlc from openRTSP 
>> starts as actual unix time stamps, once a RTCP is received from the 
>> media source openRTSP changes to an arbitrarily number
>
> This is normal, and expected; there's no bug here.  It's because the 
> first few presentation times - before RTCP synchronization occurs - 
> are just 'guesses' made by the receiving code (based on the receiver's 
> 'wall clock' and the RTP timestamp).  However, once RTCP 
> synchronization occurs, all subsequent presentation times will be 
> accurate.  (Depending upon the server, these presentation times - 
> after RTCP synchronization has occurred - might not necessarily look 
> like current Unix timestamps, but they *will be* accurate, and in sync 
> with other substreams, unless of course your server is broken.)
>
> This means is that a receiver should be prepared for the fact that the 
> first few presentation times (until RTCP synchronization starts) will 
> not be accurate.  The code, however, can check this by calling 
> "RTPSource:: hasBeenSynchronizedUsingRTCP()".  If this returns False, 
> then the presentation times are not accurate, and should be treated 
> with 'a grain of salt'.  However, once the call to returns True, then 
> the presentation times (from then on) will be accurate.
>
> Note, however, that this is *already* implemented in VLC (in its 
> "live555" demux module), so I don't know why you're trying to reinvent 
> the wheel here.  You should be able to just use VLC 'as is'.


From finlayson at live555.com  Mon Jan 18 18:18:12 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 18 Jan 2010 18:18:12 -0800
Subject: [Live-devel] Request to Fix inconsistent timestamps in openrtsp
In-Reply-To: <4B550ECE.2020508@green-light.ca>
References: <4B550278.9040800@green-light.ca>
	<f06240808c77ab3e4ff00@[66.80.62.44]> <4B550ECE.2020508@green-light.ca>
Message-ID: <f06240809c77ac102c994@[66.80.62.44]>

>The problem I experience with VLC is that it takes the first set of 
>presentation stamps as it's seed.

VLC's "live555" demux module (see "modules_demux_live555.cpp") does 
not do this.  (At least, it shouldn't be doing this.  If - after 
inspecting that code - you're *sure* there's a bug there, then please 
report it to VLC (not to us; VLC is not our software).)  Note, in 
particular, the call to "hasBeenSynchronizedUsingRTCP()" in that 
code.  So, if you're not using the "live555" demux module, then you 
probably should.  Once again, please don't try to reinvent the wheel.


>I have tried playing with the code myself in vlc but have not had 
>success getting a proper result out of it, it's beyond my ability to 
>resolve.

Once again, are you using VLC's "live555" demux module?  If not, why 
not?  (In any case, alleged bugs in VLC are off-topic for this 
mailing list.)


>Could openRTSP

I think you mean "the LIVE555 Streaming Media libraries", not 
"openRTSP".  "openRTSP" is a demo application, not a library.

>  not simply calculate an offset after the RCTP packet and adjust 
>each subsequent packet by that offset to keep the whole PTS stream 
>consistent?

Because - in the case where you have more than one substream (e.g., 
audio + video), that would *not* keep their presentation times in 
sync.

Remember, once again, that the presentation times for the audio and 
video streams - after "hasBeenSynchronizedUsingRTCP()" returns True 
for both - will be accurate, and in sync with each other.  But the 
presentation times that occurred *before* 
"hasBeenSynchronizedUsingRTCP()" returns True will not be in sync. 
Therefore, although we could - in principle - add an offset to the 
audio presentation times so that their presentation times after RTCP 
sync are consistent with those before RTCP sync, we could not also do 
the same for the video presentation times, without bringing the audio 
and video presentation times out of sync with each other.

This is why only the presentation times that occur after 
"hasBeenSynchronizedUsingRTCP()" returns True can be trusted for A/V 
synchronization, and why VLC's "live555" demux module calls that 
function.
-- 

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

From alpharoot at gmail.com  Mon Jan 18 23:32:19 2010
From: alpharoot at gmail.com (alpharoot)
Date: Tue, 19 Jan 2010 15:32:19 +0800
Subject: [Live-devel] multi file read in testOnDemandRTSPServer
Message-ID: <5b42f1311001182332i14b37002i146b49bc63d43da@mail.gmail.com>

Hi,
I am developing a rtsp server which is based on
testOnDemandRTSPServer/mpeg4ESVideoTest. The video source is from a
camera instead of files so that I can implement a live video server.

I found When streaming video MPEG4VideoFileServerMediaSubsession reads
files from the beginning for several times. It looks like the first
time it reads in the header, and next times it reads and really
streams the data. If reuseFirstSource is set to True then the file
will be opened and read twice.

However, if the video is from camera the situation is a little
complex. Basically the video data will be discarded once it is read
because we have limited buffer. If MPEG4VideoFileServerMediaSubsession
has to read video data several times, I have to allocate another
buffer to save the data. The question is how many data should be saved
(1 or 2 frames or else)?

BTW, the multicast applications (testMPEG4VideoStreamer etc) reads the
file only for once.

-- 
Bill

From finlayson at live555.com  Tue Jan 19 01:38:17 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 19 Jan 2010 01:38:17 -0800
Subject: [Live-devel] multi file read in testOnDemandRTSPServer
In-Reply-To: <5b42f1311001182332i14b37002i146b49bc63d43da@mail.gmail.com>
References: <5b42f1311001182332i14b37002i146b49bc63d43da@mail.gmail.com>
Message-ID: <f06240800c77b28d9d528@[66.80.62.44]>

>I am developing a rtsp server which is based on
>testOnDemandRTSPServer/mpeg4ESVideoTest. The video source is from a
>camera instead of files so that I can implement a live video server.
>
>I found When streaming video MPEG4VideoFileServerMediaSubsession reads
>files from the beginning for several times. It looks like the first
>time it reads in the header, and next times it reads and really
>streams the data. If reuseFirstSource is set to True then the file
>will be opened and read twice.

Yes, this is unavoidable, unfortunately.  The server needs to read 
the MPEG-4 video data initially, so it can parse it to figure out the 
stream-specific 'config' information (the SDP "a=fmtp:..." line) that 
gets returned as part of the RTSP "DESCRIBE" response.  It then needs 
to read the data a second time when it later gets delivered to the 
client (in response to RTSP "PLAY").

If the input data is a file (as it is with the unmodified 
"testOnDemandRTSPServer"), then the server actually rereads the same 
data (i.e., from the beginning of the file).  However, if the input 
data is a live source, then it's not necessary that the second read 
return the same data as the first read.  Instead, you can treat the 
input data as being an unseekable object.  You don't need to buffer 
the data from the first read.
-- 

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

From alpharoot at gmail.com  Tue Jan 19 04:01:51 2010
From: alpharoot at gmail.com (alpharoot)
Date: Tue, 19 Jan 2010 20:01:51 +0800
Subject: [Live-devel] multi file read in testOnDemandRTSPServer
In-Reply-To: <f06240800c77b28d9d528@66.80.62.44>
References: <5b42f1311001182332i14b37002i146b49bc63d43da@mail.gmail.com>
	<f06240800c77b28d9d528@66.80.62.44>
Message-ID: <5b42f1311001190401yebbb589lce8446d436e3930@mail.gmail.com>

On 1/19/10, Ross Finlayson <finlayson at live555.com> wrote:
> > I am developing a rtsp server which is based on
> > testOnDemandRTSPServer/mpeg4ESVideoTest. The video source
> is from a
> > camera instead of files so that I can implement a live video server.
> >
> > I found When streaming video
> MPEG4VideoFileServerMediaSubsession reads
> > files from the beginning for several times. It looks like the first
> > time it reads in the header, and next times it reads and really
> > streams the data. If reuseFirstSource is set to True then the file
> > will be opened and read twice.
> >
>
> Yes, this is unavoidable, unfortunately.  The server needs to read the
> MPEG-4 video data initially, so it can parse it to figure out the
> stream-specific 'config' information (the SDP "a=fmtp:..." line) that gets
> returned as part of the RTSP "DESCRIBE" response.  It then needs to read the
> data a second time when it later gets delivered to the client (in response
> to RTSP "PLAY").
>
> If the input data is a file (as it is with the unmodified
> "testOnDemandRTSPServer"), then the server actually rereads the same data
> (i.e., from the beginning of the file).  However, if the input data is a
> live source, then it's not necessary that the second read return the same
> data as the first read.  Instead, you can treat the input data as being an
> unseekable object.  You don't need to buffer the data from the first read.
It looks like the current MPEG4VideoStreamFramer implementation
doesn't support this mode, because it maintains a state machine for
parsing MPEG4 data. Each time it reads the video data, it seeks
VISUAL_OBJECT_SEQUENCE_START_CODE (0x000001B0) which only exists at
the beginning of the stream. If the START_CODE doesn't exist the state
machine will break and streaming will fail.
However for H264 I believe we don't need to buffer the data.
Maybe the restricted state machine (ie, seeking START_CODE) in
MPEG4VideoStreamFramer is not necessary (sorry for this question, I
don't have specific knowledge about MPEG4 standard)?

-- 
Bill

From rob.krakora at gmail.com  Tue Jan 19 05:05:17 2010
From: rob.krakora at gmail.com (Robert Krakora)
Date: Tue, 19 Jan 2010 08:05:17 -0500
Subject: [Live-devel] Request to Fix inconsistent timestamps in openrtsp
In-Reply-To: <f06240809c77ac102c994@66.80.62.44>
References: <4B550278.9040800@green-light.ca>
	<f06240808c77ab3e4ff00@66.80.62.44> <4B550ECE.2020508@green-light.ca>
	<f06240809c77ac102c994@66.80.62.44>
Message-ID: <b24e53351001190505y21d05d37sad85ebe68090441a@mail.gmail.com>

Hello,

I use VLC 0.9.10 and receive audio and video streams on a large scale LAN
both unicast and multicast from a variety of security and webcams via VLC
with live555 RTSP and video and audio are in sync with the
hasBeenSynchronizedUsingRTCP() function getting called.  Which version of
VLC are you using?  Ross is correct, this appears to be a VLC issue and not
a live555 issue.

Best Regards,

-- 
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax

On Mon, Jan 18, 2010 at 9:18 PM, Ross Finlayson <finlayson at live555.com>wrote:

> The problem I experience with VLC is that it takes the first set of
>> presentation stamps as it's seed.
>>
>
> VLC's "live555" demux module (see "modules_demux_live555.cpp") does not do
> this.  (At least, it shouldn't be doing this.  If - after inspecting that
> code - you're *sure* there's a bug there, then please report it to VLC (not
> to us; VLC is not our software).)  Note, in particular, the call to
> "hasBeenSynchronizedUsingRTCP()" in that code.  So, if you're not using the
> "live555" demux module, then you probably should.  Once again, please don't
> try to reinvent the wheel.
>
>
>
>  I have tried playing with the code myself in vlc but have not had success
>> getting a proper result out of it, it's beyond my ability to resolve.
>>
>
> Once again, are you using VLC's "live555" demux module?  If not, why not?
>  (In any case, alleged bugs in VLC are off-topic for this mailing list.)
>
>
>  Could openRTSP
>>
>
> I think you mean "the LIVE555 Streaming Media libraries", not "openRTSP".
>  "openRTSP" is a demo application, not a library.
>
>
>   not simply calculate an offset after the RCTP packet and adjust each
>> subsequent packet by that offset to keep the whole PTS stream consistent?
>>
>
> Because - in the case where you have more than one substream (e.g., audio +
> video), that would *not* keep their presentation times in sync.
>
> Remember, once again, that the presentation times for the audio and video
> streams - after "hasBeenSynchronizedUsingRTCP()" returns True for both -
> will be accurate, and in sync with each other.  But the presentation times
> that occurred *before* "hasBeenSynchronizedUsingRTCP()" returns True will
> not be in sync. Therefore, although we could - in principle - add an offset
> to the audio presentation times so that their presentation times after RTCP
> sync are consistent with those before RTCP sync, we could not also do the
> same for the video presentation times, without bringing the audio and video
> presentation times out of sync with each other.
>
> This is why only the presentation times that occur after
> "hasBeenSynchronizedUsingRTCP()" returns True can be trusted for A/V
> synchronization, and why VLC's "live555" demux module calls that function.
>
> --
>
> 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/20100119/e6deaf8d/attachment-0001.html>

From gbonneau at miranda.com  Tue Jan 19 07:25:02 2010
From: gbonneau at miranda.com (BONNEAU Guy)
Date: Tue, 19 Jan 2010 10:25:02 -0500
Subject: [Live-devel] Request to Fix inconsistent timestamps in openrtsp
In-Reply-To: <4B550ECE.2020508@green-light.ca>
References: <4B550278.9040800@green-light.ca><f06240808c77ab3e4ff00@[66.80.62.44]>
	<4B550ECE.2020508@green-light.ca>
Message-ID: <6353CA579307224BAFDE9495906E691603D21872@ca-ops-mail>

I do not know enough about the OpenRSTP application neither understand
how you interface the live camera stream with it. But your problem look 
very similar to one I had 2 years ago with VLC. In fact you might have 
ran into the same synchronization issue I have had while I was working 
for another company. To understand that problem I had to recompile VLC 
with modified code I added to the live555 demux wrapper code that VLC 
used. You will find some links below. VLC was doing exactly what you 
described with an application I developed that was using the live555 
library.

The video was an Mpeg2 elementary stream and the audio was a PCM stream.

This is what I found. The seed time for the timestamp of the Mpeg2 video

stream is initialized when the the MPEGVideoStreamFramer is created when

the method MPEGVideoStreamFramer::reset() is called by the constructor.

For the audio the seed time for timestamp of the PCM was initialized by 
the object ByteStreamFileSource when method 
ByteStreamFileSource::doReadFromFile() is called the first time.

As long as the starting of the video sink by method startPlaying is very

close (a few ms) to the creation of the Mpeg framer you are fine. You 
have no synchronization problem with VLC.  But if you start the sink a 
few seconds after the creation of the Mpeg framer the video sink will 
nonetheless use the timestamp seed that was initialized at the creation 
of the object while the audio will use a timestamp seed that is
initialized 
at the time the sink is started. And in the latest case an application
like 
VLC try to compensate the few seconds of gap once the RTCP
synchronization 
packed is received and cannot because the gap between the audio and
video 
is too big.

My point of view is that the MpegFramer of the live555 library shouldn't

use a time seed that is initialized when the object is created but
rather 
when the computePresentationTime() is called the first time. Though I 
experienced that problem with the Mpeg framer you might have a look at
the 
live555 code if your video stream uses another framer.

I suggested a minor change to the live555 library to solve that problem
that 
is explained in the thread below. I am not sure but I think it was never

implemented. You might look at this thread yourself. It includes 2
application 
that demonstrate the problem. If I remember I was using an I frame only
mpeg2 
stream as a source for the video. You might try the patch I suggested to
check 
if it solve your problem.

http://lists.live555.com/pipermail/live-devel/2008-February/008121.html
http://lists.live555.com/pipermail/live-devel/attachments/20080212/8ba7d
ba1/attachment.ksh 
http://lists.live555.com/pipermail/live-devel/attachments/20080212/8ba7d
ba1/attachment-0001.ksh

Hope this help.
GB

>-----Original Message-----
>From: live-devel-bounces at ns.live555.com [mailto:live-devel-
>bounces at ns.live555.com] On Behalf Of Keith Page
>Sent: Monday, January 18, 2010 20:46
>To: LIVE555 Streaming Media - development & use
>Subject: Re: [Live-devel] Request to Fix inconsistent timestamps in
>openrtsp
>
>The problem I experience with VLC is that it takes the first set of
>presentation stamps as it's seed. When the new PTS stamps start coming
>in it detects that the numbers are way off from before, outside it's
>tolerance and throws an error saying PTS GAP, resetting clock, it then
>rebuffers. While that buffering takes place it throws out the frames
>coming in, leaving a blank section of the final muxed video. Once the
>buffer has refilled it is then fine on  per stream basis. During this
>process the video streams are able to stay in sync within a few ms but
>the audio is now all defunct and off by 4 - 8 seconds. The result is
the
>first 30 second of video is pretty much junk and has to be cut off, and
>the audio through out the entire video is delayed as stated before.
>
>I have tried playing with the code myself in vlc but have not had
>success getting a proper result out of it, it's beyond my ability to
>resolve. Though i thought if we could get a stream of stable PTS from
>openRTSP this problem would go away from VLC's point of view. VLC's
code
>currently looks for the RTCP and then reset all it's counters once it's
>seen and throws out it's current buffer and rebuilds a new one.
>
>So we aren't trying to re-invent any wheel, we are running into a
>problem with the current wheel not working in this situation,  that I
>thought could be fixed here by uniforming the PTS through the RTCP
sync.
>
>Could openRTSP not simply calculate an offset after the RCTP packet and
>adjust each subsequent packet by that offset to keep the whole PTS
>stream consistent? What would be the downside to doing this?
>
>Thanks
>Keith
>
>On 10-01-18 5:03 PM, Ross Finlayson wrote:
>>> The beginning of the muxing in vlc suffers from starts and stops
>>> while RTCP occurs. The time stamps being fed into vlc from openRTSP
>>> starts as actual unix time stamps, once a RTCP is received from the
>>> media source openRTSP changes to an arbitrarily number
>>
>> This is normal, and expected; there's no bug here.  It's because the
>> first few presentation times - before RTCP synchronization occurs -
>> are just 'guesses' made by the receiving code (based on the
receiver's
>> 'wall clock' and the RTP timestamp).  However, once RTCP
>> synchronization occurs, all subsequent presentation times will be
>> accurate.  (Depending upon the server, these presentation times -
>> after RTCP synchronization has occurred - might not necessarily look
>> like current Unix timestamps, but they *will be* accurate, and in
sync
>> with other substreams, unless of course your server is broken.)
>>
>> This means is that a receiver should be prepared for the fact that
the
>> first few presentation times (until RTCP synchronization starts) will
>> not be accurate.  The code, however, can check this by calling
>> "RTPSource:: hasBeenSynchronizedUsingRTCP()".  If this returns False,
>> then the presentation times are not accurate, and should be treated
>> with 'a grain of salt'.  However, once the call to returns True, then
>> the presentation times (from then on) will be accurate.
>>
>> Note, however, that this is *already* implemented in VLC (in its
>> "live555" demux module), so I don't know why you're trying to
reinvent
>> the wheel here.  You should be able to just use VLC 'as is'.
>
>_______________________________________________
>live-devel mailing list
>live-devel at lists.live555.com
>http://lists.live555.com/mailman/listinfo/live-devel

From finlayson at live555.com  Tue Jan 19 07:17:43 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 19 Jan 2010 07:17:43 -0800
Subject: [Live-devel] multi file read in testOnDemandRTSPServer
In-Reply-To: <5b42f1311001190401yebbb589lce8446d436e3930@mail.gmail.com>
References: <5b42f1311001182332i14b37002i146b49bc63d43da@mail.gmail.com>
	<f06240800c77b28d9d528@66.80.62.44>
	<5b42f1311001190401yebbb589lce8446d436e3930@mail.gmail.com>
Message-ID: <f06240800c77b7d0f8f59@[66.80.62.44]>

>It looks like the current MPEG4VideoStreamFramer implementation
>doesn't support this mode, because it maintains a state machine for
>parsing MPEG4 data. Each time it reads the video data, it seeks
>VISUAL_OBJECT_SEQUENCE_START_CODE (0x000001B0) which only exists at
>the beginning of the stream. If the START_CODE doesn't exist the state
>machine will break and streaming will fail.

OK, so you would need to buffer at least that data.

>However for H264 I believe we don't need to buffer the data.
>Maybe the restricted state machine (ie, seeking START_CODE) in
>MPEG4VideoStreamFramer is not necessary (sorry for this question, I
>don't have specific knowledge about MPEG4 standard)?

If your input source delivers discrete MPEG-4 frames (i.e., one frame 
at a time), then you could use "MPEG4VideoStreamDiscreteFramer" 
instead.
-- 

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

From finlayson at live555.com  Tue Jan 19 08:19:41 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 19 Jan 2010 08:19:41 -0800
Subject: [Live-devel] Request to Fix inconsistent timestamps in openrtsp
In-Reply-To: <6353CA579307224BAFDE9495906E691603D21872@ca-ops-mail>
References: <4B550278.9040800@green-light.ca><f06240808c77ab3e4ff00@[66.80.62.44]>
	<4B550ECE.2020508@green-light.ca>
	<6353CA579307224BAFDE9495906E691603D21872@ca-ops-mail>
Message-ID: <f06240802c77b8ae0cc7f@[66.80.62.44]>

>I do not know enough about the OpenRSTP application neither understand
>how you interface the live camera stream with it. But your problem look
>very similar to one I had 2 years ago with VLC.

No, it's completely different.  The original poster was describing a 
problem that he had at the *client* end (because he wasn't using our 
code correctly).  Your problem was a problem with maintaining correct 
synchronization at the *server* end (and thus had nothing 
specifically to do with VLC; it would have been a problem with *any* 
client).  As I noted back then, you could probably overcome your 
(server) problem by using discrete input sources, rather than 
unstructured byte stream sources:
	http://lists.live555.com/pipermail/live-devel/2008-February/008122.html

Please don't confuse things by hijacking inappropriate discussion 
threads :-) :-)
-- 

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

From alpharoot at gmail.com  Tue Jan 19 18:58:12 2010
From: alpharoot at gmail.com (alpharoot)
Date: Wed, 20 Jan 2010 10:58:12 +0800
Subject: [Live-devel] multi file read in testOnDemandRTSPServer
In-Reply-To: <f06240800c77b7d0f8f59@66.80.62.44>
References: <5b42f1311001182332i14b37002i146b49bc63d43da@mail.gmail.com>
	<f06240800c77b28d9d528@66.80.62.44>
	<5b42f1311001190401yebbb589lce8446d436e3930@mail.gmail.com>
	<f06240800c77b7d0f8f59@66.80.62.44>
Message-ID: <5b42f1311001191858y5da5e3dat394cb72deefe1940@mail.gmail.com>

On 1/19/10, Ross Finlayson <finlayson at live555.com> wrote:
> > It looks like the current MPEG4VideoStreamFramer implementation
> > doesn't support this mode, because it maintains a state machine for
> > parsing MPEG4 data. Each time it reads the video data, it seeks
> > VISUAL_OBJECT_SEQUENCE_START_CODE (0x000001B0) which only
> exists at
> > the beginning of the stream. If the START_CODE doesn't exist the state
> > machine will break and streaming will fail.
> >
>
> OK, so you would need to buffer at least that data.
>
> > However for H264 I believe we don't need to buffer the data.
> > Maybe the restricted state machine (ie, seeking START_CODE) in
> > MPEG4VideoStreamFramer is not necessary (sorry for this question, I
> > don't have specific knowledge about MPEG4 standard)?
> >
>
> If your input source delivers discrete MPEG-4 frames (i.e., one frame at a
> time), then you could use
> "MPEG4VideoStreamDiscreteFramer" instead.
That's great. MPEG4VideoStreamDiscreteFramer resolves the issue
perfectly. Now I don't need to buffer any data.

My MPEG4 video data is frame-based. The interesting thing is that we
don't need to feed the input to MPEG4VideoStreamDiscreteFramer frame
by frame, the MPEG4VideoStreamDiscreteFramer still works fine.

Thanks.

-- 
Bill

From finlayson at live555.com  Tue Jan 19 19:13:53 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 19 Jan 2010 19:13:53 -0800
Subject: [Live-devel] multi file read in testOnDemandRTSPServer
In-Reply-To: <5b42f1311001191858y5da5e3dat394cb72deefe1940@mail.gmail.com>
References: <5b42f1311001182332i14b37002i146b49bc63d43da@mail.gmail.com>
	<f06240800c77b28d9d528@66.80.62.44>
	<5b42f1311001190401yebbb589lce8446d436e3930@mail.gmail.com>
	<f06240800c77b7d0f8f59@66.80.62.44>
	<5b42f1311001191858y5da5e3dat394cb72deefe1940@mail.gmail.com>
Message-ID: <f06240800c77c248f27d2@[66.80.62.44]>

>My MPEG4 video data is frame-based. The interesting thing is that we
>don't need to feed the input to MPEG4VideoStreamDiscreteFramer frame
>by frame, the MPEG4VideoStreamDiscreteFramer still works fine.

No, you shouldn't do that, because the downstream object (usually a 
"MPEG4ESVideoRTPSink") assumes that data is fed to it one frame at a 
time.  (If you feed it more than one frame at a time, the resulting 
output RTP packets might not be compliant with the standard payload 
format, and might therefore end up being misinterpreted by a 
receiving client.)

A "MPEG4VideoStreamDiscreteFramer" should be fed exactly one MPEG-4 
video frame at a time.
-- 

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

From sharda.murthi at gmail.com  Tue Jan 19 19:20:28 2010
From: sharda.murthi at gmail.com (Sharda Murthi)
Date: Tue, 19 Jan 2010 22:20:28 -0500
Subject: [Live-devel] query
In-Reply-To: <f06240809c7102338cce6@66.80.62.44>
References: <000f01ca5918$ff31ee70$fd95cb50$@shah@wisedv.com>
	<f06240809c7102338cce6@66.80.62.44>
Message-ID: <e6b1d6e71001191920v30c16fel76297ed24655782e@mail.gmail.com>

Hi,

I am also trying to do what Karan is trying to do. I enabled port forwarding
on port 8554 on my system to allow the incoming packets from being blocked
by the firewall (from a connection outside of my network). The connection is
getting established, but no packets are being received. Can anyone help me
with this?

Sharda

On Fri, Oct 30, 2009 at 12:04 AM, Ross Finlayson <finlayson at live555.com>wrote:

>   I am new to openRTSP. I have installed the live555 streaming server on my
>> computer.
>> I am able to stream mp3 files locally through vlc media player but how to
>> stream it globally.?
>> I mean on 192.168.0.2 which is connected in LAN to my pc streaming is done
>> but I want to check it globally by assigning my global IP..
>>
>
> Look at the "rtsp://" URL that the "LIVE555 Media Server" application
> prints when it starts out.  If the IP address in this URL is a local IP
> address (e.g., 192.168.0.2), then just replace it by your server computer's
> *global* IP address.  Your clients (on the Internet) should then be able to
> use that URL to access your server.
> --
>
> 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/20100119/60ac9684/attachment.html>

From marcos at a5security.com  Tue Jan 19 23:56:39 2010
From: marcos at a5security.com (Miguel Angel Arcos)
Date: Wed, 20 Jan 2010 08:56:39 +0100
Subject: [Live-devel] H264 Decompress
Message-ID: <39b9a2b31001192356s10833eb4v8cae85b5ea5c4f2c@mail.gmail.com>

Dear Ross,

we started to develop using H264 protocol and we have some questions about
it. We are using all the comunication with live555 to extract data from an
Ip Camera with protocol H264. We have single NAL unit mode non-interleaved
and we are having problems to decompress using x264.

When we use x264 we init correctly the codec but when we try to decompress
we recieve ICERR_ERROR. If we try to decompress with VLC all its ok and we
can see the video correctly.

This are our questions:

- When I recieve every frame I recieve too one packet every time and we
ignore this, we use subsession->rtpSource()->curPacketMarkerBit() to do
this. This packet we think is only for information because is very small, 52
or 53 bytes. Is possible parse this packet to know what information
contains?

- The other question is about another very small packet of 4 bytes that we
recieve. That packet is recieved after X frames. We dont know what is this
and the information that it contains.

- We need some information of the two packets to decompress the image data
to avoid the ICERR_ERROR?

PD: We have been reading "RTP Payload Format for H.264 Video" and the FAQ of
live555 and we dont find the solution.

Thank you in advance.

-- 
Miguel Angel Arcos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100120/34b282bd/attachment-0001.html>

From finlayson at live555.com  Wed Jan 20 00:23:13 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 20 Jan 2010 00:23:13 -0800
Subject: [Live-devel] H264 Decompress
In-Reply-To: <39b9a2b31001192356s10833eb4v8cae85b5ea5c4f2c@mail.gmail.com>
References: <39b9a2b31001192356s10833eb4v8cae85b5ea5c4f2c@mail.gmail.com>
Message-ID: <f06240801c77c6c85c8a1@[66.80.62.44]>

>we started to develop using H264 protocol and we have some questions 
>about it. We are using all the comunication with live555 to extract 
>data from an Ip Camera with protocol H264. We have single NAL unit 
>mode non-interleaved and we are having problems to decompress using 
>x264.

Unfortunately I can't help you with decompression (decoding).  Our 
software doesn't do any decoding.


>- When I recieve every frame I recieve too one packet every time and 
>we ignore this, we use subsession->rtpSource()->curPacketMarkerBit() 
>to do this.

No, you don't need to do this call yourself!  We already handle the 
reception of the RTP payload format for H.264.  Just create a 
"H264VideoRTPSource" object.  It does all the work for you.

Are you sure that your server is sending its data in RTP?  If you are 
writing the server yourself (using our software), make sure that it 
uses  "H264VideoRTPSink", and that this is fed using a subclass of 
"H264VideoStreamFramer".
-- 

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

From finlayson at live555.com  Wed Jan 20 00:25:38 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 20 Jan 2010 00:25:38 -0800
Subject: [Live-devel] H264 Decompress
Message-ID: <f06240802c77c6e5434fb@[66.80.62.44]>

Also, H.264 is not a 'protocol' - it's a *codec*.  RTP is the protocol.
-- 

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

From finlayson at live555.com  Wed Jan 20 07:01:14 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 20 Jan 2010 07:01:14 -0800
Subject: [Live-devel] RTSP trick play, extra PES packet issue...
In-Reply-To: <4B544D10.5050507@sidc.com.tw>
References: <4B544D10.5050507@sidc.com.tw>
Message-ID: <f06240803c77c898e96be@[66.80.62.44]>

When a MPEG Transport Stream file is indexed (to produce an index 
(.tsx) file), our code skips over PES headers, so that the resulting 
index file points *only* to MPEG Elementary Stream video data, not 
PES headers (or any other non-MPEG-video data).  The 'trick play' 
code uses this indexed video data to generate new video data that 
represents the new (fast-forward or reverse-play) stream.

This new video stream is then converted back into a MPEG Transport 
Stream file.  As part of doing this, our code inserts a new PES 
header in front of the video data, before packaging it as MPEG 
Tranport Stream packets.  This new PES header is not an 'extra' 
header; it is simply replacing the PES header that we skipped over 
when we indexed the original file.  I don't believe there is anything 
wrong with this PES header; on the contrary, it is necessary in order 
to make the resulting Transport Stream file (for the 'trick play' 
stream) legal.

In summary: I believe that the Transport Stream data that our 'trick 
play' code produces is legal; there are no 'extra' PES headers.  If, 
however, your decoder is not properly handling this 'trick play' 
Transport Stream data because of something illegal that we are doing, 
then please let us know (with specific details).
-- 

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

From rob.krakora at messagenetsystems.com  Wed Jan 20 07:03:23 2010
From: rob.krakora at messagenetsystems.com (Robert Krakora)
Date: Wed, 20 Jan 2010 10:03:23 -0500
Subject: [Live-devel] Late binding fix in 2010.01.15 version not yielding
	video...
Message-ID: <b24e53351001200703i784c3a8apd783520e59f2968b@mail.gmail.com>

Ross:

The fix with which you provided me for the multicast destination address
embedded in the SETUP response does not appear to be yielding video.  The
RTSP server and clients and hence the camera that I am testing against are
at a remote location where nobody was available until today.  Since I was
seeing GET_PARAMETER traffic when I remotely logged in after applying your
fix, I assumed video was playing.  However, the people on site now tell me
that there is no video and I was able to obtain the trace below.  I went
back to the 2010.01.12 version with my hack and video is again present.  Let
me know if you need a Wireshark capture to debug this.

[root at mediaport088 MessageNet]# export DISPLAY=:0.0; vlc -vvvvv --noosd
--fullscreen --m4v-fps 30 --rtsp-mcast -I rc --no-audio rtsp://
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp
VLC media player 0.9.10 Grishenko
[00000001] main libvlc debug: VLC media player - version 0.9.10 Grishenko -
(c) 1996-2009 the VideoLAN team
[00000001] main libvlc debug: libvlc was configured with ../configure
'--prefix=/usr' '--libdir=/usr/lib64' '--with-live555-tree=/usr/lib64/live'
'--enable-run-as-root' '--enable-debug' 'LDFLAGS=-L/usr/lib64'
LibVLC has detected an unusable buggy GNU/libc version.
Please update to version 2.8 or newer.
[00000001] main libvlc debug: translation test: code is "C"
[00000001] main libvlc debug: checking builtin modules
[00000001] main libvlc debug: checking plugin modules
[00000001] main libvlc debug: loading plugins cache file
/root/.cache/vlc/plugins-04081e.dat
[00000001] main libvlc debug: recursively browsing `/usr/lib64/vlc'
[00000001] main libvlc debug: module bank initialized, found 259 modules
[00000001] main libvlc warning: Unable to get HAL device properties
[00000001] main libvlc debug: opening config file (/root/.config/vlc/vlcrc)
[00000001] main libvlc debug: CPU has capabilities 486 586 MMX 3DNow! MMXEXT
SSE SSE2 FPU
[00000001] main libvlc debug: looking for memcpy module: 4 candidates
[00000001] main libvlc debug: using memcpy module "memcpymmxext"
[00000349] main interaction debug: thread 1090869568 (Interaction control)
created at priority 0 (../../src/interface/interaction.c:382)
[00000351] main input debug: Creating an input for 'Media Library'
[00000351] main input debug: Input is a meta file: disabling unneeded
options
[00000351] main input debug:
`file/xspf-open:///root/.local/share/vlc/ml.xspf' gives access `file' demux
`xspf-open' path `/root/.local/share/vlc/ml.xspf'
[00000351] main input debug: creating access 'file'
path='/root/.local/share/vlc/ml.xspf'
[00000352] main access debug: looking for access module: 3 candidates
[00000349] main interaction debug: thread started
[00000352] access_file access debug: opening file
`/root/.local/share/vlc/ml.xspf'
[00000352] main access debug: using access module "access_file"
[00000352] main access debug: TIMER module_Need() : 3.457 ms - Total 3.457
ms / 1 intvls (Avg 3.457 ms)
[00000357] main stream debug: Using AStream*Stream
[00000357] main stream debug: pre-buffering...
[00000357] main stream debug: received first data for our buffer
[00000351] main input debug: creating demux: access='file' demux='xspf-open'
path='/root/.local/share/vlc/ml.xspf'
[00000358] main demux debug: looking for demux module: 1 candidate
[00000358] playlist demux debug: using XSPF playlist reader
[00000358] main demux debug: using demux module "playlist"
[00000358] main demux debug: TIMER module_Need() : 1.856 ms - Total 1.856 ms
/ 1 intvls (Avg 1.856 ms)
[00000351] main input debug:
`file/xspf-open:///root/.local/share/vlc/ml.xspf' successfully opened
[00000373] main xml debug: looking for xml module: 2 candidates
[00000373] main xml debug: using xml module "xml"
[00000373] main xml debug: TIMER module_Need() : 2.067 ms - Total 2.067 ms /
1 intvls (Avg 2.067 ms)
[00000358] playlist demux debug: parsed 0 tracks successfully
[00000373] main xml debug: removing module "xml"
[00000351] main input debug: EOF reached
[00000351] main input debug: control type=1
[00000358] main demux debug: removing module "playlist"
[00000352] main access debug: removing module "access_file"
[00000351] main input debug: Destroying the input for 'Media Library'
[00000351] main input debug: TIMER input launching for 'Media Library' :
14.506 ms - Total 14.506 ms / 1 intvls (Avg 14.506 ms)
[00000375] main preparser debug: waiting for thread initialization
[00000375] main preparser debug: thread started
[00000375] main preparser debug: thread 1101359424 (preparser) created at
priority 0 (../../src/playlist/thread.c:79)
[00000376] main fetcher debug: waiting for thread initialization
[00000376] main fetcher debug: thread started
[00000376] main fetcher debug: thread 1111849280 (fetcher) created at
priority 0 (../../src/playlist/thread.c:108)
[00000350] main playlist debug: waiting for thread initialization
[00000350] main playlist debug: thread started
[00000350] main playlist debug: thread 1122339136 (playlist) created at
priority 0 (../../src/playlist/thread.c:117)
[00000377] main interface debug: looking for interface module: 1 candidate
[00000377] main interface debug: using interface module "hotkeys"
[00000377] main interface debug: TIMER module_Need() : 0.938 ms - Total
0.938 ms / 1 intvls (Avg 0.938 ms)
[00000377] main interface debug: thread 1132828992 (interface) created at
priority 0 (../../src/interface/interface.c:168)
[00000379] main interface debug: looking for interface module: 1 candidate
[00000350] main playlist debug: rebuilding array of current - root Playlist
[00000350] main playlist debug: rebuild done - 0 items, index -1
[00000377] main interface debug: thread started
[00000379] main interface debug: using interface module "inhibit"
[00000379] main interface debug: TIMER module_Need() : 21.137 ms - Total
21.137 ms / 1 intvls (Avg 21.137 ms)
[00000379] main interface debug: thread 1143318848 (interface) created at
priority 0 (../../src/interface/interface.c:168)
[00000381] main interface debug: looking for interface module: 1 candidate
[00000381] main interface debug: using interface module "screensaver"
[00000381] main interface debug: TIMER module_Need() : 0.725 ms - Total
0.725 ms / 1 intvls (Avg 0.725 ms)
[00000381] main interface debug: thread 1153808704 (interface) created at
priority 0 (../../src/interface/interface.c:168)
[00000350] main playlist debug: adding item `rtsp://
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp' ( rtsp://
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp )
[00000381] main interface debug: thread started
[00000383] main interface debug: looking for interface module: 18 candidates
[00000383] main interface debug: using interface module "signals"
[00000383] main interface debug: TIMER module_Need() : 0.560 ms - Total
0.560 ms / 1 intvls (Avg 0.560 ms)
[00000383] main interface debug: thread 1174788416 (interface) created at
priority 0 (../../src/interface/interface.c:168)
[00000350] main playlist debug: rebuilding array of current - root Playlist
[00000350] main playlist debug: rebuild done - 1 items, index -1
[00000385] main interface debug: looking for interface module: 18 candidates
[00000379] main interface debug: thread started
[00000383] main interface debug: thread started
Remote control interface initialized. Type `help' for help.
[00000385] main interface debug: using interface module "rc"
[00000385] main interface debug: TIMER module_Need() : 1.532 ms - Total
1.532 ms / 1 intvls (Avg 1.532 ms)
[00000385] main interface debug: thread 1185278272 (interface) created at
priority 0 (../../src/interface/interface.c:168)
[00000385] main interface debug: thread started
[00000350] main playlist debug: starting new item
[00000350] main playlist debug: processing request item null node Playlist
skip 0
[00000350] main playlist debug: creating new input thread
[00000387] main input debug: Creating an input for 'rtsp://
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp'
[00000387] main input debug: waiting for thread initialization
[00000387] main input debug: thread started
[00000387] main input debug: `rtsp://
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp' gives access `rtsp'
demux `' path `dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp'
[00000387] main input debug: creating demux: access='rtsp' demux='' path='
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp'
[00000387] main input debug: thread 1195768128 (input) created at priority
10 (../../src/input/input.c:370)
[00000388] main demux debug: looking for access_demux module: 1 candidate
Sending request: OPTIONS rtsp://172.19.3.223:554/mpeg4/media.amp RTSP/1.0
CSeq: 1
User-Agent: VLC media player (LIVE555 Streaming Media v2010.01.12)


Received OPTIONS response: RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN


Sending request: DESCRIBE rtsp://172.19.3.223:554/mpeg4/media.amp RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: VLC media player (LIVE555 Streaming Media v2010.01.15)


Received DESCRIBE response: RTSP/1.0 401 Unauthorized
CSeq: 2
WWW-Authenticate: Basic realm="/"


Sending request: DESCRIBE rtsp://172.19.3.223:554/mpeg4/media.amp RTSP/1.0
CSeq: 3
Accept: application/sdp
Authorization: Basic ZGNhbXBiZWxsOm1zZHZpZGVv
User-Agent: VLC media player (LIVE555 Streaming Media v2010.01.15)


Received DESCRIBE response: RTSP/1.0 200 OK
CSeq: 3
Content-Base: rtsp://172.19.3.223:554/mpeg4/media.amp/
Content-Type: application/sdp
Content-Length: 696


Need to read 696 extra bytes
Read 696 extra bytes: v=0
o=- 19457605049436 19457605049442 IN IP4 172.19.3.223
s=Media Presentation
e=NONE
c=IN IP4 0.0.0.0
b=AS:8000
t=0 0
a=control:*
a=range:npt=now-
a=mpeg4-iod:
"data:application/mpeg4-iod;base64,AoDUAE8BAf/1AQOAbwABQFBkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBUjBCR3dVZkF4Y0F5U1FBWlFRTklCRUVrK0FBZWhJQUFIb1NBQVlCQkE9PQQNAQUABAAAAAAAAAAAAAYJAQAAAAAAAAAAAzoAAkA2ZGF0YTphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTWVFTSVVFVUZQd0E9BBICDQAAAgAAAAAAAAAABQMAAEAGCQEAAAAAAAAAAA=="
m=video 0 RTP/AVP 96
b=AS:8000
a=framerate:30
a=control:trackID=1
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=245;
config=000001B0F5000001B509000001000000012008D49D88032516043C14440F;
a=mpeg4-esid:201

[00000388] live555 demux debug: RTP subsession 'video/MP4V-ES'
Sending request: SETUP rtsp://172.19.3.223:554/mpeg4/media.amp/trackID=1RTSP/1.0
CSeq: 4
Transport: RTP/AVP;multicast;client_port=43242-43243
Authorization: Basic ZGNhbXBiZWxsOm1zZHZpZGVv
User-Agent: VLC media player (LIVE555 Streaming Media v2010.01.12)


Received SETUP response: RTSP/1.0 200 OK
CSeq: 4
Session: 1366558838;timeout=60
Transport:
RTP/AVP;multicast;destination=239.209.84.157;ttl=5;port=50000-50001;mode="PLAY"


[00000387] main input debug: selecting program id=0
[00000388] live555 demux debug: setup start: 0 stop:0
Sending request: PLAY rtsp://172.19.3.223:554/mpeg4/media.amp/ RTSP/1.0
CSeq: 5
Session: 1366558838
Range: npt=0.000-
Authorization: Basic ZGNhbXBiZWxsOm1zZHZpZGVv
User-Agent: VLC media player (LIVE555 Streaming Media v2010.01.12)


Received PLAY response: RTSP/1.0 200 OK
CSeq: 5
Session: 1366558838
Range: npt=now-
RTP-Info: url=trackID=1;seq=16983;rtptime=1906327257


[00000388] live555 demux debug: We have a timeout of 60 seconds
[00000391] main generic debug: waiting for thread initialization
[00000391] main generic debug: thread started
[00000391] main generic debug: thread 1206257984 (liveMedia-timeout) created
at priority 0 (../../../modules/demux/live555.cpp:1055)
[00000388] live555 demux debug: spawned timeout thread
[00000388] live555 demux debug: play start: 0 stop:0
[00000388] main demux debug: using access_demux module "live555"
[00000388] main demux debug: TIMER module_Need() : 122.963 ms - Total
122.963 ms / 1 intvls (Avg 122.963 ms)
[00000392] main decoder debug: looking for decoder module: 26 candidates
[00000392] avcodec decoder debug: libavcodec initialized (interface 3419392
)
[00000392] avcodec decoder debug: using direct rendering
[00000392] avcodec decoder debug: ffmpeg codec (MPEG-4 Video) started
[00000392] main decoder debug: using decoder module "avcodec"
[00000392] main decoder debug: TIMER module_Need() : 16.157 ms - Total
16.157 ms / 1 intvls (Avg 16.157 ms)
[00000392] main decoder debug: thread 1216747840 (decoder) created at
priority 0 (../../src/input/decoder.c:217)
[00000387] main input debug: `rtsp://
dcampbell:msdvideo at 172.19.3.223:554/mpeg4/media.amp' successfully opened
[00000392] main decoder debug: thread started
[00000387] main input debug: control type=1

Best Regards,

-- 
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100120/76416b53/attachment-0001.html>

From finlayson at live555.com  Wed Jan 20 15:19:05 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 20 Jan 2010 15:19:05 -0800
Subject: [Live-devel] Late binding fix in 2010.01.15 version not
 yielding video...
In-Reply-To: <b24e53351001200703i784c3a8apd783520e59f2968b@mail.gmail.com>
References: <b24e53351001200703i784c3a8apd783520e59f2968b@mail.gmail.com>
Message-ID: <f06240805c77d3cfd64d8@[66.80.62.44]>

>The fix with which you provided me for the multicast destination 
>address embedded in the SETUP response does not appear to be 
>yielding video.

Well, beforehand you told me that it worked OK!

Anyway, the fix was to reimplement the "Socket::changePort()" 
function (in "groupsock/NetInterface.cpp") to call "bind()" (with the 
new port number), rather than closing and then reopening the socket 
(which is what both the old version and your hack did).  Could you 
please figure out why the "changePort()" function is not working for 
you?  Unfortunately, I can't test this myself, because I don't have 
server that works the way yours does.
-- 

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

From changchun.zhang at tektronix.com  Wed Jan 20 22:12:41 2010
From: changchun.zhang at tektronix.com (changchun.zhang at tektronix.com)
Date: Wed, 20 Jan 2010 22:12:41 -0800
Subject: [Live-devel] Query on AMRDeinterleaver::deliverIncomingFrame
Message-ID: <38A838806557FA4D80EFB2C91A7BC7640D98580B37@us-bv-m10.global.tektronix.net>

Hi experts,

Have someone tested the functions used to deinterleave multi AMR frames in a single RTP packet? Here I have a question on the method AMRDeinterleave::deliverIncomingFrame. 
I suspect this method can only support the scenario that one RTP packet contains only one AMR frame.
My understanding is as below:
1. MultiframedRTPSource::networkReadHandler 
   This method receives RTP packet from the network and store it in the ReorderingPacketBuffer.
2. MultiFramedRTPSource::doGetNextFrame1()
   This method get a complete bufferedpacket form the ReorderingPacketBuffer and call the virtual method processSpecialHeader of the subclass(RawAMRRTPSource) to get the info of the AMR payload header, like the ILL, ILP etc.
   The usable packet is also transferred to the fInputBuffer of the AMRDeinterleaver.
3. FramedSource::afterGetting(this)
   In our case, the AMRDeinterleaver::afterGettingFrame is used. Then AMRDeinterleaver::afterGettingFrame1
4. AMRDeinterleave::deliverIncomingFrame
   This method is supposed to deliver the AMR frames in the packet, and placed in the fFrames[fIncomingBandId][binNumber], in which the binNumber is caculated by the (ILL, ILP, numChannels).
   I understand there should a loop to traverse all the AMR frames in a packet by this method. But it seems this method is only called once per packet, from my reading. 

I do not have the traffic of the format like multiple frames in single RTP packet. The RTSP server can only encode the .amr file to single frame /single packet.There must be something missed in my reading. 




From finlayson at live555.com  Thu Jan 21 04:36:45 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 21 Jan 2010 04:36:45 -0800
Subject: [Live-devel] Query on AMRDeinterleaver::deliverIncomingFrame
In-Reply-To: <38A838806557FA4D80EFB2C91A7BC7640D98580B37@us-bv-m10.global.tektronix.net
	>
References: <38A838806557FA4D80EFB2C91A7BC7640D98580B37@us-bv-m10.global.tektronix.net
	>
Message-ID: <f06240800c77df8804489@[66.80.62.44]>

>Have someone tested the functions used to deinterleave multi AMR 
>frames in a single RTP packet? Here I have a question on the method 
>AMRDeinterleave::deliverIncomingFrame.
>I suspect this method can only support the scenario that one RTP 
>packet contains only one AMR frame.

No.  Although our current implementation supports only the 
transmission of only one AMR frame in each RTP packet 
("AMRAudioRTPSink"), it *does* support the reception (and 
deinterleaving) of multiple frames in each RTP packet.  It does this 
by redefining the virtual function "nextEnclosedFrameSize()" (in the 
class "AMRBufferedPacket").  Because of this, each "RawAMRRTPSource" 
delivers only one AMR frame at a time to its downstream object (an 
"AMRDeinterleaver"), regardless of how many AMR frames were actually 
present in the incoming RTP packet.
-- 

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

From rob.krakora at gmail.com  Thu Jan 21 05:26:55 2010
From: rob.krakora at gmail.com (Robert Krakora)
Date: Thu, 21 Jan 2010 08:26:55 -0500
Subject: [Live-devel] Late binding fix in 2010.01.15 version not
	yielding video...
In-Reply-To: <f06240805c77d3cfd64d8@66.80.62.44>
References: <b24e53351001200703i784c3a8apd783520e59f2968b@mail.gmail.com>
	<f06240805c77d3cfd64d8@66.80.62.44>
Message-ID: <b24e53351001210526l6a1352afs750ece15fafb8fee@mail.gmail.com>

Ross:

I will debug this and let you know what is going on.  Multicast data was
arriving per Wireshark.  However, I did not capture the RTSP traffic...I
cannot see the video as the location is remote.  It was bad judgement on my
part to indicate to you that it was working prematurely.  I will have
someone at the site set up the camera and I will get you some data today.
Sorry, I have a lot of things on my platter and I rushed to judgement.  ;-)

Best Regards,

-- 
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax
On Wed, Jan 20, 2010 at 6:19 PM, Ross Finlayson <finlayson at live555.com>wrote:

>  The fix with which you provided me for the multicast destination address
>> embedded in the SETUP response does not appear to be yielding video.
>>
>
> Well, beforehand you told me that it worked OK!
>
> Anyway, the fix was to reimplement the "Socket::changePort()" function (in
> "groupsock/NetInterface.cpp") to call "bind()" (with the new port number),
> rather than closing and then reopening the socket (which is what both the
> old version and your hack did).  Could you please figure out why the
> "changePort()" function is not working for you?  Unfortunately, I can't test
> this myself, because I don't have server that works the way yours does.
> --
>
> 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/20100121/a4bb95aa/attachment.html>

From rob.krakora at gmail.com  Thu Jan 21 07:58:10 2010
From: rob.krakora at gmail.com (Robert Krakora)
Date: Thu, 21 Jan 2010 10:58:10 -0500
Subject: [Live-devel] Late binding fix in 2010.01.15 version not
	yielding video...
In-Reply-To: <b24e53351001210526l6a1352afs750ece15fafb8fee@mail.gmail.com>
References: <b24e53351001200703i784c3a8apd783520e59f2968b@mail.gmail.com>
	<f06240805c77d3cfd64d8@66.80.62.44>
	<b24e53351001210526l6a1352afs750ece15fafb8fee@mail.gmail.com>
Message-ID: <b24e53351001210758l3b25b47avcff435185b5ef749@mail.gmail.com>

Ross:

It looks like kernel 2.6.18-128.1.10.el5 utilized in CentOS 5.3 does not
implement SO_REUSEPORT (see commented out SO_REUSEPORT below from "socket.h"
file for this kernel and the comment about it's needed implementation in *bold
red*).  Otherwise I believe your fix would have worked.  I did not see an
error message on the re-bind code like I would have expected though.  I am
going to retest and put in some breakpoints.

#ifndef _ASM_SOCKET_H
#define _ASM_SOCKET_H

#include <asm/sockios.h>

/* For setsockopt(2) */
#define SOL_SOCKET    1

#define SO_DEBUG    1
#define SO_REUSEADDR    2
#define SO_TYPE        3
#define SO_ERROR    4
#define SO_DONTROUTE    5
#define SO_BROADCAST    6
#define SO_SNDBUF    7
#define SO_RCVBUF    8
#define SO_SNDBUFFORCE    32
#define SO_RCVBUFFORCE    33
#define SO_KEEPALIVE    9
#define SO_OOBINLINE    10
#define SO_NO_CHECK    11
#define SO_PRIORITY    12
#define SO_LINGER    13
#define SO_BSDCOMPAT    14
*/* To add :#define SO_REUSEPORT 15 */*
#define SO_PASSCRED    16
#define SO_PEERCRED    17
#define SO_RCVLOWAT    18
#define SO_SNDLOWAT    19
#define SO_RCVTIMEO    20
#define SO_SNDTIMEO    21

/* Security levels - as per NRL IPv6 - don't actually do anything */
#define SO_SECURITY_AUTHENTICATION        22
#define SO_SECURITY_ENCRYPTION_TRANSPORT    23
#define SO_SECURITY_ENCRYPTION_NETWORK        24

#define SO_BINDTODEVICE    25

/* Socket filtering */
#define SO_ATTACH_FILTER        26
#define SO_DETACH_FILTER        27

#define SO_PEERNAME        28
#define SO_TIMESTAMP        29
#define SCM_TIMESTAMP        SO_TIMESTAMP

#define SO_ACCEPTCONN        30

#define SO_PEERSEC             31
#define SO_PASSSEC        34

#endif /* _ASM_SOCKET_H */

Best Regards,

-- 
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax

On Thu, Jan 21, 2010 at 8:26 AM, Robert Krakora <rob.krakora at gmail.com>wrote:

> Ross:
>
> I will debug this and let you know what is going on.  Multicast data was
> arriving per Wireshark.  However, I did not capture the RTSP traffic...I
> cannot see the video as the location is remote.  It was bad judgement on my
> part to indicate to you that it was working prematurely.  I will have
> someone at the site set up the camera and I will get you some data today.
> Sorry, I have a lot of things on my platter and I rushed to judgement.  ;-)
>
> Best Regards,
>
> --
> Rob Krakora
> Senior Software Engineer
> MessageNet Systems
> 101 East Carmel Dr. Suite 105
> Carmel, IN 46032
> (317)566-1677 Ext. 206
> (317)663-0808 Fax
> On Wed, Jan 20, 2010 at 6:19 PM, Ross Finlayson <finlayson at live555.com>wrote:
>
>>  The fix with which you provided me for the multicast destination address
>>> embedded in the SETUP response does not appear to be yielding video.
>>>
>>
>> Well, beforehand you told me that it worked OK!
>>
>> Anyway, the fix was to reimplement the "Socket::changePort()" function (in
>> "groupsock/NetInterface.cpp") to call "bind()" (with the new port number),
>> rather than closing and then reopening the socket (which is what both the
>> old version and your hack did).  Could you please figure out why the
>> "changePort()" function is not working for you?  Unfortunately, I can't test
>> this myself, because I don't have server that works the way yours does.
>> --
>>
>> 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/20100121/939472b5/attachment.html>

From rob.krakora at gmail.com  Thu Jan 21 08:13:18 2010
From: rob.krakora at gmail.com (Robert Krakora)
Date: Thu, 21 Jan 2010 11:13:18 -0500
Subject: [Live-devel] Late binding fix in 2010.01.15 version not
	yielding video...
In-Reply-To: <b24e53351001210758l3b25b47avcff435185b5ef749@mail.gmail.com>
References: <b24e53351001200703i784c3a8apd783520e59f2968b@mail.gmail.com>
	<f06240805c77d3cfd64d8@66.80.62.44>
	<b24e53351001210526l6a1352afs750ece15fafb8fee@mail.gmail.com>
	<b24e53351001210758l3b25b47avcff435185b5ef749@mail.gmail.com>
Message-ID: <b24e53351001210813kb984fe4gb46ade4c4898f64b@mail.gmail.com>

My bad,

SO_REUSEADDR allows binding to an address that is in a TIME_WAIT state while
SO_REUSEPORT allows multiple processes to bind to the same address.  This
has nothing to do with rebinding...I will keep looking...

On Thu, Jan 21, 2010 at 10:58 AM, Robert Krakora <rob.krakora at gmail.com>wrote:

> Ross:
>
> It looks like kernel 2.6.18-128.1.10.el5 utilized in CentOS 5.3 does not
> implement SO_REUSEPORT (see commented out SO_REUSEPORT below from "socket.h"
> file for this kernel and the comment about it's needed implementation in *bold
> red*).  Otherwise I believe your fix would have worked.  I did not see an
> error message on the re-bind code like I would have expected though.  I am
> going to retest and put in some breakpoints.
>
> #ifndef _ASM_SOCKET_H
> #define _ASM_SOCKET_H
>
> #include <asm/sockios.h>
>
> /* For setsockopt(2) */
> #define SOL_SOCKET    1
>
> #define SO_DEBUG    1
> #define SO_REUSEADDR    2
> #define SO_TYPE        3
> #define SO_ERROR    4
> #define SO_DONTROUTE    5
> #define SO_BROADCAST    6
> #define SO_SNDBUF    7
> #define SO_RCVBUF    8
> #define SO_SNDBUFFORCE    32
> #define SO_RCVBUFFORCE    33
> #define SO_KEEPALIVE    9
> #define SO_OOBINLINE    10
> #define SO_NO_CHECK    11
> #define SO_PRIORITY    12
> #define SO_LINGER    13
> #define SO_BSDCOMPAT    14
> */* To add :#define SO_REUSEPORT 15 */*
> #define SO_PASSCRED    16
> #define SO_PEERCRED    17
> #define SO_RCVLOWAT    18
> #define SO_SNDLOWAT    19
> #define SO_RCVTIMEO    20
> #define SO_SNDTIMEO    21
>
> /* Security levels - as per NRL IPv6 - don't actually do anything */
> #define SO_SECURITY_AUTHENTICATION        22
> #define SO_SECURITY_ENCRYPTION_TRANSPORT    23
> #define SO_SECURITY_ENCRYPTION_NETWORK        24
>
> #define SO_BINDTODEVICE    25
>
> /* Socket filtering */
> #define SO_ATTACH_FILTER        26
> #define SO_DETACH_FILTER        27
>
> #define SO_PEERNAME        28
> #define SO_TIMESTAMP        29
> #define SCM_TIMESTAMP        SO_TIMESTAMP
>
> #define SO_ACCEPTCONN        30
>
> #define SO_PEERSEC             31
> #define SO_PASSSEC        34
>
> #endif /* _ASM_SOCKET_H */
>
>
> Best Regards,
>
> --
> Rob Krakora
> Senior Software Engineer
> MessageNet Systems
> 101 East Carmel Dr. Suite 105
> Carmel, IN 46032
> (317)566-1677 Ext. 206
> (317)663-0808 Fax
>
> On Thu, Jan 21, 2010 at 8:26 AM, Robert Krakora <rob.krakora at gmail.com>wrote:
>
>> Ross:
>>
>> I will debug this and let you know what is going on.  Multicast data was
>> arriving per Wireshark.  However, I did not capture the RTSP traffic...I
>> cannot see the video as the location is remote.  It was bad judgement on my
>> part to indicate to you that it was working prematurely.  I will have
>> someone at the site set up the camera and I will get you some data today.
>> Sorry, I have a lot of things on my platter and I rushed to judgement.  ;-)
>>
>> Best Regards,
>>
>> --
>> Rob Krakora
>> Senior Software Engineer
>> MessageNet Systems
>> 101 East Carmel Dr. Suite 105
>> Carmel, IN 46032
>> (317)566-1677 Ext. 206
>> (317)663-0808 Fax
>> On Wed, Jan 20, 2010 at 6:19 PM, Ross Finlayson <finlayson at live555.com>wrote:
>>
>>>  The fix with which you provided me for the multicast destination
>>>> address embedded in the SETUP response does not appear to be yielding video.
>>>>
>>>
>>> Well, beforehand you told me that it worked OK!
>>>
>>> Anyway, the fix was to reimplement the "Socket::changePort()" function
>>> (in "groupsock/NetInterface.cpp") to call "bind()" (with the new port
>>> number), rather than closing and then reopening the socket (which is what
>>> both the old version and your hack did).  Could you please figure out why
>>> the "changePort()" function is not working for you?  Unfortunately, I can't
>>> test this myself, because I don't have server that works the way yours does.
>>> --
>>>
>>> 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
>>>
>>
>>
>


-- 
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100121/1b2bd13d/attachment-0001.html>

From rob.krakora at gmail.com  Thu Jan 21 12:42:15 2010
From: rob.krakora at gmail.com (Robert Krakora)
Date: Thu, 21 Jan 2010 15:42:15 -0500
Subject: [Live-devel] Late binding fix in 2010.01.15 version not
	yielding video...
In-Reply-To: <b24e53351001210813kb984fe4gb46ade4c4898f64b@mail.gmail.com>
References: <b24e53351001200703i784c3a8apd783520e59f2968b@mail.gmail.com>
	<f06240805c77d3cfd64d8@66.80.62.44>
	<b24e53351001210526l6a1352afs750ece15fafb8fee@mail.gmail.com>
	<b24e53351001210758l3b25b47avcff435185b5ef749@mail.gmail.com>
	<b24e53351001210813kb984fe4gb46ade4c4898f64b@mail.gmail.com>
Message-ID: <b24e53351001211242i6dca7983k9df183c83724ec88@mail.gmail.com>

Ross:

No multicast packets are received with the 2010-01-15 version for which you
provided the fix.  I looked at the TCP/IP stack source and it appears that
once a socket is bound it cannot be rebound.  As a test I commented out the
'bind' code block in the setupDatagramSocket() function in the
"GroupsockHelper.cpp" file and let the changePort() function in the
"NetInterface.cpp" file perform the 'bind' and multicast packets then were
received by VLC and video displayed.  I hope this helps and sorry for the
'false' positive on the first go-round.

Best Regards,

-- 
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax

On Thu, Jan 21, 2010 at 11:13 AM, Robert Krakora <rob.krakora at gmail.com>wrote:

> My bad,
>
> SO_REUSEADDR allows binding to an address that is in a TIME_WAIT state
> while SO_REUSEPORT allows multiple processes to bind to the same address.
> This has nothing to do with rebinding...I will keep looking...
>
>
> On Thu, Jan 21, 2010 at 10:58 AM, Robert Krakora <rob.krakora at gmail.com>wrote:
>
>> Ross:
>>
>> It looks like kernel 2.6.18-128.1.10.el5 utilized in CentOS 5.3 does not
>> implement SO_REUSEPORT (see commented out SO_REUSEPORT below from "socket.h"
>> file for this kernel and the comment about it's needed implementation in
>> *bold red*).  Otherwise I believe your fix would have worked.  I did not
>> see an error message on the re-bind code like I would have expected though.
>> I am going to retest and put in some breakpoints.
>>
>> #ifndef _ASM_SOCKET_H
>> #define _ASM_SOCKET_H
>>
>> #include <asm/sockios.h>
>>
>> /* For setsockopt(2) */
>> #define SOL_SOCKET    1
>>
>> #define SO_DEBUG    1
>> #define SO_REUSEADDR    2
>> #define SO_TYPE        3
>> #define SO_ERROR    4
>> #define SO_DONTROUTE    5
>> #define SO_BROADCAST    6
>> #define SO_SNDBUF    7
>> #define SO_RCVBUF    8
>> #define SO_SNDBUFFORCE    32
>> #define SO_RCVBUFFORCE    33
>> #define SO_KEEPALIVE    9
>> #define SO_OOBINLINE    10
>> #define SO_NO_CHECK    11
>> #define SO_PRIORITY    12
>> #define SO_LINGER    13
>> #define SO_BSDCOMPAT    14
>> */* To add :#define SO_REUSEPORT 15 */*
>> #define SO_PASSCRED    16
>> #define SO_PEERCRED    17
>> #define SO_RCVLOWAT    18
>> #define SO_SNDLOWAT    19
>> #define SO_RCVTIMEO    20
>> #define SO_SNDTIMEO    21
>>
>> /* Security levels - as per NRL IPv6 - don't actually do anything */
>> #define SO_SECURITY_AUTHENTICATION        22
>> #define SO_SECURITY_ENCRYPTION_TRANSPORT    23
>> #define SO_SECURITY_ENCRYPTION_NETWORK        24
>>
>> #define SO_BINDTODEVICE    25
>>
>> /* Socket filtering */
>> #define SO_ATTACH_FILTER        26
>> #define SO_DETACH_FILTER        27
>>
>> #define SO_PEERNAME        28
>> #define SO_TIMESTAMP        29
>> #define SCM_TIMESTAMP        SO_TIMESTAMP
>>
>> #define SO_ACCEPTCONN        30
>>
>> #define SO_PEERSEC             31
>> #define SO_PASSSEC        34
>>
>> #endif /* _ASM_SOCKET_H */
>>
>>
>> Best Regards,
>>
>> --
>> Rob Krakora
>> Senior Software Engineer
>> MessageNet Systems
>> 101 East Carmel Dr. Suite 105
>> Carmel, IN 46032
>> (317)566-1677 Ext. 206
>> (317)663-0808 Fax
>>
>> On Thu, Jan 21, 2010 at 8:26 AM, Robert Krakora <rob.krakora at gmail.com>wrote:
>>
>>> Ross:
>>>
>>> I will debug this and let you know what is going on.  Multicast data was
>>> arriving per Wireshark.  However, I did not capture the RTSP traffic...I
>>> cannot see the video as the location is remote.  It was bad judgement on my
>>> part to indicate to you that it was working prematurely.  I will have
>>> someone at the site set up the camera and I will get you some data today.
>>> Sorry, I have a lot of things on my platter and I rushed to judgement.  ;-)
>>>
>>> Best Regards,
>>>
>>> --
>>> Rob Krakora
>>> Senior Software Engineer
>>> MessageNet Systems
>>> 101 East Carmel Dr. Suite 105
>>> Carmel, IN 46032
>>> (317)566-1677 Ext. 206
>>> (317)663-0808 Fax
>>> On Wed, Jan 20, 2010 at 6:19 PM, Ross Finlayson <finlayson at live555.com>wrote:
>>>
>>>>  The fix with which you provided me for the multicast destination
>>>>> address embedded in the SETUP response does not appear to be yielding video.
>>>>>
>>>>
>>>> Well, beforehand you told me that it worked OK!
>>>>
>>>> Anyway, the fix was to reimplement the "Socket::changePort()" function
>>>> (in "groupsock/NetInterface.cpp") to call "bind()" (with the new port
>>>> number), rather than closing and then reopening the socket (which is what
>>>> both the old version and your hack did).  Could you please figure out why
>>>> the "changePort()" function is not working for you?  Unfortunately, I can't
>>>> test this myself, because I don't have server that works the way yours does.
>>>> --
>>>>
>>>> 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
>>>>
>>>
>>>
>>
>
>
> --
> Rob Krakora
> Senior Software Engineer
> MessageNet Systems
> 101 East Carmel Dr. Suite 105
> Carmel, IN 46032
> (317)566-1677 Ext. 206
> (317)663-0808 Fax
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100121/7511c23f/attachment.html>

From changchun.zhang at tektronix.com  Thu Jan 21 22:46:45 2010
From: changchun.zhang at tektronix.com (changchun.zhang at tektronix.com)
Date: Thu, 21 Jan 2010 22:46:45 -0800
Subject: [Live-devel] Query on AMRDeinterleaver::deliverIncomingFrame
In-Reply-To: <f06240800c77df8804489@[66.80.62.44]>
References: <38A838806557FA4D80EFB2C91A7BC7640D98580B37@us-bv-m10.global.tektronix.net	>
	<f06240800c77df8804489@[66.80.62.44]>
Message-ID: <38A838806557FA4D80EFB2C91A7BC7640D98674342@us-bv-m10.global.tektronix.net>

Thanks Ross. 
I now do see that there is a while loop in the 
MultiFramedRTPSource::doGetNextFrame1 and the 
BufferedPacket::use is used in the loop to travers all the frames in the single packet unitl this packet is used out.
Also the afterGetting(this) is called in this loop to ensure that " each "RawAMRRTPSource" 
delivers only one AMR frame at a time to its downstream object (an 
"AMRDeinterleaver"),"

Am I right?

B.R,
Changchun (Alex)


-----Original Message-----
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Thursday, January 21, 2010 8:37 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Query on AMRDeinterleaver::deliverIncomingFrame

>Have someone tested the functions used to deinterleave multi AMR 
>frames in a single RTP packet? Here I have a question on the method 
>AMRDeinterleave::deliverIncomingFrame.
>I suspect this method can only support the scenario that one RTP 
>packet contains only one AMR frame.

No.  Although our current implementation supports only the 
transmission of only one AMR frame in each RTP packet 
("AMRAudioRTPSink"), it *does* support the reception (and 
deinterleaving) of multiple frames in each RTP packet.  It does this 
by redefining the virtual function "nextEnclosedFrameSize()" (in the 
class "AMRBufferedPacket").  Because of this, each "RawAMRRTPSource" 
delivers only one AMR frame at a time to its downstream object (an 
"AMRDeinterleaver"), regardless of how many AMR frames were actually 
present in the incoming RTP packet.
-- 

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



From changchun.zhang at tektronix.com  Thu Jan 21 23:08:08 2010
From: changchun.zhang at tektronix.com (changchun.zhang at tektronix.com)
Date: Thu, 21 Jan 2010 23:08:08 -0800
Subject: [Live-devel]  Testing resource for the RTP AMR
In-Reply-To: <38A838806557FA4D80EFB2C91A7BC7640D98674342@us-bv-m10.global.tektronix.net>
References: <38A838806557FA4D80EFB2C91A7BC7640D98580B37@us-bv-m10.global.tektronix.net	>
	<f06240800c77df8804489@[66.80.62.44]>
	<38A838806557FA4D80EFB2C91A7BC7640D98674342@us-bv-m10.global.tektronix.net>
Message-ID: <38A838806557FA4D80EFB2C91A7BC7640D98674355@us-bv-m10.global.tektronix.net>

Hi experts,

I want to test the RTSP client on the all kinds of possible formates of the RTP AMR payload. But I can not find the testing resource which can generate the desired RTP stream used for this testing. I want to know how did you perform such test? The RTSP server can only generate the single frame single packet stream.

Thanks,

Alex Zhang



From changchun.zhang at tektronix.com  Fri Jan 22 01:21:20 2010
From: changchun.zhang at tektronix.com (changchun.zhang at tektronix.com)
Date: Fri, 22 Jan 2010 01:21:20 -0800
Subject: [Live-devel] Does live555 RTSP client support RTP AMR frames
	redundant?
Message-ID: <38A838806557FA4D80EFB2C91A7BC7640D98674405@us-bv-m10.global.tektronix.net>

Hi Experts,

I am not sure if the live555 support redundant AMR frames in RTP streams. I don't see such code in the live555 lib. So if the SDP contains max-red >0, how does the RTSP client react such RTP stream?

Attach is the description on max-red in SDP described in RFC4867, section 8:
max-red: The maximum duration in milliseconds that elapses between
               the primary (first) transmission of a frame and any
               redundant transmission that the sender will use.  This
               parameter allows a receiver to have a bounded delay when
               redundancy is used.  Allowed values are between 0 (no
               redundancy will be used) and 65535.  If the parameter is
               omitted, no limitation on the use of redundancy is
               present.
and the example in section 3.7.1 figure 1:
  --+--------+--------+--------+--------+--------+--------+--------+--
     | f(n-2) | f(n-1) |  f(n)  | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
   --+--------+--------+--------+--------+--------+--------+--------+--

     <---- p(n-1) ---->
              <----- p(n) ----->
                       <---- p(n+1) ---->
                                <---- p(n+2) ---->
                                         <---- p(n+3) ---->
                                                  <---- p(n+4) ---->

              Figure 1: An example of redundant transmission


Zhang, Changchun  | NM | CDC | Tektronix Communications | +86 21 38960464 | changchun.zhang at tektronix.com<mailto:zhang.changchun at tektronix.com>

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

From finlayson at live555.com  Fri Jan 22 02:52:32 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 22 Jan 2010 02:52:32 -0800
Subject: [Live-devel] Testing resource for the RTP AMR
In-Reply-To: <38A838806557FA4D80EFB2C91A7BC7640D98674355@us-bv-m10.global.tektronix.net
	>
References: <38A838806557FA4D80EFB2C91A7BC7640D98580B37@us-bv-m10.global.tektronix.net
	>	<f06240800c77df8804489@[66.80.62.44]>
	<38A838806557FA4D80EFB2C91A7BC7640D98674342@us-bv-m10.global.tektronix.net
	>
	<38A838806557FA4D80EFB2C91A7BC7640D98674355@us-bv-m10.global.tektronix.net
	>
Message-ID: <f06240800c77f337b212c@[66.80.62.44]>

>I want to test the RTSP client on the all kinds of possible formates 
>of the RTP AMR payload. But I can not find the testing resource 
>which can generate the desired RTP stream used for this testing. I 
>want to know how did you perform such test?

I can't remember, but I think I found some publically-accessible 
QuickTime RTSP streams (with AMR audio) somewhere on the Internet...
-- 

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

From finlayson at live555.com  Fri Jan 22 03:06:50 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 22 Jan 2010 03:06:50 -0800
Subject: [Live-devel] Does live555 RTSP client support RTP AMR frames
 redundant?
In-Reply-To: <38A838806557FA4D80EFB2C91A7BC7640D98674405@us-bv-m10.global.tektronix.net
	>
References: <38A838806557FA4D80EFB2C91A7BC7640D98674405@us-bv-m10.global.tektronix.net
	>
Message-ID: <f06240800c77f367ed606@[66.80.62.44]>

>I am not sure if the live555 support redundant AMR frames in RTP 
>streams. I don't see such code in the live555 lib. So if the SDP 
>contains max-red >0, how does the RTSP client react such RTP stream?

We don't recognize the "max-red" parameter, but our receiving code 
("AMRAudioRTPSource") *might* support redundant frames (using the 
same mechanism as deinterleaving).  I'm not sure, though; you'll have 
to test this for yourself.
-- 

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

From jnoring at logitech.com  Fri Jan 22 12:23:34 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Fri, 22 Jan 2010 12:23:34 -0800
Subject: [Live-devel] Blocking socket
In-Reply-To: <f06240803c77852f67f53@66.80.62.44>
References: <f06240803c77852f67f53@66.80.62.44>
Message-ID: <988ed6931001221223i2de8e831q9dbb76ed4d6af8f5@mail.gmail.com>

On Sat, Jan 16, 2010 at 9:39 PM, Ross Finlayson <finlayson at live555.com>wrote:

> Looking at the original patch, it's pretty clear that the author forgot to
>> set the socket back to be blocking.  But considering that this issue has
>> been present for well over a year, I have to wonder whether or not the
>> RTSPClient even needs to be run on a blocking socket. (Ross, you know the
>> most about this, so I'd be interested to hear your take on things).
>>
>
> I'm not planning on doing much with the existing "RTSPClient" code, because
> this code will soon be significantly overhauled so that it does I/O
> asynchronously, using the event loop, rather than the current
> blocking-with-timeout model (which doesn't fit with the event-driven model
> of the rest of the library's code).  This change will also eliminate the
> need for a "timeout" parameter (although the existing API will probably kept
> - as an option - for a while, for backwards compatibility).
>
> Fixing "RTSPClient" is high priority (second only to fixing the problems
> with RTP-over-TCP).


I've had a chance to test this change, and everything still seems to work OK
for me (I use the RTSPClient to pull directly from a Live555 on-demand
server; I also use the darwin push code, which uses the RTSPClient
internally).  How do you want the patch?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100122/6ccebd5f/attachment.html>

From finlayson at live555.com  Fri Jan 22 13:34:04 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 22 Jan 2010 13:34:04 -0800
Subject: [Live-devel] Late binding fix in 2010.01.15 version not
 yielding video...
In-Reply-To: <b24e53351001211242i6dca7983k9df183c83724ec88@mail.gmail.com>
References: <b24e53351001200703i784c3a8apd783520e59f2968b@mail.gmail.com>
	<f06240805c77d3cfd64d8@66.80.62.44>
	<b24e53351001210526l6a1352afs750ece15fafb8fee@mail.gmail.com>
	<b24e53351001210758l3b25b47avcff435185b5ef749@mail.gmail.com>
	<b24e53351001210813kb984fe4gb46ade4c4898f64b@mail.gmail.com>
	<b24e53351001211242i6dca7983k9df183c83724ec88@mail.gmail.com>
Message-ID: <f06240800c77fc9090630@[66.80.62.44]>

OK, I have now installed a new version (2010.01.22) of the software 
that should fix this problem.

Note to Rob Krakora and Alex Nemec: Please download and test this, to 
see whether it works OK (and still avoids getting any "select()" 
errors).  I can't test it myself.

Important note:  As a result of this fix, this version introduces a 
new function
              virtual void moveSocketHandling(int oldSocketNum, int 
newSocketNum) = 0;
to the "TaskScheduler" API.  We have implemented this for 
"BasicTaskScheduler".  If, however, you implement your own subclass 
of "TaskScheduler", then you will need to implement this new function 
as well.
-- 

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

From finlayson at live555.com  Fri Jan 22 13:36:06 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 22 Jan 2010 13:36:06 -0800
Subject: [Live-devel] Blocking socket
In-Reply-To: <988ed6931001221223i2de8e831q9dbb76ed4d6af8f5@mail.gmail.com>
References: <f06240803c77852f67f53@66.80.62.44>
	<988ed6931001221223i2de8e831q9dbb76ed4d6af8f5@mail.gmail.com>
Message-ID: <f06240801c77fcaa4669b@[66.80.62.44]>

>I've had a chance to test this change, and everything still seems to 
>work OK for me (I use the RTSPClient to pull directly from a Live555 
>on-demand server; I also use the darwin push code, which uses the 
>RTSPClient internally).  How do you want the patch?

A regular 'patch'-format file (e.g., produced by "diff -c") would work.
-- 

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

From a.nemec at atlas.cz  Sun Jan 24 01:27:57 2010
From: a.nemec at atlas.cz (=?utf-8?B?TsSbbWVjIEFsZXhhbmRy?=)
Date: Sun, 24 Jan 2010 09:27:57 GMT
Subject: [Live-devel] 2010.01.22 - fixed
Message-ID: <3888477987fb4c6ea6aaf58e25585ece@036d7acbd2ed456385077e148b8859b1>

An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100124/591ec036/attachment.html>
-------------- next part --------------
Hi Ross,
according to my quick tests with openRTSP I can now confirm that I receive media over multicast even from the cameras from which it was not possible before this fix, for me the fix in 2010.01.22 is working.
Thanks
Alex

From marcos at a5security.com  Mon Jan 25 03:25:08 2010
From: marcos at a5security.com (Miguel Angel Arcos)
Date: Mon, 25 Jan 2010 12:25:08 +0100
Subject: [Live-devel] H264 H264VideoRTPSource
Message-ID: <39b9a2b31001250325w68f740daid32689639ed915d7@mail.gmail.com>

Dear Ross,

I'm working with the class H264VideoRTPSource when I recieve RTP data
information of an IP Camera and I have some questions.

First, If I look my (subsession->(fVideoWidth y fVideoHeight)) and I can't
extract video resolution because this values are 0. Then I'm looking to
extract that information looking the SPS, Sequence Parameter Set, packets.
On the live555 classes I have been looking and I can't find any parser of
that data. Is possible extract that information using live555 or I need to
search another parser to do that task?

Thank you in advance.

-- 
Miguel Angel Arcos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100125/75e5a474/attachment.html>

From finlayson at live555.com  Mon Jan 25 05:00:21 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 25 Jan 2010 05:00:21 -0800
Subject: [Live-devel] H264 H264VideoRTPSource
In-Reply-To: <39b9a2b31001250325w68f740daid32689639ed915d7@mail.gmail.com>
References: <39b9a2b31001250325w68f740daid32689639ed915d7@mail.gmail.com>
Message-ID: <f06240809c78345ed46ff@[66.80.62.44]>

>I'm working with the class H264VideoRTPSource when I recieve RTP 
>data information of an IP Camera and I have some questions.
>
>First, If I look my (subsession->(fVideoWidth y fVideoHeight)) and I 
>can't extract video resolution because this values are 0.

Only a few RTSP/RTP streams specify this information in their SDP 
description (i.e., as a hint).  In general, you can get this 
information (video width and height) only by decoding the video 
stream.


>  Then I'm looking to extract that information looking the SPS, 
>Sequence Parameter Set, packets. On the live555 classes I have been 
>looking and I can't find any parser of that data. Is possible 
>extract that information using live555 or I need to search another 
>parser to do that task?

No, you will need a H.264 video decoder.
-- 

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

From jnoring at logitech.com  Mon Jan 25 07:19:45 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Mon, 25 Jan 2010 07:19:45 -0800
Subject: [Live-devel] H264 H264VideoRTPSource
In-Reply-To: <39b9a2b31001250325w68f740daid32689639ed915d7@mail.gmail.com>
References: <39b9a2b31001250325w68f740daid32689639ed915d7@mail.gmail.com>
Message-ID: <988ed6931001250719p36f4603dp1e0241605d17fd53@mail.gmail.com>

On Mon, Jan 25, 2010 at 3:25 AM, Miguel Angel Arcos
<marcos at a5security.com>wrote:

> Dear Ross,
>
> I'm working with the class H264VideoRTPSource when I recieve RTP data
> information of an IP Camera and I have some questions.
>
> First, If I look my (subsession->(fVideoWidth y fVideoHeight)) and I can't
> extract video resolution because this values are 0. Then I'm looking to
> extract that information looking the SPS, Sequence Parameter Set, packets.
> On the live555 classes I have been looking and I can't find any parser of
> that data. Is possible extract that information using live555 or I need to
> search another parser to do that task?
>

Live555 doesn't have a parser for the sequence parameter sets.  Writing such
a parser isn't too hard, although it's not completely trivial because the
SPS info uses exponential golomb encoding (a form of variable length
encoding) for many parameters.  I'd read the H264 specification if you're
interested in parsing it; also read the wiki page on exponential golomb:

http://en.wikipedia.org/wiki/Exponential-Golomb_coding

(also note that the resolution is inferred from several different values in
the SPS set--it isn't just a single value for width/height)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100125/e3a3f719/attachment.html>

From siddeeqhssn at yahoo.com  Mon Jan 25 09:29:45 2010
From: siddeeqhssn at yahoo.com (Siddeeq Hssn)
Date: Mon, 25 Jan 2010 09:29:45 -0800 (PST)
Subject: [Live-devel] Striming Sound From linux To windows
Message-ID: <96535.35004.qm@web51007.mail.re2.yahoo.com>

Hi all
i have a problem and need help please, i try to send sound file from linux to windows such that read the sound file in linux and divided the file into small parts of data or packet then send these packet to windows and play it in windows.
any help or simple example? because i am beginner in Live555, 
or if there any way to stream the sound any simple way.

thank you very much. 


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

From ansary858 at hotmail.com  Mon Jan 25 22:09:35 2010
From: ansary858 at hotmail.com (ansary mohamed)
Date: Tue, 26 Jan 2010 14:09:35 +0800
Subject: [Live-devel] Calling deviceSource in live555
Message-ID: <BAY120-W1837CA913BBE2CB104A431EC5E0@phx.gbl>


Hi all,

 

I am doing live h.264 streaming using live555. I have written the 

deviceSource class that encapsulates my hardware encoder 

ie: reading frames through sockets. I want to know how to change 

the from calling file to this deviceSource class as the whole code currently 

passing file as its arguments to several methods. Do i have to rewrite the classes 

to include the devicesource or is there a easier way to do this? Any help is appreciated.

 

 

Regards

Ansary
 		 	   		  
_________________________________________________________________
Windows 7: Find the right PC for you. Learn more.
http://windows.microsoft.com/shop
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100126/5d54bbcf/attachment.html>

From adammich2 at gmail.com  Tue Jan 26 03:00:30 2010
From: adammich2 at gmail.com (Adam Mich)
Date: Tue, 26 Jan 2010 12:00:30 +0100
Subject: [Live-devel] Different io model in LiveMedia: io completion ports,
	kqueue, epoll ?
Message-ID: <63202e931001260300v3cd6843bia4a92284bfd9b220@mail.gmail.com>

Hello,
Has anybody tried to replace standard select() loop in LiveMedia with a
different asynchronous I/O mode ? Select() isn't especially effective, when
it comes to sending or receiving a large number of small UDP packets over
many connections, and it is the most often scenario in RTP applications.
Even more important - it is hard to merge your own event queue with select()
loop - there is no easy way to break out from select() on some external
event. It would be great to have a few different backends for network event
dispatching - most systems have their own asynchronous I/O modes and it
should be relatively easy to implement them in LiveMedia.  I know there is
TaskScheduler I can reimplement, but I need also a control over
creation/destruction of a socket and over sending and receiving data ( in
Windows you have to use non standard functions instead of send() and recv()
) - something like Socket class. Any help ? Anybody did it already ?
Thanks in advance,
Kamil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100126/324246cc/attachment.html>

From lanlantao at gmail.com  Tue Jan 26 13:06:37 2010
From: lanlantao at gmail.com (Tao Wu)
Date: Tue, 26 Jan 2010 15:06:37 -0600
Subject: [Live-devel] fPresentationTime fDurationInMicroseconds value setup
Message-ID: <712d99b31001261306o5afe07b5ke909552f6fb04e3@mail.gmail.com>

Hi All,

I need to understand the value of fPresentationTime fDurationInMicroseconds.
Those two are used in almost all videoframers.
I have an IP camera, which sends out video frames in the oder of pps, sps,
I, P, P, P...(29 times) in a second.  So should the fPresentationTime/
fDurationInMicroseconds be set as 1000/32 (including both pps ,sps and vidoe
frames) ms or 1000/30 (only the video frames) ms?

I also notice that in a videoframer, a single call ::continueReadProcessing
can actually cause several ::afterGetting(this) then
::continueReadProcessing.
It looks the framer put several video frames in a single RTP packet. After
transmission, will the RTP packet be separated into different frames and
given to the client at different fixed interval ?

Thanks a lot for your explanation.

Best Regards,
Tao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100126/deee30c6/attachment.html>

From paulo at voicetechnology.com.br  Tue Jan 26 16:56:49 2010
From: paulo at voicetechnology.com.br (=?ISO-8859-1?Q?Paulo_Rog=E9rio_Panhoto?=)
Date: Tue, 26 Jan 2010 22:56:49 -0200
Subject: [Live-devel] Different io model in LiveMedia: io completion
	ports, kqueue, epoll ?
In-Reply-To: <63202e931001260300v3cd6843bia4a92284bfd9b220@mail.gmail.com>
References: <63202e931001260300v3cd6843bia4a92284bfd9b220@mail.gmail.com>
Message-ID: <9e6e8f461001261656j3e3d5580l61b81d61b50bb9d6@mail.gmail.com>

Maybe this could be implemented in terms of a portable library such as ACE
or boost::asio. That is an interesting idea. I can volunteer myself to help
with it.

Regards,

Paulo.

2010/1/26 Adam Mich <adammich2 at gmail.com>

> Hello,
> Has anybody tried to replace standard select() loop in LiveMedia with a
> different asynchronous I/O mode ? Select() isn't especially effective, when
> it comes to sending or receiving a large number of small UDP packets over
> many connections, and it is the most often scenario in RTP applications.
> Even more important - it is hard to merge your own event queue with select()
> loop - there is no easy way to break out from select() on some external
> event. It would be great to have a few different backends for network event
> dispatching - most systems have their own asynchronous I/O modes and it
> should be relatively easy to implement them in LiveMedia.  I know there is
> TaskScheduler I can reimplement, but I need also a control over
> creation/destruction of a socket and over sending and receiving data ( in
> Windows you have to use non standard functions instead of send() and recv()
> ) - something like Socket class. Any help ? Anybody did it already ?
> Thanks in advance,
> Kamil
>
> _______________________________________________
> 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/20100126/1abcc81c/attachment.html>

From snarayanan at a2etechnologies.com  Tue Jan 26 17:36:47 2010
From: snarayanan at a2etechnologies.com (Shyam Narayanan)
Date: Tue, 26 Jan 2010 17:36:47 -0800
Subject: [Live-devel] RFC compliance for live555
Message-ID: <1B9A9D002C346449A8A14D50C168C84FE4BA5F@exchsrvr.A2E.local>

Is the latest version of LIVE555 Jan 22,2010 fully compliant to the following RFCs ?
RFC 2326 -> RTSP
RFC 2327 -> SDP
RFC 2617 -> HTTP authentication
If not, is there a plan to provide full compliance to these specs in the near future ?
 
I am unable to find any specific mention of these RFCs in the source code comments or the mailing lists or the changelog.

.

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

From finlayson at live555.com  Tue Jan 26 18:08:31 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 26 Jan 2010 18:08:31 -0800
Subject: [Live-devel] fPresentationTime fDurationInMicroseconds value
 setup
In-Reply-To: <712d99b31001261306o5afe07b5ke909552f6fb04e3@mail.gmail.com>
References: <712d99b31001261306o5afe07b5ke909552f6fb04e3@mail.gmail.com>
Message-ID: <f0624080ac7854dab25d8@[66.80.62.44]>

>I need to understand the value of fPresentationTime 
>fDurationInMicroseconds. Those two are used in almost all 
>videoframers.
>I have an IP camera, which sends out video frames in the oder of 
>pps, sps, I, P, P, P...(29 times) in a second.  So should the 
>fPresentationTime/ fDurationInMicroseconds be set as 1000/32 
>(including both pps ,sps and vidoe frames) ms or 1000/30 (only the 
>video frames) ms?

Note that "fPresentationTime" and "fDurationInMicroseconds" are 
separate variables, and both should be set (although, if you know 
that your framer will always be reading from a live source (rather 
than a file), you can probably omit setting 
"fDurationInMicroseconds").

(Note: Because you mention "PPS" and "SPS", I assume that you're 
referring specifically to H.264 video.)

"fDurationInMicroseconds" should be set to 1000000/framerate  for the 
NAL unit that ends a video frame (Note: This will be the NAL unit for 
which your reimplemented "currentNALUnitEndsAccessUnit()" virtual 
function will return True), and should be set to 0 for all other NAL 
units.

Similarly, all NAL units that make up a single video frame (including 
any PPS and SPS NAL units) should be given the same 
"fPresentationTime" value (i.e., the presentation time of the video 
frame).

>It looks the framer put several video frames in a single RTP packet.

No, it's the "H264VideoRTPSink" class (i.e., our implementation of 
the RTP payload format for H.264) that takes care of packing NAL 
units into RTP packets.  You don't need to know or care about this. 
Just feed the "H264VideoRTPSink" one NAL unit at a time.
-- 

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

From finlayson at live555.com  Tue Jan 26 18:14:40 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 26 Jan 2010 18:14:40 -0800
Subject: [Live-devel] RFC compliance for live555
In-Reply-To: <1B9A9D002C346449A8A14D50C168C84FE4BA5F@exchsrvr.A2E.local>
References: <1B9A9D002C346449A8A14D50C168C84FE4BA5F@exchsrvr.A2E.local>
Message-ID: <f0624080cc78551b317c0@[66.80.62.44]>

>Is the latest version of LIVE555 Jan 22,2010 fully compliant to the 
>following RFCs ?
>RFC 2326 -> RTSP
>RFC 2327 -> SDP
>RFC 2617 -> HTTP authentication

I wouldn't say "fully compliant", but "compliant enough for most applications".

If there's some specific feature (specified in one of these standards 
documents) that isn't currently supported, but which you need to see, 
then please let us know (via 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/20100126/e0f81b4f/attachment.html>

From richymong at gmail.com  Wed Jan 27 19:53:25 2010
From: richymong at gmail.com (Richy Mong)
Date: Thu, 28 Jan 2010 11:53:25 +0800
Subject: [Live-devel] (no subject)
Message-ID: <92bcf691001271953o7a204dedm97dfefc039034ee0@mail.gmail.com>

Hi Ross,
      I am new to live555 and trying to use this powerful lib to
stream live video.I received the video data from the network with my
server and then streamed it with live555.For the client,I useed VLC.
      However,I got some problems here.
      1. There are two memory leaks here.I write my programs following
the test***streamer and free the memory as the following:
      if (sessionState.sink != NULL) sessionState.sink->stopPlaying();
      Medium::close(sessionState.rtcpInstance);	
      Medium::close(sessionState.sink);
      Medium::close(sessionState.source);
	
      Medium::close(sms);
      Medium::close(rtspServer);
      delete sessionState.rtpGroupsock;
      delete sessionState.rtcpGroupsock;

      if(scheduler) delete scheduler;
      if(env) env->reclaim();

      If I just create the sink?sourc?rtspserver etc and don't
startplaying,there will be no memory leak.But if I add
startplaying,after I close the server,there will be two memory leaks :

      Detected memory leaks!
Dumping objects ->
{594258} normal block at 0x003CC818, 32 bytes long.
 Data: <l G             > 6C 0F 47 00 00 00 00 00 00 00 00 00 00 00 00 00
{594245} normal block at 0x00B49008, 32 bytes long.
 Data: <l G             > 6C 0F 47 00 00 00 00 00 00 00 00 00 00 00 00 00

      I am sorry that It may be difficult for you to find out what
resulted in this,but can you give me some suggestion?

      2.Sometimes esapcically after I restart teh server,when I start
my server and use VLC to play th stream,the server receives the
"DECRIBE"?"SETUP" and "PLAY"command ok, but VLC just doesn't play the
stream and it tears down a few seconds later.I don't know the reason.I
use openRTSP and try to save the stream into a file.Things are the
same.The connection between the RTSP server and openRTSP is ok,but
openRTSP can't receive any data,so the file is empty. Then I restart
the server for one or more times,everything goes all right.
        I rarely run into this problem with testprogs or
OnDemandRTSPServer.Therefore,there must be some reason that I have not
found in my program.Would you please help me?

      Thanks in advance.

      Richy
      Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100128/f39631a6/attachment-0001.html>

From finlayson at live555.com  Wed Jan 27 21:43:11 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 27 Jan 2010 21:43:11 -0800
Subject: [Live-devel] (no subject)
In-Reply-To: <92bcf691001271953o7a204dedm97dfefc039034ee0@mail.gmail.com>
References: <92bcf691001271953o7a204dedm97dfefc039034ee0@mail.gmail.com>
Message-ID: <f06240802c786d24c4e7f@[66.80.62.44]>

>       1. There are two memory leaks here.I write 
>my programs following the test***streamer and 
>free the memory as the following:
>       if (sessionState.sink != NULL) sessionState.sink->stopPlaying();
>
>       Medium::close(sessionState.rtcpInstance);
>       Medium::close(sessionState.sink);
>       Medium::close(sessionState.source);
>
>       Medium::close(sms);
>       Medium::close(rtspServer);
>       delete sessionState.rtpGroupsock;
>
>       delete sessionState.rtcpGroupsock;
>
>       if(scheduler) delete scheduler;
>       if(env) env->reclaim();

What you are doing is correct (although, if you 
are planning to rerun the same code once again, 
you could reuse the same "UsageEnvironment" and 
"TaskScheduler" objects; i.e., you would not need 
to delete them).  However, why don't you just run 
your code in its own process (i.e., as a separate 
application)?  That way, all of the memory that 
you allocated will automatically be reclaimed.

>
>       If I just create the 
>sink?Asourc?Artspserver etc and don't 
>startplaying,there will be no memory leak.But if 
>I add startplaying,after I close the 
>server,there will be two memory leaks :
>
>      
>       Detected memory leaks!
>Dumping objects ->
>{594258} normal block at 0x003CC818, 32 bytes long.
>  Data: <l G             > 6C 0F 47 00 00 00 00 00 00 00 00 00 00 00 00 00
>{594245} normal block at 0x00B49008, 32 bytes long.
>
>  Data: <l G             > 6C 0F 47 00 00 00 00 00 00 00 00 00 00 00 00 00
>
>       I am sorry that It may be difficult for 
>you to find out what resulted in this,but can 
>you give me some suggestion?

Does 64 bytes of extra memory get allocated each 
time you run your code (i.e., in a loop), or does 
only 64 extra bytes get allocated, no matter how 
many times you run your code?  If it's the latter 
case, then the problem doesn't seem serious.

However, you may be able to use "valgrind" (if 
you're running on a Unix or Linux system) to help 
track down where this memory allocation is coming 
from.

>
>       2.Sometimes esapcically after I restart 
>teh server,when I start my server and use VLC to 
>play th stream,the server receives the 
>"DECRIBE"?A"SETUP" and "PLAY"command ok, but VLC 
>just doesn't play the stream and it tears down a 
>few seconds later.I don't know the reason.I use 
>openRTSP and try to save the stream into a 
>file.Things are the same.The connection between 
>the RTSP server and openRTSP is ok,but openRTSP 
>can't receive any data,so the file is empty. 
>Then I restart the server for one or more 
>times,everything goes all right.
>
>         I rarely run into this problem with 
>testprogs or OnDemandRTSPServer.Therefore,there 
>must be some reason that I have not found in my 
>program.Would you please help me?


Unfortunately not; I can (in general) help only 
with the unmodified supplied 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/20100127/1d7ec875/attachment.html>

From richymong at gmail.com  Thu Jan 28 01:27:19 2010
From: richymong at gmail.com (Richy Mong)
Date: Thu, 28 Jan 2010 17:27:19 +0800
Subject: [Live-devel] (no subject)
In-Reply-To: <f06240802c786d24c4e7f@66.80.62.44>
References: <92bcf691001271953o7a204dedm97dfefc039034ee0@mail.gmail.com>
	<f06240802c786d24c4e7f@66.80.62.44>
Message-ID: <92bcf691001280127h54f70e93sd14ba6679bbf5745@mail.gmail.com>

2010/1/28 Ross Finlayson <finlayson at live555.com>

>        1. There are two memory leaks here.I write my programs following
> the test***streamer and free the memory as the following:
>       if (sessionState.sink != NULL) sessionState.sink->stopPlaying();
>
>       Medium::close(sessionState.rtcpInstance);
>       Medium::close(sessionState.sink);
>       Medium::close(sessionState.source);
>
>       Medium::close(sms);
>       Medium::close(rtspServer);
>       delete sessionState.rtpGroupsock;
>
>       delete sessionState.rtcpGroupsock;
>
>       if(scheduler) delete scheduler;
>
>       if(env) env->reclaim();
>
>
> What you are doing is correct (although, if you are planning to rerun the
> same code once again, you could reuse the same "UsageEnvironment" and
> "TaskScheduler" objects; i.e., you would not need to delete them).  However,
> why don't you just run your code in its own process (i.e., as a separate
> application)?  That way, all of the memory that you allocated will
> automatically be reclaimed.
>
>    Thanks for your replay.I have never used a mailing list before so I
dont't know how to spilt
   my question asked from your answer.I'm sorry about the trouble you may
have in reading my
   email .Because I am using multiple thread here,so I have to reclaim the
memory by myself.
   Otherwise,there will be losts of memory leaks.

>
>       If I just create the sink?Asourc?Artspserver etc and don't
> startplaying,there will be no memory leak.But if I add startplaying,after I
> close the server,there will be two memory leaks :
>
>
>
>       Detected memory leaks!
> Dumping objects ->
> {594258} normal block at 0x003CC818, 32 bytes long.
>  Data: <l G             > 6C 0F 47 00 00 00 00 00 00 00 00 00 00 00 00 00
> {594245} normal block at 0x00B49008, 32 bytes long.
>
>  Data: <l G             > 6C 0F 47 00 00 00 00 00 00 00 00 00 00 00 00 00
>
>       I am sorry that It may be difficult for you to find out what resulted
> in this,but can you give me some suggestion?
>
>
> Does 64 bytes of extra memory get allocated each time you run your code
> (i.e., in a loop), or does only 64 extra bytes get allocated, no matter how
> many times you run your code?  If it's the latter case, then the problem
> doesn't seem serious.
>
> However, you may be able to use "valgrind" (if you're running on a Unix or
> Linux system) to help track down where this memory allocation is coming
> from.
>
>     The case is the former.My os is windows.Bad luck:)

>
>       2.Sometimes esapcically after I restart teh server,when I start my
> server and use VLC to play th stream,the server receives the
> "DECRIBE"?A"SETUP" and "PLAY"command ok, but VLC just doesn't play the
> stream and it tears down a few seconds later.I don't know the reason.I use
> openRTSP and try to save the stream into a file.Things are the same.The
> connection between the RTSP server and openRTSP is ok,but openRTSP can't
> receive any data,so the file is empty. Then I restart the server for one or
> more times,everything goes all right.
>
>         I rarely run into this problem with testprogs or
> OnDemandRTSPServer.Therefore,there must be some reason that I have not found
> in my program.Would you please help me?
>
>
>
>  Unfortunately not; I can (in general) help only with the unmodified
> supplied code.
>
> I tested today and just found that if I run my server and VLC on the same
pc,it didn't work for
serval times. If I run my server and VLC ont different computers,I did't run
into this problem.It
was strange.

Other quesitons:
I want to add the client's IP address and port into a list or arry once he
connect to the server.So that after getting a frame,I can send it to all the
client.Because my server and client may run over the iternet rather than
LAN, I don't use multicast stream.Is it possible?
Or can I follow the existed testOnDemandRTSPServer and write my own subclass
of OnDemandServerMediaSubsessionto stream live source?If I can, should
createNewStreamSource returns the same soure instead of
FramedSource::createNew?

Thans for you time and answer.

Richy
Best regards

> --
>
>
> 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/20100128/63f5a76a/attachment.html>

From finlayson at live555.com  Thu Jan 28 02:07:35 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 28 Jan 2010 02:07:35 -0800
Subject: [Live-devel] (no subject)
In-Reply-To: <92bcf691001280127h54f70e93sd14ba6679bbf5745@mail.gmail.com>
References: <92bcf691001271953o7a204dedm97dfefc039034ee0@mail.gmail.com>
	<f06240802c786d24c4e7f@66.80.62.44>
	<92bcf691001280127h54f70e93sd14ba6679bbf5745@mail.gmail.com>
Message-ID: <f06240803c78711330b99@[66.80.62.44]>

>.Because I am using multiple thread here

I hope you've read the FAQ entry on threads.


>Or can I follow the existed testOnDemandRTSPServer and write my own 
>subclass of OnDemandServerMediaSubsessionto stream live source?

Yes.  To stream via unicast (rather than multicast) you use a 
subclass of "OnDemandServerMediaSubsession" (rather than 
"PassiveServerMediaSubsession").


>If I can, should createNewStreamSource returns the same soure 
>instead of FramedSource::createNew?

No, "createNewStreamSource" must create a new source object each 
time.  Note, however, that if the "reuseFirstParameter" (to the 
"OnDemandServerMediaSubsession" constructor) is True, then the same 
input source will be used for all clients, and 
"createNewStreamSource" will (in most cases) be called only once.  If 
you are streaming from a live data source (rather than from a file), 
then you should usually set "reuseFirstParameter" to True.
-- 

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

From richymong at gmail.com  Thu Jan 28 02:37:27 2010
From: richymong at gmail.com (Richy Mong)
Date: Thu, 28 Jan 2010 18:37:27 +0800
Subject: [Live-devel] (no subject)
In-Reply-To: <f06240803c78711330b99@66.80.62.44>
References: <92bcf691001271953o7a204dedm97dfefc039034ee0@mail.gmail.com>
	<f06240802c786d24c4e7f@66.80.62.44>
	<92bcf691001280127h54f70e93sd14ba6679bbf5745@mail.gmail.com>
	<f06240803c78711330b99@66.80.62.44>
Message-ID: <92bcf691001280237g7fb4bcabrb06d1d10c063677c@mail.gmail.com>

2010/1/28 Ross Finlayson <finlayson at live555.com>

> .Because I am using multiple thread here
>>
>
> I hope you've read the FAQ entry on threads.
>
> Yes.I read the FAQ very carefully. I'm sorry that I misundstood your answer
> just now.
>
>  Or can I follow the existed testOnDemandRTSPServer and write my own
>> subclass of OnDemandServerMediaSubsessionto stream live source?
>>
>
> Yes.  To stream via unicast (rather than multicast) you use a subclass of
> "OnDemandServerMediaSubsession" (rather than
> "PassiveServerMediaSubsession").
>
>
>
>  If I can, should createNewStreamSource returns the same soure instead of
>> FramedSource::createNew?
>>
>
> No, "createNewStreamSource" must create a new source object each time.
>  Note, however, that if the "reuseFirstParameter" (to the
> "OnDemandServerMediaSubsession" constructor) is True, then the same input
> source will be used for all clients, and "createNewStreamSource" will (in
> most cases) be called only once.  If you are streaming from a live data
> source (rather than from a file), then you should usually set
> "reuseFirstParameter" to True.
>
>    Thanks.Then I don't worry about updating all the FramedSource after
getting a new frame.
   Yes,this is an effective method.However, could I do the following to
stream live video?It maybe
   familiar to multicast.

        The server is following the "test***streamer" example.A client
connects to the server.When
  the server receives the "PLAY" command,it adds the client's IP to a list
or array, every time a
  packet is sent, it will be sent to all the IP in the list.And when one
client tears down,the server
  removes its IP from the list.So that the next packet won't be sent to the
client.

        Is it impossible or does this work take much time ?I have very
little knowlege about socket,so if what I said is silly,please don't laugh
at me:)

-- 
>
> 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/20100128/397ff71e/attachment-0001.html>

From cristina.gil at sumenor.com  Thu Jan 28 03:41:51 2010
From: cristina.gil at sumenor.com (Cristina Gil)
Date: Thu, 28 Jan 2010 12:41:51 +0100
Subject: [Live-devel] NAL header bits
Message-ID: <A55C94355148429086472A2A521AAF42@SUMENORSCS.LOCAL>

Hello, 

 

Im a newbie. Im trying to decode h264 NAL header, I skip 12bytes of the RTP
header, but the next byte which I think it should be the NAL header begins
by 0 (forbidden_zero_bit). but I get "7C" (1111 1100)

 

10.. .... = Version: RFC 1889 Version (2)

0... .... = Marker: False

..0. .... = Padding: False

...0 .... = Extension: False

.... 0000 = Contributing source identifiers count: 0

 

Payload type: DynamicRTP-Type-96 (96)

Sequence number: 23252

Timestamp: 868956473

Synchronization Source identifier: 0xcbd5dcba (3419790522)

 

Payload: 7C05FFE5F98EB9B5AED78E67EB3C2A941606A7CCD179710B...

 

Do I have to use something to parse the value? 

 

Is because big/little endian??

 

Any help will be appreciated!!

 

 



AVISO LEGAL
La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100128/bdffe2f3/attachment.html>

From finlayson at live555.com  Thu Jan 28 07:05:19 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 28 Jan 2010 07:05:19 -0800
Subject: [Live-devel] (no subject)
In-Reply-To: <92bcf691001280237g7fb4bcabrb06d1d10c063677c@mail.gmail.com>
References: <92bcf691001271953o7a204dedm97dfefc039034ee0@mail.gmail.com>
	<f06240802c786d24c4e7f@66.80.62.44>
	<92bcf691001280127h54f70e93sd14ba6679bbf5745@mail.gmail.com>
	<f06240803c78711330b99@66.80.62.44>
	<92bcf691001280237g7fb4bcabrb06d1d10c063677c@mail.gmail.com>
Message-ID: <f06240801c787572a6d78@[66.80.62.44]>

>However, could I do the following to stream live video?It maybe
>    familiar to multicast.
>      
>         The server is following the "test***streamer" example.A 
>client connects to the server.When
>   the server receives the "PLAY" command,it adds the client's IP to 
>a list or array, every time a
>   packet is sent, it will be sent to all the IP in the list.And when 
>one client tears down,the server
>   removes its IP from the list.So that the next packet won't be sent 
>to the client.

No, your code doesn't need to do *anything* with IP addresses.  Our 
code *already* implements this (in the "RTSPServer" and 
"OnDemandServerMediaSubsession" classes).  Look, for example, at the 
code for "testOnDemandRTSPServer" (or "live555MediaServer").  It 
*already* implements a unicast RTSP server, with the ability to 
support multiple clients concurrently.

(This will be my last posting on this topic.)
-- 

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

From finlayson at live555.com  Thu Jan 28 07:22:46 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 28 Jan 2010 07:22:46 -0800
Subject: [Live-devel] NAL header bits
In-Reply-To: <A55C94355148429086472A2A521AAF42@SUMENORSCS.LOCAL>
References: <A55C94355148429086472A2A521AAF42@SUMENORSCS.LOCAL>
Message-ID: <f06240802c7875bed8b31@[66.80.62.44]>

>Im a newbie. Im trying to decode h264 NAL header, I skip 12bytes of 
>the RTP header

No, you should not be parsing RTP headers at all.  Our class 
"H264VideoRTPSource" already takes care of this - it extracts NAL 
units from the incoming RTP stream, and delivers them (one at a time) 
to the downstream object.  Just use 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/20100128/806f686a/attachment.html>

From lanlantao at gmail.com  Thu Jan 28 09:38:28 2010
From: lanlantao at gmail.com (Tao Wu)
Date: Thu, 28 Jan 2010 11:38:28 -0600
Subject: [Live-devel] fPresentationTime fDurationInMicroseconds value
	setup
Message-ID: <712d99b31001280938t6747d9eflaaa6a4bb5cdd8d25@mail.gmail.com>

Hi Ross,

Thanks for your explanations. I am somehow unsure about the proper setup of
fPresentationTime and fDurationInMicroseconds.
My h264 video stream comes  in the oder of pps, sps, I, P, P, P...(29 times)
in a second.
Is the following code correct ? Thank you.

::continueReadProcessing() {

  ......
  if (acquiredFrameSize > 0 ) {
      // We were able to acquire a frame from the input.
      // It has already been copied to the reader's space.
        fFrameSize = acquiredFrameSize;
        fNumTruncatedBytes = 0;

        seq++;

     // Compute "fPresentationTime"
        if ( the frame != pps or sps ) // regular video frames
             fPresentationTime.tv_usec += (long) 33*1000;
        else  // pps or sps , presentation time does not change
             ;

        while (fPresentationTime.tv_usec >= 1000000) {
            fPresentationTime.tv_usec -= 1000000;
            ++fPresentationTime.tv_sec;
        }

        if ( the frame != pps or sps ) // regular video frames
              fDurationInMicroseconds = (long) 33*1000;
        else  // pps or sps , duration is 0
               fDurationInMicroseconds = 0;

        // Call our own 'after getting' function.  Because we're not a
'leaf'
        // source, we can call this directly, without risking infinite
recursion.
        afterGetting(this);
    }
 .....................

}

>I need to understand the value of fPresentationTime
>fDurationInMicroseconds. Those two are used in almost all
>videoframers.
>I have an IP camera, which sends out video frames in the oder of
>pps, sps, I, P, P, P...(29 times) in a second.  So should the
>fPresentationTime/ fDurationInMicroseconds be set as 1000/32
>(including both pps ,sps and vidoe frames) ms or 1000/30 (only the
>video frames) ms?

Note that "fPresentationTime" and "fDurationInMicroseconds" are
separate variables, and both should be set (although, if you know
that your framer will always be reading from a live source (rather
than a file), you can probably omit setting
"fDurationInMicroseconds").

(Note: Because you mention "PPS" and "SPS", I assume that you're
referring specifically to H.264 video.)

"fDurationInMicroseconds" should be set to 1000000/framerate  for the
NAL unit that ends a video frame (Note: This will be the NAL unit for
which your reimplemented "currentNALUnitEndsAccessUnit(
)" virtual
function will return True), and should be set to 0 for all other NAL
units.

Similarly, all NAL units that make up a single video frame (including
any PPS and SPS NAL units) should be given the same
"fPresentationTime" value (i.e., the presentation time of the video
frame).

>It looks the framer put several video frames in a single RTP packet.

No, it's the "H264VideoRTPSink" class (i.e., our implementation of
the RTP payload format for H.264) that takes care of packing NAL
units into RTP packets.  You don't need to know or care about this.
Just feed the "H264VideoRTPSink" one NAL unit at a time.
--

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/20100128/2f01ad75/attachment.html>

From basteon at gmail.com  Thu Jan 28 14:13:12 2010
From: basteon at gmail.com (basteon)
Date: Fri, 29 Jan 2010 08:13:12 +1000
Subject: [Live-devel] rtp\rtsp trouble
Message-ID: <328fe7151001281413v48f7e734y232e8e7f21a7b96b@mail.gmail.com>

Hi Ross,
I guess you may point me in this case.
actually I tries todo rtsp client and rtp streamer in one program. I
use those few code samples, but just have got...

Received PLAY response: RTSP/1.0 200 OK
CSeq: 4
Session: 2C7618F1
Range: npt=0.568878-
RTP-Info: url=rtsp://127.0.0.1/axis-media/media.amp/trackID=1;seq=61092;rtptime=1796544616
Date: Fri, 26 Dec 2008 20:14:56 GMT


Started playing session
Receiving streamed data (signal with "kill -HUP 30317" or "kill -USR1
30317" to terminate)...
well done
 BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor

// >>
FramedSource *input;
mpegDemux = MPEG1or2Demux::createNew(*env, input);
//perhaps this input are wrong? and this proprietary only for file
handle interaction?

From finlayson at live555.com  Thu Jan 28 15:29:24 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 28 Jan 2010 15:29:24 -0800
Subject: [Live-devel] rtp\rtsp trouble
In-Reply-To: <328fe7151001281413v48f7e734y232e8e7f21a7b96b@mail.gmail.com>
References: <328fe7151001281413v48f7e734y232e8e7f21a7b96b@mail.gmail.com>
Message-ID: <f06240804c787ce23074f@[66.80.62.44]>

>  BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor

Make sure you're using the latest version of the code.  It fixes a 
bug that *might* have caused this.
-- 

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

From cristina.gil at sumenor.com  Fri Jan 29 04:07:41 2010
From: cristina.gil at sumenor.com (Cristina Gil)
Date: Fri, 29 Jan 2010 13:07:41 +0100
Subject: [Live-devel] NAL header bits
In-Reply-To: <f06240802c7875bed8b31@[66.80.62.44]>
References: <A55C94355148429086472A2A521AAF42@SUMENORSCS.LOCAL>
	<f06240802c7875bed8b31@[66.80.62.44]>
Message-ID: <3329B091A275428695267C925354AFAD@SUMENORSCS.LOCAL>

Hello Ross,

 

Thanks for your below. I'm trying to understand how the rtp + h264 works,
but it's kind of confusing because im not good at C. I hope you don't mind
if I ask about the de-packetized algorithm.

 
Which function is the one that splits the RTP header? And which define the
type of NAL Unit (NAL header)?
 
I also don't understand when I have to use the sprop-parameter I get in th
sdp message.
 
Again, thanks for your help!!!

 

 

  _____  

De: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] En nombre de Ross Finlayson
Enviado el: jueves, 28 de enero de 2010 16:23
Para: LIVE555 Streaming Media - development & use
Asunto: Re: [Live-devel] NAL header bits

 

Im a newbie. Im trying to decode h264 NAL header, I skip 12bytes of the RTP
header

 

No, you should not be parsing RTP headers at all.  Our class
"H264VideoRTPSource" already takes care of this - it extracts NAL units from
the incoming RTP stream, and delivers them (one at a time) to the downstream
object.  Just use this.

-- 


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



AVISO LEGAL
La Informacion incluida en el presente correo electronico es SECRETO PROFESIONAL Y CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. Si usted lee este mensaje y no es el destinatario se?alado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion o reproduccion de esta comunicacion, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la direccion arriba mencionada. Gracias.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100129/cf18c798/attachment.html>

From jafrado at gmail.com  Fri Jan 29 10:21:05 2010
From: jafrado at gmail.com (James Dougherty)
Date: Fri, 29 Jan 2010 10:21:05 -0800
Subject: [Live-devel] live streaming server
Message-ID: <03bf01caa10f$d43f73b0$7cbe5b10$@com>

Hey Folks,

 

Can anyone recommend a camera combination and S/W encoder (under Linux)

Which would allow me to stream MPEG-4 or H.264 (SD) using LIVE555? 

 

Thanks,

-James

 

 

 

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

From basteon at gmail.com  Fri Jan 29 19:19:51 2010
From: basteon at gmail.com (basteon)
Date: Sat, 30 Jan 2010 13:19:51 +1000
Subject: [Live-devel] rtp\rtsp trouble
In-Reply-To: <f06240804c787ce23074f@66.80.62.44>
References: <328fe7151001281413v48f7e734y232e8e7f21a7b96b@mail.gmail.com>
	<f06240804c787ce23074f@66.80.62.44>
Message-ID: <328fe7151001291919n1dd7c132rc7296291e28530a2@mail.gmail.com>

Yes, I tries it with the latest version at 22-Jan-2010.
I fix this problem, but I'm not sure what I do it well.
select() error it looks like socket error, therefore I use another
pointer to the UsageEnvironment* env,*env2;
first for rtsp and second for rtp socket, it looks like works, despite
it won't sending rtp packets to assigned target.

I'm not sure, but if I do only demuxing without transcoding my stream
this values must be computed by incoming audia\video codecs?

 const unsigned estimatedSessionBandwidthAudio = 160; // in kbps; for
RTCP b/w share
 const unsigned estimatedSessionBandwidthVideo = 4500; // in kbps; for
RTCP b/w share

I've got rtsp strem video/H264 and then use MPEG1or2AudioRTPSink &
MPEG1or2VideoRTPSink

2010/1/29 Ross Finlayson <finlayson at live555.com>:
>> ?BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor
>
> Make sure you're using the latest version of the code. ?It fixes a bug that
> *might* have caused this.
> --
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>

From kvolaa at seznam.cz  Sat Jan 30 12:51:58 2010
From: kvolaa at seznam.cz (Karel Volejnik)
Date: Sat, 30 Jan 2010 21:51:58 +0100
Subject: [Live-devel] live streaming server
In-Reply-To: <03bf01caa10f$d43f73b0$7cbe5b10$@com>
References: <03bf01caa10f$d43f73b0$7cbe5b10$@com>
Message-ID: <4f0842941001301251m23cc274fv62ee84c64e9dacd0@mail.gmail.com>

libavcodec (ffmpeg), x.264

2010/1/29 James Dougherty <jafrado at gmail.com>:
> Hey Folks,
>
>
>
> Can anyone recommend a camera combination and S/W encoder (under Linux)
>
> Which would allow me to stream MPEG-4 or H.264 (SD) using LIVE555?
>
>
>
> Thanks,
>
> -James
>
>
>
>
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>

From sridhar.sontha at yahoo.co.in  Sun Jan 31 22:36:55 2010
From: sridhar.sontha at yahoo.co.in (Sridhar Sontha)
Date: Mon, 1 Feb 2010 12:06:55 +0530 (IST)
Subject: [Live-devel] regarding "MPEG2TransportStreamIndexer" in the
	"\testProgs"
Message-ID: <260796.40140.qm@web94706.mail.in2.yahoo.com>



Hi,??The above executable ?MPEG2TransportStreamIndexer?
gives me an error and exits when I run it with input TS file of size say 5MB.

?

The error message is :

?"ERROR: parse buffer full; increase
MAX_FRAME_SIZE"

??"ERROR: parse buffer full; increase
MAX_FRAME_SIZE"

?

?If I try to increase the MAX_FRAME_SIZE(in the file
liveMedia\ MPEG2IndexFromTransportStream.cpp) from 4000000 to some larger
value, the code exits with Segmentation Fault.

?

I suppose the code should be independent of the TS file
size.

Why can?t it work with the larger TS files? What should be
done to make this work.

?

Pls. help me out..Thanks in advance.


Thanks,

Sridhar


      Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100201/360aff23/attachment-0001.html>

From finlayson at live555.com  Sun Jan 31 22:48:43 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 31 Jan 2010 22:48:43 -0800
Subject: [Live-devel] regarding "MPEG2TransportStreamIndexer" in the
 "\testProgs"
In-Reply-To: <260796.40140.qm@web94706.mail.in2.yahoo.com>
References: <260796.40140.qm@web94706.mail.in2.yahoo.com>
Message-ID: <f06240802c78c29851405@[66.80.62.44]>

>   The above executable "MPEG2TransportStreamIndexer" gives me an 
>error and exits when I run it with input TS file of size say 5MB.

Please put an example Transport Stream file (that fails for you) on a 
publically-accessible web (or FTP) server, and post the URL (not the 
file itself) to this mailing list, so I can download it and test it.
-- 

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