From Bernhard at Feiten.de  Wed Oct  1 00:17:06 2008
From: Bernhard at Feiten.de (Bernhard Feiten)
Date: Wed, 1 Oct 2008 09:17:06 +0200
Subject: [Live-devel] Media stream duplication on a streaming relay
References: <1134049882.43983a5aa6b32@imp4-g19.free.fr><6.2.3.4.1.20051208104044.032296d0@localhost><00e901c8d74d$6de53290$d302a8c0@Popelfranz><00b201c8f852$b7388340$d302a8c0@Popelfranz>
	<00d301c8fb7d$1389c960$d302a8c0@Popelfranz>
Message-ID: <005e01c92395$b6e526a0$d302a8c0@Popelfranz>

Attached an update of the sources. Working for audio and video now.
Comments are are welcomed.
Bernhard

----- Original Message ----- 
From: "Bernhard Feiten" <Bernhard at feiten.de>
To: "LIVE555 Streaming Media - development & use" 
<live-devel at ns.live555.com>
Sent: Monday, August 11, 2008 8:39 AM
Subject: Re: [Live-devel] Media stream duplication on a streaming relay


> Dear Ross, all,
>
> attached you find a first uncomplete version of the StreamDup classes.
> Perhpas you have some comments.  Is this in principle a way how to do it?
> I'm quite unsure what needs to be regarded concerning the getNextFrame,
> aftergetting  filter chain mechanism.
>
> Audio is working, but when I also activate the  video branch it crashes in
> H264VideoRTPSink
> Must be error,  perhaps also somwhere else in my code.
>
> Thank you for your comments,
>
> Bernhard
>
>
>
>
> ----- Original Message ----- 
> From: "Bernhard Feiten" <Bernhard at feiten.de>
> To: "LIVE555 Streaming Media - development & use"
> <live-devel at ns.live555.com>
> Sent: Thursday, August 07, 2008 7:59 AM
> Subject: Re: [Live-devel] Media stream duplication on a streaming relay
>
>
>> Dear Ross, all,
>>
>> as nobody answered I started to write a  StreamDup class following your
>> hints from the e-mail below.
>>
>> Related to that I have two questions?
>> Would it be required that the sequnce number and timestamp of the
>> duplicates are newly initialized?
>> Would RTCP also need to be considered then?
>>
>> Thank you in advance,
>> Bernhard
>>
>>
>> ----- Original Message ----- 
>> From: "Bernhard Feiten" <Bernhard at feiten.de>
>> To: "LIVE555 Streaming Media - development & use"
>> <live-devel at ns.live555.com>
>> Sent: Thursday, June 26, 2008 7:28 AM
>> Subject: Re: [Live-devel] Media stream duplication on a streaming relay
>>
>>
>>> Dear Ross, all,
>>>
>>> did somebody wrote the StreamDuplication class you proposed below
>>> already?
>>>
>>> Do you have a hint how the getNextFrame functions could be synchronized?
>>>
>>> Thank  you very much,
>>> Bernhard
>>>
>>>
>>>
>>>
>>> ----- Original Message ----- 
>>> From: "Ross Finlayson" <finlayson at live555.com>
>>> To: "LIVE555 Streaming Media - development & use"
>>> <live-devel at ns.live555.com>
>>> Sent: Thursday, December 08, 2005 8:57 PM
>>> Subject: Re: [Live-devel] Media stream duplication on a streaming relay
>>>
>>>
>>>> As you noticed, you can't duplicate a stream by having each recipient
>>>> read from a single object, because "getNextFrame()" can't be called 
>>>> more
>>>> than once on the same object concurrently.
>>>>
>>>> The solution, instead, is to create a separate object (of some
>>>> "FramedSource" subclass) for each recipient.  This new class would
>>>> implement the "doGetNextFrame()" virtual function by somehow
>>>> 'registering' with the data source object - to request a copy of the
>>>> next incoming frame.
>>>>
>>>> The data source object (which would *not* be a subclass of
>>>> "FramedSource", and so would not implement "doGetNextFrame()") would
>>>> handle these requests by delivering copies of each incoming frame to
>>>> each recipient, and not ask for a new incoming frame (from its upstream
>>>> data source) until it has finished delivering data to each downstream
>>>> recipient.
>>>>
>>>> For an example of code that is similar to this, note the relationship
>>>> between the "MPEG1or2Demux" and "MPEG1or2DemuxedElementaryStream"
>>>> classes. (In this case, however, we are demultiplexing data to
>>>> downstream recipients, rather than duplicating it.)  Note in particular
>>>> that (i) "MPEG1or2Demux" is subclassed from "Medium", not
>>>> "FramedSource", and (ii) "MPEG1or2Demux" implements a "getNextFrame()"
>>>> function that is similar to, but different from
>>>> "FramedSource::getNextFrame()".
>>>>
>>>> (This functionality (data duplication) is something that should 
>>>> probably
>>>> be added to the library someday.  Until then, however, you will need to
>>>> implement it yourself.)
>>>>
>>>>
>>>> Ross Finlayson
>>>> Live Networks, Inc. (LIVE555.COM)
>>>> <http://www.live555.com/>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: StreamDup.h
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081001/a29fff23/attachment.h>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: StreamDup.cpp
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081001/a29fff23/attachment.ksh>

From emanuele.b at automaonline.com  Wed Oct  1 02:27:32 2008
From: emanuele.b at automaonline.com (emanuele bottegoni)
Date: Wed, 01 Oct 2008 11:27:32 +0200
Subject: [Live-devel] Mplayer and SDP
Message-ID: <WorldClient-F200810011127.AA27320227@automaonline.com>

Hello developers!

I need to solve an issue regarding the local playing of both audio and
video streams.
I have a an audio/video Intercom (using SIP/SDP protocols) that is
connected in P2P to a lightweight SIP UA (PJSIP).
When the communication starts I can play the H264 video launching:

mplayer -fps 10 sdp:///home/ema/123-pj.sdp 

with the following sdp file:

v=0

o=- 3429958819 3429958820 IN IP4 192.168.100.183

s=pjmedia

c=IN IP4 192.168.100.183

t=0 0

a=X-nat:0
m=video 1234 RTP/AVP 126 125

a=rtpmap:126 H264/90000

a=fmtp:126 profile-level-id=42801E; packetization-mode=1

a=rtpmap:125 H264/90000

a=fmtp:125 profile-level-id=42801E; packetization-mode=0

a=recvonly


Now I want Mplayer plays also the ulaw (or alaw) audio stream coming in
from the intercom.
I've added some lines to the mentioned sdp file, but I get always the same
error.
The lines added are:

m=audio 4002 RTP/AVP 0 101

a=rtcp:4003 IN IP4 192.168.100.183

a=rtpmap:0 PCMU/8000

a=sendrecv

a=rtpmap:101 telephone-event/8000

and the log error is:

Failed to initiate "audio/PCMU" RTP subsession: getsockname() error: Bad
file descriptor

I've tried some modifications of the audio lines but I get always the same
error.

Anyone can suggest me the correct solution?

CHEERS

Emanuele



From finlayson at live555.com  Wed Oct  1 02:32:56 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 01 Oct 2008 02:32:56 -0700
Subject: [Live-devel] HTTP Tunneling
In-Reply-To: <002d01c9238d$afab2680$4d053c0a@telxsi.com>
References: <002d01c9238d$afab2680$4d053c0a@telxsi.com>
Message-ID: <200810010937.m919b4Gq086930@ns.live555.com>


>I would like to know if the Live555 code supports RTSP Tunneling over HTTP.
>Also,if the Section 10.12 in RFC2326(Binary interleaved data method) is laso
>well supported
>by live555.

Yes, we support both (although RTSP-over-HTTP tunneling is not yet 
fully implemented at the server end).


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From finlayson at live555.com  Wed Oct  1 03:04:23 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 01 Oct 2008 03:04:23 -0700
Subject: [Live-devel] Mplayer and SDP
In-Reply-To: <WorldClient-F200810011127.AA27320227@automaonline.com>
References: <WorldClient-F200810011127.AA27320227@automaonline.com>
Message-ID: <200810011007.m91A7J53018514@ns.live555.com>

At 02:27 AM 10/1/2008, you wrote:
>c=IN IP4 192.168.100.183

This is a unicast IP address.  You can't (in general) play a unicast 
stream just by reading a SDP description, because the SDP description 
does not, by itself, contain enough information about the stream 
endpoints.  Instead, to play a unicast stream, you usually need to 
use the SIP or RTSP protocols.

If, however, you make your stream multicast (i.e.,  using IP 
multicast addresses), you can probably play it from a SDP description.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From emanuele.b at automaonline.com  Wed Oct  1 03:56:08 2008
From: emanuele.b at automaonline.com (emanuele bottegoni)
Date: Wed, 01 Oct 2008 12:56:08 +0200
Subject: [Live-devel] Mplayer and SDP
Message-ID: <WorldClient-F200810011256.AA56080248@automaonline.com>

So with the unicast address mplayer and sdp works well.
Can I try to play the audio with sip protocol?

How CAN i do?




From emanuele.b at automaonline.com  Wed Oct  1 03:57:35 2008
From: emanuele.b at automaonline.com (emanuele bottegoni)
Date: Wed, 01 Oct 2008 12:57:35 +0200
Subject: [Live-devel] Mplayer and SDP
Message-ID: <WorldClient-F200810011257.AA57350249@automaonline.com>

I mean only the video works well in unicast.

Cheers



From finlayson at live555.com  Wed Oct  1 06:32:47 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 01 Oct 2008 06:32:47 -0700
Subject: [Live-devel] Mplayer and SDP
In-Reply-To: <WorldClient-F200810011256.AA56080248@automaonline.com>
References: <WorldClient-F200810011256.AA56080248@automaonline.com>
Message-ID: <200810011337.m91Dbd4m038329@ns.live555.com>

If you are able to play a unicast stream just by reading a SDP 
description, then that's solely by accident, and we do not support 
it.  If you want to reliably play a unicast stream, use the RTSP or 
SIP protocols.  (Note that MPlayer and VLC support RTSP, but not 
SIP.)  If you want to reliably play a stream just by reading a SDP 
descrpition, then you should make the stream multicast, rather than unicast.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From matt at schuckmannacres.com  Wed Oct  1 10:54:13 2008
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Wed, 01 Oct 2008 10:54:13 -0700
Subject: [Live-devel] Problem streaming a live H.264 stream to VLC
Message-ID: <48E3B945.1060108@schuckmannacres.com>

I'm working on prototyping a live H.264 streaming application using the 
LiveMedia rtsp/rtp library and the X264 encoder.
I've written my h264Framer class and integrated it into the 
testOnDemandRTSPServer and I can successfully stream the data to the 
OpenRTSP test application.
However, when I try to open the stream using VLC it only displays the 
first frame and nothing more.
If I open the messages window for VLC I see a whole bunch of messages 
like these

main warning: late picture skipped (266012)
main warning: late picture skipped (266000)
main warning: late picture skipped (266000)
main warning: late picture skipped (282000)
main warning: late picture skipped (250000)
main warning: late picture skipped (250000)
main warning: late picture skipped (250000)
ffmpeg warning: Unknown NAL code: 0
 (h264 at 00B22B60)
ffmpeg warning: Unknown NAL code: 0
 (h264 at 00B22B60)
main warning: late picture skipped (316000)
main warning: late picture skipped (250000)
ffmpeg error: more than 5 seconds of late video -> dropping frame 
(computer too slow ?)

I'm running both the OnDemandServer and VLC on the same PC so I don't 
think that there could be any funny clock skew going on.

I'm kind of at a loss for what's going wrong, but I am pretty new to 
this stuff.
I was hoping that somebody out there might know enough about VLC and the 
LiveMedia library to give me some clues on what to look for. For 
instance does anybody know what the numbers in the late picture skipped 
message are, they don't look like time codes to me.


Thanks
Matt S.

PS I tried stream to Quicktime Viewer too and it just wouldn't show 
anything, although it did say that it was playing the stream.









From charlie at sensoray.com  Wed Oct  1 11:30:07 2008
From: charlie at sensoray.com (Charlie X. Liu)
Date: Wed, 1 Oct 2008 11:30:07 -0700
Subject: [Live-devel] Problem streaming a live H.264 stream to VLC
In-Reply-To: <48E3B945.1060108@schuckmannacres.com>
References: <48E3B945.1060108@schuckmannacres.com>
Message-ID: <001c01c923f3$baf17060$30d45120$@com>

The latest VLC 0.9.2 sounds more tolerant. Are you with this version?


-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Matt Schuckmann
Sent: Wednesday, October 01, 2008 10:54 AM
To: live-devel at ns.live555.com
Subject: [Live-devel] Problem streaming a live H.264 stream to VLC

I'm working on prototyping a live H.264 streaming application using the 
LiveMedia rtsp/rtp library and the X264 encoder.
I've written my h264Framer class and integrated it into the 
testOnDemandRTSPServer and I can successfully stream the data to the 
OpenRTSP test application.
However, when I try to open the stream using VLC it only displays the 
first frame and nothing more.
If I open the messages window for VLC I see a whole bunch of messages 
like these

main warning: late picture skipped (266012)
main warning: late picture skipped (266000)
main warning: late picture skipped (266000)
main warning: late picture skipped (282000)
main warning: late picture skipped (250000)
main warning: late picture skipped (250000)
main warning: late picture skipped (250000)
ffmpeg warning: Unknown NAL code: 0
 (h264 at 00B22B60)
ffmpeg warning: Unknown NAL code: 0
 (h264 at 00B22B60)
main warning: late picture skipped (316000)
main warning: late picture skipped (250000)
ffmpeg error: more than 5 seconds of late video -> dropping frame 
(computer too slow ?)

I'm running both the OnDemandServer and VLC on the same PC so I don't 
think that there could be any funny clock skew going on.

I'm kind of at a loss for what's going wrong, but I am pretty new to 
this stuff.
I was hoping that somebody out there might know enough about VLC and the 
LiveMedia library to give me some clues on what to look for. For 
instance does anybody know what the numbers in the late picture skipped 
message are, they don't look like time codes to me.


Thanks
Matt S.

PS I tried stream to Quicktime Viewer too and it just wouldn't show 
anything, although it did say that it was playing the stream.








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



From bgranger at verivue.com  Wed Oct  1 12:35:59 2008
From: bgranger at verivue.com (Brett Granger)
Date: Wed, 1 Oct 2008 15:35:59 -0400
Subject: [Live-devel] Problem streaming a live H.264 stream to VLC
In-Reply-To: <48E3B945.1060108@schuckmannacres.com>
References: <48E3B945.1060108@schuckmannacres.com>
Message-ID: <48E3D11F.3040601@verivue.com>


The numbers in parentheses are a measure of "how late" the picture was 
received relative to when VLC calculated it should be displayed.  I 
believe the resolution is microseconds, so 250000 is .25 seconds late. 
Seems like you might have a problem with your presentation times? 
Unfortunately, that's about as much help as I can offer...

Good luck,
--Brett

Matt Schuckmann wrote:
> I'm working on prototyping a live H.264 streaming application using the
> LiveMedia rtsp/rtp library and the X264 encoder.
> I've written my h264Framer class and integrated it into the
> testOnDemandRTSPServer and I can successfully stream the data to the
> OpenRTSP test application.
> However, when I try to open the stream using VLC it only displays the
> first frame and nothing more.
> If I open the messages window for VLC I see a whole bunch of messages
> like these
> 
> main warning: late picture skipped (266012)
> main warning: late picture skipped (266000)
> main warning: late picture skipped (266000)
> main warning: late picture skipped (282000)
> main warning: late picture skipped (250000)
> main warning: late picture skipped (250000)
> main warning: late picture skipped (250000)
> ffmpeg warning: Unknown NAL code: 0
>  (h264 at 00B22B60)
> ffmpeg warning: Unknown NAL code: 0
>  (h264 at 00B22B60)
> main warning: late picture skipped (316000)
> main warning: late picture skipped (250000)
> ffmpeg error: more than 5 seconds of late video -> dropping frame
> (computer too slow ?)
> 
> I'm running both the OnDemandServer and VLC on the same PC so I don't
> think that there could be any funny clock skew going on.
> 
> I'm kind of at a loss for what's going wrong, but I am pretty new to
> this stuff.
> I was hoping that somebody out there might know enough about VLC and the
> LiveMedia library to give me some clues on what to look for. For
> instance does anybody know what the numbers in the late picture skipped
> message are, they don't look like time codes to me.
> 
> 
> Thanks
> Matt S.
> 
> PS I tried stream to Quicktime Viewer too and it just wouldn't show
> anything, although it did say that it was playing the stream.
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel



From finlayson at live555.com  Wed Oct  1 12:44:03 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 01 Oct 2008 12:44:03 -0700
Subject: [Live-devel] Problem streaming a live H.264 stream to VLC
In-Reply-To: <48E3D11F.3040601@verivue.com>
References: <48E3B945.1060108@schuckmannacres.com>
	<48E3D11F.3040601@verivue.com>
Message-ID: <200810011947.m91Jl8Ug024720@ns.live555.com>


>Seems like you might have a problem with your presentation times?

That's my guess also.  Are you setting "fPresentationTime" properly 
in your "H264VideoStreamFramer" subclass?  (These must be accurate 
values, aligned with 'wall clock' time ("gettimeofday()").)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From dmaljur at elma.hr  Thu Oct  2 04:58:13 2008
From: dmaljur at elma.hr (Dario)
Date: Thu, 2 Oct 2008 13:58:13 +0200
Subject: [Live-devel] Unable to stream more then 31 streams.
Message-ID: <008001c92486$2637d2a0$ec03000a@gen47>

Hi. 
I'm using one process per stream to stream from RTSP server.
After creating 31 processes, On 32nd the debug says:
recvfrom() error:
Groupsock read failed:

It dosn't matter if there is 4 processes handling 8 streams or 32 processes alltogether,
the limit is 31.
Any idea on how to fix this?


ELMA Kurtalj d.o.o. (ELMA Kurtalj ltd.)
Vitezi?eva 1a, 10000 Zagreb, Hrvatska (Viteziceva 1a, 10000 Zagreb, Croatia)
Tel: 01/3035555, Faks: 01/3035599 (Tel: ++385-1-3035555, Fax: ++385-1-3035599 )

Www:
www.elma.hr; shop.elma.hr

E-mail:
elma at elma.hr (elma at elma.hr)
pitanje at elma.hr (questions at elma.hr)
primjedbe at elma.hr (complaints at elma.hr)
prodaja at elma.hr (sales at elma.hr)
servis at elma.hr (servicing at elma.hr)
shop at elma.hr (shop at elma.hr)
skladiste at elma.hr (warehouse at elma.hr)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081002/b07ccc68/attachment.html>

From amit.yedidia at elbitsystems.com  Thu Oct  2 05:39:36 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Thu, 2 Oct 2008 15:39:36 +0300
Subject: [Live-devel] Streaming Live H264
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D35FF@mailesl5.esl.corp.elbit.co.il>

Ross,

I am still tyring to understand  the live capture issue.
I imlemented the framer (H264LiveVideoStreamFramer)  and the source
(ImxDeviceSource)
Now, when the following chain is being called:
H264FUAFragmenter::doGetNextFrame() ->
H264LiveVideoStreamFramer::doGetNextFrame() ->
ImxDeviceSource::doGetNextFrame()

What should happened at the ImxDeviceSource::doGetNextFrame()?
1.Does the function should return only when a frame is valid (and return
the poiter and size)
	Or, as I think you meant, it should call deliverFrame()?
2.Does deliverFame() is called by the chain (doGetNextFrame() ) or by
the encoder when a frame is valid?
3. Where is the waiting for the next frame is done? (after the RTPSinc
call getNextFarme())

Thank you.





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/20081002/c6146d54/attachment-0001.html>

From finlayson at live555.com  Thu Oct  2 05:37:38 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 02 Oct 2008 05:37:38 -0700
Subject: [Live-devel] Unable to stream more then 31 streams.
In-Reply-To: <008001c92486$2637d2a0$ec03000a@gen47>
References: <008001c92486$2637d2a0$ec03000a@gen47>
Message-ID: <200810021246.m92Ck54i086862@ns.live555.com>


>I'm using one process per stream to stream from RTSP server.
>After creating 31 processes, On 32nd the debug says:
>recvfrom() error:
>Groupsock read failed:

This is almost certainly due to some limit (most likely in the number 
of open files) in your OS, not an inherent limit in our software.

>  It dosn't matter if there is 4 processes handling 8 streams or 32 
> processes alltogether,
>the limit is 31.

And this confirms the above (because any limit in our software would 
have to be per-process).

>Any idea on how to fix this?

Reconfigure your OS to increase the maximum number of open files 
(sockets) that it can have at a time.  (How you would do this depends 
upon your particular OS.)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From renatomauro at libero.it  Thu Oct  2 05:48:38 2008
From: renatomauro at libero.it (Renato MAURO (Libero))
Date: Thu, 2 Oct 2008 14:48:38 +0200
Subject: [Live-devel] Unable to stream more then 31 streams.
References: <008001c92486$2637d2a0$ec03000a@gen47>
Message-ID: <013901c9248d$31a67130$2e020a0a@CSystemDev>

Hi Dario.

I had the same problem and Alkassoum suggested the right way to solve it:

"If you are running your application under windows you might have the same problem i had few months ago.
My problem was due to an windows OS limitation on the number of sockets that can be open at any one time. 
On windows the FD_SETSIZE parameter have a default value of 64, so with that default value,
the server can only handle 64/2 = 32 clients at the same time ( 2 sockets
per client). So to solve my problem i only had to increase the FD_SETSIZE
parameter."

Have a nice day,

    Renato



  ----- Original Message ----- 
  From: Dario 
  To: live-devel at ns.live555.com 
  Sent: Thursday, October 02, 2008 1:58 PM
  Subject: [Live-devel] Unable to stream more then 31 streams.


  Hi. 
  I'm using one process per stream to stream from RTSP server.
  After creating 31 processes, On 32nd the debug says:
  recvfrom() error:
  Groupsock read failed:

  It dosn't matter if there is 4 processes handling 8 streams or 32 processes alltogether,
  the limit is 31.
  Any idea on how to fix this?



------------------------------------------------------------------------------
  ELMA Kurtalj d.o.o. (ELMA Kurtalj ltd.)
  Vitezi?eva 1a, 10000 Zagreb, Hrvatska (Viteziceva 1a, 10000 Zagreb, Croatia)
  Tel: 01/3035555, Faks: 01/3035599 (Tel: ++385-1-3035555, Fax: ++385-1-3035599 )

  Www:
  www.elma.hr; shop.elma.hr

  E-mail:
  elma at elma.hr (elma at elma.hr)
  pitanje at elma.hr (questions at elma.hr)
  primjedbe at elma.hr (complaints at elma.hr)
  prodaja at elma.hr (sales at elma.hr)
  servis at elma.hr (servicing at elma.hr)
  shop at elma.hr (shop at elma.hr)
  skladiste at elma.hr (warehouse at elma.hr)



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


  _______________________________________________
  live-devel mailing list
  live-devel at lists.live555.com
  http://lists.live555.com/mailman/listinfo/live-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081002/04034615/attachment.html>

From finlayson at live555.com  Thu Oct  2 05:59:45 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 02 Oct 2008 05:59:45 -0700
Subject: [Live-devel] Streaming Live H264
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D35FF@mailesl5.esl.corp.e
	lbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D35FF@mailesl5.esl.corp.elbit.co.il>
Message-ID: <200810021303.m92D3lsj005357@ns.live555.com>


>What should happened at the ImxDeviceSource::doGetNextFrame()?
>
>1.Does the function should return only when a frame is valid (and 
>return the poiter and size)

No.  Your "doGetNextFrame()" should *not* block.  It should return 
immediately, even if no frame is currently available for delivery.

>2.Does deliverFame() is called by the chain (doGetNextFrame() ) or 
>by the encoder when a frame is valid?

You must (somehow) arrange for "deliverFrame()" to be called, by the 
event loop, when your encoder has made a new frame available.  I.e., 
the arrival of a new frame, from the encoder, has to be recognized as 
an 'event' within the event loop.

As I explain in the comments in "DeviceSource.cpp", if your encoder 
is a readable socket (open file), then this is easy to do, using 
"turnOnBackgroundReadHandling()".

If, however, your encoder is not a readable socket, then you need to 
do something else (specific to your particular system!) to arrange 
for "deliverFrame()" to get called from within the event loop.  (One 
solution, used by many people, is to use the 'watchVariable' 
parameter to "doEventLoop()", and to have a separate thread that sets 
this 'watchVariable' (and does nothing else with the LIVE555 
library!) when a new frame arrives.)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From matt at schuckmannacres.com  Thu Oct  2 10:26:59 2008
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Thu, 02 Oct 2008 10:26:59 -0700
Subject: [Live-devel]  Problem streaming a live H.264 stream to VLC
Message-ID: <48E50463.8030005@schuckmannacres.com>

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

From diego.barberio at redmondsoftware.com  Thu Oct  2 13:35:23 2008
From: diego.barberio at redmondsoftware.com (Diego Barberio)
Date: Thu, 2 Oct 2008 17:35:23 -0300
Subject: [Live-devel] Synchrnozing video and audio using
	OnDemandServerMediaSubsessions
In-Reply-To: <f06240806c4e7528e719a@[66.80.62.44]>
References: <008f01c90f92$186601f0$800101df@redmondsoftware.com>
	<f06240806c4e7528e719a@[66.80.62.44]>
Message-ID: <9E35EE91E82A4872A0477C697FE207C8@redmondsoftware.com>

Hi Ross

I have been analyzing the feedback you have sent me. However I'm still stuck
with this same issue. Here is a short brief of what I'm doing:

In addition to what I had described in my first e-mail, I have an
H263plusVideoRTPSink instance which is constructed in the
CH263plusVideoDXServerMediaSubsession. Additionally, for the audio
subsession I have written a CAlawSimpleRTPSink which extends from
SimpleRTPSink. I did this because I couldn't find any Sink for aLaw audio
with the capability for sending the rtpmap in the description message
packet. I need this field to be included in the description message.
Therefore, I only redefined the rtpmapLine() method. Attached is the code
for AlawSimpleRTPSink class.

Additionally, I have read in other e-mail (Timestamp gap in RTCP Report for
MPEG1or2VideoStreamFramer subject) a case that seems to be similar to mine.
There, you said that the code which generates RTP and RTCP presentation
times are correct, and that it is necessary to set correctly the
presentation times (you also mentioned it in the mail you sent me). Here is
the code snippet where I set the presentation time for the
CH263plusVideoDXFrameSource, after setting the fDurationInMicroseconds
(which is always 40ms) at doGetNextFrame method. The same code applies for
the Alaw audio frame, with the exception that the fDurationInMicroseconds is
about 500ms. I tried to shorten the 500ms duration to 40ms but no change was
perceived with the delay:

void CH263plusVideoDXFrameSource::setPresentationTime()
{
	// Check if this is the first frame we send
	if (fPresentationTime.tv_sec == 0 && fPresentationTime.tv_usec == 0)
	{
		// This is the first frame, so we set the current time
		gettimeofday(&this->fPresentationTime, NULL);
	}
	else
	{
		// These are the following  frames, so we set the previous
presentation time plus the frame duration
		fPresentationTime.tv_usec += this->fDurationInMicroseconds;

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

To sum up, my questions are the following:

- Am I doing something wrong, or missing anything else, in the definition of
CAlawSimpleRTPSink? Should I use another class or redefine any other method?

- Is my code for setting the presentation time correct? If not, what should
I change?

Thanks,
Diego 

-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Viernes, 05 de Septiembre de 2008 06:27 p.m.
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Synchrnozing video and audio using
OnDemandServerMediaSubsessions

To get proper audio/video synchronization, you must create a 
"RTCPInstance" for each "RTPSink".  However, the 
"OneDemandServerMediaSubsession" class does this automatically, so 
because you're subclassing this, you don't need to do anything 
special to implement RTCP - you already have it.

However, the second important thing that you need is that the 
presentation times that you give to each frame (that feeds into each 
"RTPSink") *must* be accurate.  It is those presentation times that 
get delivered to the receiver, and used (by the receiver) to do 
audio/video synchronization.

Delaying the transmission (or not) does not affect this at all; it 
doesn't matter if video packets get sent slightly ahead of audio 
packets (or vice versa).  What's important is the *presentation 
times* that you give each frame.  If those are correct, then you will 
get audio/video synchronization at the receiver.

This is assuming, of course, that your *receiver* implements standard 
RTCP-based synchronization correctly.  (If your receiver uses our 
library, than it will.)  But if your receiver is not standards 
compliant and doesn't implement this, then audio/video 
synchronization will never work.)
-- 

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

Hi all,

I'm new to the live555 library.

I have a MediaServerSession with two SubSessions (one for H263 video and the
other for G.711 A-law audio), both SubSessions extend from
OnDemandServerMediaSubsession, the one I use for the video is called
CH263plusVideoDXServerMediaSubsession and the other is called
CALawAudioDXServerMediaSubsession. I have also two FramedSources one for
each SubSession, one called CH263plusVideoDXFrameSource and the other
CAlawAudioDXFrameSource.

The streaming for both medias works perfectly, but the audio is delayed
about 1.5 seconds from the video. To solve this I've tried to delay the
video subsession by adding 1500 milliseconds to the fPresentationTime
attribute in CH263plusVideoDXServerMediaSubsession::doGetNextFrame method,
however no change was perceived. So I started googling this problem, until I
reached to the question "Why do most RTP sessions use separate streams for
audio and video? How can a receiving client synchronize these streams?" from
FAQs.


The problem is that I don't know where I should create the instance for
RTCPInstance class, and there's no variable or field where I can store it. I
looked in the OnDemandServerMediaSubsession and FramedSource class.

Is there any way to delay the video streaming without using the
RTCPInstance, if not, where I should create it and where I should store it?

If you need anything else, please ask for it.

Diego
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ALawSimpleRTPSink.cpp
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081002/f39c5cf3/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ALawSimpleRTPSink.h
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081002/f39c5cf3/attachment.h>

From finlayson at live555.com  Thu Oct  2 17:16:13 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 02 Oct 2008 17:16:13 -0700
Subject: [Live-devel] Synchrnozing video and audio using
 OnDemandServerMediaSubsessions
In-Reply-To: <9E35EE91E82A4872A0477C697FE207C8@redmondsoftware.com>
References: <008f01c90f92$186601f0$800101df@redmondsoftware.com>
	<f06240806c4e7528e719a@[66.80.62.44]>
	<9E35EE91E82A4872A0477C697FE207C8@redmondsoftware.com>
Message-ID: <200810030020.m930KOVM011101@ns.live555.com>


>void CH263plusVideoDXFrameSource::setPresentationTime()
>{
>         // Check if this is the first frame we send
>         if (fPresentationTime.tv_sec == 0 && fPresentationTime.tv_usec == 0)
>         {
>                 // This is the first frame, so we set the current time
>                 gettimeofday(&this->fPresentationTime, NULL);
>         }
>         else
>         {
>                 // These are the following  frames, so we set the previous
>presentation time plus the frame duration
>                 fPresentationTime.tv_usec += this->fDurationInMicroseconds;
>
>                 if(fPresentationTime.tv_usec>=1000000)
>                 {
>                         fPresentationTime.tv_sec++;
>                         fPresentationTime.tv_usec =
>fPresentationTime.tv_usec -                     1000000;
>                 }
>         }
>}

Where does your H.263+ video data come from?  If it comes from a live 
source (i.e., an encoder), then you may run into problems (clock 
drift) by calling "gettimeofday()" just once, and then incrementing 
the time by what you think is the duration of each frame.  Instead, 
you should set the presentation time by calling "gettimeofday()" 
*each time* you get a frame from the encoder, because then you'll be 
giving the frame a time that you know is accurate.

You should do the same thing for audio (again, if it comes from a live source).

(If, however, you're reading audio+video data from a file, you should 
call "gettimeofday()" just once (but you still need to be careful 
about giving both audio and video accurate (i.e., synchronized) 
presentation times.)



	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From gbzbz3 at yahoo.com  Fri Oct  3 01:11:32 2008
From: gbzbz3 at yahoo.com (Gbzbz Gbzbz)
Date: Fri, 3 Oct 2008 01:11:32 -0700 (PDT)
Subject: [Live-devel] Problem streaming a live H.264 stream to VLC
In-Reply-To: <200810011947.m91Jl8Ug024720@ns.live555.com>
Message-ID: <639924.99987.qm@web46305.mail.sp1.yahoo.com>

Could someone kindly implement a sample 264 streamer class for live555? A 264 NAL clip can be provided without any problem. This way, people can have a good starting point. 

--- On Wed, 10/1/08, Ross Finlayson <finlayson at live555.com> wrote:

> From: Ross Finlayson <finlayson at live555.com>
> Subject: Re: [Live-devel] Problem streaming a live H.264 stream to VLC
> To: "LIVE555 Streaming Media - development & use" <live-devel at ns.live555.com>
> Date: Wednesday, October 1, 2008, 7:44 PM
> >Seems like you might have a problem with your
> presentation times?
> 
> That's my guess also.  Are you setting
> "fPresentationTime" properly 
> in your "H264VideoStreamFramer" subclass?  (These
> must be accurate 
> values, aligned with 'wall clock' time
> ("gettimeofday()").)
> 
> 
> 	Ross Finlayson
> 	Live Networks, Inc. (LIVE555.COM)
> 	<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  Fri Oct  3 01:32:41 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 03 Oct 2008 01:32:41 -0700
Subject: [Live-devel] Problem streaming a live H.264 stream to VLC
In-Reply-To: <639924.99987.qm@web46305.mail.sp1.yahoo.com>
References: <200810011947.m91Jl8Ug024720@ns.live555.com>
	<639924.99987.qm@web46305.mail.sp1.yahoo.com>
Message-ID: <200810030837.m938bYp8027951@ns.live555.com>


>Could someone kindly implement a sample 264 streamer class for 
>live555? A 264 NAL clip can be provided without any problem. This 
>way, people can have a good starting point.

This not as simple as it was for MPEG-2 or MPEG-4 video (where we 
already have code for parsing and streaming video files).  For H.264, 
there appear to be two main difficulties:
1/ Figuring out when a NAL unit ends an 'access unit' (i.e., a 
complete video frame), and
2/ Figuring out the proper presentation times for each 'access 
unit'.  (The presentation times for each NAL unit within the same 
'access unit' will be the same.)

For 'live' H.264 data that comes from an encoder, this is usually 
straightforward.  However, for pre-recorded data that comes from a 
file, it's less obvious.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From Anoop_P.A at pmc-sierra.com  Fri Oct  3 03:18:11 2008
From: Anoop_P.A at pmc-sierra.com (Anoop P.A.)
Date: Fri, 3 Oct 2008 03:18:11 -0700
Subject: [Live-devel] streaming in and out same file
In-Reply-To: <200810030837.m938bYp8027951@ns.live555.com>
Message-ID: <A7DEA48C84FD0B48AAAE33F328C02014029161CF@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>

Hi ,

Is it possible to streamout a file while streaming in ?. I tried to
achive this through using live555 server and openRTSP client.
Unfortunately openTSP saving video with some default name that too
without extension which is necessary for live555 to sream out properly.
Whether editing openRTSP code to save file with extension will help in
streaming in and out???

Thanks
Anoop

From finlayson at live555.com  Fri Oct  3 05:59:09 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 03 Oct 2008 05:59:09 -0700
Subject: [Live-devel] streaming in and out same file
In-Reply-To: <A7DEA48C84FD0B48AAAE33F328C02014029161CF@BBY1EXM11.pmc_nt.
	nt.pmc-sierra.bc.ca>
References: <200810030837.m938bYp8027951@ns.live555.com>
	<A7DEA48C84FD0B48AAAE33F328C02014029161CF@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>
Message-ID: <200810031305.m93D5Mgw007775@ns.live555.com>


>Is it possible to streamout a file while streaming in ?. I tried to
>achive this through using live555 server and openRTSP client.
>Unfortunately openTSP saving video with some default name that too
>without extension which is necessary for live555 to sream out properly.
>Whether editing openRTSP code to save file with extension will help in
>streaming in and out???

You can do this by having "openRTSP" write a (single) output stream 
to 'stdout', and piping this to "testOnDemandRTSPServer" that reads 
from 'stdin'.  (You will need to modify the "testOnDemandRTSPServer" 
code to do this (see 
<http://www.live555.com/liveMedia/faq.html#liveInput-unicast>), bnt 
you won't need to modify the existing "openRTSP" code.)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From deasta at aol.com  Fri Oct  3 09:46:25 2008
From: deasta at aol.com (deasta at aol.com)
Date: Fri, 03 Oct 2008 12:46:25 -0400
Subject: [Live-devel] Live555server Video Stream Slowdown
Message-ID: <8CAF38EB5717210-1454-D59@FWM-D09.sysops.aol.com>

When streaming certain transport stream files (making a request from an RTSP client to the server), the server does not play the video at the expected speed. An example of the video is at <http://www.w6rz.net/>. The file <http://www.w6rz.net/parkrun1280_12mbps.ts> streamed from the server is much slower than it should be. Additionally, it seems as though that playback is not steady, meaning it looks as if it keeps a constant speed (the slower speed), and periodically jumps ahead a little. When requesting the file in trick modes, such as fast play of 2x, the file takes longer to stream.

My decoder is running at very low CPU utilization and not having any problems decoding the video, it simply appears as if the media server is throttling the video at a slower rate.

Single speed playback using VLC does not exhibit this issue. Not all transport streams exhibit this issue either.

I am wondering if the video is being throttle to compensate for the audio timing. Is there anyway to configure the server to make video the priority and drop audio based on timing problems?

Thanks.

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

From finlayson at live555.com  Fri Oct  3 14:31:45 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 03 Oct 2008 14:31:45 -0700
Subject: [Live-devel] Live555server Video Stream Slowdown
In-Reply-To: <8CAF38EB5717210-1454-D59@FWM-D09.sysops.aol.com>
References: <8CAF38EB5717210-1454-D59@FWM-D09.sysops.aol.com>
Message-ID: <200810032138.m93Lc5cL049527@ns.live555.com>

At 09:46 AM 10/3/2008, you wrote:
>When streaming certain transport stream files (making a request from 
>an RTSP client to the server), the server does not play the video at 
>the expected speed. An example of the video is at 
><http://www.w6rz.net/>. The file 
><http://www.w6rz.net/parkrun1280_12mbps.ts> streamed from the server 
>is much slower than it should be. Additionally, it seems as though 
>that playback is not steady, meaning it looks as if it keeps a 
>constant speed (the slower speed), and periodically jumps ahead a little.

Almost 1 year ago (November 2007) someone asked a similar question 
about the same (I think) file.  At that time, I tried streaming this 
file from the "LIVE555 Media Server" to VLC, both running on the same 
computer (to eliminate possible networking problems as the cause).  I 
didn't see any problem:
http://lists.live555.com/pipermail/live-devel/2007-November/007708.html

This suggests that the problem is network-related (either the network 
itself, or networking software in your OS or device driver).  Are you 
sure that you have sufficient network capacity for this stream?

>I am wondering if the video is being throttle to compensate for the 
>audio timing.

No.  A Transport Stream is streamed 'as is'; the software does not 
know or care whether a Transport Stream packet contains audio, video, 
or whatever.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From matt at schuckmannacres.com  Fri Oct  3 17:17:51 2008
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Fri, 03 Oct 2008 17:17:51 -0700
Subject: [Live-devel] Need to implement Pan Tilt Zoom (PTZ) control over
	RTSP or RTP
Message-ID: <48E6B62F.40307@schuckmannacres.com>

I'm working on a pan tilt zoom (PTZ) type video server application and 
the corresponding viewer application .
I'm using the Live555 library for RTSP and RTP, and I must it is great, 
thank you very much,
Anyway I need to implement the control back channel for controlling the 
PTZ from the viewer and I'm trying to figure out the best way to do it 
within the RTSP/RTP/RTCP and Live555 framework.

The way I figure it I can go 1 of 3 ways.
1. Use the SET_PARAMETER command for RTSP to send back the commands that 
I've defined (things like pan=5 or tilt=+10, etc) using the sessionID to 
associate the command with the session. However, it appears that the 
Live555 library doesn't support the SET_PARAMETER command so I'd have to 
go about implementing it (if I did I'd submit my implementation back to 
the library) but I don't know how difficult or trivial it will be to do 
this.

2. Use the  APP packet type for the RTCP channel to send my custom 
formated commands. This seems reasonable but I don't know if this is 
what the APP packet types in RTCP where meant for or if there would be 
any pitfalls. Also I haven't gotten deep enough into Live555 to 
determine if there is a way to send APP packets through the RTCP channel.

3. Open another RTP/RTCP connection pair with my own MIME type strictly 
dedicated to controlling the PTZ. Seems kind of overkill but it might 
make it easy to fit into the Live555 RTP sink and source framework.

I've tried to look around to see if anybody else has gone any of these 
routes but I haven't found much; the RTSP RFC does mention something 
about using the SET_PARAMETER method for PTZ control but it doesn't go 
into any great detail. Any comments or suggestions from the experts out 
there would be most appreciated.

Thanks,
Matt Schuckmann

From finlayson at live555.com  Fri Oct  3 23:10:55 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 03 Oct 2008 23:10:55 -0700
Subject: [Live-devel] Need to implement Pan Tilt Zoom (PTZ) control over
 RTSP or RTP
In-Reply-To: <48E6B62F.40307@schuckmannacres.com>
References: <48E6B62F.40307@schuckmannacres.com>
Message-ID: <200810040618.m946I0Aq016683@ns.live555.com>

It is definitely better (more appropriate) to use RTSP (the 'control 
channel') for this - your option 1.  Although we don't currently 
implement the RTSP "SET_PARAMETER" command in our server, it should 
be very easy to add this.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From Anoop_P.A at pmc-sierra.com  Mon Oct  6 00:44:03 2008
From: Anoop_P.A at pmc-sierra.com (Anoop P.A.)
Date: Mon, 6 Oct 2008 00:44:03 -0700
Subject: [Live-devel] streaming in and out same file
In-Reply-To: <200810031305.m93D5Mgw007775@ns.live555.com>
Message-ID: <A7DEA48C84FD0B48AAAE33F328C02014029161D6@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>

Hi Ross,

Thanks for your response!!!!!!!

But my requirement is to stream in a number of videos from network and
streamout some among them. So there will be number of clients (say
15-20) and one server. Can you suggest a better way to achieve this?
 Why you are giving default name for recorded videos using openRTSP??

Thanks
Anoop

-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Friday, October 03, 2008 6:29 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] streaming in and out same file


>Is it possible to streamout a file while streaming in ?. I tried to
>achive this through using live555 server and openRTSP client.
>Unfortunately openTSP saving video with some default name that too
>without extension which is necessary for live555 to sream out properly.
>Whether editing openRTSP code to save file with extension will help in
>streaming in and out???

You can do this by having "openRTSP" write a (single) output stream 
to 'stdout', and piping this to "testOnDemandRTSPServer" that reads 
from 'stdin'.  (You will need to modify the "testOnDemandRTSPServer" 
code to do this (see 
<http://www.live555.com/liveMedia/faq.html#liveInput-unicast>), bnt 
you won't need to modify the existing "openRTSP" code.)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>

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

From sureshs at tataelxsi.co.in  Mon Oct  6 04:44:42 2008
From: sureshs at tataelxsi.co.in (sureshs)
Date: Mon, 6 Oct 2008 17:14:42 +0530
Subject: [Live-devel] 720P streaming error
In-Reply-To: <mailman.0.1221801557.82916.live-devel@lists.live555.com>
Message-ID: <013101c927a8$ec85caf0$51053c0a@telxsi.com>

Hi,
I could successfully stream the live captured h.264 encoded bit stream
through the OnDemandRTSP server
and could play it on MPlayer.

I could stream only CIF and VGA formats, when I try to stream the
720p(1280x720), I am getting the following error
in Mplayer, what might be the problem?. Your suggestions in this regard is
greatly appreciated.

Error Report:
////////////////////////////////////////////////////////////////////////////
//////////////////////////
[root at rameshkarigarb ~]# mplayer rtsp://10.60.5.168:8554/H264VideoTest
MPlayer 1.0rc2-4.1.1 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (Family: 15, Model: 4, Stepping: 9)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

Playing rtsp://10.60.5.168:8554/H264VideoTest.
Resolving 10.60.5.168 for AF_INET6...
Couldn't resolve name for AF_INET6: 10.60.5.168
Connecting to server 10.60.5.168[10.60.5.168]: 8554...
rtsp_session: unsupported RTSP server. Server type is 'unknown'.
STREAM_LIVE555, URL: rtsp://10.60.5.168:8554/H264VideoTest
Stream not seekable!
 file format detected.
Initiated "video/H264" RTP subsession on port 32774
MultiFramedRTPSource::doGetNextFrame1(): The total received frame size
exceeds the client's buffer size (49997).  194 bytes of trailing data will
be dropped!
demux_rtp: Guessed the video frame rate as 33 frames-per-second.
        (If this is wrong, use the "-fps <frame-rate>" option instead.)
VIDEO:  [H264]  0x0  0bpp  33.000 fps    0.0 kbps ( 0.0 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
Audio: no sound
Starting playback...
[h264 @ 0x88f0610]prefix too large at 53 31
[h264 @ 0x88f0610]error while decoding MB 53 31
[h264 @ 0x88f0610]concealing 1116 DC, 1116 AC, 1116 MV errors
VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [xv] 1280x720 => 1280x720 Planar YV12
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
X11 error: BadAlloc (insufficient resources for operation)
////////////////////////////////////////////////////////////////////////////
/////



Regards,
Suresh S
Phone: +91-80-22979919
Mobile: +91-99020-66995





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  Mon Oct  6 06:58:24 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 06 Oct 2008 06:58:24 -0700
Subject: [Live-devel] 720P streaming error
In-Reply-To: <013101c927a8$ec85caf0$51053c0a@telxsi.com>
References: <mailman.0.1221801557.82916.live-devel@lists.live555.com>
	<013101c927a8$ec85caf0$51053c0a@telxsi.com>
Message-ID: <200810061402.m96E2WRp015827@ns.live555.com>

That error has nothing to do with our software.  You need to ask 
about this on a "MPlayer" mailing list.

(I suggest also trying VLC, as it's (IMHO) a superior media player 
client than MPlayer.)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From nshamshiva at gmail.com  Mon Oct  6 08:02:41 2008
From: nshamshiva at gmail.com (Shiva Shankar N)
Date: Mon, 6 Oct 2008 12:02:41 -0300
Subject: [Live-devel] sending PAUSE and then PLAY request in openrtsp
Message-ID: <4f96b010810060802r4f7b6ff0icae2391e666e272@mail.gmail.com>

Hi All,

 I am developing rtsp client for media player. I want to pause the streaming
for few second to decode the video. Can I use pauseMediaSession() function
to pause the streaming with breaking the video sequence and play after few
seconds ? . Does this pauseMediaSession() function works ?
If there is any better method, please can you suggest me .

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

From stianbroen at hotmail.com  Mon Oct  6 15:14:38 2008
From: stianbroen at hotmail.com (Stian Broen)
Date: Tue, 7 Oct 2008 00:14:38 +0200
Subject: [Live-devel] general question
Message-ID: <BAY134-W288E26AC4269CD18EC79AEDA390@phx.gbl>


Hi,

I'm planning to make a video server application, and would like to get some question answered before I start the actual work. I will first explain how the application should work, and then the questions.

The application will be a server in which a client can stream video from over a LAN. It must be in such a way, that it is possible to experiment with different video codecs and different settings of those. It should also be possible to experiment with individual video coding methods (such as for example DCT-transform only, VLC-coding only etc.). In this way I hope to find a spesific video compression method that is well suited for a spesific type of video. The video is composed of data from a subsea sonar. It will run on a PC with Windows XP, and I will use Microsoft Visual C++ 2008 Express Edition for development. I realize that the application will perhaps need to be split in two, one for the video-coding, and one for the server-specific purposes. And an adequate interface between the two.

I'm rather new to this kind of programming, but I have the basic knowledge in networks-theory, TCP/IP socket programming, videocompression and C/C++. My questions are :

* Will you recommend live555 code as a starting platform for this kind of application?
* Has there already been made similar applications for these kinds of experimenting? If yes, where can i learn about these? 
* Is there perhaps some resources regarding live555 you recommend I look at before working with the code?

And if there are any questions you think I SHOULD be asking regarding this spesific type of application, but hasn't, feel free to answer them anyway =)


regards

Stian Broen

_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081007/8fb5ae49/attachment.html>

From matt at schuckmannacres.com  Mon Oct  6 15:29:43 2008
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Mon, 06 Oct 2008 15:29:43 -0700
Subject: [Live-devel] Need to implement Pan Tilt Zoom (PTZ) control over
 RTSP or RTP
In-Reply-To: <200810040618.m946I0Aq016683@ns.live555.com>
References: <48E6B62F.40307@schuckmannacres.com>
	<200810040618.m946I0Aq016683@ns.live555.com>
Message-ID: <48EA9157.4020103@schuckmannacres.com>

Thanks for the input, what would be the proper way to go about 
implementing this? Do I make the modifications and then submit a patch 
back to you, or just implement it in my own build or pay you to do it or 
? . I didn't see any developer guide lines or how to get to your 
CVS/Subversion/whatever repository.

Thanks
Matt S.

Ross Finlayson wrote:
> It is definitely better (more appropriate) to use RTSP (the 'control 
> channel') for this - your option 1.  Although we don't currently 
> implement the RTSP "SET_PARAMETER" command in our server, it should be 
> very easy to add this.
>
>
>     Ross Finlayson
>     Live Networks, Inc. (LIVE555.COM)
>     <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  Mon Oct  6 18:23:00 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 06 Oct 2008 18:23:00 -0700
Subject: [Live-devel] Need to implement Pan Tilt Zoom (PTZ) control over
 RTSP or RTP
In-Reply-To: <48EA9157.4020103@schuckmannacres.com>
References: <48E6B62F.40307@schuckmannacres.com>
	<200810040618.m946I0Aq016683@ns.live555.com>
	<48EA9157.4020103@schuckmannacres.com>
Message-ID: <200810070127.m971Rc5l033627@ns.live555.com>

It's up to you.  If you want to submit a patch to implement 
"SET_PARAMETER", then that would be great.  (Perhaps use a virtual 
function to support your custom parameters, so you can do this in a 
subclass of "RTSPServer".)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From finlayson at live555.com  Mon Oct  6 18:24:50 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 06 Oct 2008 18:24:50 -0700
Subject: [Live-devel] sending PAUSE and then PLAY request in  openrtsp
In-Reply-To: <4f96b010810060802r4f7b6ff0icae2391e666e272@mail.gmail.com>
References: <4f96b010810060802r4f7b6ff0icae2391e666e272@mail.gmail.com>
Message-ID: <200810070132.m971Wgpo038901@ns.live555.com>


>Does this pauseMediaSession() function works ?

Of course it works.

(Note thought, that (due to a known limitation of the code) if you're 
using RTP-over-TCP streaming, then you won't be able to do a "PAUSE" 
- or any other RTSP command - following the initial "PLAY".)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From Chad_Ata at BrightCom.com  Mon Oct  6 20:29:27 2008
From: Chad_Ata at BrightCom.com (Chad Ata)
Date: Mon, 6 Oct 2008 20:29:27 -0700
Subject: [Live-devel] RTSP - tunneling through an HTTP proxy
Message-ID: <OF027E712F.872D0A20-ON882574DB.0012AD03-882574DB.00113863@ALPHALOGIX>

Howdy,

I think the answer to this questions is NO, but I want to make sure just 
incase...
 
        * Is there "currently" any way to tunnel RTSP streams (with 
RTSPClient and DarwinInjector) through an Authenticating HTTP Proxy? 

I searched the code for the handling of the 407 response code and found 
nothing.

Thank You!
-Chad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081006/2842c9ad/attachment.html>

From finlayson at live555.com  Mon Oct  6 20:23:22 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 06 Oct 2008 20:23:22 -0700
Subject: [Live-devel] RTSP - tunneling through an HTTP proxy
In-Reply-To: <OF027E712F.872D0A20-ON882574DB.0012AD03-882574DB.00113863@
	ALPHALOGIX>
References: <OF027E712F.872D0A20-ON882574DB.0012AD03-882574DB.00113863@ALPHALOGIX>
Message-ID: <200810070332.m973W8hS061788@ns.live555.com>


>         * Is there "currently" any way to tunnel RTSP streams (with 
> RTSPClient and DarwinInjector) through an Authenticating HTTP Proxy?

No.  However, it might be possible to modify the RTSP-over-HTTP 
support in the "RTSPClient" class to do this.

(Note that this would have nothing at all to do with 
"DarwinInjector"; that's just a hack specifically for Apple's "Darwin 
Streaming Server".)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From sureshs at tataelxsi.co.in  Mon Oct  6 22:40:20 2008
From: sureshs at tataelxsi.co.in (sureshs)
Date: Tue, 7 Oct 2008 11:10:20 +0530
Subject: [Live-devel] 720P streaming error
In-Reply-To: <200810061402.m96E2WRp015827@ns.live555.com>
Message-ID: <003d01c9283f$2fbb1410$51053c0a@telxsi.com>

Hi Ross,

Thanks for your suggestion, The VLC player is displaying the 720p, I guess
there is some problem with the MPlayer.

Regards,
Suresh S

-----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, October 06, 2008 7:28 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] 720P streaming error


That error has nothing to do with our software.  You need to ask
about this on a "MPlayer" mailing list.

(I suggest also trying VLC, as it's (IMHO) a superior media player
client than MPlayer.)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>

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


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 sureshs at tataelxsi.co.in  Mon Oct  6 22:40:20 2008
From: sureshs at tataelxsi.co.in (sureshs)
Date: Tue, 7 Oct 2008 11:10:20 +0530
Subject: [Live-devel] 720P streaming error
In-Reply-To: <200810061402.m96E2WRp015827@ns.live555.com>
Message-ID: <003d01c9283f$2fbb1410$51053c0a@telxsi.com>

Hi Ross,

Thanks for your suggestion, The VLC player is displaying the 720p, I guess
there is some problem with the MPlayer.

Regards,
Suresh S

-----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, October 06, 2008 7:28 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] 720P streaming error


That error has nothing to do with our software.  You need to ask
about this on a "MPlayer" mailing list.

(I suggest also trying VLC, as it's (IMHO) a superior media player
client than MPlayer.)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>

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


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 xl at nbicc.com  Mon Oct  6 22:50:54 2008
From: xl at nbicc.com (xl)
Date: Tue, 7 Oct 2008 13:50:54 +0800
Subject: [Live-devel] How to debug the livemedia source code?
Message-ID: <200810071350541093975@nbicc.com>

Dears,
I have successfully built the code on linux,and I want to dubug it with gdb command.But it shows "no symbol table is loaded.Use the file command".I debug my own linux programs with gdb and it works normally.What's the problem?
Thanks for your reply.
Regards,
                                               Shelia

2008-10-07 



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

From finlayson at live555.com  Mon Oct  6 23:03:15 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 06 Oct 2008 23:03:15 -0700
Subject: [Live-devel] How to debug the livemedia source code?
In-Reply-To: <200810071350541093975@nbicc.com>
References: <200810071350541093975@nbicc.com>
Message-ID: <200810070608.m9768GnS024593@ns.live555.com>


>I have successfully built the code on linux,and I want to dubug it 
>with gdb command.But it shows "no symbol table is loaded.Use the 
>file command".I debug my own linux programs with gdb and it works 
>normally.What's the problem?

You should use the "config.limux-gdb" configuration file, not the 
usual "config.linux" configuration file.  I.e., create your Makefiles 
by running
         genMakefiles linux-gdb
rather than
         genMakefiles linux


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From soumyapnarayan at tataelxsi.co.in  Wed Oct  8 01:30:56 2008
From: soumyapnarayan at tataelxsi.co.in (Soumya P N)
Date: Wed, 8 Oct 2008 14:00:56 +0530
Subject: [Live-devel] Memory Leak while exiting from doEventLoop
Message-ID: <003e01c92920$30092dd0$45033c0a@telxsi.com>

Hi,
In the downloaded code the doEventLoop() was not exiting and it was a
infinite loop. Now i changed the code
so that it will exit on keyboard hit. Then also it is not exiting properly.I
think it is
because of some memory leaks. Can anyone give an idea about the resources to
be freed while exiting
from loop?

thanks in advance,,
Soumya.



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 venugopalpaikr at tataelxsi.co.in  Wed Oct  8 01:59:31 2008
From: venugopalpaikr at tataelxsi.co.in (venugopalpaikr)
Date: Wed, 8 Oct 2008 14:29:31 +0530
Subject: [Live-devel] query regarding debug messages
Message-ID: <005001c92924$2e1ace80$3c033c0a@telxsi.com>

Hi,
    I have bulit a server using RTSPServer.cpp and am using openRTSP as the
client. During DEBUG am not able to proceed after SETUP state. What i feel
is the error is due to urlPresuffix and urlSuffix.]
The DEBUG messages are as shown:

parseRTSPRequestString() returned cmdName "DESCRIBE", urlPreSuffix "",
urlSuffix "Codec00"
sending response: RTSP/1.0 200 OK
CSeq: 2
Date: Wed, Oct 08 2008 08:45:58 GMT
Content-Base: rtsp://10.60.3.55/Codec00/
Content-Type: application/sdp
Content-Length: 371

sdp info.....................



parseRTSPRequestString() returned cmdName "SETUP", urlPreSuffix "Codec00",
urlSuffix ""
sending response: RTSP/1.0 400 Bad Request
Date: Wed, Oct 08 2008 08:45:58 GMT
Allow: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

In the DESCRIBE message my urlSuffix is Codec00 and in my SETUP message my
urlPresuffix is Codec00. The server returns a stream not found error because
of this.
Can anyone help me with this??

Am not using any subsession but harcoding the sdp. My streamname is Codec00
but trackid is NULL.

Thanks in advance.


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 stianbroen at hotmail.com  Wed Oct  8 05:13:56 2008
From: stianbroen at hotmail.com (Stian Broen)
Date: Wed, 8 Oct 2008 14:13:56 +0200
Subject: [Live-devel] fatal error : ntwin32.mak not found
Message-ID: <BAY134-W291D7462D00A32B4D504F7DA3B0@phx.gbl>


Hi,

I'm trying to compile the code with VS 2005 according to Eric Flickners 'hints' refered to in the homepage. I'm following every step , except step 4, since this seems to be included in the newest code. When i run the bat file in step  7, i get problems. I receive this error : "liveMedia.mak(17) : fatal error : ntwin32.mak not found". I am indeed missing ntwin32.mak and win32.mak from C:\Microsoft Visual Studio 8\VC\include. Have anyone had similar problems? Where can I find these files? I'm using 'Microsoft Visual C++ 2005 Express Edition' on a Windows XP PC.

regards

Stian Broen

_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081008/5cbf6f27/attachment.html>

From finlayson at live555.com  Wed Oct  8 07:17:22 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 08 Oct 2008 07:17:22 -0700
Subject: [Live-devel] Memory Leak while exiting from doEventLoop
In-Reply-To: <003e01c92920$30092dd0$45033c0a@telxsi.com>
References: <003e01c92920$30092dd0$45033c0a@telxsi.com>
Message-ID: <200810081421.m98ELlO1049155@ns.live555.com>


>In the downloaded code the doEventLoop() was not exiting and it was a
>infinite loop. Now i changed the code
>so that it will exit on keyboard hit. Then also it is not exiting properly.

What do you mean "not exiting properly"?  Is "doEventLoop()" (when 
you add a 'watch variable' returning, or not?  Have you read this 
link (which is in the FAQ):
         http://lists.live555.com/pipermail/live-devel/2006-March/004192.html


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From finlayson at live555.com  Wed Oct  8 07:33:28 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 08 Oct 2008 07:33:28 -0700
Subject: [Live-devel] query regarding debug messages
In-Reply-To: <005001c92924$2e1ace80$3c033c0a@telxsi.com>
References: <005001c92924$2e1ace80$3c033c0a@telxsi.com>
Message-ID: <200810081436.m98EapYN064826@ns.live555.com>


>Can anyone help me with this??

Probably not, because you made your own modifications/additions to the code.

First make sure the existing RTSP server applications 
("testOnDemandRTSPServer" and "live555MediaServer") work for 
you.  Then, look at how/why your modifications broke.  (Most likely 
you're not setting the "ServerMediaSession"s "streamName" 
properly.)  Remember, You Have Complete Source Code.



	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From erik at hovland.org  Wed Oct  8 08:27:57 2008
From: erik at hovland.org (Erik Hovland)
Date: Wed, 8 Oct 2008 08:27:57 -0700
Subject: [Live-devel] [patch] One FSF address line got missed
Message-ID: <20081008152757.GA29806@hovland.org>

I can't find the change in my tree. So I think that this patch is needed
to fix the FSF address in the file RTPSource.cpp.

E

-- 
Erik Hovland
mail: erik at hovland.org
web: http://hovland.org/
PGP/GPG public key available on request
-------------- next part --------------
A non-text attachment was scrubbed...
Name: live555-fix-fsf-address.patch
Type: text/x-diff
Size: 730 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081008/fef2e38a/attachment.bin>

From mli00 at yahoo.com  Wed Oct  8 17:53:33 2008
From: mli00 at yahoo.com (Martin)
Date: Wed, 8 Oct 2008 17:53:33 -0700 (PDT)
Subject: [Live-devel] openRTSP, testOnDemandRTSPServer, VLC
Message-ID: <267831.71496.qm@web36407.mail.mud.yahoo.com>

Dear Ross, all,

I am new?to live555.?When I tested out the RTSP flow, Something I don't quite understand.

1) I compiled?latest (live.2008.09.02.tar.gz) under Linux, every thing OK, no issue.

2) I downloaded and renamed "para.m4e" to "test.m4e", and put that under "testProgs" directory.

3) I started testOnDemandRTSPServer.

4) Then I run openRTSP with the provided RTSP URL from testOnDemandRTSPServer, something like:
????????? ./openRTSP rtsp://192.168.188.0:8554/mpeg4ESVideoTest
This ran OK and created a local file called "video-MP4V-ES-1".

5) Then I started VLC 0.9.2?to received the RTSP stream. This also ran OK and able to display the whole streaming video.


Everythings seems?OK, but there are somethings I don't quite understand:

1) When I open the?"para.m4e" file locally, VLC cannot play?the video. Why can VLC play the video when streaming, but not when?play locally?

2) The received "video-MP4V-ES-1" is different from the original "para.m4e", at least at the beginning section of the stream. Why? How do I know if the received stream is intact?


Thanks,
-martin



      

From finlayson at live555.com  Wed Oct  8 18:28:29 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 08 Oct 2008 18:28:29 -0700
Subject: [Live-devel] openRTSP, testOnDemandRTSPServer, VLC
In-Reply-To: <267831.71496.qm@web36407.mail.mud.yahoo.com>
References: <267831.71496.qm@web36407.mail.mud.yahoo.com>
Message-ID: <200810090142.m991gctk058396@ns.live555.com>


>1) When I open the "para.m4e" file locally, VLC cannot play the 
>video. Why can VLC play the video when streaming, but not when play locally?

Because VLC does not recognize the ".m4e" filename extension as 
representing a MPEG-4 Video Elementary Stream file.  There's no 
reason in principle why VLC could not play such files, but it 
currently doesn't.  (VLC is not our software, though, so this is not 
the right mailing list to use to complain about 'bugs' in VLC :-)


>2) The received "video-MP4V-ES-1" is different from the original 
>"para.m4e", at least at the beginning section of the stream. Why?

Possibly because some data (RTP) packets were lost in transit.

>  How do I know if the received stream is intact?

You can rename the file to have a ".m4e" filename extension, and then 
try streaming it again (to VLC or QuickTime Player, for example).


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From gabrieledeluca at libero.it  Thu Oct  9 00:18:52 2008
From: gabrieledeluca at libero.it (gabrieledeluca at libero.it)
Date: Thu,  9 Oct 2008 09:18:52 +0200
Subject: [Live-devel] (no subject)
Message-ID: <K8GMZG$2143FF82FFB34335621E86C798153794@libero.it>

Hi,
I want relaying rtp packets unicast->unicast stream...
I'm live555 newbie, can You give me  tips?

I already see your example testRelay.cpp but it's a multicast->unicast relayng!

Help me,
thanks in advance,

Bobo


From dan.bolser at gmail.com  Thu Oct  9 01:22:48 2008
From: dan.bolser at gmail.com (Dan Bolser)
Date: Thu, 9 Oct 2008 09:22:48 +0100
Subject: [Live-devel] RTSP authentication for a 'real' stream?
Message-ID: <2c8757af0810090122u54a66fb6xc46716378ed5dba8@mail.gmail.com>

Hi,

I am trying to play a 'real' stream that uses RTSP with
authentication. Although I pass the username and password options, I
don't get a 'session'.


Below is an example of the output using openRTSP. Note that if I use
the wrong user name or password, the error is different (also below).
So the user/passwd are being used, but at some point authentication is
not happening. Do I need to pass my browser cookies or somthgin?

Is this a problem with the code, or a fundamental problem with
authentication of real streams?


Thanks for any feedback,

Dan.



OUTPUT USING CORRECT USER / PASSWD:

~/src/live/testProgs/openRTSP -u me secret
rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm
Sending request: OPTIONS
rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm RTSP/1.0
CSeq: 1
User-Agent: openRTSP (LIVE555 Streaming Media v2008.10.07)


Received OPTIONS response: RTSP/1.0 200 OK
CSeq: 1
Date: Thu, 09 Oct 2008 08:13:42 GMT
Server: Helix Server Version 11.1.7.3406 (win32) (RealServer compatible)
Public: OPTIONS, DESCRIBE, ANNOUNCE, PLAY, PAUSE, SETUP,
GET_PARAMETER, SET_PARAMETER, TEARDOWN
TurboPlay: 1
RealChallenge1: b73ec43d19678437ac8152bfe93e1278
StatsMask: 8


Sending request: DESCRIBE
rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: openRTSP (LIVE555 Streaming Media v2008.10.07)


Received DESCRIBE response: RTSP/1.0 401 Unauthorized
CSeq: 2
Date: Thu, 09 Oct 2008 08:13:42 GMT
Set-Cookie: cbid=hfcjjmelcgmkhidmeojokpktmojrktlufkejkielejcfelplqnrompqtpopsrqduhfjgjhhl;path=/;expires=Thu,31-Dec-2037
23:59:59 GMT
WWW-Authenticate: Basic realm="MEETSTREAM.ContentRealm"


Sending request: DESCRIBE
rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm RTSP/1.0
CSeq: 3
Accept: application/sdp
Authorization: Basic ZGFuLmJvbHNlcjowMDAwMDY=
User-Agent: openRTSP (LIVE555 Streaming Media v2008.10.07)


Received DESCRIBE response: RTSP/1.0 200 OK
CSeq: 3
Date: Thu, 09 Oct 2008 08:13:42 GMT
Last-Modified: Thu, 02 Oct 2008 01:52:05 GMT
Content-base: rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm/
Vary: User-Agent, ClientID
Content-type: application/sdp
x-real-usestrackid: 1
Content-length: 2912


Need to read 2912 extra bytes
Read 2912 extra bytes: v=0
o=- 1222912325 1222912325 IN IP4 143.48.1.141
s=Genome Informatics
i=CSHL Leading Strand (C) CSHL 2008
c=IN IP4 0.0.0.0
t=0 0
a=SdpplinVersion:1610641560
a=StreamCount:integer;2
a=control:*
a=Flags:integer;25
a=IsRealDataType:integer;1
a=Author:buffer;"Q1NITCBMZWFkaW5nIFN0cmFuZAA="
a=Copyright:buffer;"KEMpIENTSEwgMjAwOAA="
a=Title:buffer;"R2Vub21lIEluZm9ybWF0aWNzAA=="
a=ASMRuleBook:string;"#($Bandwidth < 350000),Stream0Bandwidth =
117959, Stream1Bandwidth = 32041;#($Bandwidth >=
350000),Stream0Bandwidth = 317959, Stream1Bandwidth = 32041;"
a=range:npt=0-5261.077000
m=video 0 RTP/AVP 101
b=AS:382
b=RR:11923
b=RS:3974
a=control:streamid=0
a=range:npt=0-5260.243000
a=length:npt=5260.243000
a=rtpmap:101 x-pn-realvideo/1000
a=fmtp:101
a=mimetype:string;"video/x-pn-realvideo"
a=Helix-Adaptation-Support:1
a=AvgBitRate:integer;317959
a=AvgPacketSize:integer;349
a=EndOneRuleEndAll:integer;1
a=EndTime:integer;5260243
a=MaxBitRate:integer;317959
a=MaxPacketSize:integer;1342
a=MinimumSwitchOverlap:integer;0
a=Preroll:integer;5048
a=SeekGreaterOnSwitch:integer;1
a=StartTime:integer;0
a=OpaqueData:buffer;"TUxUSQAFAAIAAAAAAAEAAQADAAAAIgAAACJWSURPUlY0MAKAAeAADAAAAAAAGAAAAAgQIEAAgAAAAAAiAAAAIlZJRE9SVjQwAoAB4AAMAAAAAAAYAAAACBAgQACAAAAAACIAAAAiVklET1JWNDACgAHgAAwAAAAAABgAAAAIECBAAIAA"
a=RMFF 1.0 Flags:buffer;"AAUAAgACAAAAAgAA"
a=ASMRuleBook:string;"#($Bandwidth <
117959),TimestampDelivery=T,DropByN=T,priority=9;#($Bandwidth >=
117959) && ($Bandwidth <
317959),AverageBandwidth=117959,Priority=9;#($Bandwidth >= 117959) &&
($Bandwidth < 317959),AverageBandwidth=0,Priority=5,OnDepend=\"1\";#($Bandwidth
>= 317959),AverageBandwidth=317959,Priority=9;#($Bandwidth >=
317959),AverageBandwidth=0,Priority=5,OnDepend=\"3\";"
a=intrinsicDurationType:string;"intrinsicDurationContinuous"
a=StreamName:string;"video/x-pn-multirate-realvideo logical stream"
m=audio 0 RTP/AVP 101
b=AS:35
b=RR:1201
b=RS:400
a=control:streamid=1
a=range:npt=0-5261.077000
a=length:npt=5261.077000
a=rtpmap:101 x-pn-realaudio/1000
a=fmtp:101
a=mimetype:string;"audio/x-pn-realaudio"
a=Helix-Adaptation-Support:1
a=ActualPreroll:integer;2275
a=AvgBitRate:integer;32041
a=AvgPacketSize:integer;651
a=EndOneRuleEndAll:integer;1
a=EndTime:integer;5260243
a=MaxBitRate:integer;32041
a=MaxPacketSize:integer;651
a=MinimumSwitchOverlap:integer;200
a=Preroll:integer;4550
a=SeekGreaterOnSwitch:integer;0
a=StartTime:integer;0
a=OpaqueData:buffer;"TUxUSQACAAAAAAABAAAAVi5yYf0ABQAALnJhNQAAABAABQAAAEYABAAAAosAAAAAAAOqtAAAAAAADgKLAF0AAAAArEQAAKxEAAAAEAABZ2VucmNvb2sBBwAAAAAACAEAAAEEAAAl"
a=RMFF 1.0 Flags:buffer;"AAIAAgAA"
a=ASMRuleBook:string;"AverageBandwidth=32041,Priority=5;AverageBandwidth=0,Priority=5,OnDepend=\"0\",
OffDepend=\"0\";"
a=intrinsicDurationType:string;"intrinsicDurationContinuous"
a=StreamName:string;"audio/x-pn-multirate-realaudio logical stream"

Opened URL "rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm",
returning a SDP description:
v=0
o=- 1222912325 1222912325 IN IP4 143.48.1.141
s=Genome Informatics
i=CSHL Leading Strand (C) CSHL 2008
c=IN IP4 0.0.0.0
t=0 0
a=SdpplinVersion:1610641560
a=StreamCount:integer;2
a=control:*
a=Flags:integer;25
a=IsRealDataType:integer;1
a=Author:buffer;"Q1NITCBMZWFkaW5nIFN0cmFuZAA="
a=Copyright:buffer;"KEMpIENTSEwgMjAwOAA="
a=Title:buffer;"R2Vub21lIEluZm9ybWF0aWNzAA=="
a=ASMRuleBook:string;"#($Bandwidth < 350000),Stream0Bandwidth =
117959, Stream1Bandwidth = 32041;#($Bandwidth >=
350000),Stream0Bandwidth = 317959, Stream1Bandwidth = 32041;"
a=range:npt=0-5261.077000
m=video 0 RTP/AVP 101
b=AS:382
b=RR:11923
b=RS:3974
a=control:streamid=0
a=range:npt=0-5260.243000
a=length:npt=5260.243000
a=rtpmap:101 x-pn-realvideo/1000
a=fmtp:101
a=mimetype:string;"video/x-pn-realvideo"
a=Helix-Adaptation-Support:1
a=AvgBitRate:integer;317959
a=AvgPacketSize:integer;349
a=EndOneRuleEndAll:integer;1
a=EndTime:integer;5260243
a=MaxBitRate:integer;317959
a=MaxPacketSize:integer;1342
a=MinimumSwitchOverlap:integer;0
a=Preroll:integer;5048
a=SeekGreaterOnSwitch:integer;1
a=StartTime:integer;0
a=OpaqueData:buffer;"TUxUSQAFAAIAAAAAAAEAAQADAAAAIgAAACJWSURPUlY0MAKAAeAADAAAAAAAGAAAAAgQIEAAgAAAAAAiAAAAIlZJRE9SVjQwAoAB4AAMAAAAAAAYAAAACBAgQACAAAAAACIAAAAiVklET1JWNDACgAHgAAwAAAAAABgAAAAIECBAAIAA"
a=RMFF 1.0 Flags:buffer;"AAUAAgACAAAAAgAA"
a=ASMRuleBook:string;"#($Bandwidth <
117959),TimestampDelivery=T,DropByN=T,priority=9;#($Bandwidth >=
117959) && ($Bandwidth <
317959),AverageBandwidth=117959,Priority=9;#($Bandwidth >= 117959) &&
($Bandwidth < 317959),AverageBandwidth=0,Priority=5,OnDepend=\"1\";#($Bandwidth
>= 317959),AverageBandwidth=317959,Priority=9;#($Bandwidth >=
317959),AverageBandwidth=0,Priority=5,OnDepend=\"3\";"
a=intrinsicDurationType:string;"intrinsicDurationContinuous"
a=StreamName:string;"video/x-pn-multirate-realvideo logical stream"
m=audio 0 RTP/AVP 101
b=AS:35
b=RR:1201
b=RS:400
a=control:streamid=1
a=range:npt=0-5261.077000
a=length:npt=5261.077000
a=rtpmap:101 x-pn-realaudio/1000
a=fmtp:101
a=mimetype:string;"audio/x-pn-realaudio"
a=Helix-Adaptation-Support:1
a=ActualPreroll:integer;2275
a=AvgBitRate:integer;32041
a=AvgPacketSize:integer;651
a=EndOneRuleEndAll:integer;1
a=EndTime:integer;5260243
a=MaxBitRate:integer;32041
a=MaxPacketSize:integer;651
a=MinimumSwitchOverlap:integer;200
a=Preroll:integer;4550
a=SeekGreaterOnSwitch:integer;0
a=StartTime:integer;0
a=OpaqueData:buffer;"TUxUSQACAAAAAAABAAAAVi5yYf0ABQAALnJhNQAAABAABQAAAEYABAAAAosAAAAAAAOqtAAAAAAADgKLAF0AAAAArEQAAKxEAAAAEAABZ2VucmNvb2sBBwAAAAAACAEAAAEEAAAl"
a=RMFF 1.0 Flags:buffer;"AAIAAgAA"
a=ASMRuleBook:string;"AverageBandwidth=32041,Priority=5;AverageBandwidth=0,Priority=5,OnDepend=\"0\",
OffDepend=\"0\";"
a=intrinsicDurationType:string;"intrinsicDurationContinuous"
a=StreamName:string;"audio/x-pn-multirate-realaudio logical stream"

Unable to create receiver for "video/X-PN-REALVIDEO" subsession: RTP
payload format unknown or not supported
Unable to create receiver for "audio/X-PN-REALAUDIO" subsession: RTP
payload format unknown or not supported





OUTPUT USING *INCORRECT* USER / PASSWD (as a test):

~/src/live/testProgs/openRTSP -u me whatever
rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm
Sending request: OPTIONS
rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm RTSP/1.0
CSeq: 1
User-Agent: openRTSP (LIVE555 Streaming Media v2008.10.07)


Received OPTIONS response: RTSP/1.0 200 OK
CSeq: 1
Date: Thu, 09 Oct 2008 08:20:16 GMT
Server: Helix Server Version 11.1.7.3406 (win32) (RealServer compatible)
Public: OPTIONS, DESCRIBE, ANNOUNCE, PLAY, PAUSE, SETUP,
GET_PARAMETER, SET_PARAMETER, TEARDOWN
TurboPlay: 1
RealChallenge1: 3fe3f9f0e840918e7d03f7969b1c391d
StatsMask: 8


Sending request: DESCRIBE
rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: openRTSP (LIVE555 Streaming Media v2008.10.07)


Received DESCRIBE response: RTSP/1.0 401 Unauthorized
CSeq: 2
Date: Thu, 09 Oct 2008 08:20:16 GMT
Set-Cookie: cbid=ifjjgmpijjikfldmeojokpktlojrktlufkejkidlejjfeiplmnkrnpltnrnnrqmpqfcjjhcl;path=/;expires=Thu,31-Dec-2037
23:59:59 GMT
WWW-Authenticate: Basic realm="MEETSTREAM.ContentRealm"


Sending request: DESCRIBE
rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm RTSP/1.0
CSeq: 3
Accept: application/sdp
Authorization: Basic ZGFuLmJvbHNlcjowMDAwMDYw
User-Agent: openRTSP (LIVE555 Streaming Media v2008.10.07)


Received DESCRIBE response: RTSP/1.0 401 Unauthorized
CSeq: 3
Date: Thu, 09 Oct 2008 08:20:16 GMT
WWW-Authenticate: Basic realm="MEETSTREAM.ContentRealm"


Failed to get a SDP description from URL
"rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm": cannot handle
DESCRIBE response: RTSP/1.0 401 Unauthorized

From finlayson at live555.com  Thu Oct  9 06:13:31 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 09 Oct 2008 06:13:31 -0700
Subject: [Live-devel] RTSP authentication for a 'real' stream?
In-Reply-To: <2c8757af0810090122u54a66fb6xc46716378ed5dba8@mail.gmail.co
 m>
References: <2c8757af0810090122u54a66fb6xc46716378ed5dba8@mail.gmail.com>
Message-ID: <200810091322.m99DMOir087922@ns.live555.com>

The authentication is not the problem; it is working perfectly.

The problem is shown by the following error lines:

>Unable to create receiver for "video/X-PN-REALVIDEO" subsession: RTP
>payload format unknown or not supported
>Unable to create receiver for "audio/X-PN-REALAUDIO" subsession: RTP
>payload format unknown or not supported

The FAQ explains what's wrong here; I'll let you read it to get the answer.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From dan.bolser at gmail.com  Thu Oct  9 07:00:38 2008
From: dan.bolser at gmail.com (Dan Bolser)
Date: Thu, 9 Oct 2008 15:00:38 +0100
Subject: [Live-devel] RTSP authentication for a 'real' stream?
In-Reply-To: <200810091322.m99DMOir087922@ns.live555.com>
References: <2c8757af0810090122u54a66fb6xc46716378ed5dba8@mail.gmail.com>
	<200810091322.m99DMOir087922@ns.live555.com>
Message-ID: <2c8757af0810090700n755f6fe0n7aa7eafbe45434c2@mail.gmail.com>

2008/10/9 Ross Finlayson <finlayson at live555.com>:
> The authentication is not the problem; it is working perfectly.
>
> The problem is shown by the following error lines:
>
>> Unable to create receiver for "video/X-PN-REALVIDEO" subsession: RTP
>> payload format unknown or not supported
>> Unable to create receiver for "audio/X-PN-REALAUDIO" subsession: RTP
>> payload format unknown or not supported
>
> The FAQ explains what's wrong here; I'll let you read it to get the answer.

Ahh... I had thought that these lines were not significant (for some reason).

How can I dump the stream to file in order to open the file with real
player or mplayer? Is this possible? Part of the problem (I think) is
that authentication fails with mplayer, so it would be convenient to
use LIVE555 to just dump the file.


Thanks for the pointer to the FAQ - I was getting confused because of
the different mplayer / vlc / etc. problems / error messages!

Dan.


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



-- 
http://network.nature.com/profile/dan

From gabrieledeluca at libero.it  Thu Oct  9 08:48:42 2008
From: gabrieledeluca at libero.it (gabrieledeluca at libero.it)
Date: Thu,  9 Oct 2008 17:48:42 +0200
Subject: [Live-devel] Streaming relaying
Message-ID: <K8HAL6$905F658EAE9BA383CD5A9C9FB0F68D83@libero.it>

Hi,
I want relaying rtp packets unicast->unicast stream...
I'm live555 newbie, can You give me tips?

I already see your example testRelay.cpp but it's a multicast->unicast relayng!

Help me,
thanks in advance,

Bobo


From gabrieledeluca at libero.it  Thu Oct  9 08:53:37 2008
From: gabrieledeluca at libero.it (gabrieledeluca at libero.it)
Date: Thu,  9 Oct 2008 17:53:37 +0200
Subject: [Live-devel] testOnDemandRTSPServer problem with test.mpg
Message-ID: <K8HATD$907C62B4194C79834DBB37AC40CB185C@libero.it>

Hi,
I have a problem with testOnDemandRTSPServer with mpg file!
In fact, I receive the mpeg ok but audio is broken (audio is ok after pause or stop and re-play).
Why? Video Subsession is ok, Audio Subsession don't work very well. 
I use VLC to play the stream!

Thanks in advance,

Bobo


From javatexan at gmail.com  Thu Oct  9 09:28:22 2008
From: javatexan at gmail.com (javatexan rocks)
Date: Thu, 9 Oct 2008 11:28:22 -0500
Subject: [Live-devel] openRTSP questions
Message-ID: <898771230810090928y1199f614kc0971f34eacf8d5@mail.gmail.com>

Is there a Live555 IRC channel on freenode.net?  Just curious, the IRC
channels seem to be very helpful with other multimedia based projects like
mythtv, etc.

I have enjoyed playing with the openRTSP program, it has fit my needs in
almost every way.  I am getting to the point though that I will have to
change some of the behavior and I would like to ping you seasoned guys
before I "run off into the weeds".  This is what I think I need to do,
comments are most welcome.  I think I need to have openRTSP to start the
RTSP session and never let it go (only stop on Ctrl-C) and I need to change
the file sink maybe with a decorator, to be smart enough to save so many
minutes are saved to one datafile then open another file and continue to
save to it...so on and so on.  So the HDD does not completely fill, I want
to delete older files if the total used size is bigger than some upper
limit.  It needs to work on the same principle as a security camera hooked
to a vcr that "loops" recording.

Does this sound reasonable?  I am not seeing how I will pass the extra
configuration parameters to the decorator yet, or even if the decorator is
possible.  I am basing my project on openRTSP and the mp4 and quicktime
filesink.

Thanks in advance for your help.
-javatexan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081009/b2ef56a5/attachment.html>

From finlayson at live555.com  Thu Oct  9 11:17:22 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 09 Oct 2008 11:17:22 -0700
Subject: [Live-devel] openRTSP questions
In-Reply-To: <898771230810090928y1199f614kc0971f34eacf8d5@mail.gmail.com
 >
References: <898771230810090928y1199f614kc0971f34eacf8d5@mail.gmail.com>
Message-ID: <200810091825.m99IPH4X004827@ns.live555.com>

At 09:28 AM 10/9/2008, you wrote:
>Is there a Live555 IRC channel on <http://freenode.net>freenode.net?

No.  Support for the "LIVE555 Streaming Media" software is via this 
mailing list.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From finlayson at live555.com  Thu Oct  9 11:21:24 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 09 Oct 2008 11:21:24 -0700
Subject: [Live-devel] RTSP authentication for a 'real' stream?
In-Reply-To: <2c8757af0810090700n755f6fe0n7aa7eafbe45434c2@mail.gmail.co
 m>
References: <2c8757af0810090122u54a66fb6xc46716378ed5dba8@mail.gmail.com>
	<200810091322.m99DMOir087922@ns.live555.com>
	<2c8757af0810090700n755f6fe0n7aa7eafbe45434c2@mail.gmail.com>
Message-ID: <200810091829.m99ITvHa009612@ns.live555.com>


>How can I dump the stream to file in order to open the file with real
>player or mplayer? Is this possible?

I'm sure it's 'possible'.  However, because "Real Networks" does not 
document their proprietary RTP payload formats or file formats, it's 
unlikely you'll be able to find out how.

The solution is to give up on using "Real Networks" servers, and use 
a standards-compliant server instead.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From finlayson at live555.com  Thu Oct  9 11:25:59 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 09 Oct 2008 11:25:59 -0700
Subject: [Live-devel] testOnDemandRTSPServer problem with test.mpg
In-Reply-To: <K8HATD$907C62B4194C79834DBB37AC40CB185C@libero.it>
References: <K8HATD$907C62B4194C79834DBB37AC40CB185C@libero.it>
Message-ID: <200810091835.m99IZHZQ015114@ns.live555.com>


>I have a problem with testOnDemandRTSPServer with mpg file!
>In fact, I receive the mpeg ok but audio is broken (audio is ok 
>after pause or stop and re-play).
>Why? Video Subsession is ok, Audio Subsession don't work very well.
>I use VLC to play the stream!

Please put the (".mpg") file on a publically-accessible web (or FTP) 
server, and post the URL (*not* the file itself) to this mailing 
list, so we can try to figure out what's wrong.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From finlayson at live555.com  Thu Oct  9 11:32:56 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 09 Oct 2008 11:32:56 -0700
Subject: [Live-devel] Streaming relaying
In-Reply-To: <K8HAL6$905F658EAE9BA383CD5A9C9FB0F68D83@libero.it>
References: <K8HAL6$905F658EAE9BA383CD5A9C9FB0F68D83@libero.it>
Message-ID: <200810091840.m99Ie6x1020052@ns.live555.com>


>I want relaying rtp packets unicast->unicast stream...
>I'm live555 newbie, can You give me tips?
>
>I already see your example testRelay.cpp but it's a 
>multicast->unicast relayng!

Please *do not* post the same question to the mailing list more than 
once!  (Because of this, all future postings from you will be moderated.)

None of our demo applications do unicast->unicast relaying.

However, if the input stream's destination port number is known in 
advance (i..e, you're not using RTSP to initiate the stream), then 
you *may* be able to get our "testRelay" demo application to work by 
changing "inputAddressStr" to "0.0.0.0" (and, of course, setting 
"inputPort" appropriately).

If you're using RTSP, then things are more difficult.  You can't 
easily do raw-UDP-level relaying, but you could do RTP payload 
relaying by replacing "FIleSink" with an appropriate "RTPSink" 
subclass, for each stream.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From gabrieledeluca at libero.it  Thu Oct  9 11:55:00 2008
From: gabrieledeluca at libero.it (Gabriele De Luca)
Date: Thu, 09 Oct 2008 20:55:00 +0200
Subject: [Live-devel] Streaming relaying
Message-ID: <48EE5384.1010506@libero.it>

Sorry,
I'm rewrite previous message because the first message have the empy object.
Can you explain me in *exhaustive *steps how do the replacing "FileSink" 
with an appropriate "RTPSink" subclass, for each stream?
I use SDP to configure my connection!

Thanks in advance,

Bobo


From dan.bolser at gmail.com  Thu Oct  9 12:59:13 2008
From: dan.bolser at gmail.com (Dan Bolser)
Date: Thu, 9 Oct 2008 20:59:13 +0100
Subject: [Live-devel] RTSP authentication for a 'real' stream?
In-Reply-To: <200810091829.m99ITvHa009612@ns.live555.com>
References: <2c8757af0810090122u54a66fb6xc46716378ed5dba8@mail.gmail.com>
	<200810091322.m99DMOir087922@ns.live555.com>
	<2c8757af0810090700n755f6fe0n7aa7eafbe45434c2@mail.gmail.com>
	<200810091829.m99ITvHa009612@ns.live555.com>
Message-ID: <2c8757af0810091259y380f8be2wb9fba5b9f587839e@mail.gmail.com>

2008/10/9 Ross Finlayson <finlayson at live555.com>

>
>  How can I dump the stream to file in order to open the file with real
>> player or mplayer? Is this possible?
>>
>
> I'm sure it's 'possible'.  However, because "Real Networks" does not
> document their proprietary RTP payload formats or file formats, it's
> unlikely you'll be able to find out how.
>
> The solution is to give up on using "Real Networks" servers, and use a
> standards-compliant server instead.


Thats great, except for the fact that I have no choice but to use this
particular server for this particular content in this instance. Like when
someone sends you a vital document that just happens to be in a proprietary
format. Sometimes you simply have no choice.

Perhaps I'm being dumb, but I thought that if openRTSP is trying to play the
stream, it would be relatively simple to dump that stream to file. Or am I
missing the point?

Cheers,

Dan.



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



-- 
http://network.nature.com/profile/dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081009/ffcfb5cf/attachment.html>

From LINY0029 at ntu.edu.sg  Thu Oct  9 19:29:22 2008
From: LINY0029 at ntu.edu.sg (#LIN YOUMING#)
Date: Fri, 10 Oct 2008 10:29:22 +0800
Subject: [Live-devel] Enquiry on compiling error
Message-ID: <B1AA98568C81904FB704DF464FC6216E0199E291@MAIL24.student.main.ntu.edu.sg>

Hi,
 
I am a student from NTU, Singapore. I have downloaded the codes and compile accordingly to the steps. I am using Visual Studio 2008 but apparently, I seems to have error when running the patch.
 
Probably you can enlighten me?
 
Regards,
Wayne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081010/3dc91728/attachment.html>

From soumyapnarayan at tataelxsi.co.in  Thu Oct  9 20:27:34 2008
From: soumyapnarayan at tataelxsi.co.in (Soumya P N)
Date: Fri, 10 Oct 2008 08:57:34 +0530
Subject: [Live-devel] Memory Leak while exiting from doEventLoop
In-Reply-To: <200810081421.m98ELlO1049155@ns.live555.com>
Message-ID: <006201c92a88$23be9060$45033c0a@telxsi.com>

Hi Ross,

   In the BasicTaskScheduler::doEventLoop I have added code for exiting on
keyboard hit. Now if I am hitting keyboard, it will exit from the loop ,but
after that it hangs.I think it may be due to some memory leaks. So if you
can help me on the resources to be deleted before forcefully exiting from
that loop,,,it will be great...

Thanks,,,,,
Soumya

-----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, October 08, 2008 7:47 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Memory Leak while exiting from doEventLoop



>In the downloaded code the doEventLoop() was not exiting and it was a
>infinite loop. Now i changed the code
>so that it will exit on keyboard hit. Then also it is not exiting properly.

What do you mean "not exiting properly"?  Is "doEventLoop()" (when
you add a 'watch variable' returning, or not?  Have you read this
link (which is in the FAQ):
         http://lists.live555.com/pipermail/live-devel/2006-March/004192.htm
l


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>

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


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  Thu Oct  9 20:37:03 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 09 Oct 2008 20:37:03 -0700
Subject: [Live-devel] RTSP authentication for a 'real' stream?
In-Reply-To: <2c8757af0810091259y380f8be2wb9fba5b9f587839e@mail.gmail.co
 m>
References: <2c8757af0810090122u54a66fb6xc46716378ed5dba8@mail.gmail.com>
	<200810091322.m99DMOir087922@ns.live555.com>
	<2c8757af0810090700n755f6fe0n7aa7eafbe45434c2@mail.gmail.com>
	<200810091829.m99ITvHa009612@ns.live555.com>
	<2c8757af0810091259y380f8be2wb9fba5b9f587839e@mail.gmail.com>
Message-ID: <200810100344.m9A3i0q7085572@ns.live555.com>


>Perhaps I'm being dumb, but I thought that if openRTSP is trying to 
>play the stream, it would be relatively simple to dump that stream 
>to file. Or am I missing the point?

"openRTSP" doesn't 'play' anything; it just downloads data.

In the case of the "X-PN_REAL..." streams, it doesn't know how the 
data is packed into RTP packets (i.e., what special headers etc. 
might be present there), so it can't do anything intelligent with the stream.

You can, however, give "openRTSP" the "-S 4" option, to tell it to 
download all data that it receives (following the standard RTP 
header).  See <http://www.live555.com/openRTSP/#other-options>.  If 
you do this, though, it's very unlikely that you'll be able to do 
anything useful with the received data.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From finlayson at live555.com  Thu Oct  9 20:47:28 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 09 Oct 2008 20:47:28 -0700
Subject: [Live-devel] RTSP authentication for a 'real' stream?
Message-ID: <200810100352.m9A3qeNv094582@ns.live555.com>

Oops, in my previous message, I meant to say

You can, however, give "openRTSP" the "-S 0" option (not "-S 4").  Sorry.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From dan.bolser at gmail.com  Thu Oct  9 23:08:10 2008
From: dan.bolser at gmail.com (Dan Bolser)
Date: Fri, 10 Oct 2008 07:08:10 +0100
Subject: [Live-devel] RTSP authentication for a 'real' stream?
In-Reply-To: <200810100344.m9A3i0q7085572@ns.live555.com>
References: <2c8757af0810090122u54a66fb6xc46716378ed5dba8@mail.gmail.com>
	<200810091322.m99DMOir087922@ns.live555.com>
	<2c8757af0810090700n755f6fe0n7aa7eafbe45434c2@mail.gmail.com>
	<200810091829.m99ITvHa009612@ns.live555.com>
	<2c8757af0810091259y380f8be2wb9fba5b9f587839e@mail.gmail.com>
	<200810100344.m9A3i0q7085572@ns.live555.com>
Message-ID: <2c8757af0810092308r561dad6cj6944a145f9eee3de@mail.gmail.com>

2008/10/10 Ross Finlayson <finlayson at live555.com>:
>
>> Perhaps I'm being dumb, but I thought that if openRTSP is trying to play
>> the stream, it would be relatively simple to dump that stream to file. Or am
>> I missing the point?
>
> "openRTSP" doesn't 'play' anything; it just downloads data.

Ah, OK. Where would it save the file? (Perhaps see the below.)


> In the case of the "X-PN_REAL..." streams, it doesn't know how the data is
> packed into RTP packets (i.e., what special headers etc. might be present
> there), so it can't do anything intelligent with the stream.
>
> You can, however, give "openRTSP" the "-S 4" option, to tell it to download
> all data that it receives (following the standard RTP header).  See
> <http://www.live555.com/openRTSP/#other-options>.  If you do this, though,
> it's very unlikely that you'll be able to do anything useful with the
> received data.

Doesn't mplayer stand a chance?


In any case, I am still getting an error using the "-S 0" option:

"Failed to setup "video/X-PN-REALVIDEO" subsession: SETUP: cannot
handle response: RTSP/1.0 461 Unsupported transport" ??


(Details below). Sorry if this is simply related to propriatary vs.
standard formats again.


Thanks for your help,

Dan


openRTSP -S 0 -u me secret rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm
Sending request: OPTIONS
rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm RTSP/1.0
CSeq: 1
User-Agent: openRTSP (LIVE555 Streaming Media v2008.04.02)


Received OPTIONS response: RTSP/1.0 200 OK
CSeq: 1
Date: Fri, 10 Oct 2008 05:57:37 GMT
Server: Helix Server Version 11.1.7.3406 (win32) (RealServer compatible)
Public: OPTIONS, DESCRIBE, ANNOUNCE, PLAY, PAUSE, SETUP,
GET_PARAMETER, SET_PARAMETER, TEARDOWN
TurboPlay: 1
RealChallenge1: 5b55d20742297181dffee564bff228d8
StatsMask: 8


Sending request: DESCRIBE
rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: openRTSP (LIVE555 Streaming Media v2008.04.02)


Received DESCRIBE response: RTSP/1.0 401 Unauthorized
CSeq: 2
Date: Fri, 10 Oct 2008 05:57:38 GMT
Set-Cookie: cbid=efdgohpihjckfidmeojonphqnrjrktlufkejkidligdfjiplrnjoppkternnkqnpifcgfmgi;path=/;expires=Thu,31-Dec-2037
23:59:59 GMT
WWW-Authenticate: Basic realm="MEETSTREAM.ContentRealm"


Sending request: DESCRIBE
rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm RTSP/1.0
CSeq: 3
Accept: application/sdp
Authorization: Basic ZGFuLmJvbHNlcjowMDAwMDY=
User-Agent: openRTSP (LIVE555 Streaming Media v2008.04.02)


Received DESCRIBE response: RTSP/1.0 200 OK
CSeq: 3
Date: Fri, 10 Oct 2008 05:57:38 GMT
Last-Modified: Thu, 02 Oct 2008 01:52:05 GMT
Content-base: rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm/
Vary: User-Agent, ClientID
Content-type: application/sdp
x-real-usestrackid: 1
Content-length: 2912


Need to read 2912 extra bytes
Read 2912 extra bytes: v=0
o=- 1222912325 1222912325 IN IP4 143.48.1.141
s=Genome Informatics
i=CSHL Leading Strand (C) CSHL 2008
c=IN IP4 0.0.0.0
t=0 0
a=SdpplinVersion:1610641560
a=StreamCount:integer;2
a=control:*
a=Flags:integer;25
a=IsRealDataType:integer;1
a=Author:buffer;"Q1NITCBMZWFkaW5nIFN0cmFuZAA="
a=Copyright:buffer;"KEMpIENTSEwgMjAwOAA="
a=Title:buffer;"R2Vub21lIEluZm9ybWF0aWNzAA=="
a=ASMRuleBook:string;"#($Bandwidth < 350000),Stream0Bandwidth =
117959, Stream1Bandwidth = 32041;#($Bandwidth >=
350000),Stream0Bandwidth = 317959, Stream1Bandwidth = 32041;"
a=range:npt=0-5261.077000
m=video 0 RTP/AVP 101
b=AS:382
b=RR:11923
b=RS:3974
a=control:streamid=0
a=range:npt=0-5260.243000
a=length:npt=5260.243000
a=rtpmap:101 x-pn-realvideo/1000
a=fmtp:101
a=mimetype:string;"video/x-pn-realvideo"
a=Helix-Adaptation-Support:1
a=AvgBitRate:integer;317959
a=AvgPacketSize:integer;349
a=EndOneRuleEndAll:integer;1
a=EndTime:integer;5260243
a=MaxBitRate:integer;317959
a=MaxPacketSize:integer;1342
a=MinimumSwitchOverlap:integer;0
a=Preroll:integer;5048
a=SeekGreaterOnSwitch:integer;1
a=StartTime:integer;0
a=OpaqueData:buffer;"TUxUSQAFAAIAAAAAAAEAAQADAAAAIgAAACJWSURPUlY0MAKAAeAADAAAAAAAGAAAAAgQIEAAgAAAAAAiAAAAIlZJRE9SVjQwAoAB4AAMAAAAAAAYAAAACBAgQACAAAAAACIAAAAiVklET1JWNDACgAHgAAwAAAAAABgAAAAIECBAAIAA"
a=RMFF 1.0 Flags:buffer;"AAUAAgACAAAAAgAA"
a=ASMRuleBook:string;"#($Bandwidth <
117959),TimestampDelivery=T,DropByN=T,priority=9;#($Bandwidth >=
117959) && ($Bandwidth <
317959),AverageBandwidth=117959,Priority=9;#($Bandwidth >= 117959) &&
($Bandwidth < 317959),AverageBandwidth=0,Priority=5,OnDepend=\"1\";#($Bandwidth
>= 317959),AverageBandwidth=317959,Priority=9;#($Bandwidth >=
317959),AverageBandwidth=0,Priority=5,OnDepend=\"3\";"
a=intrinsicDurationType:string;"intrinsicDurationContinuous"
a=StreamName:string;"video/x-pn-multirate-realvideo logical stream"
m=audio 0 RTP/AVP 101
b=AS:35
b=RR:1201
b=RS:400
a=control:streamid=1
a=range:npt=0-5261.077000
a=length:npt=5261.077000
a=rtpmap:101 x-pn-realaudio/1000
a=fmtp:101
a=mimetype:string;"audio/x-pn-realaudio"
a=Helix-Adaptation-Support:1
a=ActualPreroll:integer;2275
a=AvgBitRate:integer;32041
a=AvgPacketSize:integer;651
a=EndOneRuleEndAll:integer;1
a=EndTime:integer;5260243
a=MaxBitRate:integer;32041
a=MaxPacketSize:integer;651
a=MinimumSwitchOverlap:integer;200
a=Preroll:integer;4550
a=SeekGreaterOnSwitch:integer;0
a=StartTime:integer;0
a=OpaqueData:buffer;"TUxUSQACAAAAAAABAAAAVi5yYf0ABQAALnJhNQAAABAABQAAAEYABAAAAosAAAAAAAOqtAAAAAAADgKLAF0AAAAArEQAAKxEAAAAEAABZ2VucmNvb2sBBwAAAAAACAEAAAEEAAAl"
a=RMFF 1.0 Flags:buffer;"AAIAAgAA"
a=ASMRuleBook:string;"AverageBandwidth=32041,Priority=5;AverageBandwidth=0,Priority=5,OnDepend=\"0\",
OffDepend=\"0\";"
a=intrinsicDurationType:string;"intrinsicDurationContinuous"
a=StreamName:string;"audio/x-pn-multirate-realaudio logical stream"

Opened URL "rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm",
returning a SDP description:
v=0
o=- 1222912325 1222912325 IN IP4 143.48.1.141
s=Genome Informatics
i=CSHL Leading Strand (C) CSHL 2008
c=IN IP4 0.0.0.0
t=0 0
a=SdpplinVersion:1610641560
a=StreamCount:integer;2
a=control:*
a=Flags:integer;25
a=IsRealDataType:integer;1
a=Author:buffer;"Q1NITCBMZWFkaW5nIFN0cmFuZAA="
a=Copyright:buffer;"KEMpIENTSEwgMjAwOAA="
a=Title:buffer;"R2Vub21lIEluZm9ybWF0aWNzAA=="
a=ASMRuleBook:string;"#($Bandwidth < 350000),Stream0Bandwidth =
117959, Stream1Bandwidth = 32041;#($Bandwidth >=
350000),Stream0Bandwidth = 317959, Stream1Bandwidth = 32041;"
a=range:npt=0-5261.077000
m=video 0 RTP/AVP 101
b=AS:382
b=RR:11923
b=RS:3974
a=control:streamid=0
a=range:npt=0-5260.243000
a=length:npt=5260.243000
a=rtpmap:101 x-pn-realvideo/1000
a=fmtp:101
a=mimetype:string;"video/x-pn-realvideo"
a=Helix-Adaptation-Support:1
a=AvgBitRate:integer;317959
a=AvgPacketSize:integer;349
a=EndOneRuleEndAll:integer;1
a=EndTime:integer;5260243
a=MaxBitRate:integer;317959
a=MaxPacketSize:integer;1342
a=MinimumSwitchOverlap:integer;0
a=Preroll:integer;5048
a=SeekGreaterOnSwitch:integer;1
a=StartTime:integer;0
a=OpaqueData:buffer;"TUxUSQAFAAIAAAAAAAEAAQADAAAAIgAAACJWSURPUlY0MAKAAeAADAAAAAAAGAAAAAgQIEAAgAAAAAAiAAAAIlZJRE9SVjQwAoAB4AAMAAAAAAAYAAAACBAgQACAAAAAACIAAAAiVklET1JWNDACgAHgAAwAAAAAABgAAAAIECBAAIAA"
a=RMFF 1.0 Flags:buffer;"AAUAAgACAAAAAgAA"
a=ASMRuleBook:string;"#($Bandwidth <
117959),TimestampDelivery=T,DropByN=T,priority=9;#($Bandwidth >=
117959) && ($Bandwidth <
317959),AverageBandwidth=117959,Priority=9;#($Bandwidth >= 117959) &&
($Bandwidth < 317959),AverageBandwidth=0,Priority=5,OnDepend=\"1\";#($Bandwidth
>= 317959),AverageBandwidth=317959,Priority=9;#($Bandwidth >=
317959),AverageBandwidth=0,Priority=5,OnDepend=\"3\";"
a=intrinsicDurationType:string;"intrinsicDurationContinuous"
a=StreamName:string;"video/x-pn-multirate-realvideo logical stream"
m=audio 0 RTP/AVP 101
b=AS:35
b=RR:1201
b=RS:400
a=control:streamid=1
a=range:npt=0-5261.077000
a=length:npt=5261.077000
a=rtpmap:101 x-pn-realaudio/1000
a=fmtp:101
a=mimetype:string;"audio/x-pn-realaudio"
a=Helix-Adaptation-Support:1
a=ActualPreroll:integer;2275
a=AvgBitRate:integer;32041
a=AvgPacketSize:integer;651
a=EndOneRuleEndAll:integer;1
a=EndTime:integer;5260243
a=MaxBitRate:integer;32041
a=MaxPacketSize:integer;651
a=MinimumSwitchOverlap:integer;200
a=Preroll:integer;4550
a=SeekGreaterOnSwitch:integer;0
a=StartTime:integer;0
a=OpaqueData:buffer;"TUxUSQACAAAAAAABAAAAVi5yYf0ABQAALnJhNQAAABAABQAAAEYABAAAAosAAAAAAAOqtAAAAAAADgKLAF0AAAAArEQAAKxEAAAAEAABZ2VucmNvb2sBBwAAAAAACAEAAAEEAAAl"
a=RMFF 1.0 Flags:buffer;"AAIAAgAA"
a=ASMRuleBook:string;"AverageBandwidth=32041,Priority=5;AverageBandwidth=0,Priority=5,OnDepend=\"0\",
OffDepend=\"0\";"
a=intrinsicDurationType:string;"intrinsicDurationContinuous"
a=StreamName:string;"audio/x-pn-multirate-realaudio logical stream"

Created receiver for "video/X-PN-REALVIDEO" subsession (client ports
32802-32803)
Created receiver for "audio/X-PN-REALAUDIO" subsession (client ports
32804-32805)
Sending request: SETUP
rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm/streamid=0 RTSP/1.0
CSeq: 4
Transport: RTP/AVP;unicast;client_port=32802-32803
Authorization: Basic ZGFuLmJvbHNlcjowMDAwMDY=
User-Agent: openRTSP (LIVE555 Streaming Media v2008.04.02)


Received SETUP response: RTSP/1.0 461 Unsupported transport
CSeq: 4
Date: Fri, 10 Oct 2008 05:57:43 GMT


Failed to setup "video/X-PN-REALVIDEO" subsession: SETUP: cannot
handle response: RTSP/1.0 461 Unsupported transport
Sending request: SETUP
rtsp://meetstream.cshl.edu:554/Secure/INFOUK/1.rm/streamid=1 RTSP/1.0
CSeq: 5
Transport: RTP/AVP;unicast;client_port=32804-32805
Authorization: Basic ZGFuLmJvbHNlcjowMDAwMDY=
User-Agent: openRTSP (LIVE555 Streaming Media v2008.04.02)


Received SETUP response: RTSP/1.0 461 Unsupported transport
CSeq: 5
Date: Fri, 10 Oct 2008 05:57:43 GMT


Failed to setup "audio/X-PN-REALAUDIO" subsession: SETUP: cannot
handle response: RTSP/1.0 461 Unsupported transport





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



-- 
http://network.nature.com/profile/dan

From finlayson at live555.com  Thu Oct  9 23:12:56 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 09 Oct 2008 23:12:56 -0700
Subject: [Live-devel] RTSP authentication for a 'real' stream?
In-Reply-To: <2c8757af0810092308r561dad6cj6944a145f9eee3de@mail.gmail.co
 m>
References: <2c8757af0810090122u54a66fb6xc46716378ed5dba8@mail.gmail.com>
	<200810091322.m99DMOir087922@ns.live555.com>
	<2c8757af0810090700n755f6fe0n7aa7eafbe45434c2@mail.gmail.com>
	<200810091829.m99ITvHa009612@ns.live555.com>
	<2c8757af0810091259y380f8be2wb9fba5b9f587839e@mail.gmail.com>
	<200810100344.m9A3i0q7085572@ns.live555.com>
	<2c8757af0810092308r561dad6cj6944a145f9eee3de@mail.gmail.com>
Message-ID: <200810100618.m9A6IQMH049381@ns.live555.com>


>In any case, I am still getting an error using the "-S 0" option:
>
>"Failed to setup "video/X-PN-REALVIDEO" subsession: SETUP: cannot
>handle response: RTSP/1.0 461 Unsupported transport" ??

OK, now you're totally out of luck.  The Real Networks server is 
telling you that it does not support the standard RTSP/RTP/UDP protocol.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From soumya.patra at lge.com  Thu Oct  9 23:23:19 2008
From: soumya.patra at lge.com (soumya patra)
Date: Fri, 10 Oct 2008 11:53:19 +0530
Subject: [Live-devel] Audio video Synchronization problem
Message-ID: <20081010062320.3CEA055800B@LGEMRELSE7Q.lge.com>

Hi Ross,

    

      I have some synchronization problem in my streaming server.

  We are streaming H.264 with G.711 (PCMU), It is streaming properly because
I can trace both audio and video packet through network analyzer.

    But the audio is not audible in VLC client along with video. But it is
audible when I am streaming audio only.

 

   Waiting for your response.

 

Thanks & Regards

Soumya

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

From mean.while.mw at gmail.com  Thu Oct  9 23:37:35 2008
From: mean.while.mw at gmail.com (alex)
Date: Fri, 10 Oct 2008 14:37:35 +0800
Subject: [Live-devel] seeking in DSS stream
Message-ID: <ac699b810810092337q64421f9aqe967ead9f79f6798@mail.gmail.com>

hi,
I stream a mp4(h264+aac) file from a Darwin Streaming Server v5.5.3
and write a livemedia test client to test it.
When I do seeking operation, I find that when the client send pause,
seek and play command and start playing again, there will be a gap in
the DSS's RTCP SR ntpTimestamp(I print out this in
RTPReceptionStats::noteIncomingSR()), and this will cause the
MediaSubsession::getNormalPlayTime return a wrong NPT, jump from
201.17 to 3.78.
I think when client do seeking operation and send the rtsp play
command, the RTPReceptionStats::fHasBeenSynchronized should be set to
false, so that MediaSubsession::getNormalPlayTime can update the value
of fNPT_PTS_Offset with the new ntpTimestamp in the following RTCP SR.
Or if this jump of ntpTimestamp is a bug of the DSS server?
Could you please give me some advise?
I paste some of the logs after the mail. I print a message in
MediaSubsession::getNormalPlayTime(), and print a message when the
client receive incoming SR. The format is
 [ptsDouble*scale()]+[fNPT_PTS_Offset]=NPT[npt]-[curPacketRTPTimestamp][rtpInfo.timestamp]--A/V
 [1223617239.875652]-[-1223617038.702323]=NPT[201.173325]-[9813284][9756964]--A
Thank you very much for your help!
Yours, mw
-------------------------------------------------------------------------------------------------------
Sending request: PLAY rtsp://192.168.1.11/test.mp4/ RTSP/1.0
CSeq: 4
Session: 70888435244962
Range: npt=0.000-
User-Agent: RTP demuxer (LIVE555 Streaming Media v2008.05.12)


Received PLAY response: RTSP/1.0 200 OK
Server: DSS/5.5.3 (Build/489.12; Platform/Win32; Release/Darwin; )
Cseq: 4
Session: 70888435244962
Range: npt=0.00000-2099.88267
RTP-Info: url=rtsp://192.168.1.11/test.mp4/trackID=2;seq=30349;rtptime=4447,url=rtsp://192.168.1.11/test.mp4/trackID=6;seq=10665;rtptime=24057

(...omit some lines)

 [1223617035.630666]-[-1223617035.460000]=NPT[0.170666]-[9524][1332]--A
 [1223617035.660000]-[-1223617035.460000]=NPT[0.200000]-[46350][28350]--V
 [1223617035.715999]-[-1223617035.460000]=NPT[0.255999]-[13620][1332]--A
 [1223617035.700000]-[-1223617035.460000]=NPT[0.240000]-[49950][28350]--V
(...omit some lines)

 [1223617037.820000]-[-1223617035.460000]=NPT[2.360000]-[240750][28350]--V
 [1223617037.849324]-[-1223617035.460000]=NPT[2.389324]-[116020][1332]--A
 [1223617037.849324]-[-1223617035.460000]=NPT[2.389324]-[116020][1332]--A
 [1223617037.860000]-[-1223617035.460000]=NPT[2.400000]-[244350][28350]--V
(  seek to 200s)
Sending request: PAUSE rtsp://192.168.1.11/test.mp4/ RTSP/1.0
CSeq: 5
Session: 21775484192068
User-Agent: RTP demuxer (LIVE555 Streaming Media v2008.05.12)


 [1223617038.019990]-[-1223617035.460000]=NPT[2.559990]-[124212][1332]--A
 [1223617038.019990]-[-1223617035.460000]=NPT[2.559990]-[124212][1332]--A
Received PAUSE response: RTSP/1.0 200 OK
Server: DSS/5.5.3 (Build/489.12; Platform/Win32; Release/Darwin; )
Cseq: 5
Session: 21775484192068

 [1223617037.980000]-[-1223617035.460000]=NPT[2.520000]-[255150][28350]--V
 [1223617038.020000]-[-1223617035.460000]=NPT[2.560000]-[258750][28350]--V
===[noteIncomingSR][line:365]fSyncTime[0.000000]fSyncTimestamp[892679493]
===[noteIncomingSR][line:372]fSyncTime[1223617039.690000]fSyncTimestamp[171685]
Sending request: PLAY rtsp://192.168.1.11/test.mp4/ RTSP/1.0
CSeq: 6
Session: 21775484192068
Range: npt=200.000-
User-Agent: RTP demuxer (LIVE555 Streaming Media v2008.05.12)


 [1223617238.702323]-[-1223617035.460000]=NPT[203.242325]-[9756964][1332]--A
Received PLAY response: RTSP/1.0 200 OK
Server: DSS/5.5.3 (Build/489.12; Platform/Win32; Release/Darwin; )
Cseq: 6
Session: 21775484192068
Range: npt=200.00000-2099.88267
RTP-Info: url=rtsp://192.168.1.11/test.mp4/trackID=2;seq=4179;rtptime=18324000,url=rtsp://192.168.1.11/test.mp4/trackID=6;seq=21669;rtptime=9756964

(...omit some lines)
 [1223617239.875652]-[-1223617038.702323]=NPT[201.173325]-[9813284][9756964]--A
 [1223617239.875652]-[-1223617038.702323]=NPT[201.173325]-[9813284][9756964]--A
 [1223617239.875652]-[-1223617038.702323]=NPT[201.173325]-[9813284][9756964]--A
 [1223617239.864999]-[-1223617038.744999]=NPT[201.119995]-[18424800][18324000]--V
 [1223617239.904999]-[-1223617038.744999]=NPT[201.160004]-[18428400][18324000]--V
 [1223617239.944999]-[-1223617038.744999]=NPT[201.199997]-[18432000][18324000]--V
===[noteIncomingSR][line:365]fSyncTime[1223617239.875652]fSyncTimestamp[9813284]
===[noteIncomingSR][line:372]fSyncTime[1223617042.483000]fSyncTimestamp[9817380]
===[noteIncomingSR][line:365]fSyncTime[1223617239.944999]fSyncTimestamp[18432000]
===[noteIncomingSR][line:372]fSyncTime[1223617042.508000]fSyncTimestamp[18435600]
 [1223617042.483000]-[-1223617038.702323]=NPT[3.780677]-[9817380][9756964]--A
 [1223617042.483000]-[-1223617038.702323]=NPT[3.780677]-[9817380][9756964]--A
 [1223617042.483000]-[-1223617038.702323]=NPT[3.780677]-[9817380][9756964]--A
 [1223617042.483000]-[-1223617038.702323]=NPT[3.780677]-[9817380][9756964]--A
 [1223617042.508000]-[-1223617038.744999]=NPT[3.763001]-[18435600][18324000]--V
 [1223617042.568333]-[-1223617038.702323]=NPT[3.866010]-[9821476][9756964]--A
 [1223617042.568333]-[-1223617038.702323]=NPT[3.866010]-[9821476][9756964]--A

From finlayson at live555.com  Fri Oct 10 00:16:45 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 10 Oct 2008 00:16:45 -0700
Subject: [Live-devel] Audio video Synchronization problem
In-Reply-To: <20081010062320.3CEA055800B@LGEMRELSE7Q.lge.com>
References: <20081010062320.3CEA055800B@LGEMRELSE7Q.lge.com>
Message-ID: <200810100724.m9A7Op2W023263@ns.live555.com>


>      I have some synchronization problem in my streaming server.
>   We are streaming H.264 with G.711 (PCMU), It is streaming 
> properly because I can trace both audio and video packet through 
> network analyzer.
>     But the audio is not audible in VLC client along with video. 
> But it is audible when I am streaming audio only.

Once again: Make sure that you are giving accurate presentation times 
- aligned with 'wall clock time' - to both your audio and video frames.

If you are sure you are doing this, and are still having problems 
with VLC, then you will need to ask for help on a VLC mailing list.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From finlayson at live555.com  Fri Oct 10 00:20:42 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 10 Oct 2008 00:20:42 -0700
Subject: [Live-devel] seeking in DSS stream
In-Reply-To: <ac699b810810092337q64421f9aqe967ead9f79f6798@mail.gmail.co
 m>
References: <ac699b810810092337q64421f9aqe967ead9f79f6798@mail.gmail.com>
Message-ID: <200810100724.m9A7Opav023279@ns.live555.com>


>When I do seeking operation, I find that when the client send pause,
>seek and play command and start playing again, there will be a gap in
>the DSS's RTCP SR ntpTimestamp(I print out this in
>RTPReceptionStats::noteIncomingSR()), and this will cause the
>MediaSubsession::getNormalPlayTime return a wrong NPT, jump from
>201.17 to 3.78.

This shows that your "DSS" is badly broken.  Make sure you're using 
an up-to-date version.  If you are, and are still having this 
problem, then you need to complain on a DSS-related mailing 
list.  (When a third-party server is badly broken like this, there's 
little we can do.)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From sukhbir.singh20 at gmail.com  Sun Oct 12 01:13:21 2008
From: sukhbir.singh20 at gmail.com (Sukhbir Singh)
Date: Sun, 12 Oct 2008 13:43:21 +0530
Subject: [Live-devel] Live555 as a multimedia platform
Message-ID: <3b2878e60810120113p4a69fc7bva7fc09f13a97292b@mail.gmail.com>

Hi All,

        We are planning to make a platform using Live555 that will provide
        simultaneous 120 SIP/RTSP session.

        For transcoding, we are planning to intergrate ffmpeg with Live555.
        First help us by assuring that Is it possible to make platfrom using
Live555 and
        ffmpeg that can provide 120 SIP/RTSP session simultaneously.

        Secondly, we want to know, Whether we should use 120 processes or
120 threads (in a process)
        to run 120 SIP/RTSP session simultaneously?

        As per my experience, threads are better than processes. but to run
mutiple session using Live555,
        i read processes are better than threads.

        Thirdly, we tested testOnDemandRTSPServer and found that it can
provide mutiple RTSP session
        simulaneously.We have gone through testOnDemandRTSPServer code for
mp3 file streaming.
        But We are not able to find how this code is running mutiple session
without
        using thread/process for particular session.

        Can u please tell us how you people are running mutiple session
without using thread and process
        for single session.

With Regards,
Sukhbir Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081012/4ae0df8a/attachment.html>

From finlayson at live555.com  Sun Oct 12 01:22:45 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 12 Oct 2008 01:22:45 -0700
Subject: [Live-devel] Live555 as a multimedia platform
In-Reply-To: <3b2878e60810120113p4a69fc7bva7fc09f13a97292b@mail.gmail.co
 m>
References: <3b2878e60810120113p4a69fc7bva7fc09f13a97292b@mail.gmail.com>
Message-ID: <200810120825.m9C8P8ps015242@ns.live555.com>


>        Thirdly, we tested testOnDemandRTSPServer and found that it 
> can provide mutiple RTSP session
>         simulaneously.We have gone through testOnDemandRTSPServer 
> code for mp3 file streaming.
>         But We are not able to find how this code is running 
> mutiple session without
>         using thread/process for particular session.

An application using the "LIVE555 Streaming Media" code uses a single 
event loop - rather than multiple threads- to implement concurrency.

In particular, for a RTSP server, the availability of new file data 
is an 'event', which is handled, in this case, by streaming the file 
data to the requesting client.  The code can, and does, handle many 
different open files (and this clients).

To use the "LIVE555 Streaming Media" code, you need to understand 
event-driven programming.  (It also helps to READ THE FAQ.)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From guiluge at gmail.com  Tue Oct 14 08:06:46 2008
From: guiluge at gmail.com (Guillaume Ferry)
Date: Tue, 14 Oct 2008 17:06:46 +0200
Subject: [Live-devel] Question about RTSP paths
Message-ID: <425f13530810140806gaa5471fo419f4b5e7a431a40@mail.gmail.com>

Hi there,

As an older thread, found in March 2008 archives, an alternative syntax
exists for RTSP urls.

Here is a quote :

//////

>What I'd like to do:
>
>MPEG4 streams: rtsp://host/video/MPEG4/stream[number]
>H263 streams: rtsp://host/video/H263/stream[number]
>
>Please note the filenames pathnames are "virtual", i.e. they don't
>exist. Every stream is associated to a live source read from a
>configuration file, and it has no correspondent in the file system

Then why bother? I'm sure you could (somehow) hack the RTSP server
code to do what you want to do, but why not just use a character
other than "/" in the RTSP URLs - e.g.,
 rtsp://host/video:MPEG4:stream[number]
? This would require no change to the existing code.
//////

I wanted to verify this point, and it doesn't seem to work for me, or maybe
I don't get the whole point at all :)

For instance, i have a medium that is located in this sub-tree :
./foo/bar/baz/video.mpg

As the RTSP server runs at the root of this tree, I thought I could access
the medium with this url :

rtsp://localhost:6666/foo:bar:baz:video.mpg

Am I wrong on this one ?

Thanks in advance,

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

From finlayson at live555.com  Tue Oct 14 08:21:50 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 14 Oct 2008 08:21:50 -0700
Subject: [Live-devel] Question about RTSP paths
In-Reply-To: <425f13530810140806gaa5471fo419f4b5e7a431a40@mail.gmail.com
 >
References: <425f13530810140806gaa5471fo419f4b5e7a431a40@mail.gmail.com>
Message-ID: <200810141524.m9EFOtmD061747@ns.live555.com>


>For instance, i have a medium that is located in this sub-tree : 
>./foo/bar/baz/video.mpg
>
>As the RTSP server runs at the root of this tree, I thought I could 
>access the medium with this url :
>
>rtsp://localhost:6666/foo:bar:baz:video.mpg
>
>Am I wrong on this one ?

No, you can do this, but you first need to create a symbolic link - 
at the root of the tree - named "foo:bar:baz:video.mpg" - that points 
to the actual file.

I.e., at the root of thr tree, run
         ln -s foo/bar/baz/video.mpg foo:bar:baz:video.mpg
(if you're running a Unix system; I don;t know how you do this in Windoze).

I.e., the actual file name, read by the server, is "foo:bar:baz:video.mpg"


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From guiluge at gmail.com  Tue Oct 14 08:35:33 2008
From: guiluge at gmail.com (Guillaume Ferry)
Date: Tue, 14 Oct 2008 17:35:33 +0200
Subject: [Live-devel] Question about RTSP paths
In-Reply-To: <425f13530810140806gaa5471fo419f4b5e7a431a40@mail.gmail.com>
References: <425f13530810140806gaa5471fo419f4b5e7a431a40@mail.gmail.com>
Message-ID: <425f13530810140835q15e9d23fx25cc1f0b0e8eba47@mail.gmail.com>

Thanks Ron,

Indeed I'm using a Unix-flavored system :)

I'll check this out !

Best regards,

Guillaume.

2008/10/14 Guillaume Ferry <guiluge at gmail.com>

> Hi there,
>
> As an older thread, found in March 2008 archives, an alternative syntax
> exists for RTSP urls.
>
> Here is a quote :
>
> //////
>
> >What I'd like to do:
> >
> >MPEG4 streams: rtsp://host/video/MPEG4/stream[number]
> >H263 streams: rtsp://host/video/H263/stream[number]
> >
> >Please note the filenames pathnames are "virtual", i.e. they don't
> >exist. Every stream is associated to a live source read from a
> >configuration file, and it has no correspondent in the file system
>
> Then why bother? I'm sure you could (somehow) hack the RTSP server
> code to do what you want to do, but why not just use a character
> other than "/" in the RTSP URLs - e.g.,
>  rtsp://host/video:MPEG4:stream[number]
> ? This would require no change to the existing code.
> //////
>
> I wanted to verify this point, and it doesn't seem to work for me, or maybe
> I don't get the whole point at all :)
>
> For instance, i have a medium that is located in this sub-tree :
> ./foo/bar/baz/video.mpg
>
> As the RTSP server runs at the root of this tree, I thought I could access
> the medium with this url :
>
> rtsp://localhost:6666/foo:bar:baz:video.mpg
>
> Am I wrong on this one ?
>
> Thanks in advance,
>
> Guillaume.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081014/a33ff1b3/attachment.html>

From bgmarete at gmail.com  Wed Oct 15 08:03:01 2008
From: bgmarete at gmail.com (Brian Marete)
Date: Wed, 15 Oct 2008 18:03:01 +0300
Subject: [Live-devel] Detecting/Notifying on new multicast media
Message-ID: <6dd519ae0810150803p28f5017cj91866c9619ecaeea@mail.gmail.com>

Hello,

I am writing a streaming application with live555, both on the server
and client ends. I will be using live555 to mulitcast MPEG2 transport
streams over RTP to the clients. Periodically, the server will stop
multicasting the current file and switch to a new one, sending it to
the same multicast address and port to which the previous TS was being
sent.

Now, obviously, the second TS may defer in parameters from the 1st TS.
For example, the picture size could be different, or it could contain
a different video codec. I am thinking that the decoder on the client
end will need, somehow, to know of this change. Are there any
facilities in live555, the TS protocol or the RTP protocol that would
help with this. Or am I on my own and will have to parse the TS coming
out of the MediaSink in the client application.

Perhaps someone could suggest a better way of doing this?

Thanks.

-- 
B. Gitonga Marete
Tel: +254-722-151-590

From finlayson at live555.com  Wed Oct 15 14:29:26 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 15 Oct 2008 14:29:26 -0700
Subject: [Live-devel] Detecting/Notifying on new multicast media
In-Reply-To: <6dd519ae0810150803p28f5017cj91866c9619ecaeea@mail.gmail.co
 m>
References: <6dd519ae0810150803p28f5017cj91866c9619ecaeea@mail.gmail.com>
Message-ID: <200810152133.m9FLXndf049565@ns.live555.com>


>I am writing a streaming application with live555, both on the server
>and client ends. I will be using live555 to mulitcast MPEG2 transport
>streams over RTP to the clients. Periodically, the server will stop
>multicasting the current file and switch to a new one, sending it to
>the same multicast address and port to which the previous TS was being
>sent.
>
>Now, obviously, the second TS may defer in parameters from the 1st TS.
>For example, the picture size could be different, or it could contain
>a different video codec. I am thinking that the decoder on the client
>end will need, somehow, to know of this change. Are there any
>facilities in live555, the TS protocol or the RTP protocol that would
>help with this.

No, because the RTP payload format for Transport Stream data is 
extremely simple: RTP packets contain just the Transport Stream data 
(in groups of 188-byte transport 'packets'), with no extra 
RTP-specific parameters.  In other words, you don't do anything extra 
to our RTSP/RTP/RTCP code to stream your 'joined' Transport Stream 
data; instead, all of the information that a client's decoder 
requires needs to be in the Transport Stream data itself.

Fortunately, though, the Transport Stream header (inside the 
Transport Stream data itself - independent of RTP) includes a 1-bit 
"discontinuity_indicator" that you can use to indicate - to a 
receiver - that a Transport Stream 'join' has taken place.  (See the 
ISO-IEC specification for Transport Streams: ISO-IEC 13818-1, section 2.4.3.5.)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From bgmarete at gmail.com  Wed Oct 15 16:07:07 2008
From: bgmarete at gmail.com (Brian Marete)
Date: Thu, 16 Oct 2008 02:07:07 +0300
Subject: [Live-devel] Detecting/Notifying on new multicast media
In-Reply-To: <200810152133.m9FLXndf049565@ns.live555.com>
References: <6dd519ae0810150803p28f5017cj91866c9619ecaeea@mail.gmail.com>
	<200810152133.m9FLXndf049565@ns.live555.com>
Message-ID: <6dd519ae0810151607p56bd467bjc145552f9cd0247f@mail.gmail.com>

On Thu, Oct 16, 2008 at 12:29 AM, Ross Finlayson <finlayson at live555.com> wrote:
>
>> I am writing a streaming application with live555, both on the server
>> and client ends. I will be using live555 to mulitcast MPEG2 transport
>> streams over RTP to the clients. Periodically, the server will stop
>> multicasting the current file and switch to a new one, sending it to
>> the same multicast address and port to which the previous TS was being
>> sent.
>>
>> Now, obviously, the second TS may defer in parameters from the 1st TS.
>> For example, the picture size could be different, or it could contain
>> a different video codec. I am thinking that the decoder on the client
>> end will need, somehow, to know of this change. Are there any
>> facilities in live555, the TS protocol or the RTP protocol that would
>> help with this.
>
> No, because the RTP payload format for Transport Stream data is extremely
> simple: RTP packets contain just the Transport Stream data (in groups of
> 188-byte transport 'packets'), with no extra RTP-specific parameters.  In
> other words, you don't do anything extra to our RTSP/RTP/RTCP code to stream
> your 'joined' Transport Stream data; instead, all of the information that a
> client's decoder requires needs to be in the Transport Stream data itself.
>
> Fortunately, though, the Transport Stream header (inside the Transport
> Stream data itself - independent of RTP) includes a 1-bit
> "discontinuity_indicator" that you can use to indicate - to a receiver -
> that a Transport Stream 'join' has taken place.  (See the ISO-IEC
> specification for Transport Streams: ISO-IEC 13818-1, section 2.4.3.5.)

Thanks.

-- 
B. Gitonga Marete
Tel: +254-722-151-590

From bgmarete at gmail.com  Wed Oct 15 16:17:16 2008
From: bgmarete at gmail.com (Brian Marete)
Date: Thu, 16 Oct 2008 02:17:16 +0300
Subject: [Live-devel] RTCP Bye in PassiveServerMediaSession
Message-ID: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com>

Hello,

I am playing with the vobStreamer application, using MPlayer -rc2 to
view the stream.

The behavior I expect is that at the end of the stream, when
stopPlaying() is called on both sinks, live555 should send and RTCP
Bye packet, causing MPlayer to exit. But l have confirmed with
wireshark that live555 never sends such a packet, causing MPlayer to
start playing the vob stream at the beginning again when it is
restarted in the afterPlaying() function.

What, in the API, should I do to force an RTCP bye packet to be sent
after the sinks are closed? Further, in a case such as this where a
session consists of 2 RTP streams, what are the semantics of an RTCP
Bye packet associated with just one of the streams? Presumably, they
(if ever) are sent separately. Should the player exit on the first
RTCP Bye packet seen for just one (of possibly many) RTP sessions that
it is playing as a result of an rtsp:// request?

Or is this a problem with no clean solution in the current RTSP
standard? (I have seen RFC drafts envisaging an END_OF_STREAM server
to client message in future).

Thanks.

-- 
B. Gitonga Marete
Tel: +254-722-151-590

From finlayson at live555.com  Wed Oct 15 20:17:33 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 15 Oct 2008 20:17:33 -0700
Subject: [Live-devel] RTCP Bye in PassiveServerMediaSession
In-Reply-To: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.co
 m>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com>
Message-ID: <200810160321.m9G3LVN4011929@ns.live555.com>


>The behavior I expect is that at the end of the stream, when
>stopPlaying() is called on both sinks, live555 should send and RTCP
>Bye packet, causing MPlayer to exit.

No, that's not what the code does.  When the code reaches the end of 
the input file, it reads/streams it again starting from the 
beginning.  During this whole time, the output (network) stream 
remains intact, so no RTCP "BYE" ever gets sent.

I.e., the code runs in a loop, reading/streaming the same file(s) 
over and over again.

>What, in the API, should I do to force an RTCP bye packet to be sent
>after the sinks are closed?

In the current code, the (RTP)Sinks never get closed! (See above.)

However, if you wanted to cause a RTCP "BYE" packet to get sent, then 
the way to do this would be to call "Medium::close()" on the 
"RTCPInstance" object.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From finlayson at live555.com  Wed Oct 15 20:15:58 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 15 Oct 2008 20:15:58 -0700
Subject: [Live-devel] RTCP Bye in PassiveServerMediaSession
In-Reply-To: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.co
 m>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com>
Message-ID: <200810160321.m9G3LVr7011952@ns.live555.com>

At 04:17 PM 10/15/2008, you wrote:
>Hello,
>
>I am playing with the vobStreamer application, using MPlayer -rc2 to
>view the stream.
>
>The behavior I expect is that at the end of the stream, when
>stopPlaying() is called on both sinks, live555 should send and RTCP
>Bye packet, causing MPlayer to exit. But l have confirmed with
>wireshark that live555 never sends such a packet, causing MPlayer to
>start playing the vob stream at the beginning again when it is
>restarted in the afterPlaying() function.
>
>What, in the API, should I do to force an RTCP bye packet to be sent
>after the sinks are closed? Further, in a case such as this where a
>session consists of 2 RTP streams, what are the semantics of an RTCP
>Bye packet associated with just one of the streams? Presumably, they
>(if ever) are sent separately. Should the player exit on the first
>RTCP Bye packet seen for just one (of possibly many) RTP sessions that
>it is playing as a result of an rtsp:// request?
>
>Or is this a problem with no clean solution in the current RTSP
>standard? (I have seen RFC drafts envisaging an END_OF_STREAM server
>to client message in future).
>
>Thanks.
>
>--
>B. Gitonga Marete
>Tel: +254-722-151-590
>_______________________________________________
>live-devel mailing list
>live-devel at lists.live555.com
>http://lists.live555.com/mailman/listinfo/live-devel



From Anoop_P.A at pmc-sierra.com  Thu Oct 16 04:44:26 2008
From: Anoop_P.A at pmc-sierra.com (Anoop P.A.)
Date: Thu, 16 Oct 2008 04:44:26 -0700
Subject: [Live-devel] optimising openRTSP
In-Reply-To: <200810160321.m9G3LVr7011952@ns.live555.com>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com>
	<200810160321.m9G3LVr7011952@ns.live555.com>
Message-ID: <A7DEA48C84FD0B48AAAE33F328C020140291621A@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>

Hi All,

I have cross compiled openRTSP for mips platform and I am using its for
recording mjpeg streams(30fps frame rate 32kb frame size). I need to run
multiple instances of  this client ( say 16). But the problem is one
openRTSP client consuming around 12% of CPU time. So it is difficult to
run more than 6 clients sessions without considerable packet loss. How
do I optimize openRTSP application??

Thanks
Anoop

From finlayson at live555.com  Thu Oct 16 06:32:19 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 16 Oct 2008 06:32:19 -0700
Subject: [Live-devel] optimising openRTSP
In-Reply-To: <A7DEA48C84FD0B48AAAE33F328C020140291621A@BBY1EXM11.pmc_nt.
	nt.pmc-sierra.bc.ca>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com>
	<200810160321.m9G3LVr7011952@ns.live555.com>
	<A7DEA48C84FD0B48AAAE33F328C020140291621A@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>
Message-ID: <200810161335.m9GDZ2fI051583@ns.live555.com>


>I have cross compiled openRTSP for mips platform and I am using its for
>recording mjpeg streams(30fps frame rate 32kb frame size). I need to run
>multiple instances of  this client ( say 16). But the problem is one
>openRTSP client consuming around 12% of CPU time.

That's strange, considering that the application - after it does the 
RTSP protocol exchange - does little more than sitting in a loop, 
reading data from a network socket and then writing it to a 
file.  (It also adds a JPEG header for each frame.)

>  So it is difficult to
>run more than 6 clients sessions without considerable packet loss. How
>do I optimize openRTSP application??

I don't know.  You're first going to have to figure out where it's 
spending most of its CPU time, and why.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From bgmarete at gmail.com  Thu Oct 16 07:29:15 2008
From: bgmarete at gmail.com (Brian Marete)
Date: Thu, 16 Oct 2008 17:29:15 +0300
Subject: [Live-devel] RTCP Bye in PassiveServerMediaSession
In-Reply-To: <200810160321.m9G3LVN4011929@ns.live555.com>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com>
	<200810160321.m9G3LVN4011929@ns.live555.com>
Message-ID: <6dd519ae0810160729l6581b67ei330402203d4b31ce@mail.gmail.com>

On Thu, Oct 16, 2008 at 6:17 AM, Ross Finlayson <finlayson at live555.com> wrote:
>
>> The behavior I expect is that at the end of the stream, when
>> stopPlaying() is called on both sinks, live555 should send and RTCP
>> Bye packet, causing MPlayer to exit.
>
> No, that's not what the code does.  When the code reaches the end of the
> input file, it reads/streams it again starting from the beginning.  During
> this whole time, the output (network) stream remains intact, so no RTCP
> "BYE" ever gets sent.
>
> I.e., the code runs in a loop, reading/streaming the same file(s) over and
> over again.
>
>> What, in the API, should I do to force an RTCP bye packet to be sent
>> after the sinks are closed?
>
> In the current code, the (RTP)Sinks never get closed! (See above.)
>
> However, if you wanted to cause a RTCP "BYE" packet to get sent, then the
> way to do this would be to call "Medium::close()" on the "RTCPInstance"
> object.
>

Thanks Ross. But if I do the above, do I have to restart networking?
That is, are the sinks and groupsocks still usable after this? And the
Server Media Session? In other words, once I do the above, what else
do I have to do to clean up in rebuild again in preparation of
streaming the next file?

-- 
B. Gitonga Marete
Tel: +254-722-151-590

From gbonneau at matrox.com  Thu Oct 16 08:15:09 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Thu, 16 Oct 2008 11:15:09 -0400
Subject: [Live-devel] Reviewing RTPSource.cpp
Message-ID: <7AE644B56E5D48F38653B560597495EF@dorvalmatrox.matrox.com>

Minor comment about RTPSource.cpp.
 
While reading the code for some understanding of the internal mecanism I
came
across the code.
 
double timeDiff 
  = timestampDiff/(double)(fOurRTPSource.timestampFrequency());

in method RTPReceptionStats::noteIncomingPacket.

But the method already receive that value as parameter:
unsigned timestampFrequency.

Thus the code can be changed to

double timeDiff 
  = timestampDiff/(double)(timestampFrequency);

I believe this change make keeping a reference to fOurRTPSource
In class RTPReceptionStats and RTPReceptionStatsDB useless.

Or I missed something!

Regards
Guy Bonneau







From always.chen at gmail.com  Thu Oct 16 12:27:35 2008
From: always.chen at gmail.com (Always Chen)
Date: Fri, 17 Oct 2008 03:27:35 +0800
Subject: [Live-devel] Receiving MPEG4 stream from a video server and
	transport they out
Message-ID: <28849dfe0810161227t2c1eef18q794ea4ca0a76777c@mail.gmail.com>

Dear Ross, all,
  I'm new to live555. I have a video server that it can stream out video
data and the stream's format is use mpeg4. I can receive stream from that
device using openRTSP. And I also can see mpeg4 video in VLC using
testOnDemandRTSPServer. Now, I want to receive stream from the video server
using live555. And I also want to have a software video server. The software
video server's income stream is come from receive process. I already read
FAQ, but I still haven't any idea to do this. So, I try to find the answer
at the live-devel mail list and find some information. But I still have some
problem as follow:
  1. When I try to use the command as follow:openRTSP -s 0 -v rtsp://
admin:12345678 at 192.0.0.10:6000/udpstream | testOnDemandRTSPServer
     I can saw the video using VLC at other computer. But the video quality
is so bad enough(lots of mosaic, lose lots of frame, delay etc.).
     How should I improve the problem?
  2. I try to modified testMPEG4VideoStreamer and merge it into openRTSP.
Modifed place as follow:
          void play(void* clientData) {
               MediaSubsessionIterator MSIterator(*ClientMediaSession);
               MediaSubsession *ClientMediaSubsession = NULL;

               ClientMediaSubsession = MSIterator.next();
               FramedSource* videoES = ClientMediaSubsession->readSource();

               // Create a framer for the Video Elementary Stream:
               videoSource = MPEG4VideoStreamFramer::createNew(*env,
videoES);

               // Finally, start playing:
               *env << "Beginning to read from file...\n";
               videoSink->startPlaying(*videoSource, afterPlaying,
videoSink);
          }
     When I executed it. It had show lots of error message as follow:
          MPEG4VideoStreamParser::parseVideoObjectPlane(): Saw unexpected
code 000001E0
          MPEG4VideoStreamParser::analyzeVOLHeader(): marker_bit not set!
     And Sometime had error message as follow:
          MPEG4VideoStreamParser::parseVideoObjectPlane(): This appears to
be a 'short video header', which we current don't support
     Or
          MultiFramedRTPSource::doGetNextFrame1(): The total received frame
size exceeds the client's buffer size (152).  464 bytes of trailing data
will be dropped!
     I also used VLC debug mode to connect my modified program at other
computer. I can saw the first picture, but I can't saw any more on the next.
VLC's log message as follow:
          avcodec warning: cannot decode one frame (283 bytes)
          main warning: late picture skipped (138772)
          avcodec warning: cannot decode one frame (283 bytes)
          main warning: late picture skipped (231508)
          avcodec warning: cannot decode one frame (282 bytes)
          main warning: late picture skipped (371951)
          main warning: late picture skipped (462513)
          main warning: late picture skipped (917404)
          main warning: late picture skipped (97524)
          avcodec warning: cannot decode one frame (288 bytes)
          avcodec warning: cannot decode one frame (98 bytes)
          avcodec warning: cannot decode one frame (250 bytes)
          avcodec warning: cannot decode one frame (98 bytes)
          avcodec warning: cannot decode one frame (282 bytes)
          main warning: late picture skipped (1095917)
          avcodec warning: cannot decode one frame (283 bytes)
          main warning: late picture skipped (136277)
          main warning: late picture skipped (127051)
          avcodec warning: cannot decode one frame (283 bytes)
          avcodec warning: cannot decode one frame (282 bytes)
          live555 debug: tk->rtpSource->hasBeenSynchronizedUsingRTCP()
          avcodec warning: cannot decode one frame (98 bytes)
     What's problem in the process? And how should I fix the problem?

     Thanks for your help.
-- 
Best regards,

Always Chen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081017/53e9d89a/attachment.html>

From finlayson at live555.com  Thu Oct 16 16:15:22 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 16 Oct 2008 16:15:22 -0700
Subject: [Live-devel] Receiving MPEG4 stream from a video server and
 transport they out
In-Reply-To: <28849dfe0810161227t2c1eef18q794ea4ca0a76777c@mail.gmail.co
 m>
References: <28849dfe0810161227t2c1eef18q794ea4ca0a76777c@mail.gmail.com>
Message-ID: <200810162318.m9GNI50c059033@ns.live555.com>


>   1. When I try to use the command as follow:openRTSP -s 0 -v 
> rtsp://admin:12345678 at 192.0.0.10:6000/udpstream | testOnDemandRTSPServer
>      I can saw the video using VLC at other computer. But the video 
> quality is so bad enough(lots of mosaic, lose lots of frame, delay etc.).
>      How should I improve the problem?

First, are you sure that you should be adding "-s 0"?  (If the RTP 
payload format includes a special header, then this option will 
(incorrectly) include it in the output.)

Second, I assume that you modified the "testOnDemandRTSPServer" code 
as described in http://www.live555.com/liveMedia/faq.html#liveInput-unicast

I suggest that you first try breaking your command into separate steps:
         openRTSP -v ... > testFile
and then
         testOnDemandRTSPServer < testFile

If this doesn't work either, then you may need to increase your OS's 
socket buffering in "openRTSP"; see 
http://www.live555.com/liveMedia/faq.html#packet-loss

If, however, the separate steps work, but piping doesn't, then you 
probably need to (somehow) increase the buffer size that your OS uses 
for pipes.

>   2. I try to modified testMPEG4VideoStreamer and merge it into openRTSP.

I don't recommend this.  Remember that once you make major 
modifications like this to the existing code, you can't expect much 
support (especially with a "@gmail.com" email address).


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From finlayson at live555.com  Thu Oct 16 18:36:45 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 16 Oct 2008 18:36:45 -0700
Subject: [Live-devel] Reviewing RTPSource.cpp
In-Reply-To: <7AE644B56E5D48F38653B560597495EF@dorvalmatrox.matrox.com>
References: <7AE644B56E5D48F38653B560597495EF@dorvalmatrox.matrox.com>
Message-ID: <200810170140.m9H1esV9007575@ns.live555.com>


>Thus the code can be changed to
>
>double timeDiff
>   = timestampDiff/(double)(timestampFrequency);
>
>I believe this change make keeping a reference to fOurRTPSource
>In class RTPReceptionStats and RTPReceptionStatsDB useless.

Yes, you're right.  This will get cleaned up in the next release of 
the code.  Thanks for pointing this out.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From finlayson at live555.com  Thu Oct 16 18:38:49 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 16 Oct 2008 18:38:49 -0700
Subject: [Live-devel] RTCP Bye in PassiveServerMediaSession
In-Reply-To: <6dd519ae0810160729l6581b67ei330402203d4b31ce@mail.gmail.co
 m>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com>
	<200810160321.m9G3LVN4011929@ns.live555.com>
	<6dd519ae0810160729l6581b67ei330402203d4b31ce@mail.gmail.com>
Message-ID: <200810170145.m9H1jt95012771@ns.live555.com>


>  In other words, once I do the above, what else
>do I have to do to clean up in rebuild again in preparation of
>streaming the next file?

If you want to keep the existingoutput network connections, and 
continue streaming the next file, then you don't need to make *any* 
changes to the existing code.  In particular, you should *not* be 
sending any RTCP "BYE" packet in this case.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From AidenYuan at coomosoft.com  Thu Oct 16 19:57:46 2008
From: AidenYuan at coomosoft.com (Aiden_Coomo)
Date: Fri, 17 Oct 2008 10:57:46 +0800
Subject: [Live-devel] about RTCP sending
Message-ID: <001101c93004$21f0ee50$9909a8c0@shuweiyuan>

Hi, Guys!

         I implemented H264Payload, but I found my first RTCP SR was sent
very lately. It was sent after the 150th RTP package.

     And the timestamps in it were not as same as RTP packages, NTP time was
error.

     How shall I fix those problems?

 

Best wishes,

 

Aiden

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

From finlayson at live555.com  Thu Oct 16 20:10:43 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 16 Oct 2008 20:10:43 -0700
Subject: [Live-devel] about RTCP sending
In-Reply-To: <001101c93004$21f0ee50$9909a8c0@shuweiyuan>
References: <001101c93004$21f0ee50$9909a8c0@shuweiyuan>
Message-ID: <200810170313.m9H3DNuu003760@ns.live555.com>


>         I implemented H264Payload, but I found my first RTCP SR was 
> sent very lately. It was sent after the 150th RTP package.

This is probably because your "ServerMediaSubsession" subclass's 
"createNewStreamSource()" function is not setting the result 
parameter "estBitrate" correctly.  That parameter needs to be set to 
the (sub)stream's estimated bitrate in *kilobits-per-second*.

>      And the timestamps in it were not as same as RTP packages, NTP 
> time was error.

Your frame's presentation times need to be aligned with wall-clock time.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From bgmarete at gmail.com  Fri Oct 17 05:11:38 2008
From: bgmarete at gmail.com (Brian Marete)
Date: Fri, 17 Oct 2008 15:11:38 +0300
Subject: [Live-devel] RTCP Bye in PassiveServerMediaSession
In-Reply-To: <200810170145.m9H1jt95012771@ns.live555.com>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com>
	<200810160321.m9G3LVN4011929@ns.live555.com>
	<6dd519ae0810160729l6581b67ei330402203d4b31ce@mail.gmail.com>
	<200810170145.m9H1jt95012771@ns.live555.com>
Message-ID: <6dd519ae0810170511x65d3b7b2j4205669445e9e3f7@mail.gmail.com>

On Fri, Oct 17, 2008 at 4:38 AM, Ross Finlayson <finlayson at live555.com> wrote:
>
>>  In other words, once I do the above, what else
>> do I have to do to clean up in rebuild again in preparation of
>> streaming the next file?
>
> If you want to keep the existingoutput network connections, and continue
> streaming the next file, then you don't need to make *any* changes to the
> existing code.  In particular, you should *not* be sending any RTCP "BYE"
> packet in this case.

I am looking at the vobstreamer as a starting model for an application
that will stream other codecs (H264, MPEG4) such that the next file
may be very different from the 1st, so that I want the client code to
see the RTCP BYE and re-request a fixed SMS over RTSP so that it can
get a possibly new SDP for the next file.

That is why I want to know how I can clean-up networking and restart
it again after forcing an RTCP BYE. Would very much appreciate your
advice on this.

Thanks Ross.

-- 
B. Gitonga Marete
Tel: +254-722-151-590

From finlayson at live555.com  Fri Oct 17 06:27:43 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 17 Oct 2008 06:27:43 -0700
Subject: [Live-devel] RTCP Bye in PassiveServerMediaSession
In-Reply-To: <6dd519ae0810170511x65d3b7b2j4205669445e9e3f7@mail.gmail.co
 m>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com>
	<200810160321.m9G3LVN4011929@ns.live555.com>
	<6dd519ae0810160729l6581b67ei330402203d4b31ce@mail.gmail.com>
	<200810170145.m9H1jt95012771@ns.live555.com>
	<6dd519ae0810170511x65d3b7b2j4205669445e9e3f7@mail.gmail.com>
Message-ID: <200810171330.m9HDUTN6059762@ns.live555.com>


> >>  In other words, once I do the above, what else
> >> do I have to do to clean up in rebuild again in preparation of
> >> streaming the next file?
> >
> > If you want to keep the existingoutput network connections, and continue
> > streaming the next file, then you don't need to make *any* changes to the
> > existing code.  In particular, you should *not* be sending any RTCP "BYE"
> > packet in this case.
>
>I am looking at the vobstreamer as a starting model for an application
>that will stream other codecs (H264, MPEG4) such that the next file
>may be very different from the 1st,

It's not possible to do this within a single RTSP/RTP session, 
because the client needs to get new information (SDP) about each new codec.

To do what you want, you will need to create a new RTSP protocol 
exchange ("DESCRIBE", "SETUP", "PLAY") for each new stream.  You 
should be using "oipenRTSP" - not "vobStreamer" - as your model.

>  so that I want the client code to
>see the RTCP BYE and re-request a fixed SMS over RTSP

No, you can't (reliably) use RTCP "BYE" to trigger this, because the 
server will not always send a "BYE" when it reaches the stream.  If 
the stream is 'seekable', then the server will not send a "BYE", so 
as to allow the client - if it wishes - to seek to an earlier point 
in the stream and continue playing it.  For 'seekable' streams, 
"openRTSP" (and other RTSP clients) uses the *duration* of the stream 
(which is obtailed from the SDP description in the "DESCRIBE" 
response) to figure out how long the stream lasts.

Once again, you should use "oipenRTSP" - not "vobStreamer" - as your 
model.  In fact, I suggest reading/playing each new stream using a 
separate *process* (i.e., application), rather than trying to do 
everything within a single process.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From finlayson at live555.com  Fri Oct 17 06:31:05 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 17 Oct 2008 06:31:05 -0700
Subject: [Live-devel] RTCP Bye in PassiveServerMediaSession
Message-ID: <200810171333.m9HDXkEv063195@ns.live555.com>


>No, you can't (reliably) use RTCP "BYE" to trigger this, because the 
>server will not always send a "BYE" when it reaches the stream.

I meant to say, of course:

No, you can't (reliably) use RTCP "BYE"s to trigger this, because the 
server will not always send a "BYE" when it reaches the end of the stream.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From bgmarete at gmail.com  Fri Oct 17 07:06:22 2008
From: bgmarete at gmail.com (Brian Marete)
Date: Fri, 17 Oct 2008 17:06:22 +0300
Subject: [Live-devel] RTCP Bye in PassiveServerMediaSession
In-Reply-To: <200810171330.m9HDUTN6059762@ns.live555.com>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com>
	<200810160321.m9G3LVN4011929@ns.live555.com>
	<6dd519ae0810160729l6581b67ei330402203d4b31ce@mail.gmail.com>
	<200810170145.m9H1jt95012771@ns.live555.com>
	<6dd519ae0810170511x65d3b7b2j4205669445e9e3f7@mail.gmail.com>
	<200810171330.m9HDUTN6059762@ns.live555.com>
Message-ID: <6dd519ae0810170706x21e91803mb3c777e7ed7b6e9f@mail.gmail.com>

On Fri, Oct 17, 2008 at 4:27 PM, Ross Finlayson <finlayson at live555.com> wrote:
>
>> >>  In other words, once I do the above, what else
>> >> do I have to do to clean up in rebuild again in preparation of
>> >> streaming the next file?
>> >
>> > If you want to keep the existingoutput network connections, and continue
>> > streaming the next file, then you don't need to make *any* changes to
>> > the
>> > existing code.  In particular, you should *not* be sending any RTCP
>> > "BYE"
>> > packet in this case.
>>
>> I am looking at the vobstreamer as a starting model for an application
>> that will stream other codecs (H264, MPEG4) such that the next file
>> may be very different from the 1st,
>
> It's not possible to do this within a single RTSP/RTP session, because the
> client needs to get new information (SDP) about each new codec.
>

This is exactly my point. I wish to trigger the request of a new RTSP
session from the client end so it (the client) can get new SDP
information. To do this, I want the client to see and RTCP BYE so that
it closes the current RTSP session and requests a new one at the same
(fixed) PassiveServerMediaSession RTSP url on the server end. So the
question is what should be the general construct/destruct procedure
for:

0. Forcing an RTCP BYE (using Medium::close() as you advised earlier)

1. (Possibly) closing the existing RTP Sinks and creating new ones.

2. (Possibly) closing the SMS and creating a new one associated with
the new sinks.

3. (Possibly) closing the current sources and creating new ones.

Thanks.



-- 
B. Gitonga Marete
Tel: +254-722-151-590

From finlayson at live555.com  Fri Oct 17 11:44:14 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 17 Oct 2008 11:44:14 -0700
Subject: [Live-devel] RTCP Bye in PassiveServerMediaSession
In-Reply-To: <6dd519ae0810170706x21e91803mb3c777e7ed7b6e9f@mail.gmail.co
 m>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com>
	<200810160321.m9G3LVN4011929@ns.live555.com>
	<6dd519ae0810160729l6581b67ei330402203d4b31ce@mail.gmail.com>
	<200810170145.m9H1jt95012771@ns.live555.com>
	<6dd519ae0810170511x65d3b7b2j4205669445e9e3f7@mail.gmail.com>
	<200810171330.m9HDUTN6059762@ns.live555.com>
	<6dd519ae0810170706x21e91803mb3c777e7ed7b6e9f@mail.gmail.com>
Message-ID: <200810171853.m9HIrLwH097051@ns.live555.com>

As I noted in my last message, you can use the existing RTSP client 
mechanism (using "openRTSP" as a model) to
1/ Detect when a stream has ended - using *either* RTCP "BYE* packets 
coming from the server, *or* (if the server keeps the stream open, 
without sending a "BYE") using the stream duration (obtained from the 
SDP description), and
2/ When the stream has ended, send a RTSP "TEARDOWN" command, which 
will cause the server to reclaim any state associated with the stream 
(if it didn't already do so), and
3/ Open/play the next stream, using RTSP

If you do this, you don't need to make *any* changes to existing 
servers (e.g., "live555MediaServer") - plus, your client could, if it 
wished, play streams from many different servers.

(This will be my last posting on this topic. Also, because you use a 
"@gmail.com" email address, any future postings from you will be moderated.)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From 1985renzf at gmail.com  Mon Oct 20 00:41:03 2008
From: 1985renzf at gmail.com (zhenfeng ren)
Date: Mon, 20 Oct 2008 15:41:03 +0800
Subject: [Live-devel] about socket nonblock
Message-ID: <cdf4ec730810200041t26f5f90bp3b78f02328ecda8@mail.gmail.com>

hi, everyone:
   In Live555, I find that:
   Create a socket, and then set it nonblock.
   I cannot understand, why choosing the nonblock?

zhenfeng ren

From finlayson at live555.com  Mon Oct 20 01:09:15 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 20 Oct 2008 01:09:15 -0700
Subject: [Live-devel] about socket nonblock
In-Reply-To: <cdf4ec730810200041t26f5f90bp3b78f02328ecda8@mail.gmail.com
 >
References: <cdf4ec730810200041t26f5f90bp3b78f02328ecda8@mail.gmail.com>
Message-ID: <200810200812.m9K8C85t033056@ns.live555.com>


>   In Live555, I find that:
>    Create a socket, and then set it nonblock.
>    I cannot understand, why choosing the nonblock?

Because applications that use the "LIVE555 Streaming Media" code run 
as a single-threaded event loop, we usually can't block on I/O 
to/from a socket.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From 1985renzf at gmail.com  Mon Oct 20 03:15:26 2008
From: 1985renzf at gmail.com (zhenfeng ren)
Date: Mon, 20 Oct 2008 18:15:26 +0800
Subject: [Live-devel] about socket nonblock
In-Reply-To: <200810200812.m9K8C85t033056@ns.live555.com>
References: <cdf4ec730810200041t26f5f90bp3b78f02328ecda8@mail.gmail.com>
	<200810200812.m9K8C85t033056@ns.live555.com>
Message-ID: <cdf4ec730810200315o55a9927fv536ecaf2111cd8f1@mail.gmail.com>

    single-thread ,that is the reason! Thank you very much.


2008/10/20 Ross Finlayson <finlayson at live555.com>:
>
>>  In Live555, I find that:
>>   Create a socket, and then set it nonblock.
>>   I cannot understand, why choosing the nonblock?
>
> Because applications that use the "LIVE555 Streaming Media" code run as a
> single-threaded event loop, we usually can't block on I/O to/from a socket.
>
>
>        Ross Finlayson
>        Live Networks, Inc. (LIVE555.COM)
>        <http://www.live555.com/>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>

From AidenYuan at coomosoft.com  Mon Oct 20 22:32:04 2008
From: AidenYuan at coomosoft.com (Aiden_Coomo)
Date: Tue, 21 Oct 2008 13:32:04 +0800
Subject: [Live-devel] question about when the first SR was sent
Message-ID: <000001c9333e$5a16ea90$9909a8c0@shuweiyuan>

HI,Guys

         Had it better that the first SR package is sent following the first
RTP package?

     If so, the Client may know the relationship of server NTP time and
server RTP timestamp as quickly as possible

     How do you think?

 

Aiden

 

 

 

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

From finlayson at live555.com  Mon Oct 20 22:55:12 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 20 Oct 2008 22:55:12 -0700
Subject: [Live-devel] question about when the first SR was sent
In-Reply-To: <000001c9333e$5a16ea90$9909a8c0@shuweiyuan>
References: <000001c9333e$5a16ea90$9909a8c0@shuweiyuan>
Message-ID: <200810210558.m9L5w6a4005860@ns.live555.com>


>         Had it better that the first SR package is sent following 
> the first RTP package?

You mean "packet", not "package".

>      If so, the Client may know the relationship of server NTP time 
> and server RTP timestamp as quickly as possible

Actually, it would be even better if the first RTCP "SR" packet were 
sent *before* the first RTP packet, for the reason you state.  I 
think the RTP specification allows this (for unicast streams, at 
least), and so this is something we may end up doing someday.

(In any case, though, a client must always allow for some RTP packets 
to be received before the first RTCP "SR" packet is received - i.e., 
before properly time-synchronized presentation times can be inferred 
from the RTP packets.)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From Lin.Dong at peektraffic.com  Tue Oct 21 07:10:49 2008
From: Lin.Dong at peektraffic.com (Lin.Dong at peektraffic.com)
Date: Tue, 21 Oct 2008 10:10:49 -0400
Subject: [Live-devel] MPEG4 streaming warnign info
In-Reply-To: <41E16D542244C24F97752590527EF9BB01FD9C19@flsv1065.pal.quixote.prv>
References: <41E16D542244C24F97752590527EF9BB01FD9C19@flsv1065.pal.quixote.prv>
Message-ID: <41E16D542244C24F97752590527EF9BB01FD9C1C@flsv1065.pal.quixote.prv>

Hi ALL, 

I used the "testOnDemandRTSPServer" for my streaming project, the video
streaming seems working fine, but  the  testOnDemandRTSPServer program
kept post  warning message on my screen as followings:

MPEG4VideoStreamParser::parserVideoObjectLayer(): this appears to be a
'short video header which we current don't support 

MPEG4VideoStreamParser::analyzeVOLHeader(): marker_bit 2 not set!  

 I am sure I did  not enable short video header flag in my mpeg-4
encoding. I do not why I got these warning messages.   

 my input stream contains one channel of video and the format are 

 Headers +  Elementary_Stream   + Headers +  Elementary_Stream  +
Headers +  Elementary_Stream + .......

 Headers =  Visual_object_Sequence_Header    Visual_Object_Header
Visual_Object_Layer_Header   

I also tried that only sending headers at the beginning,  then loading
Elementary_Stream to streamer without headers between
Elementary_Streams,  but it seemed the streaming was not working at all.


Thank you for your help. 
  
Lin Dong 
------------------------------------------- 
Embedded Software Engineer 
Peek Traffic Corporation  
Email: Lin.Dong at peektraffic.com <mailto:Lin.Dong at QuixoteCorp.com>  



* C O N F I D E N T I A L I T Y N O T I C E *
-----------------------------------------------------------
The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Peek Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081021/b62afc4d/attachment.html>

From morgan.torvolt at gmail.com  Tue Oct 21 08:15:33 2008
From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=)
Date: Tue, 21 Oct 2008 15:15:33 +0000
Subject: [Live-devel] Question regarding seeking and using epoch time.
Message-ID: <3cc3561f0810210815i78f53161sab94e4332a0fd920@mail.gmail.com>

Hi all.

I wish to use the offset parameter in live to access saved data from a
video source. My plan was to save this low bandwidth stream in files
with a short duration and a filename based on epoch. This way I could
have as long a backlog as I wanted, and still access it easily. My
problem is that the current value of epoch is way higher than the
precision of the float that is used in both openRTSP and the live
library at the moment. Using double instead of float troughout the
library when handling the seek times would solve this problem.

Obviously this usage is way outside what this parameter is meant to be
used for, but it seems as if the RTSP protocol supports it. If I run
openRTSP with -s 1223990137, the log contains this:
Range: npt=1223990144.000-
which is not far off the position I wanted. My server plays from the
ntp position correctly it seems.

Is there an interest in "fixing" this in the live555 library? If so, I
will try to dig trough it all and submit a patch. If not, I will just
fix my local copy.


Best Regards
Morgan

From finlayson at live555.com  Tue Oct 21 13:50:31 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 21 Oct 2008 13:50:31 -0700
Subject: [Live-devel] MPEG4 streaming warnign info
In-Reply-To: <41E16D542244C24F97752590527EF9BB01FD9C1C@flsv1065.pal.quix
	ote.prv>
References: <41E16D542244C24F97752590527EF9BB01FD9C19@flsv1065.pal.quixote.prv>
	<41E16D542244C24F97752590527EF9BB01FD9C1C@flsv1065.pal.quixote.prv>
Message-ID: <200810212058.m9LKwQi1045671@ns.live555.com>


>I used the "testOnDemandRTSPServer" for my streaming project, the 
>video streaming seems working fine, but  the  testOnDemandRTSPServer 
>program  kept post  warning message on my screen as followings:
>
>MPEG4VideoStreamParser::parserVideoObjectLayer(): this appears to be 
>a 'short video header which we current don't support
>
>MPEG4VideoStreamParser::analyzeVOLHeader(): marker_bit 2 not set!
>
>  I am sure I did  not enable short video header flag in my mpeg-4 
> encoding. I do not why I got these warning messages.

Quite simply - you get those warning messages because your "test.m4e" 
file appears to not be a valid MPEG-4 Video Elementary Stream file.

Please put your "test.m4e" file on a web server, and send us the URL, 
so we can download it and test it for ourselves.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From finlayson at live555.com  Tue Oct 21 14:27:52 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 21 Oct 2008 14:27:52 -0700
Subject: [Live-devel] Question regarding seeking and using epoch  time.
In-Reply-To: <3cc3561f0810210815i78f53161sab94e4332a0fd920@mail.gmail.co
 m>
References: <3cc3561f0810210815i78f53161sab94e4332a0fd920@mail.gmail.com>
Message-ID: <200810212131.m9LLVrZ3080442@ns.live555.com>


>My
>problem is that the current value of epoch is way higher than the
>precision of the float that is used in both openRTSP and the live
>library at the moment. Using double instead of float troughout the
>library when handling the seek times would solve this problem.

Yes.

>Is there an interest in "fixing" this in the live555 library?

I'm not particularly interested in this, but if you send us a patch, 
I'll probably add it.

(In the meantime, you could just use an offset from some fixed, later 
'epoch' time - e.g., 1/1/2008.)


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From gabrieledeluca at libero.it  Wed Oct 22 02:25:33 2008
From: gabrieledeluca at libero.it (gabrieledeluca at libero.it)
Date: Wed, 22 Oct 2008 11:25:33 +0200
Subject: [Live-devel] SDP format
Message-ID: <K94VIL$250F115F8BBC3C84D437071575A9D9D5@libero.it>

Hi,
I want to know the structure of a file SDP for MPEG2 file.
I have this SDP:
v=0
o=- 2 3587745594 IN IP4 127.0.0.0
s=QuickTime
t=0 0
a=range:npt=now-
a=isma-compliance:2,2.0,2
m=audio 6666 RTP/AVP 96
c=IN IP4 239.255.42.42/15
b=AS:8
a=rtpmap:96 mpeg4-generic/8000/1
a=fmtp:96 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1588
a=mpeg4-esid:101
m=video 8888 RTP/AVP 97
c=IN IP4 239.255.42.42/15
a=rtpmap:97 H264/90000
a=fmtp:97 packetization-mode=1;profile-level-id=4D4016;sprop-parameter-sets=J01AFqkYFAe2ANQYBBrbCte98BA=,KN4JF6A=
a=mpeg4-esid:201
a=cliprect:0,0,480,640
a=framesize:97 640-480

I must create a relayer, and It's work only few second. 


From finlayson at live555.com  Wed Oct 22 07:40:23 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 22 Oct 2008 07:40:23 -0700
Subject: [Live-devel] SDP format
In-Reply-To: <K94VIL$250F115F8BBC3C84D437071575A9D9D5@libero.it>
References: <K94VIL$250F115F8BBC3C84D437071575A9D9D5@libero.it>
Message-ID: <200810221444.m9MEi5ri058185@ns.live555.com>


>I want to know the structure of a file SDP for MPEG2 file.
>I have this SDP:
>v=0
>o=- 2 3587745594 IN IP4 127.0.0.0
>s=QuickTime
>t=0 0
>a=range:npt=now-
>a=isma-compliance:2,2.0,2
>m=audio 6666 RTP/AVP 96
>c=IN IP4 239.255.42.42/15
>b=AS:8
>a=rtpmap:96 mpeg4-generic/8000/1
>a=fmtp:96 
>profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1588
>a=mpeg4-esid:101
>m=video 8888 RTP/AVP 97
>c=IN IP4 239.255.42.42/15
>a=rtpmap:97 H264/90000
>a=fmtp:97 
>packetization-mode=1;profile-level-id=4D4016;sprop-parameter-sets=J01AFqkYFAe2ANQYBBrbCte98BA=,KN4JF6A=
>a=mpeg4-esid:201
>a=cliprect:0,0,480,640
>a=framesize:97 640-480

This is *not* a MPEG-2 stream.  It's a stream that consists of two 
substreams: MPEG-4 AAC audio, and H.264 video.

Our SDP parsing code ("MediaSession::createNew()") will figure this out.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From gbonneau at matrox.com  Wed Oct 22 12:21:50 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Wed, 22 Oct 2008 15:21:50 -0400
Subject: [Live-devel] NULL Sink
Message-ID: <725EF8367E90486C8918AB34E14B91F2@dorvalmatrox.matrox.com>

Hi Ross,
 
I  have a use case for a "NULL Sink" that would sinks a RTP source packets
without any further processing. I know this is very easy to write down using
for example the FileSink.cpp source code. But I was wondering if this code
might already exist in the library. At first glance I didn't found such
code.
 
Thanks for your support
Guy Bonneau
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081022/96c6c18a/attachment-0001.html>

From finlayson at live555.com  Wed Oct 22 13:31:59 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 22 Oct 2008 13:31:59 -0700
Subject: [Live-devel] NULL Sink
In-Reply-To: <725EF8367E90486C8918AB34E14B91F2@dorvalmatrox.matrox.com>
References: <725EF8367E90486C8918AB34E14B91F2@dorvalmatrox.matrox.com>
Message-ID: <200810222037.m9MKbkTk028362@ns.live555.com>


>I have a use case for a "NULL Sink" that would sinks a RTP source 
>packets without any further processing. I know this is very easy to 
>write down using for example the FileSink.cpp source code. But I was 
>wondering if this code might already exist in the library. At first 
>glance I didn't found such code.

No, there's no such code there right now.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>


From morgan.torvolt at gmail.com  Wed Oct 22 13:58:20 2008
From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=)
Date: Wed, 22 Oct 2008 20:58:20 +0000
Subject: [Live-devel] Question regarding seeking and using epoch time.
In-Reply-To: <200810212131.m9LLVrZ3080442@ns.live555.com>
References: <3cc3561f0810210815i78f53161sab94e4332a0fd920@mail.gmail.com>
	<200810212131.m9LLVrZ3080442@ns.live555.com>
Message-ID: <3cc3561f0810221358vc2c13d5o6b6c6edcafc1a3eb@mail.gmail.com>

> I'm not particularly interested in this, but if you send us a patch, I'll
> probably add it.

After actually writing the patch, I am less confident that you will actually.

I made the change. I believe I managed to change it everywhere. At
least the tests I have done works well.

I realize that this changes some functions at some places. There are a
couple of functions that uses reference transfer of the float/double.
Where this happens you cannot pass a float to the function as you
could before. This means recompiling and changing from float to double
some places. Since double is used many other places anyway, my
preference would be to change them all to double.

Some people might get some unexpected results, in that the
seekStreamSource(float) function that used to work, will not work
anymore. No compile errors. they will need to change to double for it
to work again.

I do not believe that this will make the code go slower since it seems
to me that the changes affects functions that are not called very
often.

In total, it gives something, and whatever it changes is for the
better for the library. It might give some people headaches though.

If it was up to me, I would replace all floats with doubles. Problems
like mine would never happen again. This is up to you though Ross.
There might be good reasons for not doing this that I am not entirely
aware of (like code efficiency on embedded systems) of course, but the
PCR calculations it TransportStreamFramer is double, is it not?

> (In the meantime, you could just use an offset from some fixed, later
> 'epoch' time - e.g., 1/1/2008.)
>

Not a very good permanent solution I belive. Floats have only 7.2
digits of precision (some argues 7.5), which starts giving errors
after less than half a year. It would just go downhill from there, and
get worse and worse. This might be a good argument for actually
impelementing my patch, as others that has a half year video
surveillance backlog and want to access it as one single file (playing
smaller files back to back for instance) will need it.


Best regards
Morgan T?rvolt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 002.patch
Type: application/octet-stream
Size: 24481 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081022/43c7f6d6/attachment-0001.obj>

From gbonneau at matrox.com  Wed Oct 22 17:41:30 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Wed, 22 Oct 2008 20:41:30 -0400
Subject: [Live-devel] Null Sink
Message-ID: <E4F09415859F437E9EA95FF2F0426CA4@dorvalmatrox.matrox.com>

Ross,

I have had a need for a NULL sink mainly for development purpose while
debugging some add-on to the library or to understand the internal mechanism
of RTP reception of the library or for snooping the RTP packets on a
computer with wireshark installed. It is rather trivial but it does the job
and can replace the file sink with most testing application. Feel free to
include it in the library if you think it might be useful. 
 
Regards
Guy Bonneau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081022/cbb74934/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: NullSink.cpp
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081022/cbb74934/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NullSink.hh
Type: application/octet-stream
Size: 1698 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081022/cbb74934/attachment.obj>

From auto.web at msa.hinet.net  Fri Oct 24 07:13:23 2008
From: auto.web at msa.hinet.net (Kuei-Yi)
Date: Fri, 24 Oct 2008 22:13:23 +0800
Subject: [Live-devel] Some questions need your help!
Message-ID: <000501c935e2$ade46fc0$0b00a8c0@Partner>

Hi Ross, all,

I have some questions as follows:

 

1. I want to write an application. I hope it can receive and send video
streaming at the same time. In that case, should I open two
BasicTaskSchedulers and two UsageEnvironments? Or, just only one
BasicTaskScheduler and one UsageEnvironment is enough?

 

2. I have a device which acts as a real-time MPEG4 video streaming server.
It resides at rtsp://adm:12345 at 177.0.0.1:5000/udpstream. I can use the
example of openRTSP program to communicate with it. But I read the example
of openRTSP program a lot of times and I still cannot understand one thing
which is ?Where has the continuously received video stream gone??. Where
can I find it?

 

3. This is an extension to question 2. I have objects of MPEG4ESVideoRTPSink
and MPEG4GenericRTPSink. Which one can be used to contain the video stream
coming from video streaming server?

 

Thanks.

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

From finlayson at live555.com  Fri Oct 24 13:59:13 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 24 Oct 2008 13:59:13 -0700
Subject: [Live-devel] Question regarding seeking and using epoch time.
In-Reply-To: <3cc3561f0810221358vc2c13d5o6b6c6edcafc1a3eb@mail.gmail.com>
References: <3cc3561f0810210815i78f53161sab94e4332a0fd920@mail.gmail.com>
	<200810212131.m9LLVrZ3080442@ns.live555.com>
	<3cc3561f0810221358vc2c13d5o6b6c6edcafc1a3eb@mail.gmail.com>
Message-ID: <f06240805c527e7785237@[66.80.62.44]>

Morgan,

FYI, I have applied your patch; it will appear in the next release of 
the software.
-- 

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

From finlayson at live555.com  Fri Oct 24 14:56:39 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 24 Oct 2008 14:56:39 -0700
Subject: [Live-devel] Some questions need your help!
In-Reply-To: <000501c935e2$ade46fc0$0b00a8c0@Partner>
References: <000501c935e2$ade46fc0$0b00a8c0@Partner>
Message-ID: <f06240800c527f44311f2@[66.80.62.44]>

>1. I want to write an application. I hope it can receive and send 
>video streaming at the same time. In that case, should I open two 
>BasicTaskSchedulers and two UsageEnvironments? Or, just only one 
>BasicTaskScheduler and one UsageEnvironment is enough?

You can probably do what you want using just a single event loop. 
I.e., one "UsageEnvironment" and one "BasicTaskScheduler".


>  2. I have a device which acts as a real-time MPEG4 video streaming 
>server. It resides at rtsp://adm:12345 at 177.0.0.1:5000/udpstream. I 
>can use the example of openRTSP program to communicate with it. But 
>I read the example of openRTSP program a lot of times and I still 
>cannot understand one thing which is 'Where has the continuously 
>received video stream gone?'. Where can I find it?

The output files - named "video-<something>" and "audio-<something>" 
- should be stored on your computer, in the same directory from which 
you ran the "openRTSP" application.


>  3. This is an extension to question 2. I have objects of 
>MPEG4ESVideoRTPSink and MPEG4GenericRTPSink. Which one can be used 
>to contain the video stream coming from video streaming server?

Neither of these.  "RTPSink"s are used to *send* RTP data.  To 
receive RTP data, "RTPSource"s are used.  This data is then written 
to a "MediaSink" subclass - e.g., a "FileSink" (for "openRTSP").
-- 

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/20081024/6446ad57/attachment.html>

From mlaibow.davinci at gmail.com  Sun Oct 26 02:20:48 2008
From: mlaibow.davinci at gmail.com (Mat Laibowitz)
Date: Sun, 26 Oct 2008 05:20:48 -0400
Subject: [Live-devel] rtsp client and server in the same app
Message-ID: <5bbfe18a0810260220y6879e4bcn3df75eef16a01ee5@mail.gmail.com>

So I have made it pretty far referencing the complete source code and the
test programs.
But I am a bit stuck on one issue.
I have built a RTSP server with a custom FrameSource that talks to my
hardware for encoding.
This works great, it uses the background read handling and can be received
by openRTSP or mplayer or vlc or quicktime without fail.

I have also created a custom client based on openRTSP that talks to my
hardware to decode the stream and display it on the framebuffer or record it
to a file. This also works great and when the two programs are on different
nodes the client can receive from the server.

If I put them both on the same node, they also work, provided that I turn
off the connection to the hardware enc/dec in one of the programs (the
client will just record the mpeg4 stream to file and not decode it and
display it).
This is because of a limit of the platform that I can only access the
hardware codec from one process/program.

So I am trying to combine the client and the server in one application.
The code is essentially the same, it just uses one environment and one call
to the task loop.

The RTSP server starts up fine and I can receive the video anywhere
including with a version of the same application with the server and
hardware decoding turned off.

However, the client always fails when started from the same program as the
server.
The error message is:
Failed to get a SDP description from URL "rtsp://
18.85.45.131:8554/videoStream":
 Failed to read response: Cannot assign requested address

I am guessing that the client somehow is trying to use some resource that is
already in use by the server. But I am not sure what that can be. Any help
would be greatly appreciated. I thought it was a port or sockets problem at
first, but one is a client and one is a server, and they both work if they
are in separate programs on the same device.

Thanks for a great system, I am quite happy to have my devices streaming
video between them, I just need to solve this one integration issue and it
will be great.

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

From mlaibow.davinci at gmail.com  Sun Oct 26 02:52:37 2008
From: mlaibow.davinci at gmail.com (Mat Laibowitz)
Date: Sun, 26 Oct 2008 05:52:37 -0400
Subject: [Live-devel] rtsp client and server in the same app
In-Reply-To: <5bbfe18a0810260220y6879e4bcn3df75eef16a01ee5@mail.gmail.com>
References: <5bbfe18a0810260220y6879e4bcn3df75eef16a01ee5@mail.gmail.com>
Message-ID: <5bbfe18a0810260252of42dfa8u1270738530c6ac05@mail.gmail.com>

A little more info. It is not the SDP request that fails, it is the OPTIONS
request that returns NULL.
I added a check fro null after the getOptionsRequest as shown below. And it
returns NULL when called in the same program as starting a RTSP server.
So the actual error message is the same, but it is from the OPTIONS request
and not the SDP request.
-mat

Created Client:
0xc3b98

Sending request: OPTIONS rtsp://18.85.45.131:8554/videoStreamRTSP/1.0

CSeq:
1

User-Agent: spinner_video_control (LIVE555 Streaming Media
v2008.09.02)





RTSP "OPTIONS" request failed:Failed to read response: Cannot assign
requested
address

Sending request: DESCRIBE rtsp://18.85.45.131:8554/videoStreamRTSP/1.0

CSeq:
2

Accept:
application/sdp

User-Agent: spinner_video_control (LIVE555 Streaming Media
v2008.09.02)


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




Failed to get a SDP description from URL "rtsp://
18.85.45.131:8554/videoStream": Failed to read response: Cannot assign
requested address
/

  if (sendOptionsRequest) {
    // Begin by sending an "OPTIONS" command:
    char* optionsResponse
      = getOptionsResponse(ourClient, rtspUrl, username, password);
    if (sendOptionsRequestOnly) {
      if (optionsResponse == NULL) {
    *env << clientProtocolName << " \"OPTIONS\" request failed: "
         << env->getResultMsg() << "\n";
      } else {
    *env << clientProtocolName << " \"OPTIONS\" request returned: "
         << optionsResponse << "\n";
      }
      return shutdown(FAILURE);
    }
    if(optionsResponse == NULL) {
      *env << clientProtocolName << " \"OPTIONS\" request failed:" <<
env->getResultMsg()  << "\n";
    } else {
     *env << clientProtocolName << " \"OPTIONS\" request returned: "
         << optionsResponse << "\n";
    }
    delete[] optionsResponse;
  }


On Sun, Oct 26, 2008 at 5:20 AM, Mat Laibowitz <mlaibow.davinci at gmail.com>wrote:

> So I have made it pretty far referencing the complete source code and the
> test programs.
> But I am a bit stuck on one issue.
> I have built a RTSP server with a custom FrameSource that talks to my
> hardware for encoding.
> This works great, it uses the background read handling and can be received
> by openRTSP or mplayer or vlc or quicktime without fail.
>
> I have also created a custom client based on openRTSP that talks to my
> hardware to decode the stream and display it on the framebuffer or record it
> to a file. This also works great and when the two programs are on different
> nodes the client can receive from the server.
>
> If I put them both on the same node, they also work, provided that I turn
> off the connection to the hardware enc/dec in one of the programs (the
> client will just record the mpeg4 stream to file and not decode it and
> display it).
> This is because of a limit of the platform that I can only access the
> hardware codec from one process/program.
>
> So I am trying to combine the client and the server in one application.
> The code is essentially the same, it just uses one environment and one call
> to the task loop.
>
> The RTSP server starts up fine and I can receive the video anywhere
> including with a version of the same application with the server and
> hardware decoding turned off.
>
> However, the client always fails when started from the same program as the
> server.
> The error message is:
> Failed to get a SDP description from URL "rtsp://
> 18.85.45.131:8554/videoStream":
>  Failed to read response: Cannot assign requested address
>
> I am guessing that the client somehow is trying to use some resource that
> is already in use by the server. But I am not sure what that can be. Any
> help would be greatly appreciated. I thought it was a port or sockets
> problem at first, but one is a client and one is a server, and they both
> work if they are in separate programs on the same device.
>
> Thanks for a great system, I am quite happy to have my devices streaming
> video between them, I just need to solve this one integration issue and it
> will be great.
>
> -mat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081026/ce16f448/attachment.html>

From amit.yedidia at elbitsystems.com  Sun Oct 26 02:57:56 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Sun, 26 Oct 2008 11:57:56 +0200
Subject: [Live-devel] rtsp client and server in the same app
In-Reply-To: <5bbfe18a0810260252of42dfa8u1270738530c6ac05@mail.gmail.com>
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D3628@mailesl5.esl.corp.elbit.co.il>

I think its beacuse both are trying to use the same port (8554)
 

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 Mat Laibowitz
	Sent: Sunday, October 26, 2008 11:53 AM
	To: live-devel at ns.live555.com; mlaibow.davinci at gmail.com
	Subject: Re: [Live-devel] rtsp client and server in the same app
	
	
	A little more info. It is not the SDP request that fails, it is
the OPTIONS request that returns NULL.
	I added a check fro null after the getOptionsRequest as shown
below. And it returns NULL when called in the same program as starting a
RTSP server.
	So the actual error message is the same, but it is from the
OPTIONS request and not the SDP request.
	-mat
	
	Created Client: 0xc3b98

	Sending request: OPTIONS rtsp://18.85.45.131:8554/videoStream
RTSP/1.0

	CSeq: 1

	User-Agent: spinner_video_control (LIVE555 Streaming Media
v2008.09.02)

	

	

	RTSP "OPTIONS" request failed:Failed to read response: Cannot
assign requested address

	Sending request: DESCRIBE rtsp://18.85.45.131:8554/videoStream
RTSP/1.0

	CSeq: 2

	Accept: application/sdp

	User-Agent: spinner_video_control (LIVE555 Streaming Media
v2008.09.02)

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

	

	Failed to get a SDP description from URL
"rtsp://18.85.45.131:8554/videoStream": Failed to read response: Cannot
assign requested address

	/
	
	  if (sendOptionsRequest) {
	    // Begin by sending an "OPTIONS" command:
	    char* optionsResponse
	      = getOptionsResponse(ourClient, rtspUrl, username,
password);
	    if (sendOptionsRequestOnly) {
	      if (optionsResponse == NULL) {
	    *env << clientProtocolName << " \"OPTIONS\" request failed:
"
	         << env->getResultMsg() << "\n";
	      } else {
	    *env << clientProtocolName << " \"OPTIONS\" request
returned: "
	         << optionsResponse << "\n";
	      }
	      return shutdown(FAILURE);
	    }
	    if(optionsResponse == NULL) {
	      *env << clientProtocolName << " \"OPTIONS\" request
failed:" << env->getResultMsg()  << "\n";
	    } else {
	     *env << clientProtocolName << " \"OPTIONS\" request
returned: "
	         << optionsResponse << "\n";   
	    }
	    delete[] optionsResponse;
	  }
	
	
	
	On Sun, Oct 26, 2008 at 5:20 AM, Mat Laibowitz
<mlaibow.davinci at gmail.com> wrote:
	

		So I have made it pretty far referencing the complete
source code and the test programs.
		But I am a bit stuck on one issue.
		I have built a RTSP server with a custom FrameSource
that talks to my hardware for encoding.
		This works great, it uses the background read handling
and can be received by openRTSP or mplayer or vlc or quicktime without
fail.
		
		I have also created a custom client based on openRTSP
that talks to my hardware to decode the stream and display it on the
framebuffer or record it to a file. This also works great and when the
two programs are on different nodes the client can receive from the
server.
		
		If I put them both on the same node, they also work,
provided that I turn off the connection to the hardware enc/dec in one
of the programs (the client will just record the mpeg4 stream to file
and not decode it and display it).
		This is because of a limit of the platform that I can
only access the hardware codec from one process/program.
		
		So I am trying to combine the client and the server in
one application.
		The code is essentially the same, it just uses one
environment and one call to the task loop.
		
		The RTSP server starts up fine and I can receive the
video anywhere including with a version of the same application with the
server and hardware decoding turned off.
		
		However, the client always fails when started from the
same program as the server.
		The error message is:
		Failed to get a SDP description from URL
"rtsp://18.85.45.131:8554/videoStream":

		 Failed to read response: Cannot assign requested
address
		
		I am guessing that the client somehow is trying to use
some resource that is already in use by the server. But I am not sure
what that can be. Any help would be greatly appreciated. I thought it
was a port or sockets problem at first, but one is a client and one is a
server, and they both work if they are in separate programs on the same
device.
		
		Thanks for a great system, I am quite happy to have my
devices streaming video between them, I just need to solve this one
integration issue and it will be great.
		
		-mat
		



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/20081026/ec5dc101/attachment-0001.html>

From mlaibow.davinci at gmail.com  Sun Oct 26 04:04:33 2008
From: mlaibow.davinci at gmail.com (Mat Laibowitz)
Date: Sun, 26 Oct 2008 07:04:33 -0400
Subject: [Live-devel] rtsp client and server in the same app
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D3628@mailesl5.esl.corp.elbit.co.il>
References: <5bbfe18a0810260252of42dfa8u1270738530c6ac05@mail.gmail.com>
	<EB34B5A39CF26E408490ED9279BF10A71D3628@mailesl5.esl.corp.elbit.co.il>
Message-ID: <5bbfe18a0810260404v5f2306c5ned28b21ebfcbef75@mail.gmail.com>

Yeah, but one is a server and one is a client, so it should work that way I
think.
Maybe I am missing something about ports in multicast.
Thanks,
-mat

2008/10/26 Yedidia Amit <amit.yedidia at elbitsystems.com>

>  I think its beacuse both are trying to use the same port (8554)
>
>
> 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 *Mat Laibowitz
> *Sent:* Sunday, October 26, 2008 11:53 AM
> *To:* live-devel at ns.live555.com; mlaibow.davinci at gmail.com
> *Subject:* Re: [Live-devel] rtsp client and server in the same app
>
> A little more info. It is not the SDP request that fails, it is the OPTIONS
> request that returns NULL.
> I added a check fro null after the getOptionsRequest as shown below. And it
> returns NULL when called in the same program as starting a RTSP server.
> So the actual error message is the same, but it is from the OPTIONS request
> and not the SDP request.
> -mat
>
> Created Client:
> 0xc3b98
>
> Sending request: OPTIONS rtsp://18.85.45.131:8554/videoStreamRTSP/1.0
>
> CSeq:
> 1
>
> User-Agent: spinner_video_control (LIVE555 Streaming Media
> v2008.09.02)
>
>
>
>
>
> RTSP "OPTIONS" request failed:Failed to read response: Cannot assign
> requested
> address
>
> Sending request: DESCRIBE rtsp://18.85.45.131:8554/videoStreamRTSP/1.0
>
> CSeq:
> 2
>
> Accept:
> application/sdp
>
> User-Agent: spinner_video_control (LIVE555 Streaming Media
> v2008.09.02)
>
>
> -------------------------------------------------------
>
>
>
>
> Failed to get a SDP description from URL "rtsp://
> 18.85.45.131:8554/videoStream": Failed to read response: Cannot assign
> requested address
> /
>
>   if (sendOptionsRequest) {
>     // Begin by sending an "OPTIONS" command:
>     char* optionsResponse
>       = getOptionsResponse(ourClient, rtspUrl, username, password);
>     if (sendOptionsRequestOnly) {
>       if (optionsResponse == NULL) {
>     *env << clientProtocolName << " \"OPTIONS\" request failed: "
>          << env->getResultMsg() << "\n";
>       } else {
>     *env << clientProtocolName << " \"OPTIONS\" request returned: "
>          << optionsResponse << "\n";
>       }
>       return shutdown(FAILURE);
>     }
>     if(optionsResponse == NULL) {
>       *env << clientProtocolName << " \"OPTIONS\" request failed:" <<
> env->getResultMsg()  << "\n";
>     } else {
>      *env << clientProtocolName << " \"OPTIONS\" request returned: "
>          << optionsResponse << "\n";
>     }
>     delete[] optionsResponse;
>   }
>
>
> On Sun, Oct 26, 2008 at 5:20 AM, Mat Laibowitz <mlaibow.davinci at gmail.com>wrote:
>
>> So I have made it pretty far referencing the complete source code and the
>> test programs.
>> But I am a bit stuck on one issue.
>> I have built a RTSP server with a custom FrameSource that talks to my
>> hardware for encoding.
>> This works great, it uses the background read handling and can be received
>> by openRTSP or mplayer or vlc or quicktime without fail.
>>
>> I have also created a custom client based on openRTSP that talks to my
>> hardware to decode the stream and display it on the framebuffer or record it
>> to a file. This also works great and when the two programs are on different
>> nodes the client can receive from the server.
>>
>> If I put them both on the same node, they also work, provided that I turn
>> off the connection to the hardware enc/dec in one of the programs (the
>> client will just record the mpeg4 stream to file and not decode it and
>> display it).
>> This is because of a limit of the platform that I can only access the
>> hardware codec from one process/program.
>>
>> So I am trying to combine the client and the server in one application.
>> The code is essentially the same, it just uses one environment and one
>> call to the task loop.
>>
>> The RTSP server starts up fine and I can receive the video anywhere
>> including with a version of the same application with the server and
>> hardware decoding turned off.
>>
>> However, the client always fails when started from the same program as the
>> server.
>> The error message is:
>> Failed to get a SDP description from URL "rtsp://
>> 18.85.45.131:8554/videoStream":
>>  Failed to read response: Cannot assign requested address
>>
>> I am guessing that the client somehow is trying to use some resource that
>> is already in use by the server. But I am not sure what that can be. Any
>> help would be greatly appreciated. I thought it was a port or sockets
>> problem at first, but one is a client and one is a server, and they both
>> work if they are in separate programs on the same device.
>>
>> Thanks for a great system, I am quite happy to have my devices streaming
>> video between them, I just need to solve this one integration issue and it
>> will be great.
>>
>> -mat
>>
>
> **
> *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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081026/4aac5f3d/attachment-0001.html>

From finlayson at live555.com  Sun Oct 26 07:31:59 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 26 Oct 2008 07:31:59 -0700
Subject: [Live-devel] rtsp client and server in the same app
In-Reply-To: <5bbfe18a0810260404v5f2306c5ned28b21ebfcbef75@mail.gmail.com>
References: <5bbfe18a0810260252of42dfa8u1270738530c6ac05@mail.gmail.com>
	<EB34B5A39CF26E408490ED9279BF10A71D3628@mailesl5.esl.corp.elbit.co.il>
	<5bbfe18a0810260404v5f2306c5ned28b21ebfcbef75@mail.gmail.com>
Message-ID: <f06240807c52a2f1793c0@[66.80.62.44]>

>Yeah, but one is a server and one is a client, so it should work 
>that way I think.

Depending on your operating system, this might still not be possible.

I suggest not doing what you are trying to do (run the client and the 
server that it's communicating with in the same application).  It's 
weird, and not useful (because the client and server are already 
communicating using sockets, rather than via shared memory, there's 
no need for them to reside within the same application).
-- 

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

From mlaibow.davinci at gmail.com  Sun Oct 26 12:56:59 2008
From: mlaibow.davinci at gmail.com (Mat Laibowitz)
Date: Sun, 26 Oct 2008 15:56:59 -0400
Subject: [Live-devel] rtsp client and server in the same app
In-Reply-To: <f06240807c52a2f1793c0@66.80.62.44>
References: <5bbfe18a0810260252of42dfa8u1270738530c6ac05@mail.gmail.com>
	<EB34B5A39CF26E408490ED9279BF10A71D3628@mailesl5.esl.corp.elbit.co.il>
	<5bbfe18a0810260404v5f2306c5ned28b21ebfcbef75@mail.gmail.com>
	<f06240807c52a2f1793c0@66.80.62.44>
Message-ID: <5bbfe18a0810261256s17a6336iaf2458d034c1817b@mail.gmail.com>

The problem is the MPEG hardware. I can only have one open connection to
MPEG hardware for both encoding and decoding.
I don't need the client to talk to its local server. I need the client to
talk to a server on a remote device.
So if I have two devices one serves rtsp://ip1:8554/video and connects a
client to rtsp://ip2:8554/video in the same application and the other device
does the opposite.
I think this should be possible. I think they should bind to different
sockets and exists as different tasks in the scheduler.
It is failing at the readSocket command of the RTSP client's sendOptionsCmd
function.
Thanks,
-mat


On Sun, Oct 26, 2008 at 10:31 AM, Ross Finlayson <finlayson at live555.com>wrote:

> Yeah, but one is a server and one is a client, so it should work that way I
>> think.
>>
>
> Depending on your operating system, this might still not be possible.
>
> I suggest not doing what you are trying to do (run the client and the
> server that it's communicating with in the same application).  It's weird,
> and not useful (because the client and server are already communicating
> using sockets, rather than via shared memory, there's no need for them to
> reside within the same application).
> --
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081026/34dd29f0/attachment.html>

From linux_is_next at hotmail.com  Sun Oct 26 13:43:38 2008
From: linux_is_next at hotmail.com (bos marcel)
Date: Sun, 26 Oct 2008 21:43:38 +0100
Subject: [Live-devel] wirecast
In-Reply-To: <5bbfe18a0810261256s17a6336iaf2458d034c1817b@mail.gmail.com>
References: <5bbfe18a0810260252of42dfa8u1270738530c6ac05@mail.gmail.com>
	<EB34B5A39CF26E408490ED9279BF10A71D3628@mailesl5.esl.corp.elbit.co.il>
	<5bbfe18a0810260404v5f2306c5ned28b21ebfcbef75@mail.gmail.com>
	<f06240807c52a2f1793c0@66.80.62.44> 
	<5bbfe18a0810261256s17a6336iaf2458d034c1817b@mail.gmail.com>
Message-ID: <BLU125-W446EBF3FFBFFA1FC77D9D2B4250@phx.gbl>


 
I found a neat program called wirecast - it has basicly everything to transmitt over mobilephones
AND over other systems. I am very impressed. Works for both mac and pc! its located at softpeda
for download.. 
 
/marcel
 
 
 
_________________________________________________________________
Senaste sportnyheterna & rykande f?rska resultat!
http://sport.msn.se/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081026/ef14d9dc/attachment.html>

From finlayson at live555.com  Sun Oct 26 16:20:55 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 26 Oct 2008 16:20:55 -0700
Subject: [Live-devel] wirecast
In-Reply-To: <BLU125-W446EBF3FFBFFA1FC77D9D2B4250@phx.gbl>
References: <5bbfe18a0810260252of42dfa8u1270738530c6ac05@mail.gmail.com>
	<EB34B5A39CF26E408490ED9279BF10A71D3628@mailesl5.esl.corp.elbit.co.il>
	<5bbfe18a0810260404v5f2306c5ned28b21ebfcbef75@mail.gmail.com>
	<f06240807c52a2f1793c0@66.80.62.44> 
	<5bbfe18a0810261256s17a6336iaf2458d034c1817b@mail.gmail.com>
	<BLU125-W446EBF3FFBFFA1FC77D9D2B4250@phx.gbl>
Message-ID: <f06240802c52aabb10bca@[66.80.62.44]>

What does this have to do with our software?

This mailing list is for questions/discussions about the "LIVE555 
Streaming Media" software only!
-- 

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

From s.boschi at totalwire.it  Mon Oct 27 02:21:20 2008
From: s.boschi at totalwire.it (Sigismondo Boschi)
Date: Mon, 27 Oct 2008 10:21:20 +0100
Subject: [Live-devel] mpeg and user data
Message-ID: <49058810.6070100@totalwire.it>

Hi,

we have developed a streaming server based on live555, that gets mpeg4 
frames and streams them as a MPEG elementary stream.

Now I need to add some user data to each frame. I think that the correct 
way is to define a user data mpeg elementary stream, mux it with the 
video stream and add the resulting transport stream as a subsession to 
live555.

Is this idea correct? Can you give me some reference on how to build a 
user data ES and how to add it to the SDP (and other details that I am 
probably missing?).

Many thanks for any help.

Kind 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/20081027/28651399/attachment.vcf>

From amit.yedidia at elbitsystems.com  Mon Oct 27 04:00:08 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Mon, 27 Oct 2008 13:00:08 +0200
Subject: [Live-devel] mpeg and user data
In-Reply-To: <49058810.6070100@totalwire.it>
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D362E@mailesl5.esl.corp.elbit.co.il>

Why not using rtp extension?

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 
> Sigismondo Boschi
> Sent: Monday, October 27, 2008 11:21 AM
> To: LIVE555 Streaming Media - development & use
> Subject: [Live-devel] mpeg and user data
> 
> Hi,
> 
> we have developed a streaming server based on live555, that 
> gets mpeg4 
> frames and streams them as a MPEG elementary stream.
> 
> Now I need to add some user data to each frame. I think that 
> the correct 
> way is to define a user data mpeg elementary stream, mux it with the 
> video stream and add the resulting transport stream as a 
> subsession to 
> live555.
> 
> Is this idea correct? Can you give me some reference on how 
> to build a 
> user data ES and how to add it to the SDP (and other details 
> that I am 
> probably missing?).
> 
> Many thanks for any help.
> 
> Kind 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
> 

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  Mon Oct 27 06:47:13 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 27 Oct 2008 06:47:13 -0700
Subject: [Live-devel] mpeg and user data
In-Reply-To: <49058810.6070100@totalwire.it>
References: <49058810.6070100@totalwire.it>
Message-ID: <f06240800c52b74df0bcc@[66.80.62.44]>

>we have developed a streaming server based on live555, that gets 
>mpeg4 frames and streams them as a MPEG elementary stream.
>
>Now I need to add some user data to each frame.

Is this 'user data' really 'per frame' - i.e., tightly associated 
with the MPEG-4 frame data?  If so, then the best way to do this 
would be to try to find some provision in the MPEG-4 video 
specification for such data, and just carry it inside the MPEG-4 
frame data somehow.  (I don't know whether the MPEG-4 spec has any 
provision for this, though.)

>  I think that the correct way is to define a user data mpeg 
>elementary stream, mux it with the video stream and add the 
>resulting transport stream as a subsession to live555.

Yes, you could do this - though this Transport Stream would 
completely replace the MPEG-4 Video Elementary Stream that you're 
streaming right now - it wouldn't just be added 'as a subsession'.
-- 

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

From s.boschi at totalwire.it  Mon Oct 27 07:25:33 2008
From: s.boschi at totalwire.it (Sigismondo Boschi)
Date: Mon, 27 Oct 2008 15:25:33 +0100
Subject: [Live-devel] mpeg and user data
In-Reply-To: <f06240800c52b74df0bcc@[66.80.62.44]>
References: <49058810.6070100@totalwire.it>
	<f06240800c52b74df0bcc@[66.80.62.44]>
Message-ID: <4905CF5D.6070608@totalwire.it>

Ross Finlayson wrote:
>> we have developed a streaming server based on live555, that gets mpeg4 
>> frames and streams them as a MPEG elementary stream.
>>
>> Now I need to add some user data to each frame.
> 
> Is this 'user data' really 'per frame' - i.e., tightly associated with 
> the MPEG-4 frame data?  If so, then the best way to do this would be to 
> try to find some provision in the MPEG-4 video specification for such 
> data, and just carry it inside the MPEG-4 frame data somehow.  (I don't 
> know whether the MPEG-4 spec has any provision for this, though.)

Yes, you are right - I have found finally the mpeg4 way to do this. I am 
  trying to inject user-data frames in the mpeg4 stream, that is frames 
starting with USER_DATA_START_CODE (0x000001B2). Actually, it seems to 
work just fine!

It has taken a lot to me to figure out this info, but then I have 
discovered that Sony and Axis cameras add trigger data in this way.

That's much easier than my first idea. Thanks for your time,
    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/20081027/3ce35976/attachment.vcf>

From sbirolo at gmail.com  Tue Oct 28 02:02:28 2008
From: sbirolo at gmail.com (Mattia Daldoss)
Date: Tue, 28 Oct 2008 10:02:28 +0100
Subject: [Live-devel] Problems with openRTSP
Message-ID: <f809cceb0810280202v32a8db81s464dd3d16bb75143@mail.gmail.com>

Hi,
   I create my own rtsp client, modifying openRTSP code given with the
library. No problem with that. But there's actually 2 things that I
can't make work:

1. Every output that I create are useless with a normal player (Vlc
for example) I got to re-encode it with ffmpeg. I read it's something
connected to the closure of the connection, so how can I tell the
cliente to stop connection? I'm on windows, VS 2005. Is there a
function that can do that? No operation with "duration" or
"durationslop", I got to close the file manually, whenever I want.

2. After that step, I actually have to store the stream into a buffer,
to do some work on the images, so taking frame per frame the stream.
Any suggestion on that?

Any help would be appreciated

Thanks in advance

Mattia

From finlayson at live555.com  Tue Oct 28 02:16:06 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 28 Oct 2008 02:16:06 -0700
Subject: [Live-devel] Problems with openRTSP
In-Reply-To: <f809cceb0810280202v32a8db81s464dd3d16bb75143@mail.gmail.com>
References: <f809cceb0810280202v32a8db81s464dd3d16bb75143@mail.gmail.com>
Message-ID: <f06240805c52c8671a40c@[66.80.62.44]>

>1. Every output that I create are useless with a normal player (Vlc
>for example) I got to re-encode it with ffmpeg.

What media type(s) are you recording?  What command-line options are 
you giving "openRTSP"?

>  I read it's something
>connected to the closure of the connection, so how can I tell the
>cliente to stop connection?

The easiest way is to use the "-d <duration>" command-line option.

>2. After that step, I actually have to store the stream into a buffer,
>to do some work on the images, so taking frame per frame the stream.
>Any suggestion on that?

Sorry, you're on your own here.
-- 

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

From amit.yedidia at elbitsystems.com  Tue Oct 28 03:16:28 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Tue, 28 Oct 2008 12:16:28 +0200
Subject: [Live-devel] Live architecture
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D3630@mailesl5.esl.corp.elbit.co.il>

Hi Ross, All

I noticed that when some Framer is using a Parser for reading from
ByteStreamFileSource an afterGetting call is schduled immediately to
taskSchedulaer (scheduleDelayedTask)  for the same function who
initially call the parser and an exception is being used to return the
Framer scope.

When using DeviceSource you suggested to implement a deliverFrame method
that  will be scheduled by the doGetNextFrame.
Which means that doGetNextFrame just schedule deliveFrame with
turnOnBackgroundReadHandling() 

Why not imlementing a deliverFrame function in the ByteStreamFileSource
and schedule it immediatly using scheduleDelayedTask() instead using the
exception mechanism.

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/20081028/1b7c3d2e/attachment.html>

From Kenneth.X.Melms.-ND at espn.com  Tue Oct 28 12:08:17 2008
From: Kenneth.X.Melms.-ND at espn.com (Melms, Kenneth X. -ND)
Date: Tue, 28 Oct 2008 15:08:17 -0400
Subject: [Live-devel] SingleStep():select() fails
Message-ID: <25534805D527D645BEFCD49F0CD507980DDB4086@XCHGBRS1.corp.espn.pvt>

Greetings all.

First post, so I'll only waste a little bandwidth saying "AWESOME LIBRARY!" and move to my issue.

I'm trying to incorporate the MPEG1or2VideoRTPSource into my application.  My application needs to poke a web service to start the RTP stream, so RTSP isn't appropriate. I just want to listen to the UDP port and capture the stream as it comes in.  I can do this in Java by just opening up a DatagramSocket, decoding the RTP packets as they stream in, but I'd like to use this library and other features of it.

I create the BasicUsageEnvironment and TaskScheduler as:

  TaskScheduler *bts = BasicTaskScheduler::createNew();
  BasicUsageEnvironment *bue = BasicUsageEnvironment::createNew(*bts);
Then I create a Groupsock to listen on my expected UDP port:

   const Port rtpPort(8898);
   struct in_addr inAddress;
   inAddress.s_addr = our_inet_addr("0.0.0.0");

   Groupsock gs(*bue, inAddress, rtpPort, 1);
And thirdly I create the FileSink and start the playing:

   sink = FileSink::createNew(*bue, "stdout");
   source = MPEG1or2VideoRTPSource::createNew(*bue, &gs);
   sink->startPlaying(*rtp_stream->source, mySessionEndCallback, NULL);
Finally - Start the eventLoop:

   bts->doEventLoop();
At this point my application exits with this error:

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

I'm sure I'm not the first to hit this issue, but I've yet to find a reason.  If I create a NEW TaskScheduler that isn't bound to the BasicUsageEnvironment and then call "doEventLoop()" -- the process continues, but packets never stream.  Am I missing something thickheaded?

tia, and keep up the good work!

Ken

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

From finlayson at live555.com  Tue Oct 28 16:35:12 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 28 Oct 2008 16:35:12 -0700
Subject: [Live-devel] SingleStep():select() fails
In-Reply-To: <25534805D527D645BEFCD49F0CD507980DDB4086@XCHGBRS1.corp.espn.pvt>
References: <25534805D527D645BEFCD49F0CD507980DDB4086@XCHGBRS1.corp.espn.pvt>
Message-ID: <f06240804c52d5152bcff@[66.80.62.44]>

>I'm trying to incorporate the MPEG1or2VideoRTPSource into my 
>application.  My application needs to poke a web service to start 
>the RTP stream, so RTSP isn't appropriate. I just want to listen to 
>the UDP port and capture the stream as it comes in.  I can do this 
>in Java by just opening up a DatagramSocket, decoding the RTP 
>packets as they stream in, but I'd like to use this library and 
>other features of it.

I'm not sure what's wrong with your code, but I suggest that you 
first start with the "testMPEG1or2VideoReceiver" demo application - 
something that you know already works - and modify that instead.

In particular, in "testMPEG1or2VideoReceiver.cpp", you will need to
1/ Change "sessionAddressStr" to "0.0.0.0", and
2/ Change "rtpPortNum" to 8898.

If that works properly (outputting received MPEG Elementary Stream 
video data to "stdout"), then you could then modify it some more, as 
appropriate.
-- 

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/20081028/8312ef8b/attachment.html>

From Anoop_P.A at pmc-sierra.com  Wed Oct 29 02:54:28 2008
From: Anoop_P.A at pmc-sierra.com (Anoop P.A.)
Date: Wed, 29 Oct 2008 02:54:28 -0700
Subject: [Live-devel] optimising openRTSP
In-Reply-To: <200810161335.m9GDZ2fI051583@ns.live555.com>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com><200810160321.m9G3LVr7011952@ns.live555.com><A7DEA48C84FD0B48AAAE33F328C020140291621A@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>
	<200810161335.m9GDZ2fI051583@ns.live555.com>
Message-ID: <A7DEA48C84FD0B48AAAE33F328C020140291627F@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>

Hi Ross,

I have profiled my system and found that around 8.7 % time is being spend in Reordering Packet Buffer <<OpenRTSP_profiling.log>> 
VMA      samples   %time   App-name      Symbol-name
??00465778 35862     8.7658  openRTSP ReorderingPacketBuffer::storePacket(BufferedPacket*) 

And around 3.4 % time is being spend in  

?00463ac8 13521     3.3049  openRTSP                 seqNumLT(unsigned short, unsigned short)


I am attaching entire oprofilelog for openRTSP log kindly help me with some suggestion to dig out the problem 

PS. These logs captured while recording 16 mjpeg streams (each with 20 FPS and 32KB framesize)

Thanks
Anoop




-----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, October 16, 2008 7:02 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] optimising openRTSP


>I have cross compiled openRTSP for mips platform and I am using its for
>recording mjpeg streams(30fps frame rate 32kb frame size). I need to run
>multiple instances of  this client ( say 16). But the problem is one
>openRTSP client consuming around 12% of CPU time.

That's strange, considering that the application - after it does the 
RTSP protocol exchange - does little more than sitting in a loop, 
reading data from a network socket and then writing it to a 
file.  (It also adds a JPEG header for each frame.)

>  So it is difficult to
>run more than 6 clients sessions without considerable packet loss. How
>do I optimize openRTSP application??

I don't know.  You're first going to have to figure out where it's 
spending most of its CPU time, and why.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>

_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081029/f66110be/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenRTSP_profiling.log
Type: application/octet-stream
Size: 12766 bytes
Desc: OpenRTSP_profiling.log
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081029/f66110be/attachment-0001.obj>

From auto.web at msa.hinet.net  Wed Oct 29 03:18:08 2008
From: auto.web at msa.hinet.net (Kuei-Yi)
Date: Wed, 29 Oct 2008 18:18:08 +0800
Subject: [Live-devel] Some questions need your help!
Message-ID: <000001c939af$a5692040$0b00a8c0@Partner>

>>  2. I have a device which acts as a real-time MPEG4 video streaming 

>>server. It resides at rtsp://adm:12345 at 177.0.0.1:5000/udpstream. I can 

>>use the example of openRTSP program to communicate with it. But I read 

>>the example of openRTSP program a lot of times and I still cannot 

>>understand one thing which is 'Where has the continuously received 

>>video stream gone?'. Where can I find it?

> 

>The output files - named "video-<something>" and "audio-<something>"

>- should be stored on your computer, in the same directory from which you
ran the "openRTSP" application.

 

Is it right that I use the following ways to store the video stream in
openRTSP?

 

MPEG4ESVideoRTPSource* m4esSource = NULL;

MediaSubsession* subsession = NULL;

MediaSubsessionIterator* iter(*session);

 

subsession = iter.next();

m4esSource = subsession->Source();

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

From sbirolo at gmail.com  Wed Oct 29 03:23:19 2008
From: sbirolo at gmail.com (Mattia Daldoss)
Date: Wed, 29 Oct 2008 11:23:19 +0100
Subject: [Live-devel] Problems with openRTSP
Message-ID: <f809cceb0810290323q17c0d57eq4242c40ab9e3b0ef@mail.gmail.com>

>>1. Every output that I create are useless with a normal player (Vlc
>>for example) I got to re-encode it with ffmpeg.
>What media type(s) are you recording?  What command-line options are
>you giving "openRTSP"?

It doesn't work with any format. I tried it "raw" (no options), avi,
mov. With duration no problems,
but as I said I'd like to modify the code in order not to have time
costraint in elaboration. Is that any way (or any function)
to call to stop receiving streams and close the file besides using time?

Thank you for answering.

Mattia Daldoss

From florian.martinot at gmail.com  Wed Oct 29 04:15:29 2008
From: florian.martinot at gmail.com (florian martinot)
Date: Wed, 29 Oct 2008 12:15:29 +0100
Subject: [Live-devel] teardown openRTSP
Message-ID: <52af42920810290415j4955a8d9ubdf29a464130e9e8@mail.gmail.com>

Dear all,

it there a way to stop openRTSP with a teardown before the end of the video?

and without the option -d <duration>

thank you for your help,

regards,

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

From Anoop_P.A at pmc-sierra.com  Wed Oct 29 04:29:29 2008
From: Anoop_P.A at pmc-sierra.com (Anoop P.A.)
Date: Wed, 29 Oct 2008 04:29:29 -0700
Subject: [Live-devel] teardown openRTSP
In-Reply-To: <52af42920810290415j4955a8d9ubdf29a464130e9e8@mail.gmail.com>
References: <52af42920810290415j4955a8d9ubdf29a464130e9e8@mail.gmail.com>
Message-ID: <A7DEA48C84FD0B48AAAE33F328C020140291628A@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>

Hi ,

 

You can use Ctrl+C to tear down 

 

Thanks

Anoop

 

________________________________

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of florian martinot
Sent: Wednesday, October 29, 2008 4:45 PM
To: live-devel at ns.live555.com
Subject: [Live-devel] teardown openRTSP

 

Dear all,

 

it there a way to stop openRTSP with a teardown before the end of the
video?

 

and without the option -d <duration>

 

thank you for your help,

 

regards,

 

Florian

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

From RGlobisch at csir.co.za  Wed Oct 29 04:35:54 2008
From: RGlobisch at csir.co.za (Ralf Globisch)
Date: Wed, 29 Oct 2008 13:35:54 +0200
Subject: [Live-devel] RTSPServer disconnects client session
	in	incomingRequestHandler1
References: <48FF111C0200004D000272A8@pta-emo.csir.co.za>
	<490866BC0200004D00027928@pta-emo.csir.co.za>
Message-ID: <490866B6.5DA9.004D.0@csir.co.za>

Hi,
I've written a RTSP Server using the liveMedia library which streams live data from a webcam unicast over TCP.
The server runs on a Linux box.

When receiving the stream the server randomly disconnects the openRtsp client (sitting on another box).
I've traced it to line 324 in RTSPServer.cpp to the RTSPServer::RTSPClientSession::incomingRequestHandler1() method. 
The debug printf looks something like 

RTSPClientSession[0x81716b0]::incomingRequestHandler1() read 1 bytes:$
RTSPClientSession[0x81716b0]::incomingRequestHandler1() read 59 bytes:
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
schedule(2.887354->1225277965.132946)
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
RTSPClientSession[0x81716b0]::incomingRequestHandler1() read 1 bytes:$
RTSPClientSession[0x81716b0]::incomingRequestHandler1() read 59 bytes:
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sending REPORT
sending RTCP packet
 80c80006 91c3678d ccb2c08d 223443d4 9e962a26 0000046c 00297480 81ca0006 91c3678d 010f7267 6c6f6269 7363682d 6c647330 31000000
sendRTPOverTCP: 56 bytes over channel 1 (socket 14)
sendRTPOverTCP: completed
schedule(3.643940->1225277968.778138)
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
RTSPClientSession[0x81716b0]::incomingRequestHandler1() read 1 bytes:$
RTSPClientSession[0x81716b0]::incomingRequestHandler1() read 59 bytes:
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
sendRTPOverTCP: 2412 bytes over channel 0 (socket 14)
sendRTPOverTCP: completed
RTSPClientSession[0x81716b0]::incomingRequestHandler1() read 1 bytes:$
RTSPClientSession[0x81716b0]::incomingRequestHandler1() read 39 bytes (of 39); terminating connection!
RTCPInstance[0x8177a08]::~RTCPInstance()
sending BYE
sending RTCP packet

Intercepting the communication using Wireshark reveals that the client periodically sends packets (I'm guessing RTCP RR) to the server which alternate between 60 bytes and 56 bytes.
The odd thing is that the last packet sent to the server which causes the server to disconnect the client has a 56 byte size according to Wireshark and a 39 bytes size according to the RTSPClientSession output.
The above output was taken whilst streaming a live audio session. However the same occurs with H263 video, and mixed audio + video session, etc all be it at different times:
1) in the video + audio session the client gets consistently disconnected  at about 170 seconds into the stream.
2) in a video only stream the client gets consistently disconnected around 340 seconds

Further observations:
1) The first client session never gets disconnected, only the sessions following. (The client is always connecting from the same IP)
2) It only occurs when streaming over TCP
3) It happens consistently at the "same time"

Please does anyone have any advice on how to debug this further?

Best 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 Anoop_P.A at pmc-sierra.com  Wed Oct 29 04:51:37 2008
From: Anoop_P.A at pmc-sierra.com (Anoop P.A.)
Date: Wed, 29 Oct 2008 04:51:37 -0700
Subject: [Live-devel] optimising openRTSP
In-Reply-To: <A7DEA48C84FD0B48AAAE33F328C020140291627F@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com><200810160321.m9G3LVr7011952@ns.live555.com><A7DEA48C84FD0B48AAAE33F328C020140291621A@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca><200810161335.m9GDZ2fI051583@ns.live555.com>
	<A7DEA48C84FD0B48AAAE33F328C020140291627F@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>
Message-ID: <A7DEA48C84FD0B48AAAE33F328C020140291628B@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>

Hi Ross,

 

If I use 30 fps stream ( 32 KB frame size and 16 channels)

 

ReorderingPacketBuffer::storePacket(BufferedPacket*) 

 

is taking around 13 % time.

 

I am having 512 MB Ram in my box. And no other service is running. 

I am running openRTSP with following options

 

?./openRTSP -Q -b 32000 -F vid-56-$i -d 1800 rtsp://172.16.48.50:$i/TestJpeg >& log56-$i &

 

Thanks

 

Anoop

________________________________

From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Anoop P.A.
Sent: Wednesday, October 29, 2008 3:24 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] optimising openRTSP

 

Hi Ross,

I have profiled my system and found that around 8.7 % time is being spend in Reordering Packet Buffer <<OpenRTSP_profiling.log>> 

VMA      samples   %time   App-name      Symbol-name

??00465778 35862     8.7658  openRTSP ReorderingPacketBuffer::storePacket(BufferedPacket*) 

And around 3.4 % time is being spend in  

?00463ac8 13521     3.3049  openRTSP                 seqNumLT(unsigned short, unsigned short)

I am attaching entire oprofilelog for openRTSP log kindly help me with some suggestion to dig out the problem 

PS. These logs captured while recording 16 mjpeg streams (each with 20 FPS and 32KB framesize)

Thanks

Anoop

-----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, October 16, 2008 7:02 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] optimising openRTSP

>I have cross compiled openRTSP for mips platform and I am using its for

>recording mjpeg streams(30fps frame rate 32kb frame size). I need to run

>multiple instances of  this client ( say 16). But the problem is one

>openRTSP client consuming around 12% of CPU time.

That's strange, considering that the application - after it does the 

RTSP protocol exchange - does little more than sitting in a loop, 

reading data from a network socket and then writing it to a 

file.  (It also adds a JPEG header for each frame.)

>  So it is difficult to

>run more than 6 clients sessions without considerable packet loss. How

>do I optimize openRTSP application??

I don't know.  You're first going to have to figure out where it's 

spending most of its CPU time, and why.

 

        Ross Finlayson

        Live Networks, Inc. (LIVE555.COM)

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

_______________________________________________

live-devel mailing list

live-devel at lists.live555.com

http://lists.live555.com/mailman/listinfo/live-devel

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

From RGlobisch at csir.co.za  Wed Oct 29 05:55:28 2008
From: RGlobisch at csir.co.za (Ralf Globisch)
Date: Wed, 29 Oct 2008 14:55:28 +0200
Subject: [Live-devel] RTSPServer disconnects client session
	in	incomingRequestHandler1
Message-ID: <4908795C.5DA9.004D.0@csir.co.za>

Update:

Replicated using liveMedia RTSP server and open RTSP to stream audio.
Disconnect also occurred at about 340 seconds. 

This seems to indicate that the request buffer is never reset and hence the 170 and 340 second times make sense too;
double the requests (or RTCP RR packets) and the buffer gets used up in half the time?

Will investigate and submit a patch if I find anything...


-- 
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  Wed Oct 29 05:56:38 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 29 Oct 2008 05:56:38 -0700
Subject: [Live-devel] optimising openRTSP
In-Reply-To: <A7DEA48C84FD0B48AAAE33F328C020140291627F@BBY1EXM11.pmc_nt.nt.pmc-sierra.b
	c.ca>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com><200810160321
	.m9G3LVr7011952@ns.live555.com><A7DEA48C84FD0B48AAAE33F328C020140291621A@B
	BY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>
	<200810161335.m9GDZ2fI051583@ns.live555.com>
	<A7DEA48C84FD0B48AAAE33F328C020140291627F@BBY1EXM11.pmc_nt.nt.pmc-sierra.b
	c.ca>
Message-ID: <f06240807c52e0a532179@[66.80.62.44]>

>I have profiled my system and found that around 8.7 % time is being 
>spend in Reordering Packet Buffer <<OpenRTSP_profiling.log>>
>
>VMA      samples   %time   App-name      Symbol-name
>
>00465778 35862     8.7658  openRTSP 
>ReorderingPacketBuffer::storePacket(BufferedPacket*)
>
>And around 3.4 % time is being spend in
>
>00463ac8 13521     3.3049  openRTSP 
>seqNumLT(unsigned short, unsigned short)
>
>I am attaching entire oprofilelog for openRTSP log kindly help me 
>with some suggestion to dig out the problem

I don't see a problem here.

It sounds like you just have high-bandwidth streams:

>PS. These logs captured while recording 16 mjpeg streams (each with 
>20 FPS and 32KB framesize)

That's almost 82 Mbps.  Are you sure you have sufficient network 
capacity for this (i.e., you don't just have 100 Mbps Ethernet, which 
would not be sufficient)?

If your problem is packet loss (but you have sufficient network 
capacity), then you need to increase your OS's buffer size for 
incoming network packets.  See 
<http://www.live555.com/liveMedia/faq.html#packet-loss>
-- 

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/20081029/9c08024f/attachment.html>

From finlayson at live555.com  Wed Oct 29 06:09:59 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 29 Oct 2008 06:09:59 -0700
Subject: [Live-devel] Problems with openRTSP
In-Reply-To: <f809cceb0810290323q17c0d57eq4242c40ab9e3b0ef@mail.gmail.com>
References: <f809cceb0810290323q17c0d57eq4242c40ab9e3b0ef@mail.gmail.com>
Message-ID: <f0624080ac52e0f945cad@[66.80.62.44]>

>  >>1. Every output that I create are useless with a normal player (Vlc
>>>for example) I got to re-encode it with ffmpeg.
>>What media type(s) are you recording?  What command-line options are
>>you giving "openRTSP"?
>
>It doesn't work with any format. I tried it "raw" (no options), avi,
>mov. With duration no problems,
>but as I said I'd like to modify the code in order not to have time
>costraint in elaboration. Is that any way (or any function)
>to call to stop receiving streams and close the file besides using time?

Yes. You can cleanly kill the application (which will cause it to 
complete writing the output file properly) by killing it with the 
"-HUP" or the "-USR1" signal.  This is stated clearly in the 
application's output.

Note that (if you're outputting a ".mov", ".mp4" or ".avi" file) you 
can't just terminate the application using <control>-C; you need to 
terminate the application cleanly using the "-HUP" or the "-USR1" 
signal - or else use the "-d <duration>" option.

If, however, you are running Windows - which doesn't let you signal 
an application like this - then you are out of luck, unless you use 
"-d <duration>".  Sorry.

From finlayson at live555.com  Wed Oct 29 06:26:24 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 29 Oct 2008 06:26:24 -0700
Subject: [Live-devel] Some questions need your help!
In-Reply-To: <000001c939af$a5692040$0b00a8c0@Partner>
References: <000001c939af$a5692040$0b00a8c0@Partner>
Message-ID: <f0624080cc52e148d8741@[66.80.62.44]>

>Is it right that I use the following ways to store the video stream 
>in openRTSP?
>
>MPEG4ESVideoRTPSource* m4esSource = NULL;
>MediaSubsession* subsession = NULL;
>MediaSubsessionIterator* iter(*session);
>
>subsession = iter.next();
>m4esSource = subsession->Source();

I don't understand your question; that code doesn't 'store' anything. 
A "RTPSource" (subclass) is used for *receiving* RTP packets, not for 
outputting anything.

Remember, once you've made modifications to the existing code, you 
can't (in general) expect much support on this mailing list.
-- 

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

From finlayson at live555.com  Wed Oct 29 06:30:59 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 29 Oct 2008 06:30:59 -0700
Subject: [Live-devel] teardown openRTSP
In-Reply-To: <52af42920810290415j4955a8d9ubdf29a464130e9e8@mail.gmail.com>
References: <52af42920810290415j4955a8d9ubdf29a464130e9e8@mail.gmail.com>
Message-ID: <f0624080dc52e15ebd908@[66.80.62.44]>

>Dear all,
>
>it there a way to stop openRTSP with a teardown before the end of the video?
>
>and without the option -d <duration>

See my earlier response to someone else's message "Problems with 
openRTSP". They had the same question.

-- 

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

From finlayson at live555.com  Wed Oct 29 06:32:46 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 29 Oct 2008 06:32:46 -0700
Subject: [Live-devel] teardown openRTSP
In-Reply-To: <A7DEA48C84FD0B48AAAE33F328C020140291628A@BBY1EXM11.pmc_nt.nt.pmc-sierra.b
	c.ca>
References: <52af42920810290415j4955a8d9ubdf29a464130e9e8@mail.gmail.com>
	<A7DEA48C84FD0B48AAAE33F328C020140291628A@BBY1EXM11.pmc_nt.nt.pmc-sierra.b
	c.ca>
Message-ID: <f0624080ec52e1619e409@[66.80.62.44]>

>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>	boundary="----_=_NextPart_001_01C939B9.9B6D3897"
>
>Hi ,
>
>You can use Ctrl+C to tear down

You can't do this if you are using the "-q", "-4" or "-i" options. 
If you're using those options, you need to signal the application 
with the "-HUP" or the "-USR1" signal.  (Note my earlier response to 
someone else's question about 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/20081029/f6826499/attachment.html>

From gabrieledeluca at libero.it  Wed Oct 29 02:20:07 2008
From: gabrieledeluca at libero.it (gabrieledeluca at libero.it)
Date: Wed, 29 Oct 2008 10:20:07 +0100
Subject: [Live-devel] Relayer
Message-ID: <K9HTXJ$5912B15B3E40373E989A9E6B9B71059B@libero.it>

Hi,
How I can do a relayer unicast->unicast (for example) using local files buffer within rtp packets?
I have as input a stream on demand (for example a MPEG4 audio/video with address rtsp://192.168.178.20:8555/mystream).

Thanks in advance,


Bobo


From Anoop_P.A at pmc-sierra.com  Wed Oct 29 08:39:19 2008
From: Anoop_P.A at pmc-sierra.com (Anoop P.A.)
Date: Wed, 29 Oct 2008 08:39:19 -0700
Subject: [Live-devel] optimising openRTSP
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com><200810160321.m9G3LVr7011952@ns.live555.com><A7DEA48C84FD0B48AAAE33F328C020140291621A@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca><200810161335.m9GDZ2fI051583@ns.live555.com><A7DEA48C84FD0B48AAAE33F328C020140291627F@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>
	<f06240807c52e0a532179@[66.80.62.44]>
Message-ID: <A7DEA48C84FD0B48AAAE33F328C0201401EF0BE1@BBY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca>

if it is 16 * 20 * 32 KB means 10 MBps. I am having gigE network. 
 
My problem is openRTSP consuming lots of cpu so I am unable to run other s/w.
 
What is this "ReorderingPacketBuffer." function doing?. is this issue ( what i a seeing) have any relation with free mem ?
 
Thaks
Aoop
________________________________

From: live-devel-bounces at ns.live555.com on behalf of Ross Finlayson
Sent: Wed 10/29/2008 6:26 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] optimising openRTSP



	I have profiled my system and found that around 8.7 % time is being spend in Reordering Packet Buffer <<OpenRTSP_profiling.log>>
	

	VMA      samples   %time   App-name      Symbol-name
	

	00465778 35862     8.7658  openRTSP ReorderingPacketBuffer::storePacket(BufferedPacket*)
	

	And around 3.4 % time is being spend in
	

	00463ac8 13521     3.3049  openRTSP                 seqNumLT(unsigned short, unsigned short)
	

	I am attaching entire oprofilelog for openRTSP log kindly help me with some suggestion to dig out the problem


I don't see a problem here.

It sounds like you just have high-bandwidth streams:


	PS. These logs captured while recording 16 mjpeg streams (each with 20 FPS and 32KB framesize)


That's almost 82 Mbps.  Are you sure you have sufficient network capacity for this (i.e., you don't just have 100 Mbps Ethernet, which would not be sufficient)?

If your problem is packet loss (but you have sufficient network capacity), then you need to increase your OS's buffer size for incoming network packets.  See <http://www.live555.com/liveMedia/faq.html#packet-loss>
-- 

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

From finlayson at live555.com  Wed Oct 29 11:33:51 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 29 Oct 2008 11:33:51 -0700
Subject: [Live-devel] optimising openRTSP
In-Reply-To: <A7DEA48C84FD0B48AAAE33F328C0201401EF0BE1@BBY1EXM11.pmc_nt.nt.pmc-sierra.b
	c.ca>
References: <6dd519ae0810151617t252442f3od4c95b785a6d15a2@mail.gmail.com><200810160321
	.m9G3LVr7011952@ns.live555.com><A7DEA48C84FD0B48AAAE33F328C020140291621A@B
	BY1EXM11.pmc_nt.nt.pmc-sierra.bc.ca><200810161335.m9GDZ2fI051583@ns.live55
	5.com><A7DEA48C84FD0B48AAAE33F328C020140291627F@BBY1EXM11.pmc_nt.nt.pmc-si
	erra.bc.ca>	<f06240807c52e0a532179@[66.80.62.44]>
	<A7DEA48C84FD0B48AAAE33F328C0201401EF0BE1@BBY1EXM11.pmc_nt.nt.pmc-sierra.b
	c.ca>
Message-ID: <f06240801c52e5c1e7e25@[66.80.62.44]>

>if it is 16 * 20 * 32 KB means 10 MBps. I am having gigE network.
>
>My problem is openRTSP consuming lots of cpu so I am unable to run other s/w.

12% (especially for 16 instances of the application) is *not* a lot 
of CPU, by any measure.

>  What is this "ReorderingPacketBuffer." function doing?

It is doing very little (especially if, as is usually the case, the 
incoming RTP packets have not been reordered by the network).  This 
is a complete Red Herring.

As I noted in my earlier message, your packet loss problem is likely 
caused by insufficient OS buffering for incoming packets.
-- 

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

From RGlobisch at csir.co.za  Thu Oct 30 00:06:55 2008
From: RGlobisch at csir.co.za (Ralf Globisch)
Date: Thu, 30 Oct 2008 09:06:55 +0200
Subject: [Live-devel] Aynchronous RTSPClient
Message-ID: <4909792F.5DA9.004D.0@csir.co.za>

Hi Ross,

Are there any plans to implement the RTSPClient using aynchronous network I/O as specified in the "To do" section of the website?
And if so, what time frame are we looking at?

Thanks,
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 finlayson at live555.com  Thu Oct 30 00:18:24 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 30 Oct 2008 00:18:24 -0700
Subject: [Live-devel] Aynchronous RTSPClient
In-Reply-To: <4909792F.5DA9.004D.0@csir.co.za>
References: <4909792F.5DA9.004D.0@csir.co.za>
Message-ID: <f06240806c52f0ff7760d@[66.80.62.44]>

>Are there any plans to implement the RTSPClient using aynchronous 
>network I/O as specified in the "To do" section of the website?

Yes.

>And if so, what time frame are we looking at?

I don't like to give 'timeframes'; however, this is a high-priority item.
-- 

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

From amit.yedidia at elbitsystems.com  Thu Oct 30 01:27:34 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Thu, 30 Oct 2008 10:27:34 +0200
Subject: [Live-devel] RTP Extension
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D363D@mailesl5.esl.corp.elbit.co.il>

Hi,

What is the proper way to imlement adding RTP extension in Live555?

Thanks,


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/20081030/e72eefd9/attachment.html>

From finlayson at live555.com  Thu Oct 30 01:46:45 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 30 Oct 2008 01:46:45 -0700
Subject: [Live-devel] RTP Extension
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D363D@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D363D@mailesl5.esl.corp.elbit.co.il>
Message-ID: <f06240807c52f22dce3b4@[66.80.62.44]>

>What is the proper way to imlement adding RTP extension in Live555?

it depends what you mean by "RTP extension".

If you're referring to just implementing a new RTP payload format, 
then this is easy - just define and implement your own subclasses of 
"MultiFramedRTPSink" (for sending) and "MultiFramedRTPSource" (for 
receiving).

If, however, you're referring to implementing RTP *header* extensions 
(as defined in RFC 3550, section 5.3.1), then there's currently no 
clean way to do this; instead, you would need to modify the existing 
"MultiFramedRTPS*.cpp" code to support 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/20081030/6328883a/attachment.html>

From amit.yedidia at elbitsystems.com  Thu Oct 30 02:11:49 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Thu, 30 Oct 2008 11:11:49 +0200
Subject: [Live-devel] RTP Extension
In-Reply-To: <f06240807c52f22dce3b4@[66.80.62.44]>
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D3641@mailesl5.esl.corp.elbit.co.il>

I mean to RTP Header Extension. and thank you for your answer.
 
what I am trying to do is adding meta data per frame to a H264 RFC3984
stream.
another way which cross my mind is to put this meta data in NAL with
unspecified NAL type (24-31).
But I need it to interop with clients which dont support my meta data.
(they just need to ignore this data)
Do you think it will do the job?
 

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, October 30, 2008 10:47 AM
	To: LIVE555 Streaming Media - development & use
	Subject: Re: [Live-devel] RTP Extension
	
	

		What is the proper way to imlement adding RTP extension
in Live555?


	it depends what you mean by "RTP extension".

	If you're referring to just implementing a new RTP payload
format, then this is easy - just define and implement your own
subclasses of "MultiFramedRTPSink" (for sending) and
"MultiFramedRTPSource" (for receiving).

	If, however, you're referring to implementing RTP *header*
extensions (as defined in RFC 3550, section 5.3.1), then there's
currently no clean way to do this; instead, you would need to modify the
existing "MultiFramedRTPS*.cpp" code to support 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/20081030/96e194b1/attachment.html>

From RGlobisch at csir.co.za  Thu Oct 30 02:39:33 2008
From: RGlobisch at csir.co.za (Ralf Globisch)
Date: Thu, 30 Oct 2008 11:39:33 +0200
Subject: [Live-devel] RTSPServer disconnects client session
	in	incomingRequestHandler1 [Update]
References: <49098F170200004D000279F9@pta-emo.csir.co.za>
	<49099CF50200004D00027A17@pta-emo.csir.co.za>
Message-ID: <49099CF5.5DA9.004D.0@csir.co.za>

Hi Ross,
I managed to track the cause of the disconnection down. 

It seems that the later connection's RR packets are not handled by RTPTransmissionStats::noteIncomingRR but by the RTSPServer::RTSPClientSession::incomingRequestHandler1.
Every RR fills the buffer up and when the buffer is finally full the RTSP server terminates the client connection.

Still don't know what exactly is causing the system to get into the error state.
Maybe this will give you some indication of what's going wrong since you know the system so in depth.

I am using the latest version of the liveMedia code: 2008/10/07
The problem occurs only when the server runs on a Linux Ubuntu system. I'm not sure if it will surface in other Linux distros.

To replicate do the following:

Setup:
  Client: OpenRtsp (sitting on another machine)
  Platform: Linux Ubuntu Hardy and Windows XP
  Transport: TCP

  Server: 
  live555 Dynamic RTSP Server (MediaServer)
  Platform: Linux Ubuntu Hardy
  Platform: Windows XP: Bug does NOT occur when the server is running on this platform

Steps:

1) Add some debug output to RTSPServer::RTSPClientSession::incomingRequestHandler1 to show that the handler was called. This must be before the 
"if (!endOfMsg) return;" statement. (once the system is in this erroneous state the method exits at this point)

2) Compile the liveMedia library with DEBUG_RR.

3) Run the server

4) Connect the first openRtsp client over tcp. At this point you'll see the RR debug output on the console. Let it run for about a minute or so. (The problem only seems to occur once the system has been running for a while: related to rtcp timeout maybe?)

5) Disconnect the openRtsp client.

6) Reconnect the client: if the RR output shows up on the server console, let the openRtsp client run for a couple of seconds.

7) Repeat 5 - 6 until after connection you see the RTSPServer::RTSPClientSession::incomingRequestHandler1 output instead of the RR output. 

At this point the RTSPClientSession handler is used for each RR packet and when the buffer is full, the connection is terminated.

In our system we obviously don't break the server following these steps. Our client connects only twice, once to sniff packets to obtain information about the media type and the second time to stream the media type.
This "double-connection" is enough for the server to go into this error state and disconnect our clients most of the time.

I've attached both the Windows and the Linux server output. Not sure if that helps track the bug down?

Any ideas?

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.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Debug_Linux.txt
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081030/058b718e/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Debug_Windows.txt
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081030/058b718e/attachment-0003.txt>

From amit.yedidia at elbitsystems.com  Thu Oct 30 02:44:37 2008
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Thu, 30 Oct 2008 11:44:37 +0200
Subject: [Live-devel] Try-catch in  parsers
Message-ID: <EB34B5A39CF26E408490ED9279BF10A71D3643@mailesl5.esl.corp.elbit.co.il>

Hi Ross, All

1.Why the parsers in the Live libarary are working with try and catch?
2. If I am implementing DeviceSouce which deliver H264 nals threw socket
(as you recommended), how should I know which nal is the last NAL fo the
AccessUnit (last nal in frame)?



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/20081030/b404f462/attachment.html>

From finlayson at live555.com  Thu Oct 30 04:58:37 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 30 Oct 2008 04:58:37 -0700
Subject: [Live-devel] RTP Extension
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D3641@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D3641@mailesl5.esl.corp.elbit.co.il>
Message-ID: <f06240800c52f518f4a1a@[66.80.62.44]>

>I mean to RTP Header Extension. and thank you for your answer.
>
>what I am trying to do is adding meta data per frame to a H264 RFC3984 stream.
>another way which cross my mind is to put this meta data in NAL with 
>unspecified NAL type (24-31).
>But I need it to interop with clients which dont support my meta 
>data. (they just need to ignore this data)
>Do you think it will do the job?


Because this 'meta data' is per frame, and thus associated directly 
with the H.264 video data, then the best solution would be to carry 
it within the H.264 video data - rather than RTP headers - if you can.
-- 

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/20081030/31648fa9/attachment.html>

From finlayson at live555.com  Thu Oct 30 05:15:04 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 30 Oct 2008 05:15:04 -0700
Subject: [Live-devel] Try-catch in  parsers
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D3643@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D3643@mailesl5.esl.corp.elbit.co.il>
Message-ID: <f06240801c52f54bc08ba@[66.80.62.44]>

>1.Why the parsers in the Live libarary are working with try and catch?

When a parser runs into the end of its input buffer (which could 
happen anywhere within the parsing code), it needs to temporarily 
stop parsing, request new input data, and then return to the event 
loop.  C++ language exceptions were a good way to do this in the code.


>2. If I am implementing DeviceSouce which deliver H264 nals threw 
>socket (as you recommended), how should I know which nal is the last 
>NAL fo the  AccessUnit (last nal in frame)?

I don't know, but presumably your encoder has this information (somehow).
-- 

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/20081030/e0eaa311/attachment.html>

From finlayson at live555.com  Thu Oct 30 06:09:45 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 30 Oct 2008 06:09:45 -0700
Subject: [Live-devel] RTSPServer disconnects client session in
 incomingRequestHandler1 [Update]
In-Reply-To: <49099CF5.5DA9.004D.0@csir.co.za>
References: <49098F170200004D000279F9@pta-emo.csir.co.za>
	<49099CF50200004D00027A17@pta-emo.csir.co.za>
	<49099CF5.5DA9.004D.0@csir.co.za>
Message-ID: <f06240802c52f5f658836@[66.80.62.44]>

>I managed to track the cause of the disconnection down.
>
>It seems that the later connection's RR packets are not handled by 
>RTPTransmissionStats::noteIncomingRR but by the 
>RTSPServer::RTSPClientSession::incomingRequestHandler1.

That's strange.  When the RTSP server handles the RTSP "PLAY" 
command, its call to "OnDemandServerMediaSubsession::startStream()" 
causes "StreamState::startPlaying()" to be called, which should cause 
a "RTCPInstance" to be created.  That should then cause incoming data 
(on the TCP connection) to be handled by the RTP/RTCP code, rather 
than the RTSP code,

>Every RR fills the buffer up and when the buffer is finally full the 
>RTSP server terminates the client connection.
>
>Still don't know what exactly is causing the system to get into the 
>error state.
>Maybe this will give you some indication of what's going wrong since 
>you know the system so in depth.

Thanks for the report.  Unfortunately, I don't know what's going 
wrong.  The fact that you see the problem only when the server runs 
Linux, and not Windows, is strange.

-- 

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

From anitarajan at tataelxsi.co.in  Thu Oct 30 06:40:01 2008
From: anitarajan at tataelxsi.co.in (Anita Rajan)
Date: Thu, 30 Oct 2008 19:10:01 +0530
Subject: [Live-devel] RTSP Tunnelling support in openRTSP
Message-ID: <020b01c93a95$03205b00$6e033c0a@telxsi.com>

Hi All,

I have extended the Live 555 server to support RTSPoverHTTPTunnelling.

I am testing it using openRTSP...
does open RTSP tunnelling(full fledged)..
that is receiving the response for the RTSP request on the GEt channel and
sending requests to teh server on the POST channel.
When i am testing the After OPTIONS the next DESCRIBE comes after
a long delay from the client.

Thanks and Regards,
A.R


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 matt at schuckmannacres.com  Thu Oct 30 09:57:11 2008
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Thu, 30 Oct 2008 09:57:11 -0700
Subject: [Live-devel] RTP Extension
In-Reply-To: <EB34B5A39CF26E408490ED9279BF10A71D3641@mailesl5.esl.corp.elbit.co.il>
References: <EB34B5A39CF26E408490ED9279BF10A71D3641@mailesl5.esl.corp.elbit.co.il>
Message-ID: <4909E767.3050403@schuckmannacres.com>

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

From finlayson at live555.com  Thu Oct 30 14:04:55 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 30 Oct 2008 14:04:55 -0700
Subject: [Live-devel] RTP Extension
In-Reply-To: <4909E767.3050403@schuckmannacres.com>
References: <EB34B5A39CF26E408490ED9279BF10A71D3641@mailesl5.esl.corp.elbit.co.il>
	<4909E767.3050403@schuckmannacres.com>
Message-ID: <f06240804c52fcf99dd9b@[66.80.62.44]>

>What's wrong with putting your meta-data in another stream that is 
>time synchronized with the H264 stream. I believe that is the 
>intended way to do such a thing in RTP.

It depends.  Is the meta-data really specific to individual video 
frames?  If so, then it's better to include it in the video data 
(rather than using RTP), if the video codec allows it.

If, however, the meta-data is intended to be time-synchronized with 
the video data, but not tied to individual video frames (e.g., it's 
something like subtitles), then it would make sense to use a separate 
RTP stream.  However, there might not be a RTP standard payload 
format for such data, so you would need to define one yourself (and 
implement it for our software).
-- 

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

From finlayson at live555.com  Thu Oct 30 14:06:54 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 30 Oct 2008 14:06:54 -0700
Subject: [Live-devel] RTSP Tunnelling support in openRTSP
In-Reply-To: <020b01c93a95$03205b00$6e033c0a@telxsi.com>
References: <020b01c93a95$03205b00$6e033c0a@telxsi.com>
Message-ID: <f06240805c52fd2337997@[66.80.62.44]>

The RTSP-over-HTTP tunneling support in our RTSP server code doesn't 
yet work properly - that's why it's commented out.

At present, we support RTSP-over-HTTP tunneling for RTSP clients only.
-- 

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

From anto.rizzo at caramail.com  Fri Oct 31 01:47:59 2008
From: anto.rizzo at caramail.com (Antonella De Luca)
Date: Fri, 31 Oct 2008 09:47:59 +0100
Subject: [Live-devel] I want be a server
Message-ID: <193707548827839@lycos-europe.com>

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

From RGlobisch at csir.co.za  Fri Oct 31 02:31:11 2008
From: RGlobisch at csir.co.za (Ralf Globisch)
Date: Fri, 31 Oct 2008 11:31:11 +0200
Subject: [Live-devel] RTSPServer disconnects client session
	in	incomingRequestHandler1 [Update]
Message-ID: <490AEC7F.5DA9.004D.0@csir.co.za>

Hi Ross,

>That's strange.  When the RTSP server handles the RTSP "PLAY" 
>command, its call to "OnDemandServerMediaSubsession::startStream()" 
>causes "StreamState::startPlaying()" to be called, which should cause 
>a "RTCPInstance" to be created.  That should then cause incoming data 
>(on the TCP connection) to be handled by the RTP/RTCP code, rather 
>than the RTSP code,

>Thanks for the report.  Unfortunately, I don't know what's going 
>wrong.  The fact that you see the problem only when the server runs 
>Linux, and not Windows, is strange.

For sure, I'm also finding it strange. I managed to replicate the results on a Fedora box too now, so it definitely seems to be a Linux problem.



-- 
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 RGlobisch at csir.co.za  Fri Oct 31 02:38:23 2008
From: RGlobisch at csir.co.za (Ralf Globisch)
Date: Fri, 31 Oct 2008 11:38:23 +0200
Subject: [Live-devel] RTSPServer disconnects client session
	in	incomingRequestHandler1 [Update]
References: <490AAD760200004D00027AE4@pta-emo.csir.co.za>
	<490AEE2F0200004D00027B47@pta-emo.csir.co.za>
Message-ID: <490AEE2F.5DA9.004D.0@csir.co.za>

Hi Ross,

Managed to isolate the problem further, the RTSP Server session timeout triggers the RTCPInstance destructor (since the client has already disconnected). 
As soon as a RTCPInstance destructor has executed, the next RTSP client request is handled by the RTSP handler instead of the RTCP handler.

It does not make a difference where the client's connect from, whether from the same box as the server, other boxes, Windows and Linux clients.

The steps to replicate the problem have now been updated to:

1) Set the DynamicRTSPServer timeout to something short like 15 seconds.
2) a) add printf in ~RTCPInstance() (So you can see that the destructor has executed)
    b) add print f in RTSP request handler. (So you can see that the incorrect handler has been called)
    c)  Compile with DEBUG_RR (so you can see when the correct RTCP handler is called) and without DEBUG (which clogs the view)
3) Run the server
4) Connect an openRtsp client over tcp
5) Wait for a RTCP handler output (Everything is as should be)
5) Kill the client
6) Wait for the ~RTCPInstance printf on the server console (this will happen 15 seconds after the client was disconnected)
7) Connect a second openRTSP client (irrespective if from the same or from another machine)
8) See the RTSP handler output appear instead of the RTCP output.

I've traced the call from RTCPInstance::~RTCPInstance() to fRTCPInterface.stopNetworkReading() to envir().taskScheduler().turnOffBackgroundReadHandling(fGS->socketNum())
but I can't see anything wrong, I've added a whole wad of debug info but the flow of events always seems to be correct.

I've compared the addresses of the handler pointer that is passed through to turnOnBackgroundReadHandling for each RTCPInstance and they are the same so I can't understand how the other handler is being called.

Also, the only platform-dependent code is the FD_CLR macro in turnOffBackgroundReadHandling? But this code also gets used by the other socket connections?

Maybe now that it's narrowed down to a few lines of code, it will make sense to you?

Please let me know if you can replicate it or if you need any other info...

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 RGlobisch at csir.co.za  Fri Oct 31 05:17:01 2008
From: RGlobisch at csir.co.za (Ralf Globisch)
Date: Fri, 31 Oct 2008 14:17:01 +0200
Subject: [Live-devel] MediaSession.cpp patch suggestion
Message-ID: <490B135D.5DA9.004D.0@csir.co.za>

Hi Ross,

I'm not sure if there's any reason against this patch, 
but since 16-bit PCM audio is always transferred in network byte order, 
shouldn't the byte order be swapped again on the client side before the sink receives the data?
Or is there any case where this isn't true?

On the other hand, this change might break existing code bases if "they" do the swapping "manually".

I've attached a patch that automatically inserts your EndianSwap16 filter when a source is created for codec type L16.

(it's the first time I've created one) so I'm not sure if it's in the correct format...

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.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MediaSession.cpp.patch
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20081031/cee2a0f2/attachment.ksh>

From anitarajan at tataelxsi.co.in  Fri Oct 31 05:51:54 2008
From: anitarajan at tataelxsi.co.in (Anita Rajan)
Date: Fri, 31 Oct 2008 18:21:54 +0530
Subject: [Live-devel] RTSP Tunnelling support in openRTSP
In-Reply-To: <f06240805c52fd2337997@[66.80.62.44]>
Message-ID: <029201c93b57$74a58d50$6e033c0a@telxsi.com>

Hi Ross,

I have implemented the RTSPOverHTTPServer in Live555 to act
as a tunnelling server.

I am using openRTSP to test.

Please let me know if my understanding is correct in the following case:
1.The connection created by the HTTP GET request is to be used send response
to the RTSP
request received from the client in the POST connection.


Does openRTSP handle this?..


Thanks and Regards,
A.R

-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com]On Behalf Of Ross Finlayson
Sent: Friday, October 31, 2008 2:37 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] RTSP Tunnelling support in openRTSP


The RTSP-over-HTTP tunneling support in our RTSP server code doesn't
yet work properly - that's why it's commented out.

At present, we support RTSP-over-HTTP tunneling for RTSP clients only.
--

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 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  Fri Oct 31 05:51:01 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 31 Oct 2008 05:51:01 -0700
Subject: [Live-devel] MediaSession.cpp patch suggestion
In-Reply-To: <490B135D.5DA9.004D.0@csir.co.za>
References: <490B135D.5DA9.004D.0@csir.co.za>
Message-ID: <f06240801c530ae8cc5a8@[66.80.62.44]>

No, the existing code is correct.  Incoming "'audio/L16" RTP data is 
(by definition) in network (big-endian) byte order.  It's up to 
whatever downstream object uses this data to decide whether or not it 
wants to byte-swap it.  (Note that your patch would not work on 
big-endian architectures, because they would not need to do any byte 
swapping.)
-- 

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

From RGlobisch at csir.co.za  Fri Oct 31 06:11:46 2008
From: RGlobisch at csir.co.za (Ralf Globisch)
Date: Fri, 31 Oct 2008 15:11:46 +0200
Subject: [Live-devel] MediaSession.cpp patch suggestion
Message-ID: <490B2032.5DA9.004D.0@csir.co.za>

Ah ok, my bad, thanks for the explanation.

>No, the existing code is correct.  Incoming "'audio/L16" RTP data is 
>(by definition) in network (big-endian) byte order.  It's up to 
>whatever downstream object uses this data to decide whether or not it 
>wants to byte-swap it.  (Note that your patch would not work on 
>big-endian architectures, because they would not need to do any byte 
>swapping.)
>-- 
>
>Ross Finlayson
>Live Networks, Inc.
>http://www.live555.com/ 



-- 
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 anto.rizzo at caramail.com  Fri Oct 31 07:56:17 2008
From: anto.rizzo at caramail.com (Antonella Rizzo)
Date: Fri, 31 Oct 2008 15:56:17 +0100
Subject: [Live-devel] Help me: I want to be a server
Message-ID: <104683452920775@lycos-europe.com>

Hi,
I must create an application that take the input from a stream (for example testOnDemandRTSP output) and server becomes! 
In others words, I am the client of testOnDemandRTSP, but before I must become server! My purpose is to dispose of most traffic between host sharing the stream! 
How to? 

Best regards

Ps. my previous message is not readable (Html version)


From matt at schuckmannacres.com  Fri Oct 31 10:12:43 2008
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Fri, 31 Oct 2008 10:12:43 -0700
Subject: [Live-devel] Implementing SET_PARAMETER and GET_PARAMETER
Message-ID: <490B3C8B.1020405@schuckmannacres.com>

This is a continuation of one of my previous messages where I expressed 
the desire to implement SET_PARAMETER  (and by extension a more complete 
GET_PARAMETER)

I'm actually starting to work on doing this and I want to try to make 
whatever I do something that can be applied back to the library for 
others to take advantage of, so here goes.

Ross you had suggested that I perhaps start by implementing a new 
virtual method on RTSPServer for SET_PARAMETER.

I looked into doing this in the code and I realized that RTSPServer 
doesn't actually handle most of the commands for each session instance, 
it's RTSPServer::RTSPClientSession which is a private member class of 
RTSPServer.
So it looks like I'll have to at the least make RTSPClientSession 
protected and provide a virtual constructor method to RTSPServer to 
create a new RTSPClientSession (or derived class) from 
RTSPServer::incomingRequestHandler1

I think I'll then need to virtualize all the handleCmd_* methods (or at 
least the GET/SET_PARAMETER ones) in RTSPClientSession so  that derived  
classes  can do there own thing here.

Does this sound something like what you were thinking Ross or were you 
thinking of something else?

Thanks for you input, and the great library
Matt Schuckmann





From finlayson at live555.com  Fri Oct 31 15:11:31 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 31 Oct 2008 15:11:31 -0700
Subject: [Live-devel] Implementing SET_PARAMETER and GET_PARAMETER
In-Reply-To: <490B3C8B.1020405@schuckmannacres.com>
References: <490B3C8B.1020405@schuckmannacres.com>
Message-ID: <f06240802c53131e363f9@[66.80.62.44]>

>Ross you had suggested that I perhaps start by implementing a new 
>virtual method on RTSPServer for SET_PARAMETER.
>
>I looked into doing this in the code and I realized that RTSPServer 
>doesn't actually handle most of the commands for each session 
>instance, it's RTSPServer::RTSPClientSession which is a private 
>member class of RTSPServer.
>So it looks like I'll have to at the least make RTSPClientSession 
>protected and provide a virtual constructor method to RTSPServer to 
>create a new RTSPClientSession (or derived class) from 
>RTSPServer::incomingRequestHandler1
>
>I think I'll then need to virtualize all the handleCmd_* methods (or 
>at least the GET/SET_PARAMETER ones) in RTSPClientSession so  that 
>derived  classes  can do there own thing here.
>
>Does this sound something like what you were thinking Ross or were 
>you thinking of something else?

It depends on which object's state you want to update as a result of 
the "SET_PARAMETER" operation.

If you want to update the state of the "RTSPClientSession" object, 
then yes, you'd probably need to add a virtual function to 
"RTSPClientSession".

If, however, you want to update the state of the "RTSPServer" object 
only, then you could probably do this by writing a generic 
implementation of "SET_PARAMETER" for "RTSPClientSession" that calls 
a new virtual function in "fOurServer" ("RTSPServer").

And if you want to update the state of the "ServerMediaSubsession" 
object, then you would have even more work to do.
-- 

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

From matt at schuckmannacres.com  Fri Oct 31 15:38:22 2008
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Fri, 31 Oct 2008 15:38:22 -0700
Subject: [Live-devel] Implementing SET_PARAMETER and GET_PARAMETER
In-Reply-To: <f06240802c53131e363f9@[66.80.62.44]>
References: <490B3C8B.1020405@schuckmannacres.com>
	<f06240802c53131e363f9@[66.80.62.44]>
Message-ID: <490B88DE.5060403@schuckmannacres.com>



Ross Finlayson wrote:
>> Ross you had suggested that I perhaps start by implementing a new 
>> virtual method on RTSPServer for SET_PARAMETER.
>>
>> I looked into doing this in the code and I realized that RTSPServer 
>> doesn't actually handle most of the commands for each session 
>> instance, it's RTSPServer::RTSPClientSession which is a private 
>> member class of RTSPServer.
>> So it looks like I'll have to at the least make RTSPClientSession 
>> protected and provide a virtual constructor method to RTSPServer to 
>> create a new RTSPClientSession (or derived class) from 
>> RTSPServer::incomingRequestHandler1
>>
>> I think I'll then need to virtualize all the handleCmd_* methods (or 
>> at least the GET/SET_PARAMETER ones) in RTSPClientSession so  that 
>> derived  classes  can do there own thing here.
>>
>> Does this sound something like what you were thinking Ross or were 
>> you thinking of something else?
>
> It depends on which object's state you want to update as a result of 
> the "SET_PARAMETER" operation.
>
> If you want to update the state of the "RTSPClientSession" object, 
> then yes, you'd probably need to add a virtual function to 
> "RTSPClientSession".
>
> If, however, you want to update the state of the "RTSPServer" object 
> only, then you could probably do this by writing a generic 
> implementation of "SET_PARAMETER" for "RTSPClientSession" that calls a 
> new virtual function in "fOurServer" ("RTSPServer").
>
> And if you want to update the state of the "ServerMediaSubsession" 
> object, then you would have even more work to do.

Well I want to update an object that represents the state of the session 
as a whole. More specifically a camera object that is producing data for 
multiple streams (at a minimum a video stream and a meta data stream).
Side effects of modifying this object could include modifying the state 
of ServerMediaSubsesssion objects associated with the session (these 
appear to be owned sorta kinda indirectly owned by the RTSPClientSession 
object). I find it a little strange that they are created as a side 
effect of the getStreamParameters() method ( at least I think we are 
talking about the same thing here).

And did I mention there will be multiple of these cameras each with 
there own state and sessions.

It seems like the RTSPClientSessions are the only objects in your 
library that represent each instance of a session as whole, yet they are 
pretty well hidden from the client API (i.e. private to the RTSPServer 
class).
The ServerMediaSession and ServerMediaSubsession objects appear to be 
more factory type classes that describe how to build up the 
RTSPClientSession and it's constituent SourceFramer objects and RTPSink 
objects. So setting a parameter on a ServerMediaSession or a 
ServerMediaSubsession object doesn't really seem appropriate.

What's nice about the RTSPClientSession is they are very general and 
they don't appear to be to muddled with the specifics and I don't want 
to change that.

Unless you can make any more suggestions I'll continue to post as  I 
move forward and let you know how things go.

Thanks
Matt S.



From finlayson at live555.com  Fri Oct 31 19:00:26 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 31 Oct 2008 19:00:26 -0700
Subject: [Live-devel] Implementing SET_PARAMETER and GET_PARAMETER
In-Reply-To: <490B88DE.5060403@schuckmannacres.com>
References: <490B3C8B.1020405@schuckmannacres.com>
	<f06240802c53131e363f9@[66.80.62.44]>
	<490B88DE.5060403@schuckmannacres.com>
Message-ID: <f06240801c53167b41f19@[66.80.62.44]>

>Well I want to update an object that represents the state of the 
>session as a whole.

Note:
- A "ServerMediaSession" represents the state of a data source, 
regardless if how many clients (if any) the data is currently being 
streamed to.  (A "ServerMediaSubsession" represents the state of a 
single media type (e.g., audio or video) within this.)
- A "RTSPClientSession" represents the state of each RTSP client.
-- 

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