From pankehust at gmail.com  Sat Nov  1 07:43:32 2008
From: pankehust at gmail.com (pan ke)
Date: Sat, 1 Nov 2008 10:43:32 -0400
Subject: [Live-devel] Streaming the same MEPG2 file circularly,
	only audio but no video
Message-ID: <43f857160811010743p5c319eb2kcc3b1ffbc4d14b25@mail.gmail.com>

I use testOnDemandRTSPServer, and change it to read from "stdin". My
other application read a MEPG2 file circularly, and pipe it to
testOnDemandRTSPServer. I use VLC as player to read the stream via
RTSP.

1)The server can work very well at the first time, however, at the
second time, that is replaying the same video, I found that there is
only audio but no video. I tried to use other format like mp4, the
same problem also appears.

2)I tried to change the reading position by setting the offset of the
file to simulate the package losses, there is also only audio but no
video appearing.
How can I solve this problem?

thanks
-- 
            Ke Pan

From anto.rizzo at caramail.com  Sat Nov  1 09:03:13 2008
From: anto.rizzo at caramail.com (Antonella Rizzo)
Date: Sat, 1 Nov 2008 17:03:13 +0100
Subject: [Live-devel] Problem with openRTSP
Message-ID: <79439166648816@lycos-europe.com>

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

From finlayson at live555.com  Sat Nov  1 22:52:53 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 1 Nov 2008 22:52:53 -0700
Subject: [Live-devel] Problem with openRTSP
In-Reply-To: <79439166648816@lycos-europe.com>
References: <79439166648816@lycos-europe.com>
Message-ID: <f06240801c532ef948b39@[66.80.62.44]>

1/ Are you able to play your RTSP stream directly using VLC?

2/ When you run "openRTSP" to create a ".avi"-format file, do you let 
it run until completion (i.e., do *not* kill "openRTSP" using 
<control>-c)?

If the answers to 1/ and 2/ are both Yes, then I'm sorry - I don't 
know what the problem is.  However, the AVI file output code is not 
totally complete; you could try to output a ".mov"-format file 
instead (using the "-q" option instead of "-i).
-- 

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

From finlayson at live555.com  Sat Nov  1 23:08:27 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 1 Nov 2008 23:08:27 -0700
Subject: [Live-devel] Streaming the same MEPG2 file circularly,
 only audio but no video
In-Reply-To: <43f857160811010743p5c319eb2kcc3b1ffbc4d14b25@mail.gmail.com>
References: <43f857160811010743p5c319eb2kcc3b1ffbc4d14b25@mail.gmail.com>
Message-ID: <f06240802c532f3b60f68@[66.80.62.44]>

>I use testOnDemandRTSPServer, and change it to read from "stdin". My
>other application read a MEPG2 file circularly, and pipe it to
>testOnDemandRTSPServer. I use VLC as player to read the stream via
>RTSP.
>
>1)The server can work very well at the first time, however, at the
>second time, that is replaying the same video, I found that there is
>only audio but no video. I tried to use other format like mp4, the
>same problem also appears.
>
>2)I tried to change the reading position by setting the offset of the
>file to simulate the package losses, there is also only audio but no
>video appearing.
>How can I solve this problem?

Is your source data a MPEG Program Stream, or a MPEG Transport Stream?

Do you get the same problem if you create a new file by concatenating 
together two or more copies of the original file, and then stream 
directly from this new file (rather than from stdin), using the 
original, unmodified "testOnDemandRTSPServer"?
-- 

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

From anto.rizzo at caramail.com  Sun Nov  2 01:25:49 2008
From: anto.rizzo at caramail.com (Antonella Rizzo)
Date: Sun, 2 Nov 2008 10:25:49 +0100
Subject: [Live-devel] Problem with openRTSP
Message-ID: <122561794963050@lycos-europe.com>

Hi Ross,
Thanks for your answer.
1) yes the url of rtsp stream works from vlc or quicktime;
2) Yes, I use ctrl+c to kill the process. 

Then, the problem is ctrl+c.
But If I want relay a real time stream, can I output openRTSP to testOnDemandRTSPServer (for example with a pipe)?
We works on this idea, but We don't know if it's possible!

Best Regards


 


1/ Are you able to play your RTSP stream directly using VLC?

2/ When you run "openRTSP" to create a ".avi"-format file, do you let 
it run until completion (i.e., do *not* kill "openRTSP" using 
<control>-c)?

If the answers to 1/ and 2/ are both Yes, then I'm sorry - I don't 
know what the problem is.  However, the AVI file output code is not 
totally complete; you could try to output a ".mov"-format file 
instead (using the "-q" option instead of "-i).
-- 

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

From finlayson at live555.com  Sun Nov  2 01:40:15 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 2 Nov 2008 01:40:15 -0700
Subject: [Live-devel] Problem with openRTSP
In-Reply-To: <122561794963050@lycos-europe.com>
References: <122561794963050@lycos-europe.com>
Message-ID: <f06240801c53316fbbbce@[66.80.62.44]>

>2) Yes, I use ctrl+c to kill the process.
>
>Then, the problem is ctrl+c.

Yes - don't do this!  If you are outputting a ".avi", ".mov", or 
".mp4" file, you must terminate "openRTSP" by signalling it with 
SIGHUP or SIGUSR1, or else waiting for "openRTSP" to complete on its 
own.


>But If I want relay a real time stream, can I output openRTSP to 
>testOnDemandRTSPServer (for example with a pipe)?

Probably, provided, of course, that "openRTSP" is receiving a 
video-only stream, or an audio-only stream, or a Transport Stream. 
If you use it to output a ".avi", ".mov", or ".mp4" file, then 
obviously you won't be able to re-stream that.
-- 

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

From anto.rizzo at caramail.com  Sun Nov  2 02:02:45 2008
From: anto.rizzo at caramail.com (Antonella Rizzo)
Date: Sun, 2 Nov 2008 11:02:45 +0100
Subject: [Live-devel] Problem with openRTSP
Message-ID: <160048446317964@lycos-europe.com>

Hi Ross,
I must real time stream an MPEG1or2AudioVideo or an H.264 (video) with MP4(audio). 
So, it isn't an elementary stream. 
I want have an output url rtsp://myIp:myPort/namesession because I want provide the real time stream on demand!
My input is rtsp://sourceIP:sourcePort/namesession!

I must see my live stream (with QuickTime or VLC) and, in the same time, I must be a server to stream what I see!

My idea is pipeling openRTSP and testOnDemandRTSPServer!

Best Regards


From finlayson at live555.com  Sun Nov  2 04:18:10 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 2 Nov 2008 05:18:10 -0700
Subject: [Live-devel] Problem with openRTSP
In-Reply-To: <160048446317964@lycos-europe.com>
References: <160048446317964@lycos-europe.com>
Message-ID: <f06240803c5334a95b7f0@[66.80.62.44]>

>I must real time stream an MPEG1or2AudioVideo or an H.264 (video) 
>with MP4(audio).
>So, it isn't an elementary stream.

Because of this, you won't be able to pipe the output of "openRTSP" 
into a RTSP server.  Sorry.
-- 

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

From stas at tech-mer.com  Sun Nov  2 06:03:12 2008
From: stas at tech-mer.com (Stas Desyatnlkov)
Date: Sun, 2 Nov 2008 16:03:12 +0200
Subject: [Live-devel] live in VoIP
Message-ID: <21E398286732DC49AD45BE8C7BE96C07354D6BB0F3@fs11.mertree.mer.co.il>

Hi All,
I have a g.729 sink class based on MediaSink.
1)      How can I receive the sender IP (I need to tell between the senders to the same multicast address)?
2)      I'd also like to receive the sequence number and CSRC identifier at the sink level.
Any ideas?


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

From anto.rizzo at caramail.com  Sun Nov  2 06:55:57 2008
From: anto.rizzo at caramail.com (Antonella Rizzo)
Date: Sun, 2 Nov 2008 15:55:57 +0100
Subject: [Live-devel] Problem with openRTSP
Message-ID: <168430012717469@lycos-europe.com>

Hi Ross,
thanks for your answers!
But how can I do relayng of real time stream (audio and video, not elementary stream) using live555?

Best Regards


From finlayson at live555.com  Sun Nov  2 19:20:32 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 2 Nov 2008 20:20:32 -0700
Subject: [Live-devel] live in VoIP
In-Reply-To: <21E398286732DC49AD45BE8C7BE96C07354D6BB0F3@fs11.mertree.mer.co.il>
References: <21E398286732DC49AD45BE8C7BE96C07354D6BB0F3@fs11.mertree.mer.co.il>
Message-ID: <f06240805c5341d2229f0@[66.80.62.44]>

>1.	How can I receive the sender IP

Our RTP receiving code does not expose this - but you don't need it. 
Instead, to identify the media source, you want the RTP "SSRC" , 
which can be obtained by calling "RTPSource::lastReceivedSSRC()".

  (I need to tell between the senders to the same multicast address)?

>2.	I'd also like to receive the sequence number and CSRC 
>identifier at the sink level.

You can't get the CSRC (because our code ignores any CSRC fields). 
You *could* get the RTP sequence number of the most recently-received 
packet by calling "RTPSource::curPacketRTPSeqNum()", but in reality, 
you probably don't need 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/20081102/bc1910e7/attachment.html>

From finlayson at live555.com  Sun Nov  2 19:43:54 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 2 Nov 2008 20:43:54 -0700
Subject: [Live-devel] Problem with openRTSP
In-Reply-To: <168430012717469@lycos-europe.com>
References: <168430012717469@lycos-europe.com>
Message-ID: <f06240807c534236e8fe9@[66.80.62.44]>

>But how can I do relayng of real time stream (audio and video, not 
>elementary stream) using live555?

You can do this *only if* your 'real time stream' is in one of the 
input media formats that we currently support - i.e., an audio or 
video elementary stream, a MPEG Program Stream, or a MPEG Transport 
Stream.
-- 

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

From amit.yedidia at elbitsystems.com  Sun Nov  2 21:53:28 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Mon, 3 Nov 2008 07:53:28 +0200
Subject: [Live-devel] Framer/Parser Implementation problem
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D3649@mailesl5.esl.corp.elbit.co.il>


Hi Ross,All.

I want to implement H264VideoStreamFramer to delievr H264 Nals.
I also want that the same framer will be used no matter if the source
ByteStreamFileSource or DeviceSource.
I implemented my device source as a readable socket which the encoder
send nal after nal into it. (I am receiving it with recv())
My problem is the following:
ByteStreamFileSource needs that H264VideoStreamFramer to have a parser.
The parser object should parse byte after byte and deliver complete Nals
to the framer. However since my Device source is already sending Nals
using send(), I just need to do recv() to receive a complete NAL,
without needing the exhausting parsing.

What is the right thing to do (to keep only one Framer)
1. implementing two types of parser and let the frame choose which to
create? (based on what?)
2. implementing two types of paser and deliver the appropriate one to
the framer upon creation (needs API change)
3. implementing two types of framer. One that make use of the parser,
and one that doesn't. (what I tried to avois)
4. implementing the parser as a Filter (concept change)

Thank you.


Amit Yedidia




The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081103/c7d48aee/attachment.html>

From finlayson at live555.com  Sun Nov  2 21:02:41 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 2 Nov 2008 22:02:41 -0700
Subject: [Live-devel] Framer/Parser Implementation problem
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D3649@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D3649@mailesl5.esl.corp.elbit.co.il>
Message-ID: <f06240808c53435409c04@[66.80.62.44]>

>My problem is the following:
>
>ByteStreamFileSource needs that H264VideoStreamFramer to have a 
>parser. The parser object should parse byte after byte and deliver 
>complete Nals to the framer. However since my Device source is 
>already sending Nals using send(), I just need to do recv() to 
>receive a complete NAL, without needing the exhausting parsing.
>
>What is the right thing to do (to keep only one Framer)
[...]

>3. implementing two types of framer. One that make use of the 
>parser, and one that doesn't. (what I tried to avois)

This is what I would do.  Note that we already do this for MPEG-1,2 
and 4 video: we have "MPEG*VideoStreamDiscreteFramer" for sources 
that deliver complete frames (one at a time), and 
"MPEG*VideoStreamFramer" for sources that deliver a byte stream.  So 
you have some existing code to use as a model.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081102/78387238/attachment-0001.html>

From amit.yedidia at elbitsystems.com  Sun Nov  2 22:51:13 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Mon, 3 Nov 2008 08:51:13 +0200
Subject: [Live-devel] Framer/Parser Implementation problem
In-Reply-To: <f06240808c53435409c04@[66.80.62.44]>
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D364A@mailesl5.esl.corp.elbit.co.il>

thanks
 

Regards,


Amit Yedidia

Elbit System Ltd.

Email: amit.yedidia at elbitsystems.com

Tel: 972-4-8318905

----------------------------------------------------------

 


________________________________

	From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
	Sent: Monday, November 03, 2008 7:03 AM
	To: LIVE555 Streaming Media - development & use
	Subject: Re: [Live-devel] Framer/Parser Implementation problem
	
	

		My problem is the following:
		

		ByteStreamFileSource needs that H264VideoStreamFramer to
have a parser. The parser object should parse byte after byte and
deliver complete Nals to the framer. However since my Device source is
already sending Nals using send(), I just need to do recv() to receive a
complete NAL, without needing the exhausting parsing.
		

		What is the right thing to do (to keep only one Framer)

	[...]


		3. implementing two types of framer. One that make use
of the parser, and one that doesn't. (what I tried to avois)


	This is what I would do.  Note that we already do this for
MPEG-1,2 and 4 video: we have "MPEG*VideoStreamDiscreteFramer" for
sources that deliver complete frames (one at a time), and
"MPEG*VideoStreamFramer" for sources that deliver a byte stream.  So you
have some existing code to use as a model.
	-- 

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


The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081103/8b89734b/attachment.html>

From prbhagwat at gmail.com  Mon Nov  3 00:41:32 2008
From: prbhagwat at gmail.com (Pramod Bhagwat)
Date: Mon, 3 Nov 2008 14:11:32 +0530
Subject: [Live-devel] QuickTimeFileSink SubsessionBuffer destructor
Message-ID: <ee39532d0811030041i61f4c3d9jaf5ce53574620deb@mail.gmail.com>

Hi Ross,
This is regarding SubsessionBuffer desctructor function present in
QuickTimeFileSink.cpp.
The code should be modified to "delete[] fData" since fData is an
array and tools
like valgrind complain saying "Mismatched free() / delete / delete []".

Warm Regards,
pramod

From RGlobisch at csir.co.za  Mon Nov  3 00:58:00 2008
From: RGlobisch at csir.co.za (Ralf Globisch)
Date: Mon, 03 Nov 2008 10:58:00 +0200
Subject: [Live-devel] RTSPServer disconnects client session
	in	incomingRequestHandler1 [Possible patch]
Message-ID: <490ED937.5DA9.004D.0@csir.co.za>

Hi Ross, 

One of my colleagues Louis Joubert found that the socket descriptors never got deleted. 
I've included his mail below. He found the difference between Windows and Linux socket implementations: 
On Windows and it seems like the accept() call returns different socket descriptors/handles 
each time while on Linux the same handles get reused.

Further debugging showed that in RTPInterface::removeStreamSocket deletes RTPInterface::fTCPStreams. 
This causes the deregisterRTPInterface to never get called by stopNetworkReading since fTCPStreams is NULL.

One quick fix we tried is to duplicate the deregistration code from stopNetworkReading in removeStreamSocket:
Since the RTSPClientSession is being deleted it should be safe to deregister the stream socket at this point?
We have attached this as a patch though we're not sure whether there are any other (unintended) side-effects.

In our tests the subsequent TCP connections are now handled by the correct handler.

Regards,
Ralf

>Hey Ralf
>
>Was looking at the live555 stuff, and this is what I can see is happening
>... dunno if it is worth anything?
>
>For every TCP connection a SocketDescriptor is created, which contains a
>hastable of subchannel stuff
>
>there is also a global hashtable of open SocketDescriptors, keyed on the
>socket descriptor returned from the accept() call
>
>ok. so on the initial TCP connection, a SocketDescriptor is created, and in
>SocketDescriptor::registerRTPInterface somewhere
>tcpHandler is assigned as a handler if isFirstRegistration is true,
>
>
>The problem is ... when the TCP connection is terminated, the above
>SocketDescriptor never gets deleted (as far is i can tell?)
>
>So, on subsequent TCP connects, the old SocketDescriptor is reused (which
>already has subchannels assigned, and therefore isFirstRegistration is
>false), and the tcpHandler thingy doesn't get set, resulting in the wrong
>handlers being called
>
>however, if you make the second TCP connection before that destructor thing
>of yours gets called (printed out in the DEBUG_RR thing), the previous
>socket is still active, accept() will return a new socket descriptor, a new
>SocketDescriptor gets created, the tcpHandler gets assigned and things work.
>But once any TCP connection gets terminated, you will have stale
>SocketDescriptors hanging around and things will break.
>
>Dunno why it would work in Windows ... maybe Windows doesn't reuse socket
>descriptor values even when the sockets were closed? No idea.
>
>In any case ... SocketDescriptors should get deleted somewhere?





-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: RTPInterface.patch
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081103/9bd22586/attachment.ksh>

From finlayson at live555.com  Mon Nov  3 01:07:43 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 3 Nov 2008 01:07:43 -0800
Subject: [Live-devel] QuickTimeFileSink SubsessionBuffer destructor
In-Reply-To: <ee39532d0811030041i61f4c3d9jaf5ce53574620deb@mail.gmail.com>
References: <ee39532d0811030041i61f4c3d9jaf5ce53574620deb@mail.gmail.com>
Message-ID: <f06240800c5346fd24bb7@[66.80.62.44]>

Thanks.  This will be fixed in the next release of the software.
-- 

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

From kittisak at jowit.com  Mon Nov  3 20:36:11 2008
From: kittisak at jowit.com (kittisak)
Date: Tue, 4 Nov 2008 11:36:11 +0700
Subject: [Live-devel] subject: unsubscription
Message-ID: <CE870934201D46EBAABF150E9256979B@STDeveloper>

I would like to unsubscribe the information for development..

Thank a lot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081104/0fb132ea/attachment.html>

From RGlobisch at csir.co.za  Mon Nov  3 23:46:52 2008
From: RGlobisch at csir.co.za (Ralf Globisch)
Date: Tue, 04 Nov 2008 09:46:52 +0200
Subject: [Live-devel] subject: unsubscription
Message-ID: <49101A0A.5DA9.004D.0@csir.co.za>

You need to unsubscribe yourself at http://lists.live555.com/mailman/listinfo/live-devel/



-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.


From finlayson at live555.com  Tue Nov  4 01:35:01 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 4 Nov 2008 01:35:01 -0800
Subject: [Live-devel] RTSPServer disconnects client session in
 incomingRequestHandler1 [Possible patch]
In-Reply-To: <490ED937.5DA9.004D.0@csir.co.za>
References: <490ED937.5DA9.004D.0@csir.co.za>
Message-ID: <f0624080dc535c74fe08f@[66.80.62.44]>

Ralf,

Many thanks for the bug report.  I have applied (a sllightly modified 
version of) your patch, and released a new version (2008.11.04) of 
the software.

Please check that it works OK for you, and eliminates your problem.
-- 

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

From RGlobisch at csir.co.za  Tue Nov  4 03:09:36 2008
From: RGlobisch at csir.co.za (Ralf Globisch)
Date: Tue, 04 Nov 2008 13:09:36 +0200
Subject: [Live-devel] RTSPServer disconnects client session
	in	incomingRequestHandler1 [Possible patch]
Message-ID: <4910498E.5DA9.004D.0@csir.co.za>

Ross,
Glad we could contribute something.

The tests I ran were all successful with the new release, thank you.

And thanks again for the great library,

Regards,
Ralf




-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.


From js at aimsint.com  Tue Nov  4 05:32:02 2008
From: js at aimsint.com (Jack A Short)
Date: Tue, 4 Nov 2008 13:32:02 -0000
Subject: [Live-devel] .NET Integration
Message-ID: <002c01c93e81$b954b750$2101a8c0@Nedko>

Hi Mailing List,

I am trying to find away of adding a video streaming into our VB.NET application. I was wondering if it was possible to use the livemedia libraries in conjunction with our VB.NET interface, so that we can integrate a video streaming application into our application.

Any help would be greatly appreciated

Best Regards
Jack Short


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

From matt at schuckmannacres.com  Tue Nov  4 08:45:06 2008
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Tue, 04 Nov 2008 08:45:06 -0800
Subject: [Live-devel] .NET Integration
In-Reply-To: <002c01c93e81$b954b750$2101a8c0@Nedko>
References: <002c01c93e81$b954b750$2101a8c0@Nedko>
Message-ID: <49107C12.4030806@schuckmannacres.com>

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

From sjardine at acm.org  Tue Nov  4 09:34:53 2008
From: sjardine at acm.org (Steve Jardine)
Date: Tue,  4 Nov 2008 17:34:53 +0000 (UTC)
Subject: [Live-devel] Binding to a specific interface
In-Reply-To: <d9e63cf60803170330q58737a32wa221df3da5c79712@mail.gmail.com>
References: <FDC516B3-ACC5-4689-8E75-EC5EFCA3A714@local>
	<d9e63cf60803170330q58737a32wa221df3da5c79712@mail.gmail.com>
Message-ID: <20081104173453.48E6B22E4A4@mpls-qmqp-04.inet.qwest.net>


    I have a system that has multiple Ethernet interfaces. How can I bind mediaserver to a specific interface. For instance, I have two interfaces: 192.168.0.1 and 10.0.0.1. I would like media server to be available to only the systems attached to the 10.0.0.x physical interface. Any ideas?

   Thanks in advance.


       Steve

From sjardine at acm.org  Tue Nov  4 09:41:46 2008
From: sjardine at acm.org (Steve Jardine)
Date: Tue,  4 Nov 2008 17:41:46 +0000 (UTC)
Subject: [Live-devel] Binding to a specific IP number
In-Reply-To: <20081104173453.48E6B22E4A4@mpls-qmqp-04.inet.qwest.net>
References: <FDC516B3-ACC5-4689-8E75-EC5EFCA3A714@local>
	<d9e63cf60803170330q58737a32wa221df3da5c79712@mail.gmail.com>
	<20081104173453.48E6B22E4A4@mpls-qmqp-04.inet.qwest.net>
Message-ID: <20081104174146.CB04753C558@mpls-qmqp-02.inet.qwest.net>

 Is there a way I can get mediaserver to bind to a specific IP #?

   Thanks,

      Steve

From finlayson at live555.com  Tue Nov  4 18:09:46 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 4 Nov 2008 18:09:46 -0800
Subject: [Live-devel] Binding to a specific interface
In-Reply-To: <20081104173453.48E6B22E4A4@mpls-qmqp-04.inet.qwest.net>
References: <FDC516B3-ACC5-4689-8E75-EC5EFCA3A714@local>
	<d9e63cf60803170330q58737a32wa221df3da5c79712@mail.gmail.com>
	<20081104173453.48E6B22E4A4@mpls-qmqp-04.inet.qwest.net>
Message-ID: <f06240804c536adc96bc5@[66.80.62.44]>

>     I have a system that has multiple Ethernet interfaces. How can I 
>bind mediaserver to a specific interface. For instance, I have two 
>interfaces: 192.168.0.1 and 10.0.0.1. I would like media server to 
>be available to only the systems attached to the 10.0.0.x physical 
>interface. Any ideas?

First, *do not* send the same question to the mailing list more than once!

There's no current way to do what you want using the pre-built 
"live555MediaServer" binary; however, you can do this by modifying 
the source code:

Add
	ReceivingInterfaceAddr = our_inet_addr("10.0.0.1");
to the start of your code (e.g., at the start of the "main()" function).
-- 

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

From anto.rizzo at caramail.com  Wed Nov  5 01:59:32 2008
From: anto.rizzo at caramail.com (Antonella Rizzo)
Date: Wed, 5 Nov 2008 10:59:32 +0100
Subject: [Live-devel] Conceptual question on testMPEG1or2AudioVideoServer
Message-ID: <183181215874657@lycos-europe.com>

Hi Ross, testMPEG1or2AudioVideoServer take an ?mpg file and serve it to a multicast address (6666 audio, 8888 video port)!?
I want take a real time stream (and not a file) and I want serve it onDemand.

How We can?


Best regards


From finlayson at live555.com  Wed Nov  5 04:54:40 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 5 Nov 2008 04:54:40 -0800
Subject: [Live-devel] Conceptual question on testMPEG1or2AudioVideoServer
In-Reply-To: <183181215874657@lycos-europe.com>
References: <183181215874657@lycos-europe.com>
Message-ID: <f06240802c53747f384af@[66.80.62.44]>

>Hi Ross, testMPEG1or2AudioVideoServer take an  mpg file and serve it 
>to a multicast address (6666 audio, 8888 video port)!
>I want take a real time stream (and not a file) and I want serve it onDemand.
>
>How We can?

Read the FAQ !!!
-- 

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

From weglanz12 at yahoo.com  Wed Nov  5 06:57:49 2008
From: weglanz12 at yahoo.com (Horst Weglanz)
Date: Wed, 5 Nov 2008 06:57:49 -0800 (PST)
Subject: [Live-devel] Recursion in continuePlaying() -> stack overflow
Message-ID: <388298.83272.qm@web45810.mail.sp1.yahoo.com>

Hello

I've a problem building an output sink for LiveMedia in my application. I wanted to use the mpeg2ts muxer capabilities and build an output sink which transports every mpeg2ts frame back to my application.
This sink basically holds a reference to a synchronized queue and simply add every frame it gets to this queue. This works so far, but when using this sink the LiveMedia threads grabbing more and more stack memory. I've monitored the current stack usage and this always ends in a stack overflow as long as this thread is running.

This probably is a result of the recursion in here
| MySink::afterGettingFrame1()
| {
|     //[..]
|     // Then try getting the next frame:
|     continuePlaying();
| }
which I built after FileSink/HTTPSink or others. I don't understand how this couldn't work if this recursion here is every time calling continuePlaying() recursively.

I started the setup this way:
| FramedSource* ts = ...
| MySink* sink = MySink::createNew( *envir(), queue, bufferSize );
|
| // Start streaming:
| sink->startPlaying(*ts, NULL, NULL);
| envir()->taskScheduler().doEventLoop();

In this scenario startPlaying() doesn't return if the recursion above is executed. After startPlaying() it goes into continuePlaying() and then further and further since fSource always remains valid and the event loop is never reached. 

| Boolean MySink::continuePlaying() 
| {
|    if (fSource == NULL) return False;
|
|    fSource->getNextFrame(fBuffer, fBufferSize,
|            afterGettingFrame, this,
|            onSourceClosure, this);
|
|    return True;
| }

What am I doing wrong here? 

Thank you very much,
HW


      


From armandopoulos at yahoo.fr  Wed Nov  5 07:24:42 2008
From: armandopoulos at yahoo.fr (Armando Ko)
Date: Wed, 5 Nov 2008 15:24:42 +0000 (GMT)
Subject: [Live-devel] jpeg streaming max. size
Message-ID: <148064.72696.qm@web25901.mail.ukl.yahoo.com>

Hallo,

i?am using the live555 for jpeg streaming and it?s great.Thanks at all.

my question is about the maximun jpeg size i can stream if i?don?t compress the file ?
i?m trying with the 227kb jpeg and the dispayling quality is wrong (the client show the file which the gray balk at the end of file at bottom) but if i?m setting the compression factor to 98
all the jpg file can be displaying but with anti-aliassing.

It?s possible that i improve something anywhere ? if yes thanks in advance

Armando



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

From sjardine at acm.org  Wed Nov  5 10:05:02 2008
From: sjardine at acm.org (Steve Jardine)
Date: Wed,  5 Nov 2008 18:05:02 +0000 (UTC)
Subject: [Live-devel] Binding to a specific IP number
In-Reply-To: <20081104174146.CB04753C558@mpls-qmqp-02.inet.qwest.net>
References: <FDC516B3-ACC5-4689-8E75-EC5EFCA3A714@local>
	<d9e63cf60803170330q58737a32wa221df3da5c79712@mail.gmail.com>
	<20081104173453.48E6B22E4A4@mpls-qmqp-04.inet.qwest.net>
	<20081104174146.CB04753C558@mpls-qmqp-02.inet.qwest.net>
Message-ID: <20081105180502.2034722E1C3@mpls-qmqp-04.inet.qwest.net>

Added the code below to live555MediaServer.cpp right after main()., It yields this when compiled:

live555MediaServer.cpp:26: error: ?ReceivingInterfaceAddr? was not declared in this scope
live555MediaServer.cpp:26: error: ?our_inet_addr? was not declared in this scope

   Adding it to GroupsockHelper.cpp in place of:
//netAddressBits ReceivingInterfaceAddr = INADDR_ANY;

   compiles, but yields:

Failed to create RTSP server: bind() error (port number: 8554): Cannot assign requested address

  when run. Ideas?

   Thanks,

      Steve


On Tue, 4 Nov 2008 18:09:46 -0800
Ross Finlayson <finlayson at live555.com> wrote:

> >     I have a system that has multiple Ethernet interfaces. How can I 
> >bind mediaserver to a specific interface. For instance, I have two 
> >interfaces: 192.168.0.1 and 10.0.0.1. I would like media server to 
> >be available to only the systems attached to the 10.0.0.x physical 
> >interface. Any ideas?
> 
> First, *do not* send the same question to the mailing list more than once!
> 
> There's no current way to do what you want using the pre-built 
> "live555MediaServer" binary; however, you can do this by modifying 
> the source code:
> 
> Add
> 	ReceivingInterfaceAddr = our_inet_addr("10.0.0.1");
> to the start of your code (e.g., at the start of the "main()" 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
> 

From finlayson at live555.com  Wed Nov  5 10:22:29 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 5 Nov 2008 10:22:29 -0800
Subject: [Live-devel] Binding to a specific IP number
In-Reply-To: <20081105180502.2034722E1C3@mpls-qmqp-04.inet.qwest.net>
References: <FDC516B3-ACC5-4689-8E75-EC5EFCA3A714@local>
	<d9e63cf60803170330q58737a32wa221df3da5c79712@mail.gmail.com>
	<20081104173453.48E6B22E4A4@mpls-qmqp-04.inet.qwest.net>
	<20081104174146.CB04753C558@mpls-qmqp-02.inet.qwest.net>
	<20081105180502.2034722E1C3@mpls-qmqp-04.inet.qwest.net>
Message-ID: <f06240803c53794bc9d24@[66.80.62.44]>

>Added the code below to live555MediaServer.cpp right after main()., 
>It yields this when compiled:
>
>live555MediaServer.cpp:26: error: 'ReceivingInterfaceAddr' was not 
>declared in this scope
>live555MediaServer.cpp:26: error: 'our_inet_addr' was not declared 
>in this scope

Add
	#include "GroupsockHelper.hh"
to the start of the file.

-- 

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

From finlayson at live555.com  Wed Nov  5 13:34:15 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 5 Nov 2008 13:34:15 -0800
Subject: [Live-devel] jpeg streaming max. size
In-Reply-To: <148064.72696.qm@web25901.mail.ukl.yahoo.com>
References: <148064.72696.qm@web25901.mail.ukl.yahoo.com>
Message-ID: <f06240800c537c0371d84@[66.80.62.44]>

>i?am using the live555 for jpeg streaming and it?s great.Thanks at all.
>
>my question is about the maximun jpeg size i can 
>stream if i?don?t compress the file ?
>i?m trying with the 227kb jpeg and the 
>dispayling quality is wrong (the client show the 
>file which the gray balk at the end of file at 
>bottom) but if i?m setting the compression 
>factor to 98
>all the jpg file can be displaying but with anti-aliassing.
>
>It?s possible that i improve something anywhere ? if yes thanks in advance

As you've discovered, JPEG is a very poor 
(inefficient) codec for video streaming.  Note 
that a 227 kByte JPEG frame will take up more 
than 150 RTP packets (assuming the default MTU of 
1500 bytes) - all of which will need to be 
received without packet loss in order for the 
receiver to be able to properly render the frame.

My first suggestion would be to use a better 
video codec (e.g., MPEG-4 or H.264).

(I assume you've increased 
"OutPacketBuffer::maxSize" to allow for your 
large input frames (otherwise you will have seen 
error messages).  And that your receiver's input 
buffer is also sufficiently large.)
-- 

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

From sjardine at acm.org  Wed Nov  5 14:03:59 2008
From: sjardine at acm.org (Steve Jardine)
Date: Wed,  5 Nov 2008 22:03:59 +0000 (UTC)
Subject: [Live-devel] Binding to a specific IP number
In-Reply-To: <f06240803c53794bc9d24@[66.80.62.44]>
References: <FDC516B3-ACC5-4689-8E75-EC5EFCA3A714@local>
	<d9e63cf60803170330q58737a32wa221df3da5c79712@mail.gmail.com>
	<20081104173453.48E6B22E4A4@mpls-qmqp-04.inet.qwest.net>
	<20081104174146.CB04753C558@mpls-qmqp-02.inet.qwest.net>
	<20081105180502.2034722E1C3@mpls-qmqp-04.inet.qwest.net>
	<f06240803c53794bc9d24@[66.80.62.44]>
Message-ID: <20081105220359.DD97F1A9E45@mpls-qmqp-01.inet.qwest.net>

Thank you!
On Wed, 5 Nov 2008 10:22:29 -0800
Ross Finlayson <finlayson at live555.com> wrote:

> Add
> 	#include "GroupsockHelper.hh"
> to the start of the file.

From finlayson at live555.com  Wed Nov  5 13:56:31 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 5 Nov 2008 13:56:31 -0800
Subject: [Live-devel] Recursion in continuePlaying() -> stack overflow
In-Reply-To: <388298.83272.qm@web45810.mail.sp1.yahoo.com>
References: <388298.83272.qm@web45810.mail.sp1.yahoo.com>
Message-ID: <f06240801c537c5f575d9@[66.80.62.44]>

Because this is your own code (& you have a "@yahoo.com" email 
address :-), I can't help you much.  However, I suspect you can fix 
your problem by replacing your call to
	FramedSource::afterGetting(this):
or just
	afterGetting(this);
with:
	nextTask() = envir().taskScheduler().scheduleDelayedTask(0,
                         (TaskFunc*)FramedSource::afterGetting, this);
	return;

This will cause the code to return to the event loop - ending the recursion.
-- 

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

From venugopalpaikr at tataelxsi.co.in  Wed Nov  5 21:53:17 2008
From: venugopalpaikr at tataelxsi.co.in (venugopalpaikr)
Date: Thu, 6 Nov 2008 11:23:17 +0530
Subject: [Live-devel] [streaming] RTSP Support for ASF streams
In-Reply-To: <f06240802c537c753c7ef@[66.80.62.44]>
Message-ID: <001b01c93fd3$f832fbf0$3c033c0a@telxsi.com>

Thank you for the information.
I have used Live 555 Media Server to establish the connection and hard-coded
the asf sdp generated using Microsoft RTSP documents. Am currently looking
into establishment of the session i.e.only RTSP not RTP.
My session ends after sending the SDP information while using VLC player.

Also by hardcoding the sdp am trying to establish the connection with
Windows Media Player which is failing. How different is windows rtsp
standard from Live555 rtsp standard?


-----Original Message-----
From: streaming-bounces at videolan.org
[mailto:streaming-bounces at videolan.org]On Behalf Of Ross Finlayson
Sent: Thursday, November 06, 2008 3:31 AM
To: streaming at videolan.org
Subject: Re: [streaming] RTSP Support for ASF streams


>Le mercredi 5 novembre 2008 06:09:38 venugopalpaikr, vous avez ?crit :
>>  1. Does VLC receive ASF streams from an RTSP server i.e. by using the
>>  following command line can i establish the connection rtsp://<ip
>>  no>:554/filename.asf?
>>  2. Does VLC accept the SDP generated by Microsoft RTSP standard or is
there
>>  any other standard? If there s any other can someone give me an example
>>  sdp.
>
>The answers are: if live555 supports it.

A more detailed answer :-)  The words "Microsoft
RTSP standard" are an oxymoron.  There *is* a
RTSP standard - and we support it - but Microsoft
does not.  They use their own proprietary (and
undocumented) variants of RTSP, and their own
proprietary (and undocumented) codecs.  We do not
support these.

You need to use a different, standards-compliant
server (e.g., "LIVE555 Media Server" or "Darwin
Streaming Server" - not Microsoft's.
--

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
streaming mailing list
To unsubscribe or modify your subscription options:
http://mailman.videolan.org/listinfo/streaming


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.

From anto.rizzo at caramail.com  Thu Nov  6 00:43:46 2008
From: anto.rizzo at caramail.com (Antonella Rizzo)
Date: Thu, 6 Nov 2008 09:43:46 +0100
Subject: [Live-devel] test*Streamer FAQ
Message-ID: <170210928418498@lycos-europe.com>

Hi Ross,
I am following the FAQ:

If you still wish to change the "test*Streamer" programs to stream using unicast, then do the following:

a) In "test*Streamer.cpp", change "destinationAddressStr" to the (unicast) IP address of the intended destination.
b) In the corresponding "test*Receiver.cpp", change "sessionAddressStr" to "0.0.0.0".

In testMPEG1or2AudioVideoStreamer, I have changhed destinationAddressStr to my IP address,
and I have changhed testMPEG1or2AudioVideo.sdp in this way:
v=0
o=- 49451 3 IN IP4 127.0.0.1
s=Test MPEG Audio+Video session
i=Parameters for the session streamed by "testMPEG1or2AudioVideoStreamer"
t=0 0
a=tool:testMPEG1or2AudioVideoStreamer
a=type:broadcast
m=audio 6666 RTP/AVP 14
c=IN IP4 0.0.0.0/127
m=video 8888 RTP/AVP 32
c=IN IP4 0.0.0.0/127

I run testMPEG1or2AudioVideoStreamer and It's ok. I run testMPEG1or2AudioVideo.sdp with QuickTime but don't work! Why? 

Best Regards


PS. in multicast my file test.mpg work very well. So, It isn't a file problem!


From finlayson at live555.com  Thu Nov  6 01:48:34 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 6 Nov 2008 01:48:34 -0800
Subject: [Live-devel] test*Streamer FAQ
In-Reply-To: <170210928418498@lycos-europe.com>
References: <170210928418498@lycos-europe.com>
Message-ID: <f06240809c5386d09d88c@[66.80.62.44]>

>I am following the FAQ:
>
>If you still wish to change the "test*Streamer" programs to stream 
>using unicast, then do the following:
>
>a) In "test*Streamer.cpp", change "destinationAddressStr" to the 
>(unicast) IP address of the intended destination.
>b) In the corresponding "test*Receiver.cpp", change 
>"sessionAddressStr" to "0.0.0.0".
>
>In testMPEG1or2AudioVideoStreamer, I have changhed 
>destinationAddressStr to my IP address,
>and I have changhed testMPEG1or2AudioVideo.sdp in this way:
>v=0
>o=- 49451 3 IN IP4 127.0.0.1
>s=Test MPEG Audio+Video session
>i=Parameters for the session streamed by "testMPEG1or2AudioVideoStreamer"
>t=0 0
>a=tool:testMPEG1or2AudioVideoStreamer
>a=type:broadcast
>m=audio 6666 RTP/AVP 14
>c=IN IP4 0.0.0.0/127
>m=video 8888 RTP/AVP 32
>c=IN IP4 0.0.0.0/127
>
>I run testMPEG1or2AudioVideoStreamer and It's ok. I run 
>testMPEG1or2AudioVideo.sdp with QuickTime but don't work! Why?

Because the FAQ describes how you can modify the 
"testMPEG1or2Receiver" application to receive the unicast stream, but 
says nothing about QuickTime Player (because that's not our software).

To my knowledge, you can't use QuickTime Player to receive/play a 
unicast stream that does not use the RTSP protocol.  However, if, 
instead, you use the "testOnDemandRTSPServer" application (which 
streams via unicast), you will be able to use QuickTime Player to 
play its streams (by entering the appropriate "rtsp://" URL).

-- 

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

From edward at v-ecom.com  Thu Nov  6 01:57:30 2008
From: edward at v-ecom.com (Edward)
Date: Thu, 06 Nov 2008 17:57:30 +0800
Subject: [Live-devel] can not play openRTSP dump file
Message-ID: <4912BF8A.7000809@v-ecom.com>

Hi,


I just downloaded live555 and compiled it on my mandriva 2008  machine. 
I was able to compile it with out any problem. When I run  openRTSP to 
stream from a darwin server, I could not play the video-MP4-ES-1 file. 
The command line I used to stream the video is ./openRTSP 
rtsp://192.168.0.5/sample_100kbit.mp4



From weglanz12 at yahoo.com  Thu Nov  6 02:08:31 2008
From: weglanz12 at yahoo.com (Horst Weglanz)
Date: Thu, 6 Nov 2008 02:08:31 -0800 (PST)
Subject: [Live-devel] Recursion in continuePlaying() -> stack overflow
References: <388298.83272.qm@web45810.mail.sp1.yahoo.com>
	<f06240801c537c5f575d9@[66.80.62.44]>
Message-ID: <556387.64663.qm@web45806.mail.sp1.yahoo.com>

> This will cause the code to return to the event loop - ending the recursion.

Thank you very much, that totally did the trick!

HW



      


From finlayson at live555.com  Thu Nov  6 02:09:05 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 6 Nov 2008 02:09:05 -0800
Subject: [Live-devel] can not play openRTSP dump file
In-Reply-To: <4912BF8A.7000809@v-ecom.com>
References: <4912BF8A.7000809@v-ecom.com>
Message-ID: <f0624080ac538723c109a@[66.80.62.44]>

>I just downloaded live555 and compiled it on my mandriva 2008 
>machine. I was able to compile it with out any problem. When I run 
>openRTSP to stream from a darwin server, I could not play the 
>video-MP4-ES-1 file.

This is a MPEG-4 Video Elementary Stream file.  Few, if any, media 
players are able to play such a file, unfortunately.

However, you can use VLC or QuickTime Player to play the stream 
directly - using the "rtsp://" URL.
-- 

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

From anto.rizzo at caramail.com  Thu Nov  6 04:30:38 2008
From: anto.rizzo at caramail.com (Antonella Rizzo)
Date: Thu, 6 Nov 2008 13:30:38 +0100
Subject: [Live-devel] Demux testOnDemandRTSPServer output
Message-ID: <184944190613525@lycos-europe.com>

Hi Ross, 
I want demux testOnDemandRTSPServer output, because my code works with audio on X port and video on Y port!?
TestOnDemandRTSPServer have an output with Audio and Video (both) on 8554 port.?So I want demux Audio on X port and video to Y port!?
I have seen MPEGDemux but it Demux a file not a live stream (rtsp://)

Best Regards


From finlayson at live555.com  Thu Nov  6 08:00:12 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 6 Nov 2008 08:00:12 -0800
Subject: [Live-devel] Demux testOnDemandRTSPServer output
In-Reply-To: <184944190613525@lycos-europe.com>
References: <184944190613525@lycos-europe.com>
Message-ID: <f0624080bc538c41bdd9e@[66.80.62.44]>

>I want demux testOnDemandRTSPServer output, because my code works 
>with audio on X port and video on Y port!
>TestOnDemandRTSPServer have an output with Audio and Video (both) on 
>8554 port. So I want demux Audio on X port and video to Y port!
>I have seen MPEGDemux but it Demux a file not a live stream (rtsp://)

Your message makes no sense, and it appears that you don't understand 
how RTSP/RTP works.

The output from "testOnDemandRTSPServer" - when it streams a MPEG 
Program Stream file - *is* demultiplexed: Audio RTP packets are sent 
to one UDP port, and video RTP packets are sent to another UDP port. 
(The TCP port 8554 is used only as the control channel - to sent RTSP 
commands.)
-- 

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

From anto.rizzo at caramail.com  Sat Nov  8 09:06:04 2008
From: anto.rizzo at caramail.com (Antonella Rizzo)
Date: Sat, 8 Nov 2008 18:06:04 +0100
Subject: [Live-devel] Rtsp-alt [FIN,
	ACK] after about one minute testOnDemandRTSPServer
Message-ID: <185187875712568@lycos-europe.com>

Hi Ross, 
I run 
      ./testOnDemandRTSPServer (on my sender at 192.168.178.27). 

Then, I run?
      ./openRTSP -r -p 8888 -c   rtsp://192.168.178.27:8554/mpeg1or2AudioVideoTest (on my receiver host 192.168.178.22).

So, I launch QuickTime (on host 192.168.178.22) with this SDP:
v=0
o=- 1226162122947046 1 IN IP4 192.168.178.27
s=Session streamed by "testOnDemandRTSPServer"
i=mpeg1or2AudioVideoTest
t=0 0
a=tool:LIVE555 Streaming Media v2008.11.04
a=type:broadcast
a=control:*
a=range:npt=0-241.617
a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer"
a=x-qt-text-inf:mpeg1or2AudioVideoTest
m=video 8888 RTP/AVP 32
c=IN IP4 0.0.0.0
a=control:track1
m=audio 8890 RTP/AVP 14
c=IN IP4 0.0.0.0
a=control:track2

It's work for about one minute!
After one minute in fact, with a sniffer on my sender, I have seen that sender send an RSTP->ALT[FIN,ACK] and receiver answer with an RTSP->ALT[ACK] and video is blocked!
Then, after 2 minutes, receiver send an RTSP PLAY and sender answer with an RTSP [RST] and on my receiver openRTSP return this message:
"Failed to start playing session: Failed to read response: Connection reset by peer".

Why? How I can avoid this?

Thanks in advance


From ajitjohn at tataelxsi.co.in  Sat Nov  8 21:33:31 2008
From: ajitjohn at tataelxsi.co.in (ajitjohn)
Date: Sun, 9 Nov 2008 11:03:31 +0530
Subject: [Live-devel] MJPEG Streamning,SDP for MJPEG
Message-ID: <000001c9422c$b54286c0$68033c0a@telxsi.com>

Hii all,

	I have written a MJPEG packetizer based on rfc 2435 and i am able to stream
mjpeg packet through the network using udp  and on the client side i am
receiving through VLC player.VLC player is receiving the packets

Stream and Media info

Read at media :123456 kB
Input Bitrate:15000 kb/s
Demuxed :
Stream Bitrate:

first  and second fields are changing, so i have inferred  that the packets
are correctly received but its not able to demux those packets.Is this
because i am not using a correct sdp? or Can anyone tell me whether RFC 2435
is supported in vlc player.

Can anyone send me a valid mjpeg SDP file.

I am using rtp header ,followed by rfc 2435 header and the payload data in
all packets .Is my understanding correct?

I am using RTP Payload type as 26 for mjpeg .

Regards,
Ajit.



The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.

From finlayson at live555.com  Sat Nov  8 22:46:33 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 8 Nov 2008 22:46:33 -0800
Subject: [Live-devel] MJPEG Streamning,SDP for MJPEG
In-Reply-To: <000001c9422c$b54286c0$68033c0a@telxsi.com>
References: <000001c9422c$b54286c0$68033c0a@telxsi.com>
Message-ID: <f0624080cc53c367a5299@[66.80.62.44]>

>Can anyone tell me whether RFC 2435 is supported in vlc player.

Yes, it is.

>	I have written a MJPEG packetizer based on rfc 2435

FYI, we also have an implementation of this (the "JPEGVideoRTPSink" 
class).  (If you decide to use this, however, please read this FAQ 
entry: http://www.live555.com/liveMedia/faq.html#jpeg-streaming
-- 

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

From pankehust at gmail.com  Sun Nov  9 12:54:20 2008
From: pankehust at gmail.com (pan ke)
Date: Sun, 9 Nov 2008 15:54:20 -0500
Subject: [Live-devel] Streaming the same MEPG2 file circularly,
	only audio but no video
In-Reply-To: <f06240802c532f3b60f68@66.80.62.44>
References: <43f857160811010743p5c319eb2kcc3b1ffbc4d14b25@mail.gmail.com>
	<f06240802c532f3b60f68@66.80.62.44>
Message-ID: <43f857160811091254n45ed4c1ag447762c1c1f5e0c5@mail.gmail.com>

Sorry for my late reply
my source data is MPEG Program Stream, and I create a new file
combining the two copies of my original file together, and I stream it
again using testOnDemandRTSPServer, the problem happened again.

I also use testMPEG1or2AudioVideoStreamer to stream the file, when i
use the original file, it can stream the file again and again without
error(actually, this amounts to rerun the streamer). however, when i
use the combined file. the error still exists. I can only get the
audio, but no video.


On Sun, Nov 2, 2008 at 1:08 AM, Ross Finlayson <finlayson at live555.com> wrote:
>> I use testOnDemandRTSPServer, and change it to read from "stdin". My
>> other application read a MEPG2 file circularly, and pipe it to
>> testOnDemandRTSPServer. I use VLC as player to read the stream via
>> RTSP.
>>
>> 1)The server can work very well at the first time, however, at the
>> second time, that is replaying the same video, I found that there is
>> only audio but no video. I tried to use other format like mp4, the
>> same problem also appears.
>>
>> 2)I tried to change the reading position by setting the offset of the
>> file to simulate the package losses, there is also only audio but no
>> video appearing.
>> How can I solve this problem?
>
> Is your source data a MPEG Program Stream, or a MPEG Transport Stream?
>
> Do you get the same problem if you create a new file by concatenating
> together two or more copies of the original file, and then stream directly
> from this new file (rather than from stdin), using the original, unmodified
> "testOnDemandRTSPServer"?
> --
>
> 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
>



-- 
            Ke Pan

From pankehust at gmail.com  Sun Nov  9 13:23:47 2008
From: pankehust at gmail.com (pan ke)
Date: Sun, 9 Nov 2008 16:23:47 -0500
Subject: [Live-devel] Streaming the same MEPG2 file circularly,
	only audio but no video
In-Reply-To: <43f857160811091254n45ed4c1ag447762c1c1f5e0c5@mail.gmail.com>
References: <43f857160811010743p5c319eb2kcc3b1ffbc4d14b25@mail.gmail.com>
	<f06240802c532f3b60f68@66.80.62.44>
	<43f857160811091254n45ed4c1ag447762c1c1f5e0c5@mail.gmail.com>
Message-ID: <43f857160811091323y27c6e2e5k6d31f24bbbd9bc04@mail.gmail.com>

I am sorry, i made a mistake. after i combined two copies of the
original files, i use another player to play the MPEG file. When i use
VLC again, i find the video part of the second segment still can't be
played. So it seems the problem comes from VLC, not live server.
Thanks for your help!
On Sun, Nov 9, 2008 at 3:54 PM, pan ke <pankehust at gmail.com> wrote:
> Sorry for my late reply
> my source data is MPEG Program Stream, and I create a new file
> combining the two copies of my original file together, and I stream it
> again using testOnDemandRTSPServer, the problem happened again.
>
> I also use testMPEG1or2AudioVideoStreamer to stream the file, when i
> use the original file, it can stream the file again and again without
> error(actually, this amounts to rerun the streamer). however, when i
> use the combined file. the error still exists. I can only get the
> audio, but no video.
>
>
> On Sun, Nov 2, 2008 at 1:08 AM, Ross Finlayson <finlayson at live555.com> wrote:
>>> I use testOnDemandRTSPServer, and change it to read from "stdin". My
>>> other application read a MEPG2 file circularly, and pipe it to
>>> testOnDemandRTSPServer. I use VLC as player to read the stream via
>>> RTSP.
>>>
>>> 1)The server can work very well at the first time, however, at the
>>> second time, that is replaying the same video, I found that there is
>>> only audio but no video. I tried to use other format like mp4, the
>>> same problem also appears.
>>>
>>> 2)I tried to change the reading position by setting the offset of the
>>> file to simulate the package losses, there is also only audio but no
>>> video appearing.
>>> How can I solve this problem?
>>
>> Is your source data a MPEG Program Stream, or a MPEG Transport Stream?
>>
>> Do you get the same problem if you create a new file by concatenating
>> together two or more copies of the original file, and then stream directly
>> from this new file (rather than from stdin), using the original, unmodified
>> "testOnDemandRTSPServer"?
>> --
>>
>> 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
>>
>
>
>
> --
>            Ke Pan
>



-- 
            Ke Pan

From s.boschi at totalwire.it  Mon Nov 10 09:45:11 2008
From: s.boschi at totalwire.it (Sigismondo Boschi)
Date: Mon, 10 Nov 2008 18:45:11 +0100
Subject: [Live-devel] bug in BasicTaskScheduler.cpp ?
Message-ID: <49187327.4070903@totalwire.it>

Hi Ross,

I have an application, written with live555, that needs to play 
continuously from an rtsp source using RTP-over-TCP. This worked fine 
with an old version of the library, but upgrading to the last one (I 
have seen many bugs solved in the mailing list), it stops restarting 
after a few BYEs (1 to 5).

I have debugged this problem, here are the outcomes.

The application works by setting up a BYE handler thats restart the RTSP 
client.

The restart routine can not be called directly, because the RTCP handler 
is destroyed on the destruction of the RTSP session, so I have called it 
asynchronously in the event loop with 
scheduleDelayedTask(0,restartTask,data)

What was happening is this:

restartTask is being called in the middle of 
BasicTaskScheduler::SingleStep(), by fDelayQueue.handleAlarm()
after selecting among all the available sockets, and so "fd_set readSet" 
now points to the one socket that was available for reading *BEFORE* 
restarting.

On the other side restartTask has closed such socket and opened new 
ones. Windowze sometimes reuse the same socket numbers, so if the socket 
actually exists, and can not be what it was in the first select (the TCP 
good socket), what is called is the UDP data handler - where nothing 
comes since all the traffic goes over TCP: the handler get stuck in the 
select.

And so the taskscheduler stop working being blocked in one select.

I have solved the problem moving fDelayQueue.handleAlarm() to the very 
end of the procedure. Now it works fine, since "readSet" is not used 
anymore.

Only doubt, if there is some reason it is there in the middle, how 
should I have dealt with such case? The only other solution coming in my 
mind, without patching the library is to stop the event loop, restart 
the client and then restart the event loop.

Thanks for the great work on the library.

Regards,
    Sigismondo









-- 
------------------------------------------------------------------
Sigismondo Boschi, PhD                     TotalWire S.r.l.
s.boschi at totalwire.it                      http://www.totalwire.it
cell: +39 346 7911896                      tel:  +39 051 302696
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s_boschi.vcf
Type: text/x-vcard
Size: 275 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081110/4eaa25dd/attachment.vcf>

From gbonneau at matrox.com  Mon Nov 10 10:36:19 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Mon, 10 Nov 2008 13:36:19 -0500
Subject: [Live-devel] Open RTSP FAQ
Message-ID: <BA62AB2FB873448FBA39EF6C4591E753@dorvalmatrox.matrox.com>

While reviewing the FAQ for OpenRTSP I think I found a typo.
 
In section: "Playing without receiving" I read
 
For example, if the SDP description contains "a=range:npt=0-25", then "-d
10" means "play the stream(s) for 10 seconds, then exit", and "-d -10" means
"play the stream(s) for 35 seconds, then exit". 
 
I think it should be:
 
For example, if the SDP description contains "a=range:npt=0-25", then "-d
10" means "play the stream(s) for 10 seconds, then exit", and "-d -35" means
"play the stream(s) for 35 seconds, then exit". 
 
Regards
Guy Bonneau
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081110/c29605d0/attachment.html>

From aavvee2002 at yahoo.com  Mon Nov 10 15:23:57 2008
From: aavvee2002 at yahoo.com (aavvee)
Date: Mon, 10 Nov 2008 15:23:57 -0800 (PST)
Subject: [Live-devel] Error while trying to build livemedia library using
	Borland C++ compiler
Message-ID: <474596.32584.qm@web62102.mail.re1.yahoo.com>

Hello there,

I am trying to build the livemedia library, so i could use it to build the openrtsp application. I follow the procedure described on the live555 website but when i execute make on the command line i get

Error E2268 inputfile.cpp 85: Call to undefined function '_lseeki64' in function
SeekFile64(FILE *,__int64,int)
Error E2268 inputfile.cpp 99: Call to undefined function '_telli64' in function

TellFile64(FILE *)
*** 2 errors in Compile ***

** error 1 ** deleting InputFile.obj

Thanks,

Gracia


      

From finlayson at live555.com  Mon Nov 10 16:01:47 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 10 Nov 2008 16:01:47 -0800
Subject: [Live-devel] bug in BasicTaskScheduler.cpp ?
In-Reply-To: <49187327.4070903@totalwire.it>
References: <49187327.4070903@totalwire.it>
Message-ID: <f06240802c53e7acc32ad@[66.80.62.44]>

To my knowledge, there is nothing wrong with the current 
"BasicTaskScheduler" code.

Did you upgrade to the very most recent version (2008.11.04) of the 
code?  That version fixed a bug similar to what you seem to be 
seeing: sockets were sometimes not being closed (and their associated 
event loop handlers not being removed) when streaming RTP-over-TCP.

Note that any time a socket gets closed, its associated event loop 
handler should also get removed (using 
"TaskScheduler::turnOffBackgroundReadHandling()"), so that it does 
not get looked at again by "select()".  I believe that the current 
version of the code does this properly.
-- 

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

From finlayson at live555.com  Mon Nov 10 18:23:57 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 10 Nov 2008 18:23:57 -0800
Subject: [Live-devel] Open RTSP FAQ
In-Reply-To: <BA62AB2FB873448FBA39EF6C4591E753@dorvalmatrox.matrox.com>
References: <BA62AB2FB873448FBA39EF6C4591E753@dorvalmatrox.matrox.com>
Message-ID: <f06240801c53e9cd5c0f4@[66.80.62.44]>

>While reviewing the FAQ for OpenRTSP I think I found a typo.
>
>In section: "Playing without receiving" I read
>
>For example, if the SDP description contains "a=range:npt=0-25", 
>then "-d 10" means "play the stream(s) for 10 seconds, then exit", 
>and "-d -10" means "play the stream(s) for 35 seconds, then exit".

No - this is correct.  Read the openRTSP documentation 
<http://www.live555.com/openRTSP/#playing-time> 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/20081110/236123ba/attachment-0001.html>

From s.boschi at totalwire.it  Tue Nov 11 00:49:14 2008
From: s.boschi at totalwire.it (Sigismondo Boschi)
Date: Tue, 11 Nov 2008 09:49:14 +0100
Subject: [Live-devel] bug in BasicTaskScheduler.cpp ?
In-Reply-To: <f06240802c53e7acc32ad@[66.80.62.44]>
References: <49187327.4070903@totalwire.it>
	<f06240802c53e7acc32ad@[66.80.62.44]>
Message-ID: <4919470A.7060608@totalwire.it>

Ross Finlayson wrote:
> To my knowledge, there is nothing wrong with the current 
> "BasicTaskScheduler" code.
> 
> Did you upgrade to the very most recent version (2008.11.04) of the 
> code?  That version fixed a bug similar to what you seem to be seeing: 
> sockets were sometimes not being closed (and their associated event loop 
> handlers not being removed) when streaming RTP-over-TCP.
Yes, I upgraded up to this last one: I have the problem with it too. 
There are two points:

1. I do not know whether it is reasonable that I want to close and 
reopen the socket in the event loop. I have interpreted "yes" looking to 
your examples - but I need a very cold restart - reopening the client 
connections. Is this reasonable?

2. What happen is very tricky, it has taken some time to understand why 
it was getting stuck after some BYEs. Even if RTP-over-TCP is used, the 
UDP handlers are registered. They never get called because the select in 
SingleStep never "activate" them, since there are no UDP packets 
incoming. Let's say for example:
   socket    handler
   2000      TCP
   2100      RTP-UDP
   2200      RTCP-UDP
only the first one result activated in "readSet" after the select in 
SingleStep, and get successfully selected again in the TCP handler.

On an incoming BYE, the call fDelayQueue.HandleAlarm() calls my "reset 
connections" handler: such sockets get closed, and new one opened and 
replace the old one in fReadSet. Nothing strange happens when they are 
different socket ids, because of the checks:

if (FD_ISSET(handler->socketNum, &readSet) &&
     FD_ISSET(handler->socketNum, &fReadSet) /* sanity check */ &&

However it happens quite frequently (20% of the times) that after the 
reopen the TCP socket id is "relocated" (I am using windows xp - I do 
not know whether with linux is the same, however in principle it can 
happen with any OS):

   socket    handler
   2300      TCP
   2000      RTP-UDP
   2100      RTCP-UDP

So the "if" passes and the handler called is RTP-UDP on the UDP 
connection. No packets incoming there, so the handler waits 
indefenitevly. The bug I have observed is related to the fact that it is 
assumed that fDelayQueue.HandleAlarm() does not perform any reconnection.

Moving the call to fDelayQueue.HandleAlarm() AFTER the call to the 
handlers solve this problem.
Another solution could be to call fDelayQueue.HandleAlarm() only upon 
timeout of the select in SingleStep, the handlers only upon socket 
"selection" of the select (only if data are incoming). Fine tune for 
cases where both events happens - but let only one of the two get executed.
A 3rd one should be not to register the UDP handlers at all.

> 
> Note that any time a socket gets closed, its associated event loop 
> handler should also get removed (using 
> "TaskScheduler::turnOffBackgroundReadHandling()"), so that it does not 
> get looked at again by "select()".  I believe that the current version 
> of the code does this properly.
Yes, I have seen it - and that's why I can not reopen directly in the 
BYE handler (it is destroyed - I did not know when I did it, but now the 
structure is very clear - nice job!), but I need to schedule an event. 
The called handler is correct - it is the fact that it has been changed 
in the middle of SingleStep that let it become one of the useless UDP 
handlers (either RTP or RTCP) instead of the TCP one.

I hope this is clearer now.

Regards,
    Sigismondo


-- 
------------------------------------------------------------------
Sigismondo Boschi, PhD                     TotalWire S.r.l.
s.boschi at totalwire.it                      http://www.totalwire.it
cell: +39 346 7911896                      tel:  +39 051 302696
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s_boschi.vcf
Type: text/x-vcard
Size: 275 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081111/18d15008/attachment.vcf>

From finlayson at live555.com  Tue Nov 11 01:22:59 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 11 Nov 2008 01:22:59 -0800
Subject: [Live-devel] bug in BasicTaskScheduler.cpp ?
In-Reply-To: <4919470A.7060608@totalwire.it>
References: <49187327.4070903@totalwire.it>
	<f06240802c53e7acc32ad@[66.80.62.44]> <4919470A.7060608@totalwire.it>
Message-ID: <f06240809c53efc2b7b1d@[66.80.62.44]>

>2. What happen is very tricky, it has taken some time to understand 
>why it was getting stuck after some BYEs. Even if RTP-over-TCP is 
>used, the UDP handlers are registered. They never get called because 
>the select in SingleStep never "activate" them, since there are no 
>UDP packets incoming.

That doesn't matter, because *TCP* packets will still be arriving (on 
the TCP socket), and will be handled.  This is a Red Herring.

As I said before, if your code properly closes your "RTPInterface" 
objects, all of the sockets will end up being closed properly (and 
all of its event loop handlers will also be deleted).  So it won't 
matter if the same socket number(s) end up getting used again later.

In the current code, there are two possible ways that "RTPInterface" 
objects (when used for RTP-over-TCP) get closed.
1/ By calling "RTPInterface::removeStreamSocket()" (e.g, as is done 
in "OnDemandServerMediaSubsession.cpp"), or
2/ By calling "RTPInterface::stopNetworkReading()" (e.g., as is done 
in "MultiFramedRTPSource.cpp")

Only then should you actually delete the "RTPinterface" object.

I'm sorry, but because we're talking about your own custom code, I 
can't help you any more with this.  (So this will probably be my last 
posting on this topic.)  But there is nothing wrong with 
"BasicTaskScheduler", and there are no plans to modify that code.
-- 

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

From s.boschi at totalwire.it  Tue Nov 11 02:17:50 2008
From: s.boschi at totalwire.it (Sigismondo Boschi)
Date: Tue, 11 Nov 2008 11:17:50 +0100
Subject: [Live-devel] bug in BasicTaskScheduler.cpp ?
In-Reply-To: <f06240809c53efc2b7b1d@[66.80.62.44]>
References: <49187327.4070903@totalwire.it>	<f06240802c53e7acc32ad@[66.80.62.44]>
	<4919470A.7060608@totalwire.it>
	<f06240809c53efc2b7b1d@[66.80.62.44]>
Message-ID: <49195BCE.1080700@totalwire.it>

Ross Finlayson wrote:

> That doesn't matter, because *TCP* packets will still be arriving (on 
> the TCP socket), and will be handled.  This is a Red Herring.
No, that TCP socket has been closed - and the corresponding socket ID 
refers occasionally to an UDP socket within the same call to SingleStep 
- if it was a red herring the TaskScheduler was not going to be stuck. 
That's a fact, not an argument. I have debugged a real problem, not 
imagined one.

Look - I do not want you change the code because of my custom code! just 
hoped to be of some help pointing out a problem that have let me become 
mad!  It seems to me you have not got the point.

Nevermind. I know how to deal with it.

Regards,
    Sigismondo

-- 
------------------------------------------------------------------
Sigismondo Boschi, PhD                     TotalWire S.r.l.
s.boschi at totalwire.it                      http://www.totalwire.it
cell: +39 346 7911896                      tel:  +39 051 302696
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s_boschi.vcf
Type: text/x-vcard
Size: 275 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081111/b59edf5d/attachment.vcf>

From gbonneau at matrox.com  Tue Nov 11 05:41:08 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Tue, 11 Nov 2008 08:41:08 -0500
Subject: [Live-devel] Open RTSP FAQ
In-Reply-To: <f06240801c53e9cd5c0f4@[66.80.62.44]>
References: <BA62AB2FB873448FBA39EF6C4591E753@dorvalmatrox.matrox.com>
	<f06240801c53e9cd5c0f4@[66.80.62.44]>
Message-ID: <0ECE2E66E9CA44D78B4D7875B89B9809@dorvalmatrox.matrox.com>

Yes you're right! 
 
I missed the minus before the 10 before the second example and got confused!
 
Thanks


  _____  

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Monday, November 10, 2008 9:24 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Open RTSP FAQ



While reviewing the FAQ for OpenRTSP I think I found a typo.

 

In section: "Playing without receiving" I read

 

For example, if the SDP description contains "a=range:npt=0-25", then "-d
10" means "play the stream(s) for 10 seconds, then exit", and "-d -10" means
"play the stream(s) for 35 seconds, then exit".


No - this is correct.  Read the openRTSP documentation
<http://www.live555.com/openRTSP/#playing-time> 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/20081111/5e4abb4f/attachment.html>

From finlayson at live555.com  Tue Nov 11 06:32:18 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 11 Nov 2008 06:32:18 -0800
Subject: [Live-devel] bug in BasicTaskScheduler.cpp ?
In-Reply-To: <49195BCE.1080700@totalwire.it>
References: <49187327.4070903@totalwire.it>
	<f06240802c53e7acc32ad@[66.80.62.44]>	<4919470A.7060608@totalwire.it>
	<f06240809c53efc2b7b1d@[66.80.62.44]> <49195BCE.1080700@totalwire.it>
Message-ID: <f0624080dc53f4511d7cb@[66.80.62.44]>

>>That doesn't matter, because *TCP* packets will still be arriving 
>>(on the TCP socket), and will be handled.  This is a Red Herring.
>No, that TCP socket has been closed - and the corresponding socket 
>ID refers occasionally to an UDP socket within the same call to 
>SingleStep - if it was a red herring the TaskScheduler was not going 
>to be stuck. That's a fact, not an argument. I have debugged a real 
>problem, not imagined one.

I have no doubt that your problem is real.  However, your proposed 
solution - messing with the "BasicTaskScheduler" code - appears to be 
merely masking your real problem: That incorrect socket numbers are 
getting passed to the call to "select()" in the event loop.

You should make sure that 
"TaskScheduler::turnOffBackgroundReadHandling()" gets called on each 
socket once it's no longer being used (before its number gets 
reclaimed for another socket).  There's apparently something about 
your custom code that is causing that not to happen for some sockets.
-- 

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

From s.boschi at totalwire.it  Wed Nov 12 00:22:44 2008
From: s.boschi at totalwire.it (Sigismondo Boschi)
Date: Wed, 12 Nov 2008 09:22:44 +0100
Subject: [Live-devel] bug in BasicTaskScheduler.cpp ?
In-Reply-To: <f0624080dc53f4511d7cb@[66.80.62.44]>
References: <49187327.4070903@totalwire.it>	<f06240802c53e7acc32ad@[66.80.62.44]>	<4919470A.7060608@totalwire.it>	<f06240809c53efc2b7b1d@[66.80.62.44]>
	<49195BCE.1080700@totalwire.it>
	<f0624080dc53f4511d7cb@[66.80.62.44]>
Message-ID: <491A9254.1060201@totalwire.it>

Ross Finlayson wrote:

> I have no doubt that your problem is real.  However, your proposed 
> solution - messing with the "BasicTaskScheduler" code - appears to be 
> merely masking your real problem: That incorrect socket numbers are 
> getting passed to the call to "select()" in the event loop.
Ross, I have solved the problem, I have mastered it. I know that the
socket number is invalid, and it is invalid because of SingleStep
behavior with my callback performing a reconnection.

Now you have 2 options:

1. It is allowed to make a restart (close the sockets and reopen new
ones) in one single step - and then SingleStep is bugged - or
2. this option is neglected: it is mandatory to close the connection in
one event, so that SingleStep will not call any wrong handler, and then
reopen in a second one, event-driven by the first. In such a case
SingleStep works correctly - I have choosen this 2nd solution in order 
to avoid to modify BasicTaskScheduler, knowing the problem it was easy 
to find a workaround.

Since that's *your* library it's up to you to choose what. see below.

> 
> You should make sure that 
> "TaskScheduler::turnOffBackgroundReadHandling()" gets called on each 
> socket once it's no longer being used (before its number gets reclaimed 
> for another socket).  There's apparently something about your custom 
> code that is causing that not to happen for some sockets.
I have logged all the TurnOn's, TurnOff's, and selects to find out this
problem. They all are called - but before the end of SingleStep - look,
this is my last attempt to explain it:

void BasicTaskScheduler::SingleStep(unsigned maxDelayTime) {
   fd_set readSet = fReadSet; // make a copy for this select() call
   // this is the origin of the problem: taking a local copy
   // fReadSet contains the 3 socket ids, referring to:
   // TCP, UDP-RCP, UDP-RTCP
   // for example:
   // TCP -> 2000
   // UDP-RCP -> 2100
   // UDP-RTCP -> 2200

   // ... omissis ...

   int selectResult = select(fMaxNumSockets, &readSet, NULL, NULL,
			    &tv_timeToDelay);
   // after the select readSet.fd_count is 1
   // and readSet.fd_array[0] is 2000
   // referring always to the TCP socket in our scenario

   // ... omissis ...

   // my restart callback is called here, scheduled by a bye handler
   fDelayQueue.handleAlarm();
   // all the 3 sockets defined before are correctly closed
   // and 3 new ones are opened.
   // They are registered in fReadSet / fReadHandlers
   // but we are here again:
   // the local variable readSet refers to the old selected socket ID.
   // so if handleAlarm change the connections, the following of
   // this routine is going to be based on outdated data.
   // This is not consistent: That's why I suggested to move this call to
   // the end.
   // When the socket ID in readSet is reused by the OS for an UDP
   // socket, the scheduler stop looping.
   // for example, it has happened that after the call:
   // TCP -> 2500
   // UDP-RCP -> 2000
   // UDP-RTCP -> 2600

   HandlerIterator iter(*fReadHandlers);
   HandlerDescriptor* handler;

   // ... omissis ...
   // (the trick with fLastHandledSocketNum does not interfere at all)

   // the 3 handlers being scanned are the NEW ones,
   // but one of them have colliding socket id (2000) with the old one.
   while ((handler = iter.next()) != NULL) {	
     if (FD_ISSET(handler->socketNum, &readSet) &&
        // TRUE for socket 2000, it is the only one in the old readSet
        // this is senseless because of the reconnetion
        // 2000 is not the tcp socket id anymore, it is a new udp socket
        // where no packets will arrive
        FD_ISSET(handler->socketNum, &fReadSet) &&
        // TRUE for socket 2000 on the fReadSet,
        // it is one of the 3 new ones
        handler->handlerProc != NULL) {
        // TRUE since it points to the newly set UDP handler

        // ... omissis ...
        // now call the UDP handler on the oldly selected socket 2000
        // but nothing incoming in UDP,
        // so it got stuck in the select inside it.
       (*handler->handlerProc)(handler->clientData, SOCKET_READABLE);
       break;
     }
   }
}

I can not be clearer than this.
If you are still on your position, that's not a problem - really - I 
just tried to give a contribution... but this now is going to be 
overkilling.

Thanks again for your great work with the live555.

Regards,
    Sigismondo
-- 
------------------------------------------------------------------
Sigismondo Boschi, PhD                     TotalWire S.r.l.
s.boschi at totalwire.it                      http://www.totalwire.it
cell: +39 346 7911896                      tel:  +39 051 302696

-------------- next part --------------
A non-text attachment was scrubbed...
Name: s_boschi.vcf
Type: text/x-vcard
Size: 275 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081112/b9fee0c6/attachment-0001.vcf>

From finlayson at live555.com  Wed Nov 12 04:47:23 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 12 Nov 2008 04:47:23 -0800
Subject: [Live-devel] bug in BasicTaskScheduler.cpp ?
In-Reply-To: <491A9254.1060201@totalwire.it>
References: <49187327.4070903@totalwire.it>
	<f06240802c53e7acc32ad@[66.80.62.44]>	<4919470A.7060608@totalwire.it>
	<f06240809c53efc2b7b1d@[66.80.62.44]>	<49195BCE.1080700@totalwire.it>
	<f0624080dc53f4511d7cb@[66.80.62.44]> <491A9254.1060201@totalwire.it>
Message-ID: <f06240804c540775480a0@[66.80.62.44]>

Ahh..., now that you've explained your problem once again, I now 
understand the issue: The alarm handler is (in your case) causing 
"fReadSet" to be modified, so that it no longer accurately reflects 
the set of readable sockets that had been previously passed to 
"select()", and produced (as "readSet") as a result of this 
"select()" call.

We ran into a similar situation a few years ago, when we were calling 
multiple event handlers (in a loop) during each call to 
"SingleStep()" - and that's why we changed the code then to call only 
one event handler at a time from "SingleStep()".

I hadn't anticipated that an alarm handler might also cause a similar 
problem - but in your case, that's wha's happening.

Your proposed solution - moving the call to "handleAlarm()" after the 
call to the event handler - should solve the problem.  This will be 
fixed in the next release of the software.  Thanks for tracking down 
this problem.

-- 

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

From rippeltippel at gmail.com  Wed Nov 12 07:14:45 2008
From: rippeltippel at gmail.com (rippel tippel)
Date: Wed, 12 Nov 2008 15:14:45 +0000
Subject: [Live-devel] Creating new subsessions
Message-ID: <c714baeb0811120714i48328e7y2d51dfc5698f626d@mail.gmail.com>

Hi all,

   I need to create a media subsession which takes RTP packets from an UDP
port and forwards them to a different port.
>From what I saw, I should first subclass OnDemandServerMediaSubsession. Is
that correct?

Actually I don't know how to tell my new class to read data from a UDP port
and to send it "as it is" to another port. I guess I shall use a MediaSink
(or RTPSink) but I am getting quite confused by the huge amount of classes
with almost similar names. Could you please give some hints?

Regards,
   Rippel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081112/dd6a5347/attachment.html>

From rwaters at pelco.com  Wed Nov 12 11:16:32 2008
From: rwaters at pelco.com (Waters, Ralph)
Date: Wed, 12 Nov 2008 11:16:32 -0800
Subject: [Live-devel] How does Live555 determine payload type?
Message-ID: <DD74B0B9B8C5F647844370BBF606F83C01054A93@CA-EVS01.pelco.org>


I am trying to write a generalized video RTSP/RTP front end to a
decoder. It has to decode MJPEG, MPEG4, MEPG2 and H.264. 
I am looking at the source code for all the test programs and see that
they all seem to predetermine their payload type.

Is there a test sample that has the information from the RTSP session,
and then uses it to create the correct sink?
If not, what do I do to determine the stream type?

Thanks, Rusty


- ------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this transmission is legally privileged and confidential, intended only for the use of the individual(s) or entities named above. This email and any files transmitted with it are the property of Pelco. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you receive this communication in error, please notify us immediately by telephone call to +1-559-292-1981 or forward the e-mail to administrator at pelco.com and then permanently delete the e-mail and destroy all soft and hard copies of the message and any attachments. Thank you for your cooperation. 
- ------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081112/fe161b40/attachment.html>

From finlayson at live555.com  Wed Nov 12 11:41:56 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 12 Nov 2008 11:41:56 -0800
Subject: [Live-devel] How does Live555 determine payload type?
In-Reply-To: <DD74B0B9B8C5F647844370BBF606F83C01054A93@CA-EVS01.pelco.org>
References: <DD74B0B9B8C5F647844370BBF606F83C01054A93@CA-EVS01.pelco.org>
Message-ID: <f06240808c540e16215ef@[66.80.62.44]>

>I am trying to write a generalized video RTSP/RTP front end to a 
>decoder. It has to decode MJPEG, MPEG4, MEPG2 and H.264.
>
>I am looking at the source code for all the test programs and see 
>that they all seem to predetermine their payload type.
>
>Is there a test sample that has the information from the RTSP 
>session, and then uses it to create the correct sink?

Look at the code for our "openRTSP" RTSP/RTP client - in particular, 
"playCommon.cpp".  Note how it uses the SDP description (returned in 
response to the RTSP "DESCRIBE" request) to create the "MediaSession" 
object for the stream.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081112/f17434ff/attachment.html>

From erik.van.dort at bluewin.ch  Wed Nov 12 14:32:22 2008
From: erik.van.dort at bluewin.ch (Erik van Dort)
Date: Wed, 12 Nov 2008 23:32:22 +0100
Subject: [Live-devel] rtsp session via Internet - NAT problem
Message-ID: <491B5976.502@bluewin.ch>

Hi,

My system consists of three nodes at different locations on the Internet:

IP-camera <---> LAN1 <---> ADSL-router/firewall/NAT-1 <---> INTERNET

VLC Server <---> LAN2 <---> ADSL-router/firewall/NAT-2 <---> INTERNET

VLC Client <---> LAN3 <---> ADSL-router/firewall/NAT-3 <---> INTERNET

The VLC Server connects to the IP camera using the following command:
vlc -I dummy -vvv rtsp://xxxx.dyndns.org:554/mpeg4/media.amp --sout
"#rtp{sdp=rtsp://:8081/test.sdp}"

This works fine. The rtsp session setup shows a.o. the following:

Sending request: SETUP rtsp://xxxx.dyndns.org:554/mpeg4/media.amp/trackID=1
RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=61954-61955
User-Agent: openRTSP (LIVE555 Streaming Media v2007.12.06)

Received SETUP response: RTSP/1.0 200 OK
CSeq: 3
Session: 0700422311;timeout=60
Transport:
RTP/AVP;unicast;client_port=61954-61955;server_port=50018-50019;ssrc=3CFA4EEC;mode="PLAY"



As the next step, I connect the VLC client to the VLC server by opening
the following network stream in a VLC player:
rtsp://yyyy.dyndns.org:8081/test.sdp

This does not work. Testing the session setup to the VLC Server with the
openRTSP tool shows the following:

Sending request: SETUP
rtsp://yyyy.dyndns.org:8081/test.sdp/trackID=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=1232-1233
User-Agent: openRTSP (LIVE555 Streaming Media v2008.11.04)

Received SETUP response: RTSP/1.0 200 OK
Transport: RTP/AVP/UDP;client_port=1232-1233
Server: VLC Server
Content-Length: 0
Cseq: 3
Cache-Control: no-cache
Session: 101027544



Comparing the session setup between the IP camera and the VLC server on
one hand, and the VLC Server and VLC client on the other hand, I see one
major difference:
IP-camera <---> VLC Server: as a response to the SETUP request both the
client_port range and the server_port range are communicated.
VLC Server <---> VLC Client: as a response to the SETUP request only the
client_port range is communicated.

NAT devices interpet SETUP request/response packets in order to build
dynamic NAT rules. As a consequence:
1) once the IP-camera starts streaming UDP packets to the VLC Server,
the NAT device at the VLC Server location knows that incoming UDP
packets with source ports 50018-50019 need to be forwarded to ports
61954-61955 of the VLC Server host, because this information was
communicated in the SETUP response.
2) after the VLC client has established an rtsp session with the VLC
Server, it starts waiting for UDP packets. But the NAT device at the VLC
Client location does not know with which source ports these UDP packets
will be coming in, because the server_port range has not been
communicated. Therefore, the NAT device at the Client location will
discard the UDP packets that are sent by the VLC server, and the VLC
Client ends up with a message like "no data received for over 10
seconds", eventually ending up with "nothing to play".

Note that this system works properly if all nodes are located within the
same LAN (no NAT devices involved).

Does anybody know if there is a way to get the server_port range being
communicated in a rtsp session setup?

Cheers........
Erik

-- 
EvD




From finlayson at live555.com  Wed Nov 12 17:57:18 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 12 Nov 2008 17:57:18 -0800
Subject: [Live-devel] rtsp session via Internet - NAT problem
In-Reply-To: <491B5976.502@bluewin.ch>
References: <491B5976.502@bluewin.ch>
Message-ID: <f06240800c54139c0ff20@[66.80.62.44]>

In general, right now, you can't expect RTSP/RTP to work over NAT. 
That is especially true if the RTSP server is behind a NAT.
-- 

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

From edward at v-ecom.com  Wed Nov 12 22:25:56 2008
From: edward at v-ecom.com (Edward)
Date: Thu, 13 Nov 2008 14:25:56 +0800
Subject: [Live-devel] cross compiling for mips
Message-ID: <491BC874.3050004@v-ecom.com>

Hi,


 I downloaded the latest source code of live555 and created a new 
config.mips file to geneate the Makefiles. But when I compiled it, it 
fails when it reaches the ld command.


From finlayson at live555.com  Wed Nov 12 22:44:10 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 12 Nov 2008 22:44:10 -0800
Subject: [Live-devel] cross compiling for mips
In-Reply-To: <491BC874.3050004@v-ecom.com>
References: <491BC874.3050004@v-ecom.com>
Message-ID: <f06240804c5417c697016@[66.80.62.44]>

>I downloaded the latest source code of live555 and created a new 
>config.mips file to geneate the Makefiles. But when I compiled it, 
>it fails when it reaches the ld command.

Well then I guess you'll need to modify your "config.mips" command 
until it works properly.  Only you know the details of your 
cross-compilation environment, so you're going to have to figure this 
out for yourself.
-- 

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

From amadorim at vdavda.com  Wed Nov 12 23:47:16 2008
From: amadorim at vdavda.com (Marco Amadori)
Date: Thu, 13 Nov 2008 08:47:16 +0100
Subject: [Live-devel] cross compiling for mips
In-Reply-To: <f06240804c5417c697016@[66.80.62.44]>
References: <491BC874.3050004@v-ecom.com> <f06240804c5417c697016@[66.80.62.44]>
Message-ID: <200811130847.17219.amadorim@vdavda.com>

On Thursday 13 November 2008, 07:44:10, Ross Finlayson wrote:

> >I downloaded the latest source code of live555 and created a new
> >config.mips file to geneate the Makefiles. But when I compiled it,
> >it fails when it reaches the ld command.
>
> Well then I guess you'll need to modify your "config.mips" command
> until it works properly.  Only you know the details of your
> cross-compilation environment, so you're going to have to figure this
> out for yourself.

I usually manually sync latest live555 code with the debian unstable package 
and build and cross build with debian tools without problems, maybe you could 
try that way (or just look at debian-embedded, aka emdebian, tools and the 
debian/rules file of the source package).

-- 
ESC:wq

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From weglanz12 at yahoo.com  Wed Nov 12 23:52:39 2008
From: weglanz12 at yahoo.com (Horst Weglanz)
Date: Wed, 12 Nov 2008 23:52:39 -0800 (PST)
Subject: [Live-devel] doGetNextFrame() timing in mpeg2ts context
Message-ID: <130306.412.qm@web45806.mail.sp1.yahoo.com>

Hello

I have a question regarding whether I use liveMedia or mpeg2ts correctly or not. I want to mux video frames to mpeg2ts, since I needed another interface than the once already included, I build my own *MySource* derived from *FramedSource*. In there is the appropriate *doGetNextFrame()* method to process a new frame - this is already working, but I was wondering whether or not correctly. In there I do something like:

| if ( isFrameAvailable() )
| {
|    processFrame();
| }
| else
| {
|    usleep(10);
|    nextTask() = envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afterGetting, this);
| }

So even if no data is available at the moment the new *afterGetting(this)* task is scheduled (same thing happens in *processFrame()*) and I've noticed that mpeg2ts frames are written to the output even if no data is coming in. Is this correctly? Does an mpeg2ts stream need some sort of null-frames to keep up some sort of clock cycle? And I was wondering about the sleep I put in there since I've seen it in some example. Does the scheduler call *doGetNextFrame()* according to the desired frames per second or instantly when he has finished this task and there is a new one waiting (like always when going through this method). Which means every time *doNextFrame()* is called regardless of data is available or not at least one mpeg2ts frame is created and (if this is called independent of the FPS rate) the amount of null frames depends on the amount of time I sleep in this function? Or is the concept of null frames total incorrect and I'm doing something wrong
 here?

Hope someone can shed a bit of light on this, since I haven't found any answers on this, thank you very much.
HW



      


From finlayson at live555.com  Thu Nov 13 00:22:24 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 13 Nov 2008 00:22:24 -0800
Subject: [Live-devel] doGetNextFrame() timing in mpeg2ts context
In-Reply-To: <130306.412.qm@web45806.mail.sp1.yahoo.com>
References: <130306.412.qm@web45806.mail.sp1.yahoo.com>
Message-ID: <f06240805c5419221870d@[66.80.62.44]>

>| if ( isFrameAvailable() )
>| {
>|    processFrame();
>| }
>| else
>| {
>|    usleep(10);
>|    nextTask() = 
>envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afterGetting, 
>this);
>| }

The big problem with this code is that if "isFrameAvailable()" 
returns False, then you end up returning control to the downstream 
object (by arranging for "FramedSource::afterGetting"  to be called). 
This is wrong - you should do that only after you've successfully 
copied data to the downstream object.

If no data is immediately available, you should instead arrange to 
call *this same* code again, *not* "FramedSource::afterGetting".

Also, calling "usleep()" is bad, because that will block the code. 
Instead, to delay, it's better to include the delay period - instead 
of 0 - in the call to "scheduleDelayedTask()".  That way, you'll 
return control to the event loop, rather than blocking.

Finally, to create a Transport Stream (multiplexed from separate data 
sources), be sure to use the "MPEG2TransportStreamMultiplexor" class. 
For an example of how to use this, see the "wis-streamer" code: 
http://www.live555.com/wis-streamer/
-- 

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

From edward at v-ecom.com  Thu Nov 13 00:25:23 2008
From: edward at v-ecom.com (Edward)
Date: Thu, 13 Nov 2008 16:25:23 +0800
Subject: [Live-devel] cross compiling for mips
In-Reply-To: <f06240804c5417c697016@[66.80.62.44]>
References: <f06240804c5417c697016@[66.80.62.44]>
Message-ID: <491BE473.6040602@v-ecom.com>

Here is the config I am using.


CROSS_COMPILE=          mipsel-linux-
COMPILE_OPTS =          $(INCLUDES) -I. -O2 -DSOCKLEN_T=socklen_t 
-DNO_STRSTREAM=1 -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64q
C =                     c
C_COMPILER =            $(CROSS_COMPILE)gcc
C_FLAGS =               $(COMPILE_OPTS)
CPP =                   cpp
CPLUSPLUS_COMPILER =    $(CROSS_COMPILE)g++
CPLUSPLUS_FLAGS =       $(COMPILE_OPTS) -Wall -DBSD=1
OBJ =                   o
LINK =                  $(CROSS_COMPILE)g++ -o
LINK_OPTS =             -L. -u
CONSOLE_LINK_OPTS =     $(LINK_OPTS)
LIBRARY_LINK =          $(CROSS_COMPILE)ld -o
LIBRARY_LINK_OPTS =     $(LINK_OPTS) -r -Bstatic
LIB_SUFFIX =                    a
LIBS_FOR_CONSOLE_APPLICATION =
LIBS_FOR_GUI_APPLICATION =
EXE =


Here is the error I get when compiling:


mipsel-linux-ld -olibgroupsock.a -L. -u -r -Bstatic \
                GroupsockHelper.o GroupEId.o inet.o Groupsock.o 
NetInterface.o NetAddress.o IOHandlers.o
mipsel-linux-ld: warning: cannot find entry symbol __start; defaulting 
to 00000000004000b0
GroupsockHelper.o: In function `makeSocketNonBlocking(int)':
GroupsockHelper.cpp:(.text+0x9c): undefined reference to `fcntl64'
GroupsockHelper.cpp:(.text+0xb8): undefined reference to `fcntl64'


From sebastien-devel at celeos.eu  Thu Nov 13 01:01:45 2008
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Thu, 13 Nov 2008 10:01:45 +0100
Subject: [Live-devel] Bug / patch in parseRTSPRequestString
Message-ID: <1226566905.491becf9c8c35@imp.celeos.eu>



Hi

I had a segfault in parseRTSPRequestString. To see gdb details, please go te the
end of the mail.

I looked into the code, and here is some comments :

- The following line appears to be useless, as j is set to i+1 next line :
  while (j < reqStrSize && (reqStr[j] == ' ' || reqStr[j] == '\t')) ++j; // skip
over any additional white space
  for (j = i+1; (int)j < (int)(reqStrSize-8); ++j) {

- My bug was because here, and I think k1 was 0 in my case
// Also look for the URL 'pre-suffix' before this:
unsigned k3 = --k1;

So why not adding a check like :
unsigned k3=0;
if( k1 > 0)
 k3 = --k1;

Regards.


gdb told me this :

#0  0xb5bfdb02 in parseRTSPRequestString (
    reqStr=0x844c050 " rvr l ..-i\rDt:Wd 2Nv20 62:2 M\rSsin
5764e5d6\nCnetLnt:0\nah-oto:n-ach\rCe:26\n\n", reqStrSize=167,
    resultCmdName=0xb28f404c "/1.0 200OK\r\nSee:vc100gt\nae e,1 o
081:45GT\neso:a4d4ffdb\rotn-egh \rCceCnrl oce\nsq 8\r\r",
resultCmdNameMaxSize=100,
    resultURLPreSuffix=0xb28f3fe8 "cam2", resultURLPreSuffixMaxSize=100,
    resultURLSuffix=0xb28f3f84 "rvr l ..-i\rDt:Wd 2Nv20 62:2 M\rSsin
5764e5d6\nCnetLnt:0\nah-oto:n-ach\rCe:26\n\n", resultURLSuffixMaxSize=100,
    resultCSeq=0xb28f3f20 "&#65533;\f\036\b$\005", resultCSeqMaxSize=100)
    at RTSPCommon.cpp:100

(gdb) x/167c reqStr
0x844c050:	32 ' '	114 'r'	118 'v'	114 'r'	32 ' '	108 'l'	32 ' '	46 '.'
0x844c058:	46 '.'	45 '-'	105 'i'	13 '\r'	68 'D'	116 't'	58 ':'	87 'W'
0x844c060:	100 'd'	32 ' '	50 '2'	78 'N'	118 'v'	50 '2'	48 '0'	32 ' '
0x844c068:	54 '6'	50 '2'	58 ':'	50 '2'	32 ' '	77 'M'	13 '\r'	83 'S'
0x844c070:	115 's'	105 'i'	110 'n'	32 ' '	53 '5'	55 '7'	54 '6'	52 '4'
0x844c078:	101 'e'	53 '5'	100 'd'	54 '6'	10 '\n'	67 'C'	110 'n'	101 'e'
0x844c080:	116 't'	76 'L'	110 'n'	116 't'	58 ':'	48 '0'	10 '\n'	97 'a'
0x844c088:	104 'h'	45 '-'	111 'o'	116 't'	111 'o'	58 ':'	110 'n'	45 '-'
0x844c090:	97 'a'	99 'c'	104 'h'	13 '\r'	67 'C'	101 'e'	58 ':'	50 '2'
0x844c098:	54 '6'	10 '\n'	10 '\n'	0 '\0'	32 ' '	56 '8'	13 '\r'	13 '\r'
0x844c0a0:	10 '\n'	82 'R'	84 'T'	83 'S'	80 'P'	47 '/'	49 '1'	46 '.'
0x844c0a8:	48 '0'	32 ' '	50 '2'	48 '0'	48 '0'	79 'O'	75 'K'	13 '\r'
0x844c0b0:	10 '\n'	83 'S'	101 'e'	101 'e'	58 ':'	118 'v'	99 'c'	49 '1'
0x844c0b8:	48 '0'	48 '0'	103 'g'	116 't'	10 '\n'	97 'a'	101 'e'	32 ' '
0x844c0c0:	101 'e'	44 ','	49 '1'	32 ' '	111 'o'	32 ' '	48 '0'	56 '8'
0x844c0c8:	49 '1'	58 ':'	52 '4'	53 '5'	71 'G'	84 'T'	10 '\n'	101 'e'
0x844c0d0:	115 's'	111 'o'	58 ':'	97 'a'	52 '4'	100 'd'	52 '4'	102 'f'
0x844c0d8:	102 'f'	100 'd'	98 'b'	13 '\r'	111 'o'	116 't'	110 'n'	45 '-'
0x844c0e0:	101 'e'	103 'g'	104 'h'	32 ' '	13 '\r'	67 'C'	99 'c'	101 'e'
0x844c0e8:	67 'C'	110 'n'	114 'r'	108 'l'	32 ' '	111 'o'	99 'c'	101 'e'
0x844c0f0:	10 '\n'	115 's'	113 'q'	32 ' '	56 '8'	13 '\r'	13 '\r'

So reqStr had to be : " rvr l ..-i\rDt:Wd 2Nv20 62:2 M\rSsin
5764e5d6\nCnetLnt:0\nah-oto:n-ach\rCe:26\n\n\0 8\r\r\nRTSP/1.0
200OK\r\nSee:vc100gt\nae e,1 o 081:45GT\neso:a4d4ffdb\rotn-egh \rCceCnrl
oce\nsq 8\r\r"


From amadorim at vdavda.com  Thu Nov 13 00:56:27 2008
From: amadorim at vdavda.com (Marco Amadori)
Date: Thu, 13 Nov 2008 09:56:27 +0100
Subject: [Live-devel] cross compiling for mips
In-Reply-To: <491BE473.6040602@v-ecom.com>
References: <f06240804c5417c697016@[66.80.62.44]> <491BE473.6040602@v-ecom.com>
Message-ID: <200811130956.27813.amadorim@vdavda.com>

On Thursday 13 November 2008, 09:25:23, Edward wrote:

> Here is the config I am using.

> CROSS_COMPILE=          mipsel-linux-
> COMPILE_OPTS =          $(INCLUDES) -I. -O2 -DSOCKLEN_T=socklen_t
> -DNO_STRSTREAM=1 -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64q
> C =                     c
> C_COMPILER =            $(CROSS_COMPILE)gcc
> C_FLAGS =               $(COMPILE_OPTS)
> CPP =                   cpp
> CPLUSPLUS_COMPILER =    $(CROSS_COMPILE)g++
> CPLUSPLUS_FLAGS =       $(COMPILE_OPTS) -Wall -DBSD=1
> OBJ =                   o
> LINK =                  $(CROSS_COMPILE)g++ -o
> LINK_OPTS =             -L. -u
> CONSOLE_LINK_OPTS =     $(LINK_OPTS)
> LIBRARY_LINK =          $(CROSS_COMPILE)ld -o
> LIBRARY_LINK_OPTS =     $(LINK_OPTS) -r -Bstatic
> LIB_SUFFIX =                    a
> LIBS_FOR_CONSOLE_APPLICATION =
> LIBS_FOR_GUI_APPLICATION =
> EXE =

I see no reference to toolchain paths, happy hacking!

-- 
ESC:wq

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From sebastien-devel at celeos.eu  Thu Nov 13 01:12:30 2008
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Thu, 13 Nov 2008 10:12:30 +0100
Subject: [Live-devel] Bug / patch in parseRTSPRequestString
In-Reply-To: <1226566905.491becf9c8c35@imp.celeos.eu>
References: <1226566905.491becf9c8c35@imp.celeos.eu>
Message-ID: <1226567550.491bef7e6a59b@imp.celeos.eu>

Sorry, I forgot to show you this from gdb, which confirm k1 was probably 0.

(gdb) p k
$4 = 80
(gdb) p k1
$5 = 4294967295
(gdb) p k2
$6 = 4294967281
(gdb) p k3
$7 = <value optimized out>
(gdb) p n
$8 = 4120
(gdb) p reqStrSize
$9 = 167


From finlayson at live555.com  Thu Nov 13 01:31:21 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 13 Nov 2008 01:31:21 -0800
Subject: [Live-devel] Bug / patch in parseRTSPRequestString
In-Reply-To: <1226566905.491becf9c8c35@imp.celeos.eu>
References: <1226566905.491becf9c8c35@imp.celeos.eu>
Message-ID: <f06240806c541a3ccab12@[66.80.62.44]>

>I looked into the code, and here is some comments :
>
>- The following line appears to be useless, as j is set to i+1 next line :
>   while (j < reqStrSize && (reqStr[j] == ' ' || reqStr[j] == '\t')) 
>++j; // skip
>over any additional white space
>   for (j = i+1; (int)j < (int)(reqStrSize-8); ++j) {

Yes.  The "for" statement should have been:
	for (; (int)j < (int)(reqStrSize-8); ++j) {


>- My bug was because here, and I think k1 was 0 in my case
>// Also look for the URL 'pre-suffix' before this:
>unsigned k3 = --k1;
>
>So why not adding a check like :
>unsigned k3=0;
>if( k1 > 0)
>  k3 = --k1;

Thanks, yes.  I have now released a new version (2008.11.13) of the 
code that fixes this problem.  Please let me know if this works OK 
for you now.

(Note, though, that you happened to run into this bug because your 
RTSP request string was badly misformed/noncompliant.)
-- 

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

From sebastien-devel at celeos.eu  Thu Nov 13 04:54:52 2008
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Thu, 13 Nov 2008 13:54:52 +0100
Subject: [Live-devel] Bug / patch in parseRTSPRequestString
In-Reply-To: <f06240806c541a3ccab12@[66.80.62.44]>
References: <1226566905.491becf9c8c35@imp.celeos.eu>
	<f06240806c541a3ccab12@[66.80.62.44]>
Message-ID: <1226580892.491c239c922f2@imp.celeos.eu>

Quoting Ross Finlayson <finlayson at live555.com>:

> Thanks, yes.  I have now released a new version (2008.11.13) of the
> code that fixes this problem.  Please let me know if this works OK
> for you now.

Thank you.
I can't tell you for sure, because I don't know how to reproduce this. But if
this happens again, I'll let you know.

> (Note, though, that you happened to run into this bug because your
> RTSP request string was badly misformed/noncompliant.)

Right. I was just playing with vlc, but I don't know how to do it again. I will
try to find out.

Thanks for the quick answer.


From weglanz12 at yahoo.com  Thu Nov 13 06:03:49 2008
From: weglanz12 at yahoo.com (Horst Weglanz)
Date: Thu, 13 Nov 2008 06:03:49 -0800 (PST)
Subject: [Live-devel] doGetNextFrame() timing in mpeg2ts context
References: <130306.412.qm@web45806.mail.sp1.yahoo.com>
	<f06240805c5419221870d@[66.80.62.44]>
Message-ID: <229525.36025.qm@web45809.mail.sp1.yahoo.com>

Thank you very much,

the clue not to schedule a call to *afterGetting()* solved also another bug which I didn't at all correlate to that issue. But when calling doNextFrame() recursively like this:

| if ( isFrameAvailable() )
| {
|    processFrame();
| }
| else
| {
|    usleep(10);
|    doNextFrame();
| }

means it would also block for so long till isFrameAvailable()==true? Which means without the recursive impact on the stack equals this:

| while( !isFrameAvailable() )
| {
|    usleep(10);
| }
| processFrame();

Is there maybe a way to directly schedule a call to *doGetNextFrame()* in the event loop since this is not a static function or what would be the alternative - if I shouldn't block the event loop with usleep but also call *doNextFrame()* when no data is available? Is there another static exit-point to call *doNextFrame()* and enter into the event loop when no data is available?

So something like this, but on a member function and not a static one?
| if ( isFrameAvailable() )
| {
|    processFrame();
| }
| else
| {
|    nextTask() = envir().taskScheduler().scheduleDelayedTask(10,(TaskFunc*)MySource::doGetNextFrame, NULL);
| }

thank you,
HW



----- Original Message ----
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com>
Sent: Thursday, November 13, 2008 9:22:24 AM
Subject: Re: [Live-devel] doGetNextFrame() timing in mpeg2ts context

> | if ( isFrameAvailable() )
> | {
> |    processFrame();
> | }
> | else
> | {
> |    usleep(10);
> |    nextTask() = envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afterGetting, this);
> | }

The big problem with this code is that if "isFrameAvailable()" returns False, then you end up returning control to the downstream object (by arranging for "FramedSource::afterGetting"  to be called). This is wrong - you should do that only after you've successfully copied data to the downstream object.

If no data is immediately available, you should instead arrange to call *this same* code again, *not* "FramedSource::afterGetting".

Also, calling "usleep()" is bad, because that will block the code. Instead, to delay, it's better to include the delay period - instead of 0 - in the call to "scheduleDelayedTask()".  That way, you'll return control to the event loop, rather than blocking.

Finally, to create a Transport Stream (multiplexed from separate data sources), be sure to use the "MPEG2TransportStreamMultiplexor" class. For an example of how to use this, see the "wis-streamer" code: http://www.live555.com/wis-streamer/



      


From finlayson at live555.com  Thu Nov 13 10:13:20 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 13 Nov 2008 10:13:20 -0800
Subject: [Live-devel] doGetNextFrame() timing in mpeg2ts context
In-Reply-To: <229525.36025.qm@web45809.mail.sp1.yahoo.com>
References: <130306.412.qm@web45806.mail.sp1.yahoo.com>
	<f06240805c5419221870d@[66.80.62.44]>
	<229525.36025.qm@web45809.mail.sp1.yahoo.com>
Message-ID: <f06240807c5421e45d0cf@[66.80.62.44]>

>Is there maybe a way to directly schedule a call to 
>*doGetNextFrame()* in the event loop since this is not a static 
>function or what would be the alternative

The alternative is to write a static member function that then calls 
"doGetNextFrame()", and have "scheduleDelayedTask()" arrange to call 
the static member function.  There are several examples of this in 
the code already.

Also, as I noted last time, you should not call "usleep(10)"; 
instead, pass 10 as the (delay) parameter to "scheduleDelayedTask()".

From paul at packetship.com  Fri Nov 14 06:21:54 2008
From: paul at packetship.com (Paul Clark)
Date: Fri, 14 Nov 2008 14:21:54 +0000
Subject: [Live-devel] RTSPClient does not accept folded headers
Message-ID: <491D8982.1040700@packetship.com>

Hi,

It seems that the RTSPClient doesn't accept folded headers from the 
server, at least for OPTIONS responses and possibly other requests as 
well.  The relevant code is around RTSPClient.cpp:586:

    // Look for a "Public:" header (which will contain our result str):
    char* lineStart;
    while (1) {
      lineStart = nextLineStart;
      if (lineStart == NULL) break;

      nextLineStart = getLine(lineStart);

      if (_strncasecmp(lineStart, "Public: ", 8) == 0) {
    delete[] result; result = strDup(&lineStart[8]);
#ifdef SUPPORT_REAL_RTSP
      } else if (_strncasecmp(lineStart, "RealChallenge1: ", 16) == 0) {
    delete[] fRealChallengeStr; fRealChallengeStr = strDup(&lineStart[16]);
#endif
      }
    }

This just looks for a line beginning "Public: " without worrying whether 
a subsequent line is a header fold beginning with whitespace.  This is 
allowed in the RFC 2326 grammar (check out token 'LWS'), which it 
inherits from HTTP and SMTP.

We've tripped over this because VLC now uses the present of 
GET_PARAMETER in the OPTIONS response to determine whether to send 
GET_PARAMETER 'keepalives', which our server requires.  The OPTIONS 
request/response is as follows:

---
Sending request: OPTIONS rtsp://barque/testcard RTSP/1.0
CSeq: 29
User-Agent: VLC media player (LIVE555 Streaming Media v2008.07.24)

Received OPTIONS response: RTSP/1.0 200 OK
CSeq: 29
Server: Packet Ship RTSP Server v2.3.0
Date: Fri, Nov 14 2008 14:11:35 GMT
Public: OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN,
  GET_PARAMETER, SET_PARAMETER
---

Because the GET_PARAMETER has been (correctly) folded to the next line, 
it isn't picked up by VLC and hence no keepalive is sent.

We can (and have) worked round this by putting GET_PARAMETER at the 
front of the OPTIONS list, but I thought I should point this out as a 
protocol issue in the library.

Many thanks

Paul
--
Paul Clark
Packet Ship Technologies Limited
http://www.packetship.com


From weglanz12 at yahoo.com  Fri Nov 14 06:47:28 2008
From: weglanz12 at yahoo.com (Horst Weglanz)
Date: Fri, 14 Nov 2008 06:47:28 -0800 (PST)
Subject: [Live-devel] doGetNextFrame() timing in mpeg2ts context
References: <130306.412.qm@web45806.mail.sp1.yahoo.com>
	<f06240805c5419221870d@[66.80.62.44]>
	<229525.36025.qm@web45809.mail.sp1.yahoo.com>
	<f06240807c5421e45d0cf@[66.80.62.44]>
Message-ID: <832426.38639.qm@web45816.mail.sp1.yahoo.com>

Thank you,

I added a static hook to schedule another *doGetNextFrame()* call and it's working as expected. Except for one thing which seems to be an issue with my usage of the TaskScheduler. I added a ByteStreamFileSource to the output video and the funny thing is: scheduled events from the ByteStreamFileSource immediately stop being executed when the first data is available in MySource. These are different objects and in in MySource I do the following:

every time data available:
    nextTask() = envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afterGetting, this);
every time no data available:
    nextTask() = envir().taskScheduler().scheduleDelayedTask(100,(TaskFunc*)MySource::doGetNextFrameStatic, this);


and in the ByteStreamFileSource there is also this frequent call:
    nextTask() = envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afterGetting, this);

Both sources do work alone and there is nothing wrong with the FileSource, the problems occurs only when two video sources being read in parallel. When I start my application usually data in MySource isn't instantly available so every time there is *no data*  -> so it schedules doGetNextFrameStatic(). At the same time data from the ByteFileSource is being read. After it has read it's frame, it schedules the next frame to *FramedSource::afterGetting(this)* which is being called. The problems occurs the moment data in MySource is available and this object also schedules a call to *FramedSource::afterGetting(this)* -- it seams it somehow overwrites the call from ByteStreamFileSource to read the next frame; of course the function pointer is probably the same but the *this* parameter is different and *nextTask()* should point to a different TaskToken since they are both different objects. 

What is going wrong here? Do I have to handle things differently when adding multiple video streams or where lies my mistake?

Thank you very much,
HW



----- Original Message ----
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com>
Sent: Thursday, November 13, 2008 7:13:20 PM
Subject: Re: [Live-devel] doGetNextFrame() timing in mpeg2ts context

> Is there maybe a way to directly schedule a call to *doGetNextFrame()* in the event loop since this is not a static function or what would be the alternative

The alternative is to write a static member function that then calls "doGetNextFrame()", and have "scheduleDelayedTask()" arrange to call the static member function.  There are several examples of this in the code already.

Also, as I noted last time, you should not call "usleep(10)"; instead, pass 10 as the (delay) parameter to "scheduleDelayedTask()".


      


From gbonneau at matrox.com  Fri Nov 14 09:01:34 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Fri, 14 Nov 2008 12:01:34 -0500
Subject: [Live-devel] VLC Media Player and late Out-Of-Order received
	packets by Live555
Message-ID: <36DFD43814154BB8A00209FBC48EEB29@dorvalmatrox.matrox.com>

While experimented with a Mpeg2 video that I streamed to the internet using
a Live555 sample application from work to home I found that the VLC media
player struggled from time to time to resync the video. This was visible by
some freezing and restarting of the video on the live window displayed by
VLC. But overall the video playing was a very pleasant experience
notwithstanding a resync from time to time. Thanks to the live555 library.
 
>From an academic point of view I was wondering about how much packet was
lost from work to home! How much packets was received out of order and so
on! I was also interesting to study the resync issue and try to correlate
with the packet losses. Thus I decided to use Wireshark to capture many
sessions of the RTP stream and the RTSP session while VLC was playing the
received video.
 
After asking Wireshark to analyze the stream I was dumbfounded looking at
the result. In fact there were no packet losses for those sessions. But
about .05% of packets were delayed by about 150-250 RTP packets. Giving that
I was streaming the video at 1.5 Mbits/Sec I estimated that the delay of
these packets were about 1 to 2 seconds. Which seemed to be a very long
delay. But this is internet.
 
After pondering with the statistic It struck me that the Live555 library set
a constant threshold of reordering packet at 100 and accept a delayed packet
if the sequence number of an out of order packet is greater than this
threshold.
 
I decided to probe the Live555 library in this case to study it behavior.
And this is what happens.
 
Once a late out-of-order packet is received with a seqNoThreshold (100)
condition being True then  the method ReorderingPacketBuffer::storePacket
accept the packet. Note that fNextExpectedSeqNo is not reinitialized at this
point. In most cases storePacket method will redefine fHeadPacket with the
late received out-of-order packet.
 
Thus the following received packets after the received out-of-order packet
will be keep on hold because the method
ReorderingPacketBuffer::getNextCompletedPacket check the condition
fHeadPacket->rtpSeqNo() == fNextExpectedSeqNo. And fHeadPacket is the
out-of-order late received packet. 
 
First glitch:
 
>From this point the only recovering mechanism that will reenable
ReorderingPacketBuffer::getNextCompletedPacket to return packets is the
timeout defined by fThresholdTime. After the timeout period then
fNextExpectedSeqNo is redefined to the sequence number of the late
out-of-order packet.
 
Second glitch:
 
Then ReorderingPacketBuffer::getNextCompletedPacket returns the late
out-of-order packet. But the new redefined fNextExpectedSeqNo to the late
out-of-order packet prevent the "in-order" next received packets from being
returned by ReorderingPacketBuffer::getNextCompletedPacket. From now on the
"in-order" received packets will be keep onhold because the method
ReorderingPacketBuffer::getNextCompletedPacket checks the fNextExpectedSeqNo
that is set to the late out-of-order packet.
 
Again the only recovering mechanism that will reenable
ReorderingPacketBuffer::getNextCompletedPacket to return packets is the
timeout defined by fThresholdTime
 
Thus 2 successives time-out occurs with an in between releases out-of-order
packet. This give an hard time to the application VLC
 
Relinking the VLC application with a new seqNoThreshold set to 300 really
improved the smoothness of the video playback.
 
I understand I could have increased the fThresholdTime to a value of 2-3
seconds to solve the problem. But for the kind of applications I am looking
on this is out of specification.
 
My feeling is that some revisiting to the
ReorderingPacketBuffer::storePacket storing algorithm would improve the
behavior of resync issue when late out-of-order packets are received. I have
2 suggestions.
 
1- I'm not sure why the threshold of 100 was choosen for seqNoThreshold .
There must be an historical issue that I do ignore. But I would suggest to
add an API to let an application be able to change that value the way it is
possible to an application to change fThresholdTime. Then by exposing that
value in an application like VLC it would be possible to fine tune the
application to the internet behavior.
 
2- If a late out-of-order packet is accepted by
ReorderingPacketBuffer::storePacket then fNextExpectedSeqNo could be
reinitialized to the new late out-of-order sequence number thus preventing a
double glitch. Only a single timeout would occur.
 
Regards
Guy Bonneau
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081114/8998f446/attachment.html>

From auto.web at msa.hinet.net  Fri Nov 14 10:49:16 2008
From: auto.web at msa.hinet.net (Kuei-Yi)
Date: Sat, 15 Nov 2008 02:49:16 +0800
Subject: [Live-devel] The address of ptr pointer is different with the
	address of fTo pointer.
Message-ID: <000901c94689$b55e2680$0b00a8c0@Partner>

Hi Ross, and all,

 

   I have a question.

   I take a close look at an example of testMPEG4VideoStreamer program. Its
process is: Upon the completion of doGetNextFrame(), the live555 will call
StreamParser:: afterGettingBytes function. And the live555 can catch
previously frame data and write it into the ptr pointer by "unsigned char *
ptr = & buffer-> curBank () [buffer-> fTotNumValidBytes];" procedure.

   My question is: I am based on testMPEG4VideoStreamer and develop my
application. I have written one DataQueue Class in order to the work of
replacing ByteStreamFileSource Class. It is smooth-going in the course work.
The frame data that it was caught from DataQueue Class are also written into
fTo pointer. But, when the process was upon the completion of
doGetNextFrame() and calling StreamParser:: afterGettingBytes function, and
finish out "unsigned char * ptr = & buffer-> curBank () [buffer->
fTotNumValidBytes];" procedure. The address of ptr pointer is different with
the address of fTo pointer. The reason cause what it is? Which procedure
have I needing to notice?

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

From finlayson at live555.com  Sat Nov 15 01:40:13 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 15 Nov 2008 01:40:13 -0800
Subject: [Live-devel] VLC Media Player and late Out-Of-Order received
 packets by Live555
In-Reply-To: <36DFD43814154BB8A00209FBC48EEB29@dorvalmatrox.matrox.com>
References: <36DFD43814154BB8A00209FBC48EEB29@dorvalmatrox.matrox.com>
Message-ID: <f06240810c54444f6c35b@[66.80.62.44]>

>After asking Wireshark to analyze the stream I was dumbfounded 
>looking at the result. In fact there were no packet losses for those 
>sessions. But about .05% of packets were delayed by about 150-250 
>RTP packets. Giving that I was streaming the video at 1.5 Mbits/Sec 
>I estimated that the delay of these packets were about 1 to 2 
>seconds.

This is insane.  There is something very broken in your network.


>After pondering with the statistic It struck me that the Live555 
>library set a constant threshold of reordering packet at 100 and 
>accept a delayed packet if the sequence number of an out of 
>order packet is greater than this threshold.
>
>I decided to probe the Live555 library in this case to study it 
>behavior. And this is what happens.
>
>Once a late out-of-order packet is received with a seqNoThreshold 
>(100) condition being True then  the method 
>ReorderingPacketBuffer::storePacket accept the packet. Note that 
>fNextExpectedSeqNo is not reinitialized at this point. In most cases 
>storePacket method will redefine fHeadPacket with the late received 
>out-of-order packet.
>
>Thus the following received packets after the received out-of-order 
>packet will be keep on hold because the method 
>ReorderingPacketBuffer::getNextCompletedPacket check the condition 
>fHeadPacket->rtpSeqNo() == fNextExpectedSeqNo. And fHeadPacket is 
>the out-of-order late received packet.

The test against "seqNoThreshold" was intended - long ago - only as a 
sanity check against really messed up streams, and probably never 
actually got satisfied for anyone else, because noone ever had a 
stream as messed up as yours :-)  You're right - it's basically just 
a historical artifact that I had forgotten about.

As you noted, accepting such excessively delayed packets causes 
problems (that I hadn't really anticipated), so because of this, the 
best thing to do would be to just remove this test altogether.  I'll 
make this fix in the next version of the code: From now on, *all* 
out-of-order packets (except those received within "fThresholdTime" 
microseconds) will be discarded.


>I understand I could have increased the fThresholdTime to a value of 
>2-3 seconds to solve the problem. But for the kind of applications I 
>am looking on this is out of specification.

You should really look into why some packets are getting delayed this 
much.  This is far in excess of what people normally see on the 
Internet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081115/b10d5006/attachment.html>

From finlayson at live555.com  Sat Nov 15 09:20:21 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 15 Nov 2008 09:20:21 -0800
Subject: [Live-devel] RTSPClient does not accept folded headers
In-Reply-To: <491D8982.1040700@packetship.com>
References: <491D8982.1040700@packetship.com>
Message-ID: <f06240800c544b4651af3@[66.80.62.44]>

Paul,

This caught me by surprise, because I had never heard of anyone (RTSP 
client or RTSP server) sending headers like this - it's very unusual.

I'll take a look at supporting such headers; however - if you have 
any control over the programming of the server that you use - I 
suggest that you change it to *not* send headers like this.  "Be 
conservative in what you send..."
-- 

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

From paul at packetship.com  Sat Nov 15 09:51:41 2008
From: paul at packetship.com (Paul Clark)
Date: Sat, 15 Nov 2008 17:51:41 +0000
Subject: [Live-devel] RTSPClient does not accept folded headers
In-Reply-To: <f06240800c544b4651af3@[66.80.62.44]>
References: <491D8982.1040700@packetship.com>
	<f06240800c544b4651af3@[66.80.62.44]>
Message-ID: <491F0C2D.4020307@packetship.com>

Ross Finlayson wrote:
> This caught me by surprise, because I had never heard of anyone (RTSP 
> client or RTSP server) sending headers like this - it's very unusual.
>
> I'll take a look at supporting such headers; however - if you have any 
> control over the programming of the server that you use - I suggest 
> that you change it to *not* send headers like this.  "Be conservative 
> in what you send..."

Yes, that's a fair point.  This is indeed our code, and the folding 
actually comes from an internal library of ours which generates and 
parses RFC822-style headers in general (for HTTP and SMTP as well), and 
it folds to avoid exceeding the SMTP line length limit of 72 characters, 
where it is mandatory.  I had forgotten this and was also quite 
surprised to see it folding the Public: header after we added 
GET/SET_PARAMETER to cope with VLC's keepalive change.

As I said, we've worked around this by promoting GET_PARAMETER to the 
front anyway, but you're probably right it would be safer to suppress 
the folding in general if clients aren't expecting it (and many STB 
clients we come across are using Live555, thanks!).

Best regards

Paul
-- 
Paul Clark
Packet Ship Technologies Limited
http://www.packetship.com


From f.podd at bradford.ac.uk  Sun Nov 16 04:05:35 2008
From: f.podd at bradford.ac.uk (Frank Podd)
Date: Sun, 16 Nov 2008 12:05:35 +0000
Subject: [Live-devel] Help MPEG4 streamingwith wait at end of file
Message-ID: <6edbd8e30811160405y41c7a2f4s1224385bb1677e8d@mail.gmail.com>

Hello,
   I'm trying to use the live555 streaming media to stream video that we are
capturing to file from a camera.
The camera encodes (mpeg4) the video and writes it to a file. At the same
time live555 is reading from that file and streaming the video over RTSP.
The problem we are having is that the live555 streamer catches up with the
end of that growing file and then restarts from the beginning of the file.
How can I configure live555 to wait at the end of the file until new frames
arrive?
Many thanks
Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081116/d549766f/attachment.html>

From up2me_gis at hotmail.com  Mon Nov 17 01:40:35 2008
From: up2me_gis at hotmail.com (=?gb2312?B?t+vA2g==?=)
Date: Mon, 17 Nov 2008 17:40:35 +0800
Subject: [Live-devel] live555 for Windows mobile 5
Message-ID: <BAY129-DS505F02706E82F0F212AF6D2130@phx.gbl>

Hi,

   I build live555 libs for windows mobile 5 use vs2005.

   I can compile and deploy openrtsp example in testProg. 
  
   But it can not run correctly in console mode. 

   So I change it to a MFC app for smart device, and call the function.

   The server side, I use testOnDemandRTSPServer.exe, 

and the client side , I try rtsp://192.168.0.128:8554/mp3AudioTest

   The server side seems run correctly and prints lots of message.

   But the client side can't receive media stream data.   
   int readSocket(UsageEnvironment& env,
        int socket, unsigned char* buffer, unsigned bufferSize,
        struct sockaddr_in& fromAddress,
        struct timeval* timeout)
   I set a break point at the function above.

   It can receive some information at the very beginning.But when the server start send stream data,

   it can't hit the break point at all.



   Could anybody tell me, why?
  
   Thanks.


   Feng
   

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

From clhosting at hotmail.com  Mon Nov 17 03:03:19 2008
From: clhosting at hotmail.com (jon chambers)
Date: Mon, 17 Nov 2008 03:03:19 -0800
Subject: [Live-devel] TR: Trick Play support on MPEG 4 Video Streams
In-Reply-To: <f06240803c467e142db88@[66.80.62.44]>
References: <!&!AAAAAAAAAAAYAAAAAAAAAHHvJFuyABZJgquVddWyTGnCgAAAEAAAAN8f3yvBb8pBi49CeO
	aEh6oBAAAAAA==@skynet.be>  <f06240803c467e142db88@[66.80.62.44]>
Message-ID: <BLU149-W29916837F3CAB76BD2063A0130@phx.gbl>


 
 
Hello Ross --
 
I am curious if this has ever been implemented?
 
Trick Play 
MPEG-TS containing H.264
 
I have installed the newest version 2008.11.13.
Seeking does not work for me so I am curious if it has been implemented and I need to check my file or if it has not yet been added.
 
 
Regards,
Jon
 
 
 
 




 
 
 
Date: Sat, 31 May 2008 22:26:33 -0700To: live-devel at ns.live555.comFrom: finlayson at live555.comSubject: Re: [Live-devel] TR: Trick Play support on MPEG 4 Video Streams


Although it does not appear explicitly on your web site, do you support Trick Play on H.264 AVC video streams?

Our RTSP server implementation supports 'trick play' when streaming from some (but not all) types of file.  What type of file are you interested in streaming from?  (Don't say "a H.264 file", because there's no such thing :-)

If you are interested in streaming from a MPEG Transport Stream file whose content is H.264 video (rather than the usual MPEG-2 video), then no, we do not currently support this.  The reason for this is that our 'trick play' (fast forward and reverse play) implementation works by selecting only video 'I-frames' from the Transport Stream file - and this currently assumes that the video is MPEG-2 only.

However, I will shortly be updating our MPEG Transport Stream index file/'trick play' support, so if you have an example of the type of file that you wish to support, then please put it on a web server and send us a link (URL) to it, so we can download it and use it in our testing.-- 

Ross FinlaysonLive Networks, Inc.http://www.live555.com/
_________________________________________________________________
Windows Live Hotmail now works up to 70% faster.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_112008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081117/c177471d/attachment-0001.html>

From matt at schuckmannacres.com  Mon Nov 17 10:12:42 2008
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Mon, 17 Nov 2008 10:12:42 -0800
Subject: [Live-devel] Suggestions on the proper way to deal with frame size
 changes in the middle of H264 stream
Message-ID: <4921B41A.8080203@schuckmannacres.com>

I'm looking for suggestions on the proper way to signal to the client 
that the frame size has changed in an H264 stream.

What I have actually works about %80 of the time.
Here is what I have.

1. Server is encoding camera data in real time using X264 and serving 
the data via Live555 RTSP server based application.
2. I believe I've setup X264 to make all I frames IDR frames (I think 
this means that all I frames will have enough information for the 
decoder to figure out the frame size, etc simply from the stream)
3. Client connects (using Live555 RTSPClient based application) and 
starts to receive the H264 stream.
4. Using FFMPEG the client application is able to start decoding and 
displaying the video.
5. At anytime the client can request that the frame size be changed by 
sending a SET_PARAMETER RTSP command to the server.
6. The server reads the SET_PARAMETER command validates that the 
requested frame size ok and modifies it to next bigger valid size if 
neccessary.
7. The server then restarts the encoder with the new frame size and 
continues to send the video data with the new frame size over the same 
stream RTP stream as before.
8. Here is where the 80% comes in. Most of the time it the FFMPEG 
decoder sees the new frame size and correctly handles it and everything 
is good but about 20% the time it doesn't and FFMPEG crashes.

It seems like what I'm doing should be ok I'm thinking that this is just 
a untested "feature" in FFMPEG (how many people actually create videos 
where the the frame size changes mid stream) and I'm just going to need 
to get setup on a Linux box to debug FFMPEG. I'm not sure and I'm 
wondering if there is a better way to do this or if there is something 
that the server should insert in the stream to signal this event to the 
client so that it can better prepare the decoder for the change in frame 
size or? I thought the just the presents of the changed IDR frames would 
be enough.

Thanks for a suggestions, you've been a great help so far.
Matt S.

Any suggestions?

 

From finlayson at live555.com  Mon Nov 17 11:46:40 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 17 Nov 2008 13:46:40 -0600
Subject: [Live-devel] Help MPEG4 streamingwith wait at end of file
In-Reply-To: <6edbd8e30811160405y41c7a2f4s1224385bb1677e8d@mail.gmail.com>
References: <6edbd8e30811160405y41c7a2f4s1224385bb1677e8d@mail.gmail.com>
Message-ID: <f06240804c54777e1b1ae@[66.80.62.44]>

>    I'm trying to use the live555 streaming media to stream video 
>that we are capturing to file from a camera.
>The camera encodes (mpeg4) the video and writes it to a file. At the 
>same time live555 is reading from that file and streaming the video 
>over RTSP. The problem we are having is that the live555 streamer 
>catches up with the end of that growing file and then restarts from 
>the beginning of the file. How can I configure live555 to wait at 
>the end of the file until new frames arrive?

Instead of reading from a file, you should read from a *pipe*, so 
that the OS will properly handle any attempts to read past the end of 
file (without returning an 'end of data' indication).

So, I suggest modifying your camera application so that it writes to 
'stdout', rather than to a file.  You can use the "tee" utility to 
record your data to a file as well as streaming it.  I.e., you can run

	your-camera-encoder-app | tee your-output-file-name | our-rtsp-server
(assuming you're on a Unix system).

You will need to modify the RTSP server code to (i) read from 
'stdin', and (ii) set "reuseFirstSource" to True. (Read the FAQ for 
more information.)
-- 

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

From anto.rizzo at caramail.com  Mon Nov 17 02:26:06 2008
From: anto.rizzo at caramail.com (Antonella Rizzo)
Date: Mon, 17 Nov 2008 11:26:06 +0100
Subject: [Live-devel] RTCP
Message-ID: <94361330124292@lycos-europe.com>

Hi Ross,
I need use RTCP SR and RR in my application.
Live555 provide RTCPIstance class to do this, it's right?
There are examples of use (best practice) in the source code?


Thanks in advance


From marc.d.moody at boeing.com  Mon Nov 17 15:14:59 2008
From: marc.d.moody at boeing.com (Moody, Marc D)
Date: Mon, 17 Nov 2008 15:14:59 -0800
Subject: [Live-devel] Trick Mode Data Rate
In-Reply-To: <f06240804c54777e1b1ae@[66.80.62.44]>
References: <6edbd8e30811160405y41c7a2f4s1224385bb1677e8d@mail.gmail.com>
	<f06240804c54777e1b1ae@[66.80.62.44]>
Message-ID: <50D34F92E6A0CC40B91B447FBF42CBBF0551D574@XCH-SW-4V2.sw.nos.boeing.com>

Ross and Community,

In regards to the Trick Mode Data Rate discussion last year.  A few
posts thus far have observed 'trick play' data rates higher than that of
the source media and a desire to throttle the data rate to some preset
maximum limit.  Please reference the following related posts from
March-July 2007.

http://lists.live555.com/pipermail/live-devel/2007-March/006317.html
http://lists.live555.com/pipermail/live-devel/2007-April/006509.html
http://lists.live555.com/pipermail/live-devel/2007-July/007210.html 

>As previously dscussed on this mailing list, we have a solution in 
>mind (it will require updating the index file format to include a new 
>'duration' field, and implement a new Transport Stream 'framer' class 
>that uses this).  There is currently no ETA for this, though.

Has there been any progress in this regard?

I am using Live555 version 0.19 source and have found that the average
'trick play' data rate for scales greater than 1X is more than double
that of the original source media.  The actual data rate seen for a
10Mbit/sec stream in trick play averages 22Mbit/sec for the following
selected scales:  2X, 4X, 8X, 16X and 64X.  Testing below 1X shows the
data rate to fall below that of the original source media.  At a scale
of 1/2X, the resulting data rate was 7.3Mbps for a 10Mbps stream.

My goal is to limit the playback data rate so that it is no greater than
that of the source media at 1X.

Ross states in his April 2007 response to "HD MPEG2 TrickPlay" , that:

Two methods were used to obtain the results above.  (Note that in both
test methods, the Live555 server in use has been modified to accept the
"scale" parameter from stdin upon stream open since VLC, to my
knowledge, doesn't let you pick the scale).

First OpenRTSP was used on the same host as the server to dump the
streamed output to a file using the following command:  

openRTSP.exe -d 34 -Ftwo_x_scale rtsp://127.0.0.l/tek.ts

The source stream is 10Mbps.  Live555 is commanded to stream at a scale
of 2X.  The output from openRTSP is 22Mbps when analyzed using TSreader.
I got the same 22Mbps results using an "unmodified version 0.19" live555
server in conjunction with the "-z 2" scale parameter of openRTSP.exe.

The second test used Wireshark to analyze Ethernet traffic on a closed
network between two PCs.  Live555 version 0.19 serving the same 10Mbps
stream to a PC running Wireshark and VLC as the RTSP client.  In each
case below, the scale was entered using stdin prior to stream open.

My results are as follows:

SCALE    AVG Mbit/sec   Time between 1st   Packets   AVG packets/sec
AVG packet size    IO Observation/time.  
                        and last packet

1X       10.429         66.989 sec         63795     952.322
1368.0 bytes       Steady data rate.  
1/2X     7.291          132.983 sec        102641    771.838
1180.0 bytes       Bursty data rate.  
2X       21.972         34.235 sec         79573     2324.345
1181.0 bytes       Bursty data rate.  
4X       22.065         17.772 sec         41483     2334.223
1181.0 bytes       Bursty data rate.  
8X       21.881         9.266 sec          21447     2314.648
1181.0 bytes       Bursty data rate.  
64X      22.207         2.212 sec          5195      2348.889
1181.0 bytes       Bursty data rate.  


>From these results, it appears that there is either a naturally
occurring maximum data rate of around 22Mbps in my particular setup or
there may be some programmed maximum that is a function of the source
data rate.  In any case, some help in understanding these results or
some help in finding a potential solution to clamping the maximum data
rate would be much appreciated.

Best regards,

Marc Moody


From finlayson at live555.com  Mon Nov 17 15:12:17 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 17 Nov 2008 17:12:17 -0600
Subject: [Live-devel] RTCP
In-Reply-To: <94361330124292@lycos-europe.com>
References: <94361330124292@lycos-europe.com>
Message-ID: <f06240805c547aa599dab@[66.80.62.44]>

>I need use RTCP SR and RR in my application.

Remember that RTCP "SR" packets are sent only by RTP data 
transmitters, and RTCP "RR" packets are sent only by RTP data 
receivers.

>Live555 provide RTCPIstance class to do this, it's right?

Yes.

>There are examples of use (best practice) in the source code?

Yes.  Look, for example, at the "openRTSP" code ("playCommon.cpp"), 
which uses data from RTCP "SR" reports to implement 'quality of 
service' reports (the "-Q" option).
-- 

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

From finlayson at live555.com  Mon Nov 17 15:45:56 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 17 Nov 2008 17:45:56 -0600
Subject: [Live-devel] Suggestions on the proper way to deal with frame
 size changes in the middle of H264 stream
In-Reply-To: <4921B41A.8080203@schuckmannacres.com>
References: <4921B41A.8080203@schuckmannacres.com>
Message-ID: <f06240806c547b1ffc25d@[66.80.62.44]>

>8. Here is where the 80% comes in. Most of the time it the FFMPEG 
>decoder sees the new frame size and correctly handles it and 
>everything is good but about 20% the time it doesn't and FFMPEG 
>crashes.

Therefore, there's a bug in FFMPEG.  That's what you need to address 
first (on some other mailing list, of course).

>It seems like what I'm doing should be ok I'm thinking that this is 
>just a untested "feature" in FFMPEG (how many people actually create 
>videos where the the frame size changes mid stream) and I'm just 
>going to need to get setup on a Linux box to debug FFMPEG. I'm not 
>sure and I'm wondering if there is a better way to do this or if 
>there is something that the server should insert in the stream to 
>signal this event to the client so that it can better prepare the 
>decoder for the change in frame size or? I thought the just the 
>presents of the changed IDR frames would be enough.

This is completely independent of our software.  You will need to ask 
about this on some other (FFMPEG-related) forum.
-- 

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

From rwaters at pelco.com  Mon Nov 17 19:27:47 2008
From: rwaters at pelco.com (Waters, Ralph)
Date: Mon, 17 Nov 2008 19:27:47 -0800
Subject: [Live-devel] How do I get the data from the lower levels.....
	Another DoGetNextFrame question
Message-ID: <DD74B0B9B8C5F647844370BBF606F83C010551D3@CA-EVS01.pelco.org>

Hi All,

First, I am very grateful for this mailing list and the help it gives. I
will try to make sure I can help support the community for this
wonderful tool, as much as I can.
This is a question about how to get the data from the lower layer
software, so I can pass it to a decoder later in a pipeline. I have an
Live555 client application that is receiving MPEG4 data from an RTP
source. I am using a file sink
to verify that the data is being received correctly. This works. What I
really want to do is to receive the MPEG4 (or H.264) data AFTER it is
reassembled from the incoming RTP packets.
I have my poll loop up and running, but am terribly confused as what to
do to get the data. I don't understand if doGetNextFrame is for the
incoming RTP packets, or for the processed sink packets.


I didn't understand the answer to:

>Is there maybe a way to directly schedule a call to
>*doGetNextFrame()* in the event loop since this is not a static 
>function or what would be the alternative

The alternative is to write a static member function that then calls
"doGetNextFrame()", and have "scheduleDelayedTask()" arrange to call the
static member function.  There are several examples of this in the code
already.

Also, as I noted last time, you should not call "usleep(10)"; instead,
pass 10 as the (delay) parameter to "scheduleDelayedTask()".


The first note I have is that all the code in the playCommon.hh, and all
the samples in testProgs do not use any client data. You have a
checkForPacketArrival(void * /*clientData*/) in which no one seems
interested
In the returned data. For example the call to it (at the end of
startPlayingStreams) is:   
  // Watch for incoming packets (if desired):
  checkForPacketArrival(NULL);

If I had multiple sources, how could I ever tell which stream it was. By
it's name it appears to be an INCOMING packet.

Do I have to rewrite a sink, like MPEG4ESVideoRTPSink, or
H264VideoRTPSink  to get the processed packets?

I don't think so. I think I am really to implement the callback for the
fAfterGettingFunc for the FramedSource, but I have no idea how to do
this.


Again, Thank you very much, Rusty


- ------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this transmission is legally privileged and confidential, intended only for the use of the individual(s) or entities named above. This email and any files transmitted with it are the property of Pelco. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you receive this communication in error, please notify us immediately by telephone call to +1-559-292-1981 or forward the e-mail to administrator at pelco.com and then permanently delete the e-mail and destroy all soft and hard copies of the message and any attachments. Thank you for your cooperation. 
- ------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081117/b9704f61/attachment-0001.html>

From finlayson at live555.com  Mon Nov 17 20:34:53 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 17 Nov 2008 22:34:53 -0600
Subject: [Live-devel] How do I get the data from the lower levels.....
 Another DoGetNextFrame question
In-Reply-To: <DD74B0B9B8C5F647844370BBF606F83C010551D3@CA-EVS01.pelco.org>
References: <DD74B0B9B8C5F647844370BBF606F83C010551D3@CA-EVS01.pelco.org>
Message-ID: <f06240808c547f6051ca9@[66.80.62.44]>

>This is a question about how to get the data from the lower layer 
>software, so I can pass it to a decoder later in a pipeline. I have 
>an Live555 client application that is receiving MPEG4 data from an 
>RTP source. I am using a file sink
>
>to verify that the data is being received correctly. This works. 
>What I really want to do is to receive the MPEG4 (or H.264) data 
>AFTER it is reassembled from the incoming RTP packets.

I'm sorry, but I don't understand this question.  A "FileSink" (or 
any other type of sink that is fed from your "MPEG4ESVideoRTPSource") 
does exactly what you're asking for: It receives the MPEG-4 data 
after it has been reassembled from the incoming RTP packets.
-- 

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/20081117/b2475fbb/attachment.html>

From finlayson at live555.com  Mon Nov 17 21:02:47 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 17 Nov 2008 23:02:47 -0600
Subject: [Live-devel] TR: Trick Play support on MPEG 4 Video Streams
In-Reply-To: <BLU149-W29916837F3CAB76BD2063A0130@phx.gbl>
References: <!&!AAAAAAAAAAAYAAAAAAAAAHHvJFuyABZJgquVddWyTGnCgAAAEAAAAN8f3yvBb8pBi49CeO
	aEh6oBAAAAAA==@skynet.be>  <f06240803c467e142db88@[66.80.62.44]>
	<BLU149-W29916837F3CAB76BD2063A0130@phx.gbl>
Message-ID: <f0624080ac547fc99a76a@[66.80.62.44]>

>I am curious if this has ever been implemented?
>
>
>
>Trick Play
>
>MPEG-TS containing H.264

No, not yet.

As I noted in my previous message about this (that you quoted):

>  if you have an example of the type of file that you wish to 
>support, then please put it on a web server and send us a link (URL) 
>to it, so we can download it and use it in our testing.


-- 

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

From finlayson at live555.com  Mon Nov 17 21:49:46 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 17 Nov 2008 23:49:46 -0600
Subject: [Live-devel] Trick Mode Data Rate
In-Reply-To: <50D34F92E6A0CC40B91B447FBF42CBBF0551D574@XCH-SW-4V2.sw.nos.boeing.com>
References: <6edbd8e30811160405y41c7a2f4s1224385bb1677e8d@mail.gmail.com>
	<f06240804c54777e1b1ae@[66.80.62.44]>
	<50D34F92E6A0CC40B91B447FBF42CBBF0551D574@XCH-SW-4V2.sw.nos.boeing.com>
Message-ID: <f0624080bc547fee93213@[66.80.62.44]>

Marc,

In my April 2007 posting, I misremembered what I had implemented.  A 
trick-play stream does, indeed, have a higher bitrate than the 
original stream, because (i) it consists only of I (i.e., key) 
frames, and (ii) has the same frame rate as the original source.  The 
reason for (ii) was that I was concerned that some set-top box 
receivers might not be able to handle a change in frame rate from the 
original stream.  However, assuming that that is in reality not a 
problem, then I plan to change the trick-play stream generation code 
so that it still contains only I-frames, but with each I-frame 
appearing at most once, and with I-frames appearing at the same rate 
as I-frames in the original stream.  Because of this, under the new 
algorithm, trick-play streams will have a lower bitrate than the 
original stream.

Suppose, for example, that the original Transport Stream contains the 
following video frames
	I1	n2	n3	n4	n5	n6	I7	n8	n9 ...
where each Ii is an I-frame, and each nj is a *non* I-frame.  In this 
example, each 6th frame is an I-frame.

Under the current algorithm, for 2x fast-forward, the following 
trick-play stream is produced:
	I1	I1	I1	I7	I7	I7	I13	I13	I13 ...
Under the new algorithm, for 2x fast-forward, the following 
trick-play stream will be produced:
	I1						I13 ...
i.e., Each I-frame will appear at most once, with I-frames appearing 
at the same rate as I-frames in the original stream.  In this 
example, the frame rate of trick-play streams will be 1/6 that of the 
original stream.

I have a policy of not answering "Are we there yet?" questions on 
this mailing list, so I'm not going to give an ETA for this.  But 
rest assured that it is a high-priority item.
-- 

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

From alex.cichowski at gmail.com  Mon Nov 17 22:50:05 2008
From: alex.cichowski at gmail.com (Alex Cichowski)
Date: Tue, 18 Nov 2008 17:20:05 +1030
Subject: [Live-devel] Patch enabling use as a DLL on Win32
Message-ID: <7c16625f0811172250ub7d13edp4c7e55a3678ba4ef@mail.gmail.com>

Dear Live555 developers,

I have created a patch that adds the necessary support for compiling
Live555 as a DLL under Visual C++ on Win32, and believe this may be
useful for other Live555 users. It may be downloaded here:
    http://sites.google.com/site/patchfiles1234/Home/LIVE_API.patch

The main change necessary is to tag all API functions and classes with
LIVE_API in the headers. LIVE_API gets #defined to
__declspec(dllimport) or __declspec(dllexport) as appropriate by a new
header "LiveGlobal.hh", which gets included by all other headers. The
user then needs to #define LIVE_EXPORTS when building the DLL, and
LIVE_DLL when using the DLL. I believe this strategy to be standard
practice for supporting DLL compilation.

Also, appropriate Visual C++ 2005 project and solution files are here
in case anyone finds them useful:
    http://sites.google.com/site/patchfiles1234/Home/live555.sln
    http://sites.google.com/site/patchfiles1234/Home/live555.vcproj
These take the approach of producing a single DLL named "live555.dll"
(or live555d.dll for debug mode) containing all four of Live555's main
libraries

Though I have not tested it, I believe the LIVE_API tag is equally
useful for compiling as a DLL under GCC/Cygwin on Win32.

This patch is against live.2008.11.13.tar.gz.

Regards,
Alex

From alex.cichowski at gmail.com  Mon Nov 17 23:00:23 2008
From: alex.cichowski at gmail.com (Alex Cichowski)
Date: Tue, 18 Nov 2008 17:30:23 +1030
Subject: [Live-devel] Shutdown crash with MPEG4VideoStreamDiscreteFramer
Message-ID: <7c16625f0811172300j2204bb0eo2994e0faf5b92daf@mail.gmail.com>

Hi all,

I have a custom MediaSink subclass drawing data from an
MPEG4VideoStreamDiscreteFramer (for the purpose of determining where
the keyframes are), which is in turn drawing data from an
MPEG4ESVideoRTPSource. I am running into a problem where during
cleanup, the MPEG4ESVideoRTPSource gets deleted too early due to the
following destructor code for
MPEG4VideoStreamDiscreteFramer:

    FramedFilter::~FramedFilter() {
      Medium::close(fInputSource);
    }

When the MediaSession is closed following this (I gather from OpenRTSP
that this is the correct cleanup order), the RTCPInstance of the
subsession still has a pointer to the MPEG4ESVideoRTPSource, which it
uses in RTCPInstance::enqueueCommonReportPrefix() during shutdown
(fSource->receptionStatsDB()), causing a crash.

As a workaround, I have created a patch (attached) for FramedFilter
that adds a "detachInputSource()" which can be used to disable
"Medium::close(fInputSource);" in the above before the cleanup
sequence. Is this an appropriate solution?

Thanks,
Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FramedFilter_detachInputSource.patch
Type: application/octet-stream
Size: 1168 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081118/feaca8e1/attachment.obj>

From alex.cichowski at gmail.com  Mon Nov 17 23:01:40 2008
From: alex.cichowski at gmail.com (Alex Cichowski)
Date: Tue, 18 Nov 2008 17:31:40 +1030
Subject: [Live-devel] New feature patch: PollingBasedTaskScheduler
Message-ID: <7c16625f0811172301r777b8e35rb19781835c777822@mail.gmail.com>

Dear Live555 developers,

Please find attached a patch that adds an additional task scheduler
named "PollingBasedTaskScheduler" to BasicUsageEnvironment. This
scheduler can be used for performing updates in a polling fashion,
i.e. without any blocking like BasicTaskScheduler does due to its use
of a nonzero timeout when calling select().

Such a strategy is useful when RTSP is not the only thing the
application is doing. I feel this may be a common requirement, so I am
submitting this patch in the hope that others may find it useful.

Also attached is a minor patch for MPEG4VideoStreamDiscreteFramer
which allows the user to retrieve the keyframe status of the last
processed frame.

These patches are against live.2008.11.13.tar.gz.

Regards,
Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PollingBasedTaskScheduler.patch
Type: application/octet-stream
Size: 7173 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081118/a36948e6/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MPEG4VideoStreamDiscreteFramer_keyframe_flags.patch
Type: application/octet-stream
Size: 3974 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081118/a36948e6/attachment-0003.obj>

From finlayson at live555.com  Mon Nov 17 23:47:49 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 18 Nov 2008 01:47:49 -0600
Subject: [Live-devel] Shutdown crash with MPEG4VideoStreamDiscreteFramer
In-Reply-To: <7c16625f0811172300j2204bb0eo2994e0faf5b92daf@mail.gmail.com>
References: <7c16625f0811172300j2204bb0eo2994e0faf5b92daf@mail.gmail.com>
Message-ID: <f06240801c5482388a806@[66.80.62.44]>

>As a workaround, I have created a patch (attached) for FramedFilter
>that adds a "detachInputSource()" which can be used to disable
>"Medium::close(fInputSource);" in the above before the cleanup
>sequence. Is this an appropriate solution?

Yes - and it will be included in the next release of the software. 
Thanks for the suggestion.
-- 

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

From finlayson at live555.com  Mon Nov 17 23:54:47 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 18 Nov 2008 01:54:47 -0600
Subject: [Live-devel] New feature patch: PollingBasedTaskScheduler
In-Reply-To: <7c16625f0811172301r777b8e35rb19781835c777822@mail.gmail.com>
References: <7c16625f0811172301r777b8e35rb19781835c777822@mail.gmail.com>
Message-ID: <f06240802c54823bfb4d3@[66.80.62.44]>

>Please find attached a patch that adds an additional task scheduler
>named "PollingBasedTaskScheduler" to BasicUsageEnvironment. This
>scheduler can be used for performing updates in a polling fashion,
>i.e. without any blocking like BasicTaskScheduler does due to its use
>of a nonzero timeout when calling select().

You can get the same effect, I think, with the existing 
"BasicTaskScheduler" by adding a periodic task, as outlined here:
	http://lists.live555.com/pipermail/live-devel/2006-March/004192.html
-- 

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

From alex.cichowski at gmail.com  Tue Nov 18 00:58:37 2008
From: alex.cichowski at gmail.com (Alex Cichowski)
Date: Tue, 18 Nov 2008 19:28:37 +1030
Subject: [Live-devel] New feature patch: PollingBasedTaskScheduler
In-Reply-To: <f06240802c54823bfb4d3@66.80.62.44>
References: <7c16625f0811172301r777b8e35rb19781835c777822@mail.gmail.com>
	<f06240802c54823bfb4d3@66.80.62.44>
Message-ID: <7c16625f0811180058w7fb9ee9uc154e4f7e6cee44b@mail.gmail.com>

OK. I have to say this does not seem like a robust solution, but maybe
it could be made to work... However, I also need to repeat the whole
process while there is still data to be read from any socket, since
the RTP handlers only read one packet at a time, and therefore can
start to lag behind if the task scheduler is not called often enough
and this is not dealt with somehow. This is a problem I was actually
seeing in practice.

In my proposed patch this is handled by having the updateImp() return
value indicate whether data was available to be processed. update()
then loops until updateImp() returns false. I am not sure how this
could be achieved with the approach you mention - how can I tell if
SingleStep() processed data or not?

As an aside, in relation to this comment in BasicTaskScheduler, and
the surrounding code...
    // For some unknown reason, select() in Windoze sometimes fails
with WSAEINVAL if
    // it was called with no entries set in "readSet".  If this
happens, ignore it:

I believe that on Win32 it is invalid to call select() with no entries
in readSet in the first place, and that this code should be considered
broken for this reason. For details, see here:
   http://msdn.microsoft.com/en-us/library/ms740141(VS.85).aspx
"Any two of the parameters, readfds, writefds, or exceptfds, can be
given as null. At least one must be non-null, and any non-null
descriptor set must contain at least one handle to a socket."

Alex



On Tue, Nov 18, 2008 at 6:24 PM, Ross Finlayson <finlayson at live555.com> wrote:
>> Please find attached a patch that adds an additional task scheduler
>> named "PollingBasedTaskScheduler" to BasicUsageEnvironment. This
>> scheduler can be used for performing updates in a polling fashion,
>> i.e. without any blocking like BasicTaskScheduler does due to its use
>> of a nonzero timeout when calling select().
>
> You can get the same effect, I think, with the existing "BasicTaskScheduler"
> by adding a periodic task, as outlined here:
>        http://lists.live555.com/pipermail/live-devel/2006-March/004192.html
> --
>
> 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 marc.d.moody at boeing.com  Tue Nov 18 05:49:25 2008
From: marc.d.moody at boeing.com (Moody, Marc D)
Date: Tue, 18 Nov 2008 05:49:25 -0800
Subject: [Live-devel] Trick Mode Data Rate
In-Reply-To: <f0624080bc547fee93213@[66.80.62.44]>
References: <6edbd8e30811160405y41c7a2f4s1224385bb1677e8d@mail.gmail.com><f06240804c54777e1b1ae@[66.80.62.44]><50D34F92E6A0CC40B91B447FBF42CBBF0551D574@XCH-SW-4V2.sw.nos.boeing.com>
	<f0624080bc547fee93213@[66.80.62.44]>
Message-ID: <50D34F92E6A0CC40B91B447FBF42CBBF0551D68A@XCH-SW-4V2.sw.nos.boeing.com>

Ross,

Thank you for the great description of the problem.  I was considering
the removal of duplicate I-frames myself within the TrickModeFilter
class.  

Generalizing your recommended solution, if we let N represent scale,
then every Nth frame would be posted once and only once at its scaled
presentation time.

Best regards,

Marc Moody 
The Boeing Company

-----Original Message-----
From: Ross Finlayson [mailto:finlayson at live555.com] 
Sent: Monday, November 17, 2008 10:50 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Trick Mode Data Rate

Marc,

In my April 2007 posting, I misremembered what I had implemented.  A
trick-play stream does, indeed, have a higher bitrate than the original
stream, because (i) it consists only of I (i.e., key) frames, and (ii)
has the same frame rate as the original source.  The reason for (ii) was
that I was concerned that some set-top box receivers might not be able
to handle a change in frame rate from the original stream.  However,
assuming that that is in reality not a problem, then I plan to change
the trick-play stream generation code so that it still contains only
I-frames, but with each I-frame appearing at most once, and with
I-frames appearing at the same rate as I-frames in the original stream.
Because of this, under the new algorithm, trick-play streams will have a
lower bitrate than the original stream.

Suppose, for example, that the original Transport Stream contains the
following video frames
	I1	n2	n3	n4	n5	n6	I7	n8
n9 ...
where each Ii is an I-frame, and each nj is a *non* I-frame.  In this
example, each 6th frame is an I-frame.

Under the current algorithm, for 2x fast-forward, the following
trick-play stream is produced:
	I1	I1	I1	I7	I7	I7	I13	I13
I13 ...
Under the new algorithm, for 2x fast-forward, the following trick-play
stream will be produced:
	I1						I13 ...
i.e., Each I-frame will appear at most once, with I-frames appearing at
the same rate as I-frames in the original stream.  In this example, the
frame rate of trick-play streams will be 1/6 that of the original
stream.

I have a policy of not answering "Are we there yet?" questions on this
mailing list, so I'm not going to give an ETA for this.  But rest
assured that it is a high-priority item.
-- 

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 matt at schuckmannacres.com  Tue Nov 18 06:42:20 2008
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Tue, 18 Nov 2008 06:42:20 -0800
Subject: [Live-devel] Suggestions on the proper way to deal with frame
 size changes in the middle of H264 stream
In-Reply-To: <f06240806c547b1ffc25d@[66.80.62.44]>
References: <4921B41A.8080203@schuckmannacres.com>
	<f06240806c547b1ffc25d@[66.80.62.44]>
Message-ID: <4922D44C.2050405@schuckmannacres.com>

That's pretty much what I thought, you seem pretty knowledgeable in this 
area and I wanted to see if anything popped out at you.
I haven't got much of a response from the FFMPEG list so I think I 
pretty much on my own.

Thanks
Matt S.

Ross Finlayson wrote:
>> 8. Here is where the 80% comes in. Most of the time it the FFMPEG 
>> decoder sees the new frame size and correctly handles it and 
>> everything is good but about 20% the time it doesn't and FFMPEG crashes.
>
> Therefore, there's a bug in FFMPEG.  That's what you need to address 
> first (on some other mailing list, of course).
>
>> It seems like what I'm doing should be ok I'm thinking that this is 
>> just a untested "feature" in FFMPEG (how many people actually create 
>> videos where the the frame size changes mid stream) and I'm just 
>> going to need to get setup on a Linux box to debug FFMPEG. I'm not 
>> sure and I'm wondering if there is a better way to do this or if 
>> there is something that the server should insert in the stream to 
>> signal this event to the client so that it can better prepare the 
>> decoder for the change in frame size or? I thought the just the 
>> presents of the changed IDR frames would be enough.
>
> This is completely independent of our software.  You will need to ask 
> about this on some other (FFMPEG-related) forum.

From rwaters at pelco.com  Tue Nov 18 09:57:07 2008
From: rwaters at pelco.com (Waters, Ralph)
Date: Tue, 18 Nov 2008 09:57:07 -0800
Subject: [Live-devel] How do I get the data from the lower levels.....
	Another DoGetNextFrame question (Ross Finlayson)
Message-ID: <DD74B0B9B8C5F647844370BBF606F83C010552F0@CA-EVS01.pelco.org>

Hi Ross,

Thanks for the response. I'm sorry that I didn't ask my question in a
simpler manner. I hope this email helps. Please remember that I am a
novice at Live555, so I cannot see from your deeply experienced eyes.

Assumption: Live555 has raw RTP video and audio packets coming in, and
it re-assembles these into a framed video for output.
 
Question: How do I get the data, from a higher level task, suck as
PollTask (below) that is the re-assembled video payload. Video packets
may be created from re-assembled RTP packets, or the video packets can
be decomposed
From 1 RTP packet into many video packets.

I need to get this video frame data.

Real Question: How do I get at the processed packets of (video frame)
data, say from a MPEG4 or H.264 source, from a background PollTask?

Do I use the solution that you gave? "The alternative is to write a
static member function that then calls "doGetNextFrame()", and have
"scheduleDelayedTask()" arrange to call the static member function.
There are several examples of this in the code already." Or is that for
the incoming, unprocessed RTP data?

Or do I use something that calls afterGettingFrame from the sink? I
think this is more likely.


I need to call the "thing" that gets me processed data from something
like this:

//=====================================================================
// This polls the event loop every so often to check for events
//=====================================================================
void RtspClientPrivate::PollTask(void* pArgs) {

  //ACE_TRACE( ACE_TEXT("RtspClientPrivate::PollTask()") );


  RtspClientPrivate *pThis = reinterpret_cast<RtspClientPrivate
*>(pArgs);

  if(NULL != pThis){
	// Call this again, after a brief delay:
	int uSecsToDelay = 100000; // 100 ms
	TaskFunc *pFunc =
reinterpret_cast<TaskFunc*>(RtspClientPrivate::PollTask);
	
	// HOW DO I GET THE DATA THAT I NEED HERE? (the upper layer)

	pThis->m_pEnv->taskScheduler().scheduleDelayedTask(uSecsToDelay,
pFunc,
	
pArgs);
  }
}

Thanks, Rusty

- ------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this transmission is legally privileged and confidential, intended only for the use of the individual(s) or entities named above. This email and any files transmitted with it are the property of Pelco. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you receive this communication in error, please notify us immediately by telephone call to +1-559-292-1981 or forward the e-mail to administrator at pelco.com and then permanently delete the e-mail and destroy all soft and hard copies of the message and any attachments. Thank you for your cooperation. 
- ------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081118/bbddeb2c/attachment-0001.html>

From finlayson at live555.com  Tue Nov 18 10:21:04 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 18 Nov 2008 12:21:04 -0600
Subject: [Live-devel] How do I get the data from the lower levels.....
 Another DoGetNextFrame question (Ross Finlayson)
In-Reply-To: <DD74B0B9B8C5F647844370BBF606F83C010552F0@CA-EVS01.pelco.org>
References: <DD74B0B9B8C5F647844370BBF606F83C010552F0@CA-EVS01.pelco.org>
Message-ID: <f06240807c548b6163f3c@[66.80.62.44]>

>Assumption: Live555 has raw RTP video and audio packets coming in, 
>and it re-assembles these into a framed video for output.
>
>
>Question: How do I get the data, from a higher level task, suck as 
>PollTask (below) that is the re-assembled video payload. Video 
>packets may be created from re-assembled RTP packets, or the video 
>packets can be decomposed
>
>From 1 RTP packet into many video packets.
>
>I need to get this video frame data.

You don't need to do anything special to get this.  The output 
delivered by a "MPEG4ESVideoRTPSource" in response to the 
"getNextFrame()" function will be a complete MPEG-4 Video frame, 
regardless of how many RTP packets the frame took up.  Our code takes 
care of reassembling a complete video frame.
-- 

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/20081118/330ea022/attachment.html>

From amit.yedidia at elbitsystems.com  Wed Nov 19 06:00:31 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Wed, 19 Nov 2008 16:00:31 +0200
Subject: [Live-devel] RTP sink to serial
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D367D@mailesl5.esl.corp.elbit.co.il>


Hi,

I want to to send RTP packets (RTP header + payload after packetization)
to a serial port.
>From my experience with Live I figure that using socket_pair will be a
good solution.
In that way I will be able to use the current code to send the data into
the socket, and on the other side I will write some listener that will
recv from the socket and   transmit it using the serial port.
Am I right?

Regards,

Amit Yedidia


The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081119/7b2180d7/attachment.html>

From plaza02 at 163.com  Wed Nov 19 06:52:45 2008
From: plaza02 at 163.com (plaza02)
Date: Wed, 19 Nov 2008 22:52:45 +0800 (CST)
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D367D@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D367D@mailesl5.esl.corp.elbit.co.il>
Message-ID: <13937874.610831227106365161.JavaMail.coremail@bj163app97.163.com>

I am a newbie to this, so sorry can't help you, :( 


?2008-11-19?"Yedidia Amit" <amit.yedidia at elbitsystems.com> ???



Hi,

I want to to send RTP packets (RTP header + payload after packetization) to a serial port.

>From my experience with Live I figure that using socket_pair will be a good solution.

In that way I will be able to use the current code to send the data into the socket, and on the other side I will write some listener that will recv from the socket and   transmit it using the serial port.

Am I right?

Regards,

Amit Yedidia

 
The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081119/c6f7b089/attachment.html>

From weglanz12 at yahoo.com  Wed Nov 19 07:22:14 2008
From: weglanz12 at yahoo.com (Horst Weglanz)
Date: Wed, 19 Nov 2008 07:22:14 -0800 (PST)
Subject: [Live-devel] doGetNextFrame() timing in mpeg2ts context
References: <130306.412.qm@web45806.mail.sp1.yahoo.com>
	<f06240805c5419221870d@[66.80.62.44]>
	<229525.36025.qm@web45809.mail.sp1.yahoo.com>
	<f06240807c5421e45d0cf@[66.80.62.44]>
	<832426.38639.qm@web45816.mail.sp1.yahoo.com>
Message-ID: <501330.45748.qm@web45803.mail.sp1.yahoo.com>

Hi,

I investigated this issue further and it confirms everything is okay, as long as my second source doesn't have any data yet. The instance the data is extracted and the call to finish the frame from this source: 
    nextTask() = envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afterGetting, this);
is scheduled and written to nextTask(), no more calls from the first source (ByteStreamFileSource or a similar own implementation):
    nextTask() = envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afterGetting, this);
will get executed. As I said it seems the other "afterGetting(this)" call overwrites the existing call already in the scheduler, but these are different objects.

Thank you very much,
HW



----- Original Message ----
From: Horst Weglanz <weglanz12 at yahoo.com>
To: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com>
Sent: Friday, November 14, 2008 3:47:28 PM
Subject: Re: [Live-devel] doGetNextFrame() timing in mpeg2ts context

Thank you,

I added a static hook to schedule another *doGetNextFrame()* call and it's working as expected. Except for one thing which seems to be an issue with my usage of the TaskScheduler. I added a ByteStreamFileSource to the output video and the funny thing is: scheduled events from the ByteStreamFileSource immediately stop being executed when the first data is available in MySource. These are different objects and in in MySource I do the following:

every time data available:
    nextTask() = envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afterGetting, this);
every time no data available:
    nextTask() = envir().taskScheduler().scheduleDelayedTask(100,(TaskFunc*)MySource::doGetNextFrameStatic, this);


and in the ByteStreamFileSource there is also this frequent call:
    nextTask() = envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afterGetting, this);

Both sources do work alone and there is nothing wrong with the FileSource, the problems occurs only when two video sources being read in parallel. When I start my application usually data in MySource isn't instantly available so every time there is *no data*  -> so it schedules doGetNextFrameStatic(). At the same time data from the ByteFileSource is being read. After it has read it's frame, it schedules the next frame to *FramedSource::afterGetting(this)* which is being called. The problems occurs the moment data in MySource is available and this object also schedules a call to *FramedSource::afterGetting(this)* -- it seams it somehow overwrites the call from ByteStreamFileSource to read the next frame; of course the function pointer is probably the same but the *this* parameter is different and *nextTask()* should point to a different TaskToken since they are both different objects. 

What is going wrong here? Do I have to handle things differently when adding multiple video streams or where lies my mistake?

Thank you very much,
HW



      


From marc.d.moody at boeing.com  Wed Nov 19 07:27:44 2008
From: marc.d.moody at boeing.com (Moody, Marc D)
Date: Wed, 19 Nov 2008 07:27:44 -0800
Subject: [Live-devel] FW:  Trick Mode Data Rate
Message-ID: <50D34F92E6A0CC40B91B447FBF42CBBF032387D4@XCH-SW-4V2.sw.nos.boeing.com>

Ross and community, 

I'm attempting to implement the first part of Ross's Trick Mode data
rate solution by skipping duplicate I-frames.  Attached is my modified
TrickModeFilter class.  I am keeping track of the TS packet number for
each I frame and allowing getNextFrame() to return with a frame size of
zero when a duplicate I-frame is detected.  I have verified that the
duplicate I-frame packets aren't being moved to the 'fTo' buffer in the
attemptDeliveryToClient() function.

I was hoping these code changes alone would be sufficient to skip
duplicate I-frames but for some reason, the resulting data rate is
unchanged.  Something else in the software is "filling" the gaps
somehow.  My guess is that a parent class (the scheduler perhaps) keeps
grabbing I-frames until it fills up a sufficient time-slice/GOP -
regardless of my skipping duplicate I-frames in the Trick Mode filter.  

Any help in identifying where to look next is appreciated.

Best regards,

Marc Moody
The Boeing Company

-----Original Message-----
From: Moody, Marc D 
Sent: Tuesday, November 18, 2008 6:49 AM
To: live-devel at lists.live555.com
Subject: RE: [Live-devel] Trick Mode Data Rate

Ross,

Thank you for the great description of the problem.  I was considering
the removal of duplicate I-frames myself within the TrickModeFilter
class.  

Generalizing your recommended solution, if we let N represent scale,
then every Nth frame would be posted once and only once at its scaled
presentation time.

Best regards,

Marc Moody
The Boeing Company

-----Original Message-----
From: Ross Finlayson [mailto:finlayson at live555.com]
Sent: Monday, November 17, 2008 10:50 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Trick Mode Data Rate

Marc,

In my April 2007 posting, I misremembered what I had implemented.  A
trick-play stream does, indeed, have a higher bitrate than the original
stream, because (i) it consists only of I (i.e., key) frames, and (ii)
has the same frame rate as the original source.  The reason for (ii) was
that I was concerned that some set-top box receivers might not be able
to handle a change in frame rate from the original stream.  However,
assuming that that is in reality not a problem, then I plan to change
the trick-play stream generation code so that it still contains only
I-frames, but with each I-frame appearing at most once, and with
I-frames appearing at the same rate as I-frames in the original stream.
Because of this, under the new algorithm, trick-play streams will have a
lower bitrate than the original stream.

Suppose, for example, that the original Transport Stream contains the
following video frames
	I1	n2	n3	n4	n5	n6	I7	n8
n9 ...
where each Ii is an I-frame, and each nj is a *non* I-frame.  In this
example, each 6th frame is an I-frame.

Under the current algorithm, for 2x fast-forward, the following
trick-play stream is produced:
	I1	I1	I1	I7	I7	I7	I13	I13
I13 ...
Under the new algorithm, for 2x fast-forward, the following trick-play
stream will be produced:
	I1						I13 ...
i.e., Each I-frame will appear at most once, with I-frames appearing at
the same rate as I-frames in the original stream.  In this example, the
frame rate of trick-play streams will be 1/6 that of the original
stream.

I have a policy of not answering "Are we there yet?" questions on this
mailing list, so I'm not going to give an ETA for this.  But rest
assured that it is a high-priority item.
-- 

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 --------------
A non-text attachment was scrubbed...
Name: MPEG2TransportStreamTrickModeFilter.hh
Type: application/octet-stream
Size: 3724 bytes
Desc: MPEG2TransportStreamTrickModeFilter.hh
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081119/b64090f4/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MPEG2TransportStreamTrickModeFilter.cpp
Type: application/octet-stream
Size: 11168 bytes
Desc: MPEG2TransportStreamTrickModeFilter.cpp
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081119/b64090f4/attachment-0003.obj>

From mamille1 at rockwellcollins.com  Wed Nov 19 15:20:03 2008
From: mamille1 at rockwellcollins.com (mamille1 at rockwellcollins.com)
Date: Wed, 19 Nov 2008 17:20:03 -0600
Subject: [Live-devel] Where are TS PCR's decoded?
Message-ID: <OF0F1DE3C7.58F834F3-ON86257506.007F5B24-86257506.00802E2F@rockwellcollins.com>

All

We're looking in to a problem with playback of our transport streams. From 
looking at the code in the liveMedia library, we think that it's primarily 
handled by MPEG2TransportStreamFramer.cpp. So that we don't interfere too 
much with a playback, we've added a few debugging print statements. 
Trouble is, we don't see the output from our debug statements.

1) Is MPEG2TransportStreamFramer.cpp the place where PCR's are processed 
and used to control when packets are sent out?

2) When recording a stream (where the final sink is a FileSink object), is 
there any processing of PCR's?

Thanks for all your help.

-=- Mike Miller
SW Engineer, Govt. Systems
Rockwell Collins, Inc.
Cedar Rapids, IA 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081119/1ab510c4/attachment.html>

From finlayson at live555.com  Wed Nov 19 18:10:00 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 19 Nov 2008 20:10:00 -0600
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D367D@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D367D@mailesl5.esl.corp.elbit.co.il>
Message-ID: <f06240800c54a76aa5e3f@[66.80.62.44]>

>I want to to send RTP packets (RTP header + payload after 
>packetization) to a serial port.
>
>From my experience with Live I figure that using socket_pair will be 
>a good solution.
>
>In that way I will be able to use the current code to send the data 
>into the socket, and on the other side I will write some listener 
>that will recv from the socket and   transmit it using the serial 
>port.
>
>Am I right?

Yes, I think so.  The current code assumes that RTP packets' 
destination will always be an IP network socket.  (This is a design 
mistake; someday I'd like to make it easier to use other (real or 
virtual) network layers underneath RTP.)

Therefore, the best way to do what you want to do is to make your 
serial interface accessible via a socket that has an IP address. 
(I'll let you figure out how to do 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/20081119/2b7a41a5/attachment.html>

From finlayson at live555.com  Wed Nov 19 22:01:29 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 20 Nov 2008 00:01:29 -0600
Subject: [Live-devel] Where are TS PCR's decoded?
In-Reply-To: <OF0F1DE3C7.58F834F3-ON86257506.007F5B24-86257506.00802E2F@rockwellcollins
	.com>
References: <OF0F1DE3C7.58F834F3-ON86257506.007F5B24-86257506.00802E2F@rockwellcollins
	.com>
Message-ID: <f06240807c54aac62c5cd@[66.80.62.44]>

Our software does not 'decode' MPEG Transport Stream data at all.  It 
never modifies any part of a Transport Stream (including the PCR 
timestamp).

Our software uses Transport Stream's PCR timestamps in only two places:
	1/ When we are creating an index file (the timestamps help 
tell us where to 'seek by time')
	2/ When we are transmitting Transport Stream data via RTP (or 
raw UDP).  To do this, our "MPEG2TransportStreamFramer" class reads 
the PCR timestamps to figure out how long to delay after sending each 
outgoing packet.

Our software does not look at PCR timestamps at all when *receiving* 
streamed Transport Stream data.
-- 

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

From microqq001 at gmail.com  Wed Nov 19 22:53:28 2008
From: microqq001 at gmail.com (qiqi)
Date: Thu, 20 Nov 2008 14:53:28 +0800
Subject: [Live-devel] [Test]This is my first post.
Message-ID: <000001c94adc$b338bb70$060010ac@MONICA>

HI,

 

I saw a thread about h264 streaming, and I wanted to reply to it. But I
don't know how to .

 

There was a "Reply via email to" button at the bottom of
www.mail-archive.com/live-devel at lists.live555.com, 

 

After I followed it, a mail was sent to somebody,whose name was on the
button,

 

But my reply has not shown in the mailing list, when I browse it via
www.mail-archive.com <http://www.mail-archive.com/> .

 

Here is the link:
http://www.mail-archive.com/live-devel at lists.live555.com/msg01936.html 

 

Thanks for any help

 

qq

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

From amit.yedidia at elbitsystems.com  Wed Nov 19 23:13:54 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Thu, 20 Nov 2008 09:13:54 +0200
Subject: [Live-devel] RTPsink with two multicast address
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D3680@mailesl5.esl.corp.elbit.co.il>


Hi All
Is it possible to add more than one multicast address to RTPSink as
destinations?
Which means that the the packet will be transmitted once for each
multicast address/

Regards,


Amit Yedidia
Elbit System Ltd.

Email: amit.yedidia at elbitsystems.com
Tel: 972-4-8318905
----------------------------------------------------------



The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081120/de4e8e53/attachment.html>

From soumya.patra at lge.com  Wed Nov 19 23:22:42 2008
From: soumya.patra at lge.com (soumya patra)
Date: Thu, 20 Nov 2008 12:52:42 +0530
Subject: [Live-devel] MP3 Audio Application
Message-ID: <20081120072237.96560558010@LGEMRELSE6Q.lge.com>

Hi Ross,

 

I am developing audio switching application in windows, I have used LAME mp3
encoder library for encoding, I want to stream this data to network. Can I
modify testMP3Streamer.cpp to make things working, Can I write directly to
stdin and pipe the stdin data directly to the testMP3Streamer input. Is it
possible? 

 

I am not good on windows, can any one give me hints how can I do this? I am
able to encode mp3 data into a file successfully.

 

 

Thanks 

Peeyush Mishra

 

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

From alex889 at gmail.com  Thu Nov 20 00:04:17 2008
From: alex889 at gmail.com (alex)
Date: Thu, 20 Nov 2008 10:04:17 +0200
Subject: [Live-devel] Newbie question regarding running the Live555 Server
	on DM642
Message-ID: <c9163a8c0811200004h4fcf2953l45f1aa2f75c4d27e@mail.gmail.com>

Hi,
I'm trying to run the Server on TI's DM642.
First i tried to make lib files of all the projects, and then run the
application.
I'm having trouble with the first steps of compiling the projects.
I get many errors. I'm using the NDK files, as the network related files.
Can i get some tips for getting stared
Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081120/942a1b5d/attachment-0001.html>

From amit.yedidia at elbitsystems.com  Thu Nov 20 01:00:51 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Thu, 20 Nov 2008 11:00:51 +0200
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <f06240800c54a76aa5e3f@[66.80.62.44]>
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D3683@mailesl5.esl.corp.elbit.co.il>

tahnks,
 
Regrading your last comment - I thought I can use 127.0.0.1 or the real
machine IP. Am I missing something?  
 

Regards,


Amit Yedidia

Elbit System Ltd.

Email: amit.yedidia at elbitsystems.com

Tel: 972-4-8318905

----------------------------------------------------------

 


________________________________

	From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
	Sent: Thursday, November 20, 2008 4:10 AM
	To: LIVE555 Streaming Media - development & use
	Subject: Re: [Live-devel] RTP sink to serial
	
	

		I want to to send RTP packets (RTP header + payload
after packetization) to a serial port.
		

		From my experience with Live I figure that using
socket_pair will be a good solution.
		

		In that way I will be able to use the current code to
send the data into the socket, and on the other side I will write some
listener that will recv from the socket and   transmit it using the
serial port.
		

		Am I right?


	Yes, I think so.  The current code assumes that RTP packets'
destination will always be an IP network socket.  (This is a design
mistake; someday I'd like to make it easier to use other (real or
virtual) network layers underneath RTP.)

	Therefore, the best way to do what you want to do is to make
your serial interface accessible via a socket that has an IP address.
(I'll let you figure out how to do this :-)
	-- 

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


The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081120/9935d9cb/attachment.html>

From amit.yedidia at elbitsystems.com  Thu Nov 20 01:04:37 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Thu, 20 Nov 2008 11:04:37 +0200
Subject: [Live-devel] Newbie question regarding running the Live555
	Serveron DM642
In-Reply-To: <c9163a8c0811200004h4fcf2953l45f1aa2f75c4d27e@mail.gmail.com>
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D3684@mailesl5.esl.corp.elbit.co.il>

I think that you should at least attach some errors, so members will be
able to give you more specific answers.
btw, did you first try to compile it for windows/linux (just to get some
experience) you might discover that your problem is not related to the
DM642.
 
Regards,


Amit Yedidia

Elbit System Ltd.

Email: amit.yedidia at elbitsystems.com

Tel: 972-4-8318905

----------------------------------------------------------

 


________________________________

	From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of alex
	Sent: Thursday, November 20, 2008 10:04 AM
	To: live-devel at ns.live555.com
	Subject: [Live-devel] Newbie question regarding running the
Live555 Serveron DM642
	
	
	Hi,
	I'm trying to run the Server on TI's DM642.
	First i tried to make lib files of all the projects, and then
run the application.
	I'm having trouble with the first steps of compiling the
projects.
	I get many errors. I'm using the NDK files, as the network
related files.
	Can i get some tips for getting stared
	Thanks,
	Alex


The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081120/4328f79d/attachment.html>

From paul at packetship.com  Thu Nov 20 01:41:25 2008
From: paul at packetship.com (Paul Clark)
Date: Thu, 20 Nov 2008 09:41:25 +0000
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D367D@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D367D@mailesl5.esl.corp.elbit.co.il>
Message-ID: <492530C5.1040403@packetship.com>

Yedidia Amit wrote:
> I want to to send RTP packets (RTP header + payload after 
> packetization) to a serial port.
>
> From my experience with Live I figure that using socket_pair will be a 
> good solution.
>
> In that way I will be able to use the current code to send the data 
> into the socket, and on the other side I will write some listener that 
> will recv from the socket and   transmit it using the serial port.
>

Just a random thought, which might save you having to have this 
IP-to-serial conversion process...  I don't know whether you've got 
control of the other end of the serial line, but could you not just set 
up a SLIP interface and send the RTP over that?   The Live555 code would 
just see it as a normal IP interface.  You'd need to do this at both 
ends, but you could then have a standard UDP socket listener at the 
receiver end to receive the RTP packets.

On Linux, see `man slattach` and 
http://www.informit.com/library/content.aspx?b=red_hat_linux7&seqNum=62

Even if you couldn't do this at the remote end, SLIP is a really simple 
protocol which you could implement yourself - see:  
http://tools.ietf.org/html/rfc1055

Regards

Paul
--
Paul Clark
Packet Ship Technologies Limited
http://www.packetship.com

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

From amit.yedidia at elbitsystems.com  Thu Nov 20 03:12:31 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Thu, 20 Nov 2008 13:12:31 +0200
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <492530C5.1040403@packetship.com>
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D368B@mailesl5.esl.corp.elbit.co.il>

Thanks Paul,
 
Seems very  very interesting..
I do have control on bothe sides.
 
According to what I understand, the SLIP (and the other configuration)
creates IP routing threw the serial line.
So after assigning SLIP device and add route to some IP (real or dummy?
does it matter?), every packet that I will send to this IP will pop out
at the other end.
 
Now, to use it in LIVE, I just need to provide the ip_addr (SLIP assigne
ip_addr ) and port (any numebr).
The socket that will be created will use this port and SLIP device for
both tx and rx.
 
Am I right?
 
thanks again.
 
 
 
 

Regards,


Amit Yedidia

----------------------------------------------------------

 


________________________________

	From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Paul Clark
	Sent: Thursday, November 20, 2008 11:41 AM
	To: LIVE555 Streaming Media - development & use
	Subject: Re: [Live-devel] RTP sink to serial
	
	
	Yedidia Amit wrote: 

		I want to to send RTP packets (RTP header + payload
after packetization) to a serial port. 

		From my experience with Live I figure that using
socket_pair will be a good solution.

		In that way I will be able to use the current code to
send the data into the socket, and on the other side I will write some
listener that will recv from the socket and   transmit it using the
serial port.


	Just a random thought, which might save you having to have this
IP-to-serial conversion process...  I don't know whether you've got
control of the other end of the serial line, but could you not just set
up a SLIP interface and send the RTP over that?   The Live555 code would
just see it as a normal IP interface.  You'd need to do this at both
ends, but you could then have a standard UDP socket listener at the
receiver end to receive the RTP packets.
	
	On Linux, see `man slattach` and
http://www.informit.com/library/content.aspx?b=red_hat_linux7&seqNum=62
	
	Even if you couldn't do this at the remote end, SLIP is a really
simple protocol which you could implement yourself - see:
http://tools.ietf.org/html/rfc1055
	
	Regards
	
	Paul
	--
	Paul Clark
	Packet Ship Technologies Limited
	http://www.packetship.com
	
	


The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081120/ec06b8c5/attachment-0001.html>

From finlayson at live555.com  Thu Nov 20 03:19:20 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 20 Nov 2008 05:19:20 -0600
Subject: [Live-devel] RTPsink with two multicast address
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D3680@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D3680@mailesl5.esl.corp.elbit.co.il>
Message-ID: <f06240809c54af6df19aa@[66.80.62.44]>

>Is it possible to add more than one multicast address to RTPSink as 
>destinations?
>
>Which means that the the packet will be transmitted once for each 
>multicast address/

Yes, call
	yourRTPSink->groupsockBeingUsed().addDestination(addr, port);
(See "groupsock/include/Groupsock.hh" for the signature of "addDestination()".)
-- 

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/20081120/51ea0ed6/attachment.html>

From finlayson at live555.com  Thu Nov 20 03:21:55 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 20 Nov 2008 05:21:55 -0600
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D3683@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D3683@mailesl5.esl.corp.elbit.co.il>
Message-ID: <f0624080ac54af8b6881d@[66.80.62.44]>

>Regrading your last comment - I thought I can use 127.0.0.1 or the 
>real machine IP. Am I missing something? 

No - you're correct.  (I'd forgotten about that.)
-- 

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/20081120/4149453d/attachment.html>

From finlayson at live555.com  Thu Nov 20 03:23:22 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 20 Nov 2008 05:23:22 -0600
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <492530C5.1040403@packetship.com>
References: <EB34B5A39CF26E408490ED9279BF10A71D367D@mailesl5.esl.corp.elbit.co.il>
	<492530C5.1040403@packetship.com>
Message-ID: <f0624080bc54af8f39666@[66.80.62.44]>

>Just a random thought, which might save you having to have this 
>IP-to-serial conversion process...  I don't know whether you've got 
>control of the other end of the serial line, but could you not just 
>set up a SLIP interface and send the RTP over that?   The Live555 
>code would just see it as a normal IP interface.  You'd need to do 
>this at both ends, but you could then have a standard UDP socket 
>listener at the receiver end to receive the RTP packets.

Yes - great idea.  I definitely recommend this.  That way, you don't 
have to write any UDP/IP parsing code at the receiving end.
-- 

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

From finlayson at live555.com  Thu Nov 20 03:25:18 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 20 Nov 2008 05:25:18 -0600
Subject: [Live-devel] MP3 Audio Application
In-Reply-To: <20081120072237.96560558010@LGEMRELSE6Q.lge.com>
References: <20081120072237.96560558010@LGEMRELSE6Q.lge.com>
Message-ID: <f0624080cc54af976b530@[66.80.62.44]>

>I am developing audio switching application in windows, I have used 
>LAME mp3 encoder library for encoding, I want to stream this data to 
>network. Can I modify testMP3Streamer.cpp to make things working, 
>Can I write directly to stdin and pipe the stdin data directly to 
>the testMP3Streamer input. Is it possible?

Yes, see http://www.live555.com/liveMedia/faq.html#liveInput
-- 

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/20081120/ff47a201/attachment.html>

From paul at packetship.com  Thu Nov 20 03:35:09 2008
From: paul at packetship.com (Paul Clark)
Date: Thu, 20 Nov 2008 11:35:09 +0000
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D368B@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D368B@mailesl5.esl.corp.elbit.co.il>
Message-ID: <49254B6D.2010605@packetship.com>

Yedidia Amit wrote:
> According to what I understand, the SLIP (and the other configuration) 
> creates IP routing threw the serial line.
> So after assigning SLIP device and add route to some IP (real or 
> dummy? does it matter?), every packet that I will send to this IP will 
> pop out at the other end.

Yes, you can use any private address that you aren't using for anything 
else - e.g. 192.168.200.1 at the sending end, 192.168.200.2 at the 
receiving end.  SLIP is very simple and you have to manually assign 
these addresses:

# *slattach /dev/ttyS0 &
# **ifconfig sl0 192.168.200.1 pointopoint 192.168.200.2**

*(or something like that).

If you want them to be dynamic you should use PPP but I'm guessing that's probably overkill here.


> Now, to use it in LIVE, I just need to provide the ip_addr (SLIP 
> assigne ip_addr ) and port (any numebr).
> The socket that will be created will use this port and SLIP device for 
> both tx and rx.

Yes, you just tell the Live555 RTP sender to send it to 
192.168.200.2:11111 (or whatever port).  

Regards

Paul
--
Paul Clark
Packet Ship Technologies Limited
http://www.packetship.com


From amit.yedidia at elbitsystems.com  Thu Nov 20 03:39:20 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Thu, 20 Nov 2008 13:39:20 +0200
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <f0624080bc54af8f39666@[66.80.62.44]>
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D368C@mailesl5.esl.corp.elbit.co.il>

But I am limited to 1006 bytes datagram which increase the UDP/RTP
header overhead.

Regards,


Amit Yedidia
Elbit System Ltd.

Email: amit.yedidia at elbitsystems.com
Tel: 972-4-8318905
----------------------------------------------------------

 

> -----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, November 20, 2008 1:23 PM
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live-devel] RTP sink to serial
> 
> >Just a random thought, which might save you having to have this 
> >IP-to-serial conversion process...  I don't know whether you've got 
> >control of the other end of the serial line, but could you not just 
> >set up a SLIP interface and send the RTP over that?   The Live555 
> >code would just see it as a normal IP interface.  You'd need to do 
> >this at both ends, but you could then have a standard UDP socket 
> >listener at the receiver end to receive the RTP packets.
> 
> Yes - great idea.  I definitely recommend this.  That way, you don't 
> have to write any UDP/IP parsing code at the receiving end.
> -- 
> 
> 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
> 

The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.

From paul at packetship.com  Thu Nov 20 04:16:53 2008
From: paul at packetship.com (Paul Clark)
Date: Thu, 20 Nov 2008 12:16:53 +0000
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <49254B6D.2010605@packetship.com>
References: <EB34B5A39CF26E408490ED9279BF10A71D368B@mailesl5.esl.corp.elbit.co.il>
	<49254B6D.2010605@packetship.com>
Message-ID: <49255535.4070604@packetship.com>

Paul Clark wrote:
> # *slattach /dev/ttyS0 &
> # **ifconfig sl0 192.168.200.1 pointopoint 192.168.200.2**

Apologies, my mail program added these *'s for some reason (bold text, I 
think).  The commands should be:

# slattach /dev/ttyS0 &
# ifconfig sl0 192.168.200.1 pointopoint 192.168.200.2

Paul
-- 
Paul Clark
Packet Ship Technologies Limited
http://www.packetship.com

From paul at packetship.com  Thu Nov 20 04:33:17 2008
From: paul at packetship.com (Paul Clark)
Date: Thu, 20 Nov 2008 12:33:17 +0000
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D368C@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D368C@mailesl5.esl.corp.elbit.co.il>
Message-ID: <4925590D.3020303@packetship.com>

Yedidia Amit wrote:
> But I am limited to 1006 bytes datagram which increase the UDP/RTP
> header overhead.
>   

Not exactly...  The kernels at each end should fragment/reassemble large 
UDP datagrams across multiple SLIP packets, just as they do across 
multiple Ethernet MAC frames if you send a UDP datagram more than 1472 
bytes.  There is a slight IP+SLIP overhead here, but the UDP/RTP headers 
are not repeated.

The RFC's recommended 1006 MTU doesn't apply if you're in control of 
both ends, anyway.  You can request a higher MTU with ifconfig:

# ifconfig sl0 192.168.200.1 pointopoint 192.168.200.2 mtu 8192

My kernel will accept anything up to 64K (although I haven't tested it),

Regards

Paul
--
Paul Clark
Packet Ship Technologies Limited
http://www.packetship.com

From amit.yedidia at elbitsystems.com  Thu Nov 20 06:42:04 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Thu, 20 Nov 2008 16:42:04 +0200
Subject: [Live-devel] LIVE555 to forward streams
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D368F@mailesl5.esl.corp.elbit.co.il>


Hi All (again),
I am planning to use the Live to forward RTP packets.
I know I need to build new subssesion for this job, which will connect
UDPSorce with UDPSink
My question is: can I use the same groupsock for both receiving and
sending (receive from one IP1 and sent to IP2),
or should I need 2 groupsock?

Regards,


Amit Yedidia
Elbit System Ltd.

Email: amit.yedidia at elbitsystems.com
Tel: 972-4-8318905
----------------------------------------------------------



The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081120/daa4b648/attachment-0001.html>

From finlayson at live555.com  Thu Nov 20 14:46:47 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 20 Nov 2008 16:46:47 -0600
Subject: [Live-devel] LIVE555 to forward streams
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D368F@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D368F@mailesl5.esl.corp.elbit.co.il>
Message-ID: <f06240800c54b991e3c04@[66.80.62.44]>

>I am planning to use the Live to forward RTP packets.
>
>I know I need to build new subssesion for this job, which will 
>connect UDPSorce with UDPSink
>
>My question is: can I use the same groupsock for both receiving and 
>sending (receive from one IP1 and sent to IP2),
>
>or should I need 2 groupsock?

Yes, you will need two groupsocks - one with a "RTPSource" (for 
receiving), and one with a "RTPSink" (for sending).
-- 

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/20081120/0fbaa3ae/attachment.html>

From cbitsunil at gmail.com  Thu Nov 20 23:22:38 2008
From: cbitsunil at gmail.com (sunil sunil)
Date: Fri, 21 Nov 2008 12:52:38 +0530
Subject: [Live-devel] RTP+RTCP
Message-ID: <da4a8c960811202322m1855944k6b2df673086f18a8@mail.gmail.com>

Hi,
I want to use Live555 library for MPEG2 TS streaming.
Can I use RTP along with RTCP (I do not want RTSP)?
If I use  "*testMPEG2TransportStreamer.cpp*" , I am not getting any RTCP
commands.
How can I use RTP+RTCP  in Live555 library.

Thanks and Regards,
Sunil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081121/1f03a3d3/attachment.html>

From finlayson at live555.com  Fri Nov 21 01:11:43 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 21 Nov 2008 01:11:43 -0800
Subject: [Live-devel] RTP+RTCP
In-Reply-To: <da4a8c960811202322m1855944k6b2df673086f18a8@mail.gmail.com>
References: <da4a8c960811202322m1855944k6b2df673086f18a8@mail.gmail.com>
Message-ID: <f06240804c54c2bac784b@[66.80.62.44]>

>Can I use RTP along with RTCP (I do not want RTSP)?
>If I use  "testMPEG2TransportStreamer.cpp" , I am not getting any 
>RTCP commands.

You are mistaken.  The "testMPEG2TransportStreamer" application 
*does* send RTCP packets.
-- 

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/20081121/601625de/attachment.html>

From mrcravens at verizon.net  Fri Nov 21 06:13:04 2008
From: mrcravens at verizon.net (Mike Cravens)
Date: Fri, 21 Nov 2008 08:13:04 -0600
Subject: [Live-devel] Multicasting and Live555 Media Server
Message-ID: <4926C1F0.9040405@verizon.net>

Two ( perhaps related) questions:

   1. What use , if any, of multicasting is made by the Live555 Media
      Server?
   2. We are trying to run both pre-built and locally built versions of
      Live555 media server on an Intel x86 machine on Centos 5.2.  When
      we execute the "live555MediaServer" command, we get a return
      showing 0.0.0.0 as the RTSP address: *Play streams from this
      server using the URL rtsp://0.0.0.0/<filename>.*

Needless to say, we are not able to stream our mpeg2 ts files using vlc.
We are able to stream the same file from an Ubuntu machine which we
installed a pre-built binary  (version 0.15 library version 2007.02.20).

The Ubuntu machine is ona different network with different
router/switch, etc.

Any suggestions on how to isolate the problem and/or any suggestions for
running on Centos and any ideas as to why liveMediaServer should return
an all zero address are appreciated greatly. 

Regards,

mrcravens at verizon.net
(972) 693-7799

 


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

From finlayson at live555.com  Fri Nov 21 09:55:51 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 21 Nov 2008 09:55:51 -0800
Subject: [Live-devel] Multicasting and Live555 Media Server
In-Reply-To: <4926C1F0.9040405@verizon.net>
References: <4926C1F0.9040405@verizon.net>
Message-ID: <f06240806c54ca3907483@[66.80.62.44]>

>1.	What use , if any, of multicasting is made by the Live555 Media Server?

None - the "LIVE55 Media Server" streams via unicast only.

If you want to stream via multicast, use one of the "test*Streamer" 
demo applications in the "testProgs" directory.

However, your bigger problem is the following:

>2.	We are trying to run both pre-built and locally built 
>versions of Live555 media server on an Intel x86 machine on Centos 
>5.2.  When we execute the "live555MediaServer" command, we get a 
>return showing 0.0.0.0 as the RTSP address: Play streams from this 
>server using the URL <rtsp://0.0.0.0/>rtsp://0.0.0.0/<filename>.

This shows that there's a problem (unknown) with your network 
interface, because both methods that we use to find the computer's IP 
address are failing:
1/ Sending a multicast packet, receiving it, then looking at its 
source address, and
2/ Calling "gethostname()" followed by "gethostbyname()".

Your first step should be to make sure that multicast is configured 
properly - i.e., make sure you have a route for 224.0.0/4.
-- 

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/20081121/7dcb531c/attachment.html>

From gbonneau at matrox.com  Fri Nov 21 12:43:49 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Fri, 21 Nov 2008 15:43:49 -0500
Subject: [Live-devel] Public vs Protected of StopPlaying()
Message-ID: <0CE8DD9C9E0A434DAD880F6A4ABCBCBD@dorvalmatrox.matrox.com>

While writing code using the library I ran through a minor compilation
problem where the compiler would complain about member function
StopPlaying() being protected.
 
The issue I got was causing by the library having class MediaSink declares
virtual member function StopPlaying() as public member. However in derived
class MultiFramedRTPSink it is being declared as protected. Since the method
is virtual I would have expected the method being declared as public also in
class MultiFramedRTPSink. Otherwise the only way to call StopPlaying() from
an application is to cast the derived sink implementation to a MediaSink
object. Then the protected StopPlaying() of MultiFramedRTPSink can be called
thorough public StopPlaying() of MediaSink.
 
Regards
Guy Bonneau
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081121/7bddfbd7/attachment.html>

From finlayson at live555.com  Sat Nov 22 22:48:28 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 22 Nov 2008 22:48:28 -0800
Subject: [Live-devel] Public vs Protected of StopPlaying()
In-Reply-To: <0CE8DD9C9E0A434DAD880F6A4ABCBCBD@dorvalmatrox.matrox.com>
References: <0CE8DD9C9E0A434DAD880F6A4ABCBCBD@dorvalmatrox.matrox.com>
Message-ID: <f0624080cc54eac498deb@[66.80.62.44]>

>While writing code using the library I ran through a minor 
>compilation problem where the compiler would complain about member 
>function StopPlaying() being protected.
>
>The issue I got was causing by the library having class MediaSink 
>declares virtual member function StopPlaying() as public member. 
>However in derived class MultiFramedRTPSink it is being declared as 
>protected. Since the method is virtual I would have expected the 
>method being declared as public also in class MultiFramedRTPSink.

I generally like to declare subclass implementations of virtual 
functions as "private" (or "protected"), to encourage programmers to 
write code that's more generic - by using the base class whenever 
possible.  I'm not strict about this, though, and will gladly change 
the declaration of subclass implementations whenever someone 
complains, as you did.

Therefore, I have changed the declaration of "stopPlaying()" to 
"public" in "MultiFramedRTPSink".  It will appear in the next release 
of the 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/20081122/4af6ddf7/attachment.html>

From amit.yedidia at elbitsystems.com  Sun Nov 23 02:52:36 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Sun, 23 Nov 2008 12:52:36 +0200
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <4925590D.3020303@packetship.com>
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D3695@mailesl5.esl.corp.elbit.co.il>

Thanks for the answer.
2 more:
1. Does the SLIP needs full duplex channel (I need data transfer only in
one direction)
2. If I want to add some error detection and error resilience bits,
outside the Live555 (the live will receive/send normal IP packets
from/toward the SLIP), is there clean way to implement it?


Regards,


Amit Yedidia
Elbit System Ltd.

Email: amit.yedidia at elbitsystems.com
Tel: 972-4-8318905
----------------------------------------------------------

 

> -----Original Message-----
> From: live-devel-bounces at ns.live555.com 
> [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Paul Clark
> Sent: Thursday, November 20, 2008 2:33 PM
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live-devel] RTP sink to serial
> 
> Yedidia Amit wrote:
> > But I am limited to 1006 bytes datagram which increase the UDP/RTP
> > header overhead.
> >   
> 
> Not exactly...  The kernels at each end should 
> fragment/reassemble large 
> UDP datagrams across multiple SLIP packets, just as they do across 
> multiple Ethernet MAC frames if you send a UDP datagram more 
> than 1472 
> bytes.  There is a slight IP+SLIP overhead here, but the 
> UDP/RTP headers 
> are not repeated.
> 
> The RFC's recommended 1006 MTU doesn't apply if you're in control of 
> both ends, anyway.  You can request a higher MTU with ifconfig:
> 
> # ifconfig sl0 192.168.200.1 pointopoint 192.168.200.2 mtu 8192
> 
> My kernel will accept anything up to 64K (although I haven't 
> tested it),
> 
> Regards
> 
> Paul
> --
> Paul Clark
> Packet Ship Technologies Limited
> http://www.packetship.com
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
> 

The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.

From Marc.Perrone at jci.com  Sun Nov 23 03:05:43 2008
From: Marc.Perrone at jci.com (Marc.Perrone at jci.com)
Date: Sun, 23 Nov 2008 05:05:43 -0600
Subject: [Live-devel] Marc Perrone is out of the office.
Message-ID: <OFFAB79583.121906F5-ON8625750A.003CF2C7-8625750A.003CF2C7@jci.com>


I will be out of the office starting  11/21/2008 and will not return until
12/02/2008.

I will respond to your message when I return.


From finlayson at live555.com  Sun Nov 23 08:31:58 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 23 Nov 2008 08:31:58 -0800
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D3695@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D3695@mailesl5.esl.corp.elbit.co.il>
Message-ID: <f0624080dc54f34c35df0@[66.80.62.44]>

>1. Does the SLIP needs full duplex channel (I need data transfer only in
>one direction)

Yes, you need a full duplex channel, for RTCP "Receiver Report" 
packets coming back from the receiver.  You would also need a 
full-duplex channel if you want RTP-over-TCP (see below).

>2. If I want to add some error detection and error resilience bits,
>outside the Live555 (the live will receive/send normal IP packets
>from/toward the SLIP), is there clean way to implement it?

No, not really.  But do you really expect much data loss over your 
SLIP channel?  If so, you could do RTP-over-TCP.
-- 

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

From amit.yedidia at elbitsystems.com  Sun Nov 23 21:40:46 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Mon, 24 Nov 2008 07:40:46 +0200
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <f0624080dc54f34c35df0@[66.80.62.44]>
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D369B@mailesl5.esl.corp.elbit.co.il>

Thanks Ross.
1. Does SLIP itself requires Full Duplex channel (I don't RTCP RR nor
TCP) ?
2. Yes .I do expect moderate data loss and bit errors. Any ideas?

Regards,


Amit Yedidia
Elbit System Ltd.

Email: amit.yedidia at elbitsystems.com
Tel: 972-4-8318905
----------------------------------------------------------

 

> -----Original Message-----
> From: live-devel-bounces at ns.live555.com 
> [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
> Sent: Sunday, November 23, 2008 6:32 PM
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live-devel] RTP sink to serial
> 
> >1. Does the SLIP needs full duplex channel (I need data 
> transfer only in
> >one direction)
> 
> Yes, you need a full duplex channel, for RTCP "Receiver Report" 
> packets coming back from the receiver.  You would also need a 
> full-duplex channel if you want RTP-over-TCP (see below).
> 
> >2. If I want to add some error detection and error resilience bits,
> >outside the Live555 (the live will receive/send normal IP packets
> >from/toward the SLIP), is there clean way to implement it?
> 
> No, not really.  But do you really expect much data loss over your 
> SLIP channel?  If so, you could do RTP-over-TCP.
> -- 
> 
> 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
> 

The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.

From finlayson at live555.com  Sun Nov 23 21:43:46 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 23 Nov 2008 21:43:46 -0800
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D369B@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D369B@mailesl5.esl.corp.elbit.co.il>
Message-ID: <f06240802c54fef15db9c@[66.80.62.44]>

>2. Yes .I do expect moderate data loss and bit errors. Any ideas?

Yes, use RTP-over-TCP (as I said in my previous message).  This means 
that you'll need a full-duplex connection.

And you *do* want RTCP.  RTCP is a required part of the RTP/RTCP standard.
-- 

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

From amit.yedidia at elbitsystems.com  Sun Nov 23 22:01:53 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Mon, 24 Nov 2008 08:01:53 +0200
Subject: [Live-devel] RTP sink to serial
In-Reply-To: <f06240802c54fef15db9c@[66.80.62.44]>
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D369C@mailesl5.esl.corp.elbit.co.il>

I know. Currently I working "non-standard". RTP-Over-TCP is not fitted
due to the overhead. I have very very strict limitations on my
bandwidth.

Regards,


Amit Yedidia
Elbit System Ltd.

Email: amit.yedidia at elbitsystems.com
Tel: 972-4-8318905
----------------------------------------------------------

 

> -----Original Message-----
> From: live-devel-bounces at ns.live555.com 
> [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
> Sent: Monday, November 24, 2008 7:44 AM
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live-devel] RTP sink to serial
> 
> >2. Yes .I do expect moderate data loss and bit errors. Any ideas?
> 
> Yes, use RTP-over-TCP (as I said in my previous message).  This means 
> that you'll need a full-duplex connection.
> 
> And you *do* want RTCP.  RTCP is a required part of the 
> RTP/RTCP standard.
> -- 
> 
> 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
> 

The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.

From amit.yedidia at elbitsystems.com  Sun Nov 23 22:16:23 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Mon, 24 Nov 2008 08:16:23 +0200
Subject: [Live-devel] RTSP over UDP
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D369D@mailesl5.esl.corp.elbit.co.il>


Hi All,
Does Live supports RTSP over UDP? ("rtspu://.....")?

Regards,


Amit Yedidia
Elbit System Ltd.

Email: amit.yedidia at elbitsystems.com
Tel: 972-4-8318905
----------------------------------------------------------



The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081124/341086cf/attachment.html>

From finlayson at live555.com  Sun Nov 23 22:53:51 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 23 Nov 2008 22:53:51 -0800
Subject: [Live-devel] RTSP over UDP
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D369D@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D369D@mailesl5.esl.corp.elbit.co.il>
Message-ID: <f06240803c54fffacbed8@[66.80.62.44]>

>Does Live supports RTSP over UDP? ("rtspu://?..")?

No, and it turns out that noone else supports it 
either.  That part of the RTSP 1.0 specification 
never became popular.  (It will not be part of 
RTSP 2.0 at all.)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081123/c4dd4ecd/attachment.html>

From microqq001 at gmail.com  Sun Nov 23 23:11:39 2008
From: microqq001 at gmail.com (qiqi z)
Date: Mon, 24 Nov 2008 15:11:39 +0800
Subject: [Live-devel] H264 RTP Streaming: A Tutorial
Message-ID: <78b5e57e0811232311l16323235gf80a9bcfd2fdb3c6@mail.gmail.com>

HI,everyone,

I found a tutorial at
http://lists.live555.com/pipermail/live-devel/2007-June/007030.html

but tutorial.tar.gz is no longer available, does anyone have a copy?

Thanks:)

qiqi

From amit.yedidia at elbitsystems.com  Sun Nov 23 23:42:05 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Mon, 24 Nov 2008 09:42:05 +0200
Subject: [Live-devel] H264 RTP Streaming: A Tutorial
In-Reply-To: <78b5e57e0811232311l16323235gf80a9bcfd2fdb3c6@mail.gmail.com>
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D36A1@mailesl5.esl.corp.elbit.co.il>

Seems that no one can fint this tutorial :)
You can ask what you want and we will try to answer.

Regards,


Amit Yedidia
Elbit System Ltd.

Email: amit.yedidia at elbitsystems.com
Tel: 972-4-8318905
----------------------------------------------------------

 

> -----Original Message-----
> From: live-devel-bounces at ns.live555.com 
> [mailto:live-devel-bounces at ns.live555.com] On Behalf Of qiqi z
> Sent: Monday, November 24, 2008 9:12 AM
> To: live-devel at ns.live555.com
> Subject: [Live-devel] H264 RTP Streaming: A Tutorial
> 
> HI,everyone,
> 
> I found a tutorial at
> http://lists.live555.com/pipermail/live-devel/2007-June/007030.html
> 
> but tutorial.tar.gz is no longer available, does anyone have a copy?
> 
> Thanks:)
> 
> qiqi
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
> 

The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.

From vinod.malamalvadakital at gmail.com  Mon Nov 24 07:38:12 2008
From: vinod.malamalvadakital at gmail.com (Vinod Kumar Malamal Vadakital)
Date: Mon, 24 Nov 2008 17:38:12 +0200
Subject: [Live-devel] client triggered rate increase
Message-ID: <fab773390811240738o31a1de57g78c82dfc8b6cc963@mail.gmail.com>

Hello,
    I am working on a project that requires a server to increase
transmission rate when a client requests for it. Currently my setup uses vlc
with live555 as the client and a darwin streaming server. I need to stream a
.3gp video using RTSP. Before I start this project, I would like to know if
anyone has tried doing the same and if live555 has some constraints that
might make this impossible. I am planning to extend the control function by
extending the query in live555.cpp in vlc to enable this. I have written a
piece of code that uses libvlc to start and stop media playback. It is from
this code that I would like to control the rate increase through vlc client
to DSS.

I am a newbie to live555, VLC and DSS and therefore would like to get some
experts opinion as to how to go forward the right and easy way. Please feel
free to comment.

Best Regards
Vinod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081124/c025594b/attachment-0001.html>

From charlie at sensoray.com  Mon Nov 24 11:30:10 2008
From: charlie at sensoray.com (Charlie X. Liu)
Date: Mon, 24 Nov 2008 11:30:10 -0800
Subject: [Live-devel] H264 RTP Streaming: A Tutorial
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D36A1@mailesl5.esl.corp.elbit.co.il>
References: <78b5e57e0811232311l16323235gf80a9bcfd2fdb3c6@mail.gmail.com>
	<EB34B5A39CF26E408490ED9279BF10A71D36A1@mailesl5.esl.corp.elbit.co.il>
Message-ID: <00a101c94e6b$113f7b50$33be71f0$@com>

Is this not the one:	http://www.white.ca/patrick/tutorial.tar.gz


-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Yedidia Amit
Sent: Sunday, November 23, 2008 11:42 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] H264 RTP Streaming: A Tutorial

Seems that no one can fint this tutorial :)
You can ask what you want and we will try to answer.

Regards,


Amit Yedidia
Elbit System Ltd.

Email: amit.yedidia at elbitsystems.com
Tel: 972-4-8318905
----------------------------------------------------------

 

> -----Original Message-----
> From: live-devel-bounces at ns.live555.com 
> [mailto:live-devel-bounces at ns.live555.com] On Behalf Of qiqi z
> Sent: Monday, November 24, 2008 9:12 AM
> To: live-devel at ns.live555.com
> Subject: [Live-devel] H264 RTP Streaming: A Tutorial
> 
> HI,everyone,
> 
> I found a tutorial at
> http://lists.live555.com/pipermail/live-devel/2007-June/007030.html
> 
> but tutorial.tar.gz is no longer available, does anyone have a copy?
> 
> Thanks:)
> 
> qiqi
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
> 

The information in this e-mail transmission contains proprietary and
business 
sensitive information.  Unauthorized interception of this e-mail may
constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this

communication is strictly prohibited. You are also asked to contact the
sender 
by reply email and immediately destroy all copies of the original message.
_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel



From neville.bradbury at opensoftaustralia.com.au  Mon Nov 24 22:11:02 2008
From: neville.bradbury at opensoftaustralia.com.au (neville bradbury)
Date: Tue, 25 Nov 2008 17:11:02 +1100
Subject: [Live-devel] Amino 125 model with Live555 Streaming server
Message-ID: <200811250611.mAP5KDBu016993@mail12.syd.optusnet.com.au>

Hi there,
 
We are having all sorts of problems to have a relatively smooth trick play
with the latest Live555 streaming server and the amino 125 model.
 
We have followed all the instructions we know about, re the parameters for
the .ts stream etc. But re wind and fast forward seem to break up the movies
which is not clean.
 
Can anyone give some idea of how to step by step tackle this problem.
 
Thanks Neville Bradbury.
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081125/e895967c/attachment.html>

From ggomand at info.fundp.ac.be  Tue Nov 25 03:24:22 2008
From: ggomand at info.fundp.ac.be (ggomand)
Date: Tue, 25 Nov 2008 12:24:22 +0100
Subject: [Live-devel] Jitter value with openRTSP
Message-ID: <492BE066.7090703@info.fundp.ac.be>

Hello all,

I'm writing to you regarding the jitter value calculated by openRTSP.

I've read this:

">I found out that jitter is expressed in timestamp units. Could you
 >please confirm or correct the following:
 >I divide the jitter value received by liblive by
 > 90000 for h263+, MPEG-Video JPEG-Video, MPEG-Audio
 > 8000 for AMR-NB, AMR-WB, PCMU, PCMA
 >to get the jitter in seconds.

Yes - however, it's best if you look this value (the RTP timestamp
frequency) directly, by calling "RTPSink:: rtpTimestampFrequency()"
(if you are a sender), or "RTPSource:: timestampFrequency()" (if you
are a receiver)."
source : http://osdir.com/ml/video.livedotcom.devel/2006-12/msg00003.html


In my case, I stream a mp4 video with the Helix Server 
(http://www.realnetworks.com/products/media_delivery.html)

So, to get the jitter value in seconds, I've made the following addition 
in the source code of the file "playCommon.cpp". (from line 1170 to 1175)

1165	RTPReceptionStatsDB::Iterator statsIter(src->receptionStatsDB());
1166	// Assume that there's only one SSRC source (usually the case):
1167	RTPReceptionStats* stats = statsIter.next(True);
1168	if (stats != NULL) {
1169
1170	//code added by myself
1171	double freq = src->timestampFrequency();
1172	*env << "stats->jitter()\t" << stats->jitter() << "\n";
1173	*env << "src->timestampFrequency()\t" << src->timestampFrequency() 
<< "\n";
1174	*env << "jitter (in seconds) :\t" << stats->jitter()/freq << "\n";
1175	//end of code added by myself
1176
1177	*env << "inter_packet_gap_ms_min\t" << 
stats->minInterPacketGapUS()/1000.0 << "\n";
1178	struct timeval totalGaps = stats->totalInterPacketGaps();
1179	double totalGapsMS = totalGaps.tv_sec*1000.0 + 
totalGaps.tv_usec/1000.0;
1180	unsigned totNumPacketsReceived = stats->totNumPacketsReceived();
1181	*env << "inter_packet_gap_ms_ave\t"
1182		 << (totNumPacketsReceived == 0 ? 0.0 : 
totalGapsMS/totNumPacketsReceived) << "\n";
1183	*env << "inter_packet_gap_ms_max\t" << 
stats->maxInterPacketGapUS()/1000.0 << "\n";
1184	}

I've got a timestampFrequency of 5544 (for the video subsession).
Is it normal or should it be 90000 ?

Is the code I've added is correct? It gives the jitter in seconds, right?


Another question, the fJitter value is in float, while the return value 
of the jitter() function is in integer, is it right?
Why this choice?

And my last question is, the value jitter that is given in the stats is 
the mean jitter or the last jitter?


Thank you in advance,

Gille

From finlayson at live555.com  Tue Nov 25 05:49:09 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 25 Nov 2008 05:49:09 -0800
Subject: [Live-devel] Jitter value with openRTSP
In-Reply-To: <492BE066.7090703@info.fundp.ac.be>
References: <492BE066.7090703@info.fundp.ac.be>
Message-ID: <f06240804c551b2235b26@[66.80.62.44]>

>So, to get the jitter value in seconds, I've made the following 
>addition in the source code of the file "playCommon.cpp". (from line 
>1170 to 1175)
>
>1165	RTPReceptionStatsDB::Iterator statsIter(src->receptionStatsDB());
>1166	// Assume that there's only one SSRC source (usually the case):
>1167	RTPReceptionStats* stats = statsIter.next(True);
>1168	if (stats != NULL) {
>1169
>1170	//code added by myself
>1171	double freq = src->timestampFrequency();

You probably need to explicitly convert to 'double' - i.e.
	double freq = (double)(src->timestampFrequency());
That will likely solve your problem.


>Another question, the fJitter value is in float, while the return 
>value of the jitter() function is in integer, is it right?
>Why this choice?

Because this is the code in RFC 3550, section A.8.
-- 

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

From ggomand at info.fundp.ac.be  Tue Nov 25 08:07:55 2008
From: ggomand at info.fundp.ac.be (ggomand)
Date: Tue, 25 Nov 2008 17:07:55 +0100
Subject: [Live-devel] Jitter value with openRTSP
In-Reply-To: <f06240804c551b2235b26@[66.80.62.44]>
References: <492BE066.7090703@info.fundp.ac.be>
	<f06240804c551b2235b26@[66.80.62.44]>
Message-ID: <492C22DB.2030703@info.fundp.ac.be>

Thank you for your reply.

>> So, to get the jitter value in seconds, I've made the following 
>> addition in the source code of the file "playCommon.cpp". (from line 
>> 1170 to 1175)
>>
>> 1165    RTPReceptionStatsDB::Iterator statsIter(src->receptionStatsDB());
>> 1166    // Assume that there's only one SSRC source (usually the case):
>> 1167    RTPReceptionStats* stats = statsIter.next(True);
>> 1168    if (stats != NULL) {
>> 1169
>> 1170    //code added by myself
>> 1171    double freq = src->timestampFrequency();
> 
> You probably need to explicitly convert to 'double' - i.e.
>     double freq = (double)(src->timestampFrequency());
> That will likely solve your problem.

I did it and it's the same result => timestampFrency = 5544

I've seen (thanks to wireshark) in the SDP : "Media Attribute (a): 
rtpmap:96 MP4V-ES/5544"

I've got the same output like this : 
http://lists.live555.com/pipermail/live-devel/2005-December/003732.html
(I'm using the same file "mpg4video.mp4".

Have you an idea about this? (5544 instead of 90000)

> 
>> Another question, the fJitter value is in float, while the return 
>> value of the jitter() function is in integer, is it right?
>> Why this choice?
> 
> Because this is the code in RFC 3550, section A.8.

Ok.

And my last question:
"the value jitter that is given in the stats (QoS stats) is the mean 
jitter?"

Thank you very much,

Gille

From vinod.malamalvadakital at gmail.com  Tue Nov 25 09:23:47 2008
From: vinod.malamalvadakital at gmail.com (Vinod Kumar Malamal Vadakital)
Date: Tue, 25 Nov 2008 19:23:47 +0200
Subject: [Live-devel] The role of DEMUX_CAN_CONTROL_RATE and
	DEMUX_CAN_SET_RATE in vlc
Message-ID: <fab773390811250923j76b90aa8k82d33b0e0fa9c55a@mail.gmail.com>

Hello everyone,
     I dont know if this is the right forum for this question. If not please
bear with me and point me to the right one. I am working with client
controlled rate adaptation in vlc which uses live555 libraries for RTSP
streaming. When reading the demux code live555.cpp, I came across two case
switches (that are comment out in vlc version 0.9.6). These two switches are
DEMUX_CAN_CONTROL_RATE and DEMUX_SET_RATE. Could anyone tell me if these
switches are for requesting a different transmission rate from the server?
If so why are they not enabled or if there are any problems with their
working?

Best Regards
Vinod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081125/5e98dc8a/attachment.html>

From finlayson at live555.com  Tue Nov 25 15:37:36 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 25 Nov 2008 15:37:36 -0800
Subject: [Live-devel] Jitter value with openRTSP
In-Reply-To: <492C22DB.2030703@info.fundp.ac.be>
References: <492BE066.7090703@info.fundp.ac.be>
	<f06240804c551b2235b26@[66.80.62.44]>
	<492C22DB.2030703@info.fundp.ac.be>
Message-ID: <f06240806c5523b9fd2e2@[66.80.62.44]>

>I've seen (thanks to wireshark) in the SDP : "Media Attribute (a): 
>rtpmap:96 MP4V-ES/5544"

You don't need to use wireshark to see this - you will also see it in 
the diagnostic output from "openRTSP".

Therefore, the server is telling you that the RTP timestamp frequency 
is 5544.  This is very unusual, because a timestamp frequency of 
90000 Hz is recommended, and used by everyone else (for MPEG-4 
Video), as far as I know.

>And my last question:
>"the value jitter that is given in the stats (QoS stats) is the mean jitter?"

It's a weighted average, as described in RFC 3550, section A.8.
-- 

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

From finlayson at live555.com  Tue Nov 25 17:13:41 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 25 Nov 2008 17:13:41 -0800
Subject: [Live-devel] The role of DEMUX_CAN_CONTROL_RATE and
 DEMUX_CAN_SET_RATE in vlc
In-Reply-To: <fab773390811250923j76b90aa8k82d33b0e0fa9c55a@mail.gmail.com>
References: <fab773390811250923j76b90aa8k82d33b0e0fa9c55a@mail.gmail.com>
Message-ID: <f06240808c552531be93a@[66.80.62.44]>

>      I dont know if this is the right forum for this question.

Sorry, it's not.  Questions about VLC (including the VLC code that 
interfaces to our libraries) should be sent to a VLC mailing list.
-- 

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

From domentarion at live.nl  Tue Nov 25 21:48:44 2008
From: domentarion at live.nl (Sander den Breejen)
Date: Wed, 26 Nov 2008 05:48:44 +0000
Subject: [Live-devel] Welcome to the "live-devel" mailing list
In-Reply-To: <mailman.0.1227678530.49763.live-devel@lists.live555.com>
References: <mailman.0.1227678530.49763.live-devel@lists.live555.com>
Message-ID: <BAY108-W24F375330E8BBBC08B82C5A20A0@phx.gbl>


Can you tell me how ? I have another question about the 'trick play' support. I have a amino 110H , witchplays my movies when i use fast forward the stream stop and when i push play is starts again. Why does the stream stop ? I wannee see that my movie goes fast forward.Or is this problem the aminobox ?Sander"It Can't Rain All The Time"
_________________________________________________________________
Zoek en win prachtige prijzen met Lucky Search!
http://www.luckysearch.nl/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081126/c761edef/attachment-0001.html>

From microqq001 at gmail.com  Tue Nov 25 22:01:53 2008
From: microqq001 at gmail.com (qiqi z)
Date: Wed, 26 Nov 2008 14:01:53 +0800
Subject: [Live-devel] H264 RTP Streaming: A Tutorial
In-Reply-To: <00a101c94e6b$113f7b50$33be71f0$@com>
References: <78b5e57e0811232311l16323235gf80a9bcfd2fdb3c6@mail.gmail.com>
	<EB34B5A39CF26E408490ED9279BF10A71D36A1@mailesl5.esl.corp.elbit.co.il>
	<00a101c94e6b$113f7b50$33be71f0$@com>
Message-ID: <78b5e57e0811252201q45c8c491t2d55a1bb3403bd@mail.gmail.com>

But it has been broken.:(

On 11/25/08, Charlie X. Liu <charlie at sensoray.com> wrote:
> Is this not the one:	http://www.white.ca/patrick/tutorial.tar.gz
>
>
> -----Original Message-----
> From: live-devel-bounces at ns.live555.com
> [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Yedidia Amit
> Sent: Sunday, November 23, 2008 11:42 PM
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live-devel] H264 RTP Streaming: A Tutorial
>
> Seems that no one can fint this tutorial :)
> You can ask what you want and we will try to answer.
>
> Regards,
>
>
> Amit Yedidia
> Elbit System Ltd.
>
> Email: amit.yedidia at elbitsystems.com
> Tel: 972-4-8318905
> ----------------------------------------------------------
>
>
>
>> -----Original Message-----
>> From: live-devel-bounces at ns.live555.com
>> [mailto:live-devel-bounces at ns.live555.com] On Behalf Of qiqi z
>> Sent: Monday, November 24, 2008 9:12 AM
>> To: live-devel at ns.live555.com
>> Subject: [Live-devel] H264 RTP Streaming: A Tutorial
>>
>> HI,everyone,
>>
>> I found a tutorial at
>> http://lists.live555.com/pipermail/live-devel/2007-June/007030.html
>>
>> but tutorial.tar.gz is no longer available, does anyone have a copy?
>>
>> Thanks:)
>>
>> qiqi
>> _______________________________________________
>> live-devel mailing list
>> live-devel at lists.live555.com
>> http://lists.live555.com/mailman/listinfo/live-devel
>>
>
> The information in this e-mail transmission contains proprietary and
> business
> sensitive information.  Unauthorized interception of this e-mail may
> constitute
> a violation of law. If you are not the intended recipient, you are hereby
> notified that any review, dissemination, distribution or duplication of this
>
> communication is strictly prohibited. You are also asked to contact the
> sender
> by reply email and immediately destroy all copies of the original message.
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>

From amit.yedidia at elbitsystems.com  Wed Nov 26 03:04:39 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Wed, 26 Nov 2008 13:04:39 +0200
Subject: [Live-devel] RTSP over UDP
In-Reply-To: <f06240803c54fffacbed8@[66.80.62.44]>
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D36B4@mailesl5.esl.corp.elbit.co.il>

If I will write new SetUpOurSocket() that will create new UDP socket (instead TCP), and the RTSP Server will listen tothis socket.
Will it work?
Are there any other changes that must be don?
 

Regards,


Amit Yedidia

Elbit System Ltd.

Email: amit.yedidia at elbitsystems.com

Tel: 972-4-8318905

----------------------------------------------------------

 


________________________________

	From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
	Sent: Monday, November 24, 2008 8:54 AM
	To: LIVE555 Streaming Media - development & use
	Subject: Re: [Live-devel] RTSP over UDP
	
	

		Does Live supports RTSP over UDP? ("rtspu://?..")?


	No, and it turns out that noone else supports it either.  That part of the RTSP 1.0 specification never became popular.  (It will not be part of RTSP 2.0 at all.)
	-- 

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


The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081126/7c22792e/attachment.html>

From anto.rizzo at caramail.com  Wed Nov 26 04:05:27 2008
From: anto.rizzo at caramail.com (Antonella Rizzo)
Date: Wed, 26 Nov 2008 13:05:27 +0100
Subject: [Live-devel] RTCP
Message-ID: <162949746054969@lycos-europe.com>

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

From rishikerala at gmail.com  Wed Nov 26 05:18:01 2008
From: rishikerala at gmail.com (Rishi kerala)
Date: Wed, 26 Nov 2008 18:48:01 +0530
Subject: [Live-devel] Regarding a help
Message-ID: <4ba29cc0811260518w7d4e5a8bha67ef386cc614da9@mail.gmail.com>

Dear All,

I am getting an error like below when I run testWavStreamer application
00:48:51 Groupsock(4: 232.139.177.210, 2222, 255): failed to join group:
setsockopt(IP_ADD_MEMBERSHIP) error: No such device
00:48:51 Groupsock(5: 232.139.177.210, 2223, 255): failed to join group:
setsockopt(IP_ADD_MEMBERSHIP) error: No such device

could anyone tell me the what will be the problem ..

I am able to ping to the ip even I am also able to file transfer from the
this IP


Thanks
Nimesh Kanoth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081126/885b9864/attachment.html>

From finlayson at live555.com  Wed Nov 26 06:00:37 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 26 Nov 2008 06:00:37 -0800
Subject: [Live-devel] RTCP
In-Reply-To: <162949746054969@lycos-europe.com>
References: <162949746054969@lycos-europe.com>
Message-ID: <f06240802c5530407d577@[66.80.62.44]>

>I want send RTCP report to my server.
>So, I call myRTCTInstance->sendReport

You don't need to do this.  Just creating a "RTCPInstance" for your 
"RTPSource", and RTCP (Reception) reports will get sent 
automatically.  You should never call "RTCPInstance::sendReport()" 
yourself.

>  but It send UDP packet to a multicast adress (224.2.2.2) and not at 
>server unicast adress.
>Why?

Because that's the way that RTCP works for ASM ("any-source 
multicast") sessions.

>My server send me packet on 6666 port( audio) and 8888 port (video), 
>so I store packets rtp in two files.
>Every for example 100 received packets, I want send an rtcp report 
>to sync audio and video when I relay this packets to another client!

Only the server sends such RTCP reports; clients do not.
-- 

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

From Kris.delbarba at lextech.com  Wed Nov 26 09:19:33 2008
From: Kris.delbarba at lextech.com (Kris DelBarba)
Date: Wed, 26 Nov 2008 11:19:33 -0600
Subject: [Live-devel] MJPEG and RTSP
Message-ID: <856D0108-0F3B-4575-988E-522DC69CE262@lextech.com>

I'm working on trying to setup a MJPEG player over RTP/RTSP but I am  
having difficulty finding/creating a sample MJPEG stream over RTSP/ 
RTP.  What tools and or solutions would you recommend. If you know of  
a test stream I could connect to and try I would appreciate it.

Thanks,

Kris DelBarba


From gbonneau at matrox.com  Wed Nov 26 14:10:34 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Wed, 26 Nov 2008 17:10:34 -0500
Subject: [Live-devel] Live555 Compilation for VLC in cygwin
Message-ID: <CBC4A482E19548A0B9181007E843384E@dorvalmatrox.matrox.com>

I have had to compile VLC media player with a new version of live555 under
cygwin context development. I have to say that even with all the information
on Wikipedia it was quite an headache. I ran through many setup issues with
both VLC player and the live555 library. Even with the Wikipedia
documentation of the VLC team I couldn't have live555 successfully link with
VLC player without having a lot of undefined.
 
It took me a few days and a lot of googling to resolve all the issues. After
looking at what I needed to resolve my linking problems it didn't seem a big
deal. But for a newbie in cygwin development I was bewildered by the setting
needed for successfully compiling the live555 for VLC media player. 
 
While googling I found that a lot of people ran through the same issues I
have had. In some cases people took days to resolve their issues. Problem is
that no posting anywhere give the whole clue about how to solve this
confusing puzzle of compilation setup with live555 library. You have the
find the pieces everywhere around the web.
 
Giving the widespread of VLC and it dependence on live555 library I would
suggest that a config file to compile the live555 for VLC with cygwin be
included with the library. I have included such a template as an attachment.
Here is my setting to successfully compile the live555 for VLC under cygwin.
 
I know this could have been posted to VLC forums. However my feeling is that
people will also look in live555 email archive for a solution.
 
Regards
Guy Bonneau
 
COMPILE_OPTS =    $(INCLUDES) -I. -O -DSOCKLEN_T=socklen_t
C =  c
C_COMPILER =  gcc
C_FLAGS =  $(COMPILE_OPTS) -DUSE_OUR_BZERO=1 -D_WIN32 -mno-cygwin
CPP =   cpp
CPLUSPLUS_COMPILER =  c++
CPLUSPLUS_FLAGS =  $(COMPILE_OPTS) -Wall -DBSD=1 -D_WIN32 -Wno-deprecated
-mno-cygwin
OBJ =   o
LINK =  c++ -o
LINK_OPTS =  -L.
CONSOLE_LINK_OPTS = $(LINK_OPTS)
LIBRARY_LINK =   ld -o
LIBRARY_LINK_OPTS =  $(LINK_OPTS) -r -Bstatic
LIB_SUFFIX =  a
LIBS_FOR_CONSOLE_APPLICATION =
LIBS_FOR_GUI_APPLICATION =
EXE = 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081126/53cf6249/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.cygwin-vlc
Type: application/octet-stream
Size: 497 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081126/53cf6249/attachment-0001.obj>

From finlayson at live555.com  Wed Nov 26 17:03:34 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 26 Nov 2008 17:03:34 -0800
Subject: [Live-devel] Live555 Compilation for VLC in cygwin
In-Reply-To: <CBC4A482E19548A0B9181007E843384E@dorvalmatrox.matrox.com>
References: <CBC4A482E19548A0B9181007E843384E@dorvalmatrox.matrox.com>
Message-ID: <f06240801c553a0da5850@[66.80.62.44]>

I don't want to add - to our distribution - anything that's specific 
to VLC, because (i) VLC is only one of the many 3rd party 
applications that use our code, and (ii) because VLC is not our code, 
it is difficult to keep track of if/when any VLC dependent code of 
ours will continue to be correct.

The only difference between your config file and the existing 
"config.cygwin" is in the definition of C_FLAGS and CPLUSPLUS_FLAGS. 
Therefore I wonder: Will your "config.cygwin-vlc" work for building 
the "LIVE555 Streaming Media" code - including the "testProgs" - by 
itself, without VLC?  If so, then I could just replace our 
"config.cygwin" with your config file.  Please let me know if I can 
go ahead and do this.
-- 

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

From vinod.malamalvadakital at gmail.com  Thu Nov 27 01:26:52 2008
From: vinod.malamalvadakital at gmail.com (Vinod Kumar Malamal Vadakital)
Date: Thu, 27 Nov 2008 11:26:52 +0200
Subject: [Live-devel] roles of DEMUX_CAN_CONTROL_RATE and DEMUX_SET_RATE in
	live555.cpp?
Message-ID: <fab773390811270126i22fea658l39a1659b00d2d2ab@mail.gmail.com>

Hello everyone,
I am working with client controlled rate adaptation in vlc which uses
live555 libraries for RTSP streaming. When reading the demux code :
live555.cpp, I came across two case switches (that are comment out in vlc
version 0.9.6). These two switches are DEMUX_CAN_CONTROL_RATE and
DEMUX_SET_RATE. Could anyone tell me if these switches are for requesting a
different transmission rate from the server? If so why are they not enabled
or if there are any problems with their working?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081127/5f3e8d59/attachment.html>

From vinod.malamalvadakital at gmail.com  Thu Nov 27 01:29:03 2008
From: vinod.malamalvadakital at gmail.com (Vinod Kumar Malamal Vadakital)
Date: Thu, 27 Nov 2008 11:29:03 +0200
Subject: [Live-devel] Sorry, Please ignore my previous mail
Message-ID: <fab773390811270129v5c0605a8ua73ee5481c545676@mail.gmail.com>

Hello
I am sorry, my previous mail was for vlc-devel and not for this forum. Sorry
about the mistake.
BR
Vinod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081127/78ca3f0a/attachment.html>

From juanfhj at yahoo.com  Thu Nov 27 05:46:43 2008
From: juanfhj at yahoo.com (Juan F. Herrera)
Date: Thu, 27 Nov 2008 05:46:43 -0800 (PST)
Subject: [Live-devel] LIVE555 usage scenarios, live streaming
Message-ID: <253150.21383.qm@web54012.mail.re2.yahoo.com>

Hi. I want to try
LIVE555 for live streaming of college lectures (with custom mods), and I?m considering these scenarios, based on the
test programs:
 
(A)
+----+-------+--------+----------+---------+------+---------+-------+
|    |Whole  |        |          |         |      |Test     |       |
|Live|bitmap |        |MPEG      |         |RTP   |MPEG1or2 |       |
|Cam |frames |        |(1,2)     |         |stream|Video    |       |
|    |(DS    |FFmpeg  |FFmpeg    |Mod of   |port  |Receiver |       |
|Win |Video  |        |video     |test     |6666  |(to      |Mplayer|
|dows|Lib)   |        |elementary|MPEG1or2
|      |stdout)  |       |
+----+-------+--------+----------+Audio    +------+---------+       |
|    |       |        |          |Streamer |      |TestMP3  |       |
|Live|       |        |          |         |RTP   |Receiver |       |
|Mic |Audio  | LAME   |MP3       |         |stream|(to      |       |
|    |       |        |audio     |         |port  |stdout)  |       |
|    |       |        |elementary|         |8888  |         |       |
+----+-------+--------+----------+---------+------+---------+-------+
                                 |Built-in
|      |RTSP     |
                                 |RTSP     |      |client   |
                                 |server   |      |         |
                                 +---------+      +---------+
 
(B)
+----+-------+--------+----------+---------+------+-------+
|    |       |        |          |         |      |       |
|Live|       |        |MPEG      |         |RTP   |       |
|Cam |Whole  |        |(1,2)     |testMPEG4|stream|       |
|    |Bitmap
|FFmpeg  |FFmpeg    |Video    |port  |       |
|Win |frames |        |video     |Streamer |6666  |       |
|dows|       |        |elementary|         |      |       |
+----+-------+--------+----------+---------+------+Mplayer|
|    |       |        |          |testMP3  |      |       |
|Live|       |        |          |Streamer |RTP   |       |
|Mic |Audio  | LAME   |MP3       |         |stream|       |
|    |       |        |audio     |         |port  |       |
|    |       |        |elementary|         |8888  |       |
+----+-------+--------+----------+---------+------+-------+
                      |          |         
                      |RTSP      |       
                      |server    |        
                      +----------+      
 
(C)
+----+-------+--------+----------+---------+------+---------+-------+
|    |       |        |          |         |      |Test     |       |
|Live|       |        |          |         |RTP   |MPEG1or2 |       |
|Cam |Whole  |        |          |         |stream|Video    |       |
|    |Bitmap
|FFmpeg  |MPEG4     |testMPEG4|port  |Receiver |       |
|Win |frames |        |video     |Video    |6666  |(to      |Mplayer|
|dows|       |        |elementary|Streamer
|      |stdout)  |       |
+----+-------+--------+----------+---------+------+---------+       |
|    |       |        |          |         |      |TestMP3  |       |
|Live|       |        |          |testMP3  |RTP   |Receiver |       |
|Mic |Audio  | LAME   |MP3       |Streamer |stream|(to      |       |
|    |       |        |audio     |         |port  |stdout)  |       |
|    |       |        |elementary|         |8888  |         |       |
+----+-------+--------+----------+---------+------+---------+-------+
                                 |Built-in |      |RTSP     |
                                 |RTSP     |      |client   |
                                 |server   |      |         |
                                 +---------+      +---------+

I thought I could study from source and docs and modding the test programs, but at this point I'm
still shopping for engines, so I wanted to ask before going deeper in trial and error.
 
Help very much appreciated

Thanks
 
Juan Herrera 
Universidad de Antioquia
Columbia

(On the other hand, if someone has an implementation, I would like to ask whether I could take a look at the code.)



      

From gbonneau at matrox.com  Thu Nov 27 07:53:02 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Thu, 27 Nov 2008 10:53:02 -0500
Subject: [Live-devel] Live555 Compilation for VLC in cygwin
In-Reply-To: <f06240801c553a0da5850@[66.80.62.44]>
References: <CBC4A482E19548A0B9181007E843384E@dorvalmatrox.matrox.com>
	<f06240801c553a0da5850@[66.80.62.44]>
Message-ID: <FED883CB8FB2412AB0BD99508C028174@dorvalmatrox.matrox.com>

No don't!

Adding the -mno-cygwin and -D_WIN32 create a context that seems to bypass
the cygwin layer to win32 api. Which VLC seems to do for the network stuff
of live555 library. It would be possible to have the live555 testing
applications link without error by using the w32api libraries of cygwin (I
tried). But this would need more modifications to the config.cygwin that
will likely break many third party applications that use the full standard
context of cygwin and don't want to bypass the cygwin layer.

I believe it would be possible to modify the config.cygwin file such that it
could support both context options. May be by using some environment
variable defining the context in cygwin to be use. But I have not enough
understanding of cygwin development to do it with confidence that I will not
break anything. May be if there is a VLC developer on this list and that he
finds that this is "his cup of tea" and want to do it.

Regards
Guy Bonneau 

> -----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, November 26, 2008 8:04 PM
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live-devel] Live555 Compilation for VLC in cygwin
> 
> I don't want to add - to our distribution - anything that's 
> specific to VLC, because (i) VLC is only one of the many 3rd 
> party applications that use our code, and (ii) because VLC is 
> not our code, it is difficult to keep track of if/when any 
> VLC dependent code of ours will continue to be correct.
> 
> The only difference between your config file and the existing 
> "config.cygwin" is in the definition of C_FLAGS and CPLUSPLUS_FLAGS. 
> Therefore I wonder: Will your "config.cygwin-vlc" work for 
> building the "LIVE555 Streaming Media" code - including the 
> "testProgs" - by itself, without VLC?  If so, then I could 
> just replace our "config.cygwin" with your config file.  
> Please let me know if I can go ahead and do 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 finlayson at live555.com  Thu Nov 27 14:56:33 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 27 Nov 2008 14:56:33 -0800
Subject: [Live-devel] Live555 Compilation for VLC in cygwin
In-Reply-To: <FED883CB8FB2412AB0BD99508C028174@dorvalmatrox.matrox.com>
References: <CBC4A482E19548A0B9181007E843384E@dorvalmatrox.matrox.com>
	<f06240801c553a0da5850@[66.80.62.44]>
	<FED883CB8FB2412AB0BD99508C028174@dorvalmatrox.matrox.com>
Message-ID: <f06240809c554d441311a@[66.80.62.44]>

>No don't!

OK, I won't.

What's puzzling me here is that the VLC people use Cygwin all the 
time to build VLC (including the "LIVE555 Streaming Media" libraries) 
for Windows.  So they must have a well-established procedure for 
doing this.  I suggest that you look more into this; I doubt that you 
really have to conjour up your own configuration file for doing this.
-- 

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

From gbonneau at matrox.com  Fri Nov 28 13:59:37 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Fri, 28 Nov 2008 16:59:37 -0500
Subject: [Live-devel] Live555 Compilation for VLC in cygwin
In-Reply-To: <f06240809c554d441311a@[66.80.62.44]>
References: <CBC4A482E19548A0B9181007E843384E@dorvalmatrox.matrox.com><f06240801c553a0da5850@[66.80.62.44]><FED883CB8FB2412AB0BD99508C028174@dorvalmatrox.matrox.com>
	<f06240809c554d441311a@[66.80.62.44]>
Message-ID: <DF356496C004489084487C417966FD50@dorvalmatrox.matrox.com>

> What's puzzling me here is that the VLC people use Cygwin all 
> the time to build VLC (including the "LIVE555 Streaming 
> Media" libraries) for Windows.  So they must have a 
> well-established procedure for doing this.  

My understanding is that they use the Cygwin development tools 
to create an executable that doesn't depends on Cygwin DLL. I
mean they don't use the Posix layer of Cygwin. So this seems to be a 
cross-compilation of a "mingw executable" on the Cygwin platform.

There is a FAQ section on the minGW FAQ about this: here is an
Excerpt: 

...For those who would like to use the Cygwin environment 
for development, yet generate non-Cygwin-dependant executables, 
a much easier option to "-mno-cygwin" does exist...

What procedure are using the VLC team? Well as I said previously
the documentation is not clear on this. Do they change the
config.cygwin like I did? Do they use their own makefile?
I really don't know. Just hope that what I found could help
other if they want to "cross-compile" live555 on Cygwin for
VLC Media Player.

Regards
Guy Bonneau


I suggest that 
> you look more into this; I doubt that you really have to 
> conjour up your own configuration file for doing 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 finlayson at live555.com  Sat Nov 29 00:27:15 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 29 Nov 2008 00:27:15 -0800
Subject: [Live-devel] Live555 Compilation for VLC in cygwin
In-Reply-To: <DF356496C004489084487C417966FD50@dorvalmatrox.matrox.com>
References: <CBC4A482E19548A0B9181007E843384E@dorvalmatrox.matrox.com><f06240801c553a0
	da5850@[66.80.62.44]><FED883CB8FB2412AB0BD99508C028174@dorvalmatrox.matrox
	.com>	<f06240809c554d441311a@[66.80.62.44]>
	<DF356496C004489084487C417966FD50@dorvalmatrox.matrox.com>
Message-ID: <f06240802c556ad2456b4@[66.80.62.44]>

>What procedure are using the VLC team? Well as I said previously
>the documentation is not clear on this. Do they change the
>config.cygwin like I did? Do they use their own makefile?
>I really don't know.

Neither do I.  But you should find this out by asking on the 
"vlc-devel at videolan.org" mailing list - not this one.
-- 

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

From amit.yedidia at elbitsystems.com  Sun Nov 30 23:23:32 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Mon, 1 Dec 2008 09:23:32 +0200
Subject: [Live-devel] Multicast session question
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D36C4@mailesl5.esl.corp.elbit.co.il>


Hi,

Following my previous questions I want to create a situation where one
source is sent to two different multicast address.
For that I am using passiveMediaSubsession where I add both destination
to the sink.

I want to generate 2 sessions that whoever asks "describe" for the first
will receive in the sdp the first multicast address,
and whoever asks "describe" for the second session will receive in the
sdp the second multicast address.

1. Is it possible? My problem is that passiveMediaSubsession->sdpLines()
doesn't know who called it (which sessionID)
2. which address does live returns for simple describe request? (as I
can see it returns only one address).

Regards,

Amit Yedidia



The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081201/5a3aa32c/attachment-0001.html>