From rajesh_gnair at yahoo.com  Sun Nov  1 21:13:42 2009
From: rajesh_gnair at yahoo.com (rajesh nair)
Date: Sun, 1 Nov 2009 21:13:42 -0800 (PST)
Subject: [Live-devel] Application to save multicast rtp video data from a ip
	camera
Message-ID: <707749.44427.qm@web56306.mail.re3.yahoo.com>

Hi,
I would like to develop an application to save?video data from a IP camera which multicasts the data using rtp. Can anyone guide me to the right source code library in live555 using which I can develop the same
Thanks in advance
Rajesh


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

From bikramjeet.singh at logiceastern.co.in  Sun Nov  1 22:02:29 2009
From: bikramjeet.singh at logiceastern.co.in (Bikramjeet Singh)
Date: Mon, 2 Nov 2009 11:32:29 +0530
Subject: [Live-devel] Application to save multicast rtp video data from
	a ip camera
In-Reply-To: <707749.44427.qm@web56306.mail.re3.yahoo.com>
References: <707749.44427.qm@web56306.mail.re3.yahoo.com>
Message-ID: <8278acf00911012202t4c0e34das536eb70fa717905b@mail.gmail.com>

in which format u want to save ur stream ,
and in which format camera is multicasting.

If it is in a TS format then its quite simple,
u just filter the video or audio(in case) and split off the TS header from
every TS packet and starts save the remaining content.

It will gives u the video file. u can view later on.

On Mon, Nov 2, 2009 at 10:43 AM, rajesh nair <rajesh_gnair at yahoo.com> wrote:

> Hi,
> I would like to develop an application to save video data from a IP camera
> which multicasts the data using rtp. Can anyone guide me to the right source
> code library in live555 using which I can develop the same
> Thanks in advance
> Rajesh
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>


-- 
Thanks and Regards
Bikramjeet singh

Logic Eastern India Private Limited
B-2, Sec- 31, Noida
http: www.logiceastern.com
Phone: +0120-2455112
ext: 212
Mobile +919971030527
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091102/1a62124c/attachment.html>

From rajesh_gnair at yahoo.com  Sun Nov  1 22:34:00 2009
From: rajesh_gnair at yahoo.com (rajesh nair)
Date: Sun, 1 Nov 2009 22:34:00 -0800 (PST)
Subject: [Live-devel] Application to save multicast rtp video data from
	a ip camera
In-Reply-To: <8278acf00911012202t4c0e34das536eb70fa717905b@mail.gmail.com>
Message-ID: <553423.84971.qm@web56306.mail.re3.yahoo.com>

Thank you Mr.Singh.
Its mpeg4 data and I would like to save it in m4v format
Let me try on the lines you mentioned
Rajesh

--- On Mon, 11/2/09, Bikramjeet Singh <bikramjeet.singh at logiceastern.co.in> wrote:


From: Bikramjeet Singh <bikramjeet.singh at logiceastern.co.in>
Subject: Re: [Live-devel] Application to save multicast rtp video data from a ip camera
To: "LIVE555 Streaming Media - development & use" <live-devel at ns.live555.com>
Date: Monday, November 2, 2009, 11:32 AM


in which format u want to save ur stream , 
and in which format camera is multicasting.

If it is in a TS format then its quite simple, 
u just filter the video or audio(in case) and split off the TS header from every TS packet and starts save the remaining content.

It will gives u the video file. u can view later on.


On Mon, Nov 2, 2009 at 10:43 AM, rajesh nair <rajesh_gnair at yahoo.com> wrote:






Hi,
I would like to develop an application to save?video data from a IP camera which multicasts the data using rtp. Can anyone guide me to the right source code library in live555 using which I can develop the same
Thanks in advance
Rajesh

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




-- 
Thanks and Regards
Bikramjeet singh

Logic Eastern India Private Limited
B-2, Sec- 31, Noida
http: www.logiceastern.com
Phone: +0120-2455112
ext: 212
Mobile +919971030527

-----Inline Attachment Follows-----


_______________________________________________
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/20091101/151b40c6/attachment.html>

From guillaume.grimaldi at c-s.fr  Mon Nov  2 00:25:01 2009
From: guillaume.grimaldi at c-s.fr (Guillaume Grimaldi)
Date: Mon, 02 Nov 2009 09:25:01 +0100
Subject: [Live-devel] [live-devel] query
In-Reply-To: <4AEABF30.5010103@c-s.fr>
References: <4AEAAC09.7030806@c-s.fr>	<f06240800c7106101dda5@[66.80.62.44]>	<4AEAB1C5.1070503@c-s.fr>	<f06240800c710649eb65f@[66.80.62.44]>	<4AEAB8DD.8080701@c-s.fr>
	<f06240801c7106af69e8a@[66.80.62.44]> <4AEABF30.5010103@c-s.fr>
Message-ID: <4AEE975D.2050300@c-s.fr>

Guillaume Grimaldi a ?crit :
> Ross Finlayson a ?crit :
>>>>> My camera generate raw format, but I plan to use H264.
>>>>
>>>>
>>>> OK, so you first need a (hardware or software) H.264 video encoder.
>>>>
>>>> Then, you will need to write your own subclass of 
>>>> "H264VideoStreamFramer", and feed your H.264 NAL units into this. 
>>>> (See also <http://www.live555.com/liveMedia/faq.html#h264-streaming>)
>>>>
>>>
>>> Ok, Thank you for your advice.
>>> A last question, can I stream in MPEG-TS format after that ? (with 
>>> MPEG2TransportStreamFramer for exemple)
>>
>> No, you should stream H.264 over RTP directly, by feeding your 
>> "H264VideoStreamFramer" (subclass) into a "H264VideoRTPSink".
Hi, I repost my question if someone has an answer.

What can I do to stream H264 in MPEG-TS format with LiveMedia ? Maybe I 
can not do that.
My problem is I have RAW video frames from my camera and I would like to 
use software solution to compress and stream video. So I planned to use 
ffmpeg to compress in H264 and liveMedia to stream in MPEG-TS. Is it 
possible ?
But if I understand well, liveMedia does not allow me to change format, 
just to stream the input video. Is it right ?

Thank you for your advice.

From finlayson at live555.com  Mon Nov  2 00:35:03 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 2 Nov 2009 00:35:03 -0800
Subject: [Live-devel] [live-devel] query
In-Reply-To: <4AEE975D.2050300@c-s.fr>
References: <4AEAAC09.7030806@c-s.fr>
	<f06240800c7106101dda5@[66.80.62.44]>	<4AEAB1C5.1070503@c-s.fr>
	<f06240800c710649eb65f@[66.80.62.44]>	<4AEAB8DD.8080701@c-s.fr>
	<f06240801c7106af69e8a@[66.80.62.44]> <4AEABF30.5010103@c-s.fr>
	<4AEE975D.2050300@c-s.fr>
Message-ID: <f06240804c71449de40ee@[66.80.62.44]>

>What can I do to stream H264 in MPEG-TS format with LiveMedia ?

We don't currently support this.  Sorry.

Instead, you should stream the H.264 video directly in RTP (using the 
"H264VideoStreamFramer" and "H264VideoRTPSink" classes, as described 
earlier)
-- 

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

From guillaume.grimaldi at c-s.fr  Mon Nov  2 01:10:21 2009
From: guillaume.grimaldi at c-s.fr (Guillaume Grimaldi)
Date: Mon, 02 Nov 2009 10:10:21 +0100
Subject: [Live-devel] [live-devel] query
In-Reply-To: <f06240804c71449de40ee@[66.80.62.44]>
References: <4AEAAC09.7030806@c-s.fr>	<f06240800c7106101dda5@[66.80.62.44]>	<4AEAB1C5.1070503@c-s.fr>	<f06240800c710649eb65f@[66.80.62.44]>	<4AEAB8DD.8080701@c-s.fr>	<f06240801c7106af69e8a@[66.80.62.44]>
	<4AEABF30.5010103@c-s.fr>	<4AEE975D.2050300@c-s.fr>
	<f06240804c71449de40ee@[66.80.62.44]>
Message-ID: <4AEEA1FD.3000005@c-s.fr>

Ross Finlayson a ?crit :
>> What can I do to stream H264 in MPEG-TS format with LiveMedia ?
>
> We don't currently support this.  Sorry.
>
> Instead, you should stream the H.264 video directly in RTP (using the 
> "H264VideoStreamFramer" and "H264VideoRTPSink" classes, as described 
> earlier)
You said you don't support H264 + MPEG-TS, but you support H264.
"MPEG2TransportStream" is included in many class name, so can I not 
stream in MPEG-TS ? Maybe I can do this but not with H264.
Sorry to insist but I must to be fixed.

From finlayson at live555.com  Mon Nov  2 01:18:03 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 2 Nov 2009 01:18:03 -0800
Subject: [Live-devel] [live-devel] query
In-Reply-To: <4AEEA1FD.3000005@c-s.fr>
References: <4AEAAC09.7030806@c-s.fr>
	<f06240800c7106101dda5@[66.80.62.44]>	<4AEAB1C5.1070503@c-s.fr>
	<f06240800c710649eb65f@[66.80.62.44]>	<4AEAB8DD.8080701@c-s.fr>
	<f06240801c7106af69e8a@[66.80.62.44]>	<4AEABF30.5010103@c-s.fr>
	<4AEE975D.2050300@c-s.fr>	<f06240804c71449de40ee@[66.80.62.44]>
	<4AEEA1FD.3000005@c-s.fr>
Message-ID: <f06240805c714534374c0@[66.80.62.44]>

>You said you don't support H264 + MPEG-TS, but you support H264.
>"MPEG2TransportStream" is included in many class name, so can I not 
>stream in MPEG-TS ? Maybe I can do this but not with H264.

That's right - we support multiplexing MPEG-1 or 2 video (along with 
MPEG-1 or 2 audio) into a Transport Stream - but not H.264 video.

If you want to stream H.264 video in RTP, then you should do this 
directly (rather than by multiplexing it into a Transport Stream 
first).

(This will be my (and your) last posting on this topic!)
-- 

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

From raj.ece03 at gmail.com  Mon Nov  2 02:37:14 2009
From: raj.ece03 at gmail.com (RAJ KUMAR)
Date: Mon, 2 Nov 2009 16:07:14 +0530
Subject: [Live-devel] Fwd: Reg:liveMedia
In-Reply-To: <mailman.3060.1257157914.870.live-devel@lists.live555.com>
References: <mailman.3060.1257157914.870.live-devel@lists.live555.com>
Message-ID: <b9cec1680911020237x7332ea96wc4331bfa9d4b2046@mail.gmail.com>

Hi All,

 I am working on ffplay ,right now i'd like to modify  the ffplay code to
support liveMedia library can any one please help me how to proceed . I
suspect to change in rtsp.c (which is there in ffplay/libavformat) is it
right?? please give some idea to proceed


Thanks in Advance.

-- 
    With Best Regards,

    Raj

    "Words carry power. Speak words that bring healing and give life"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091102/e2005a2e/attachment.html>

From dliu.cn at gmail.com  Mon Nov  2 16:54:29 2009
From: dliu.cn at gmail.com (Dong Liu)
Date: Mon, 02 Nov 2009 19:54:29 -0500
Subject: [Live-devel] Stop/restart RTP source
Message-ID: <4AEF7F45.6020109@gmail.com>

Hi,

In my project I need to stop and restart receving RTP stream. I'm using the 
following code to do these,

start and restart is the same,

mySink->startPlaying(theRtpSource, afterPlayFun, NULL);
watchVariable=0;
pScheduler->doEventLoop(&watchVariable);

For stop

mySink->stopPlaying();
watchVariable=1; // to terminate event loop

It is kind of working, but the presentation in the function 
afterGettingFrame is off. It actually jumped back in time comparing to the 
presentation time just before stopPlaying was called.

After went through some code, I found I can do,

theRtpSource.receptionStatsDB().removeRecord(theRtpSource.getLastReceivedSSRC())

This seemd fix the presentation problem. But video still seems delayed for.

Am I doing the right thing when doing stop and start the RTP stream? Is 
there anything I'm missing.

Thanks!

Dong

From finlayson at live555.com  Mon Nov  2 19:04:58 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 2 Nov 2009 19:04:58 -0800
Subject: [Live-devel] Stop/restart RTP source
In-Reply-To: <4AEF7F45.6020109@gmail.com>
References: <4AEF7F45.6020109@gmail.com>
Message-ID: <f06240801c7154d5639e0@[66.80.62.44]>

>Am I doing the right thing when doing stop and start the RTP stream?

I think so.  But what are you using for your server?  I *think* our 
RTP/RTCP server implementation will handle this correctly (because 
RTCP packets should continue to get sent even after the stream is 
stopped).  But other implementations might not handle this properly.
-- 

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

From dliu.cn at gmail.com  Tue Nov  3 05:49:36 2009
From: dliu.cn at gmail.com (Dong Liu)
Date: Tue, 03 Nov 2009 08:49:36 -0500
Subject: [Live-devel] Stop/restart RTP source
In-Reply-To: <f06240801c7154d5639e0@[66.80.62.44]>
References: <4AEF7F45.6020109@gmail.com> <f06240801c7154d5639e0@[66.80.62.44]>
Message-ID: <4AF034F0.3000908@gmail.com>

Ross Finlayson wrote:
>> Am I doing the right thing when doing stop and start the RTP stream?
> 
> I think so.  But what are you using for your server?  I *think* our 
> RTP/RTCP server implementation will handle this correctly (because RTCP 
> packets should continue to get sent even after the stream is stopped).  
> But other implementations might not handle this properly.

I'm using a real time encoder. The encoder is not a RTSP server, I'm using 
a SDP file to connect to it. So I have no way to tell the encoder to stop.

But I have two questions, first should removing the all the stats from the 
stats db in RTPSource.cpp been down when we call stopPlaying()? Second 
because I'm not calling doEventLoop(), how the RTCP packets are sent?

Thanks,

Dong

From tsahi at vicon.co.il  Tue Nov  3 07:19:59 2009
From: tsahi at vicon.co.il (Tsahi Etziony)
Date: Tue, 3 Nov 2009 17:19:59 +0200
Subject: [Live-devel] how to send RTX header extension?
Message-ID: <009001ca5c99$1bd5f980$5381ec80$@co.il>

I am using the wis-streamer to send h.264 frames over rtp/rtsp, and testing
it by watching the stream with VLC player.
I wanted to add RTP header extension to the RTP packets, and I have some
problems.
 
I have  RTPSink class that inherits from the MultiFramedRTPSink class, and I
implemented the following two virtual functions:
-          doSpecialFrameHandling() - it adds words to the special header
(which I understood it is the RTP header extension), and then calls the
original doSpecialFrameHandling() function.
-          specialHeaderSize() - it returns the size of the special header
in 32bit words.
 
the first problem I have is that I didn't find any section of the code that
turns on the 'header extension exists' bit in the RTP header. I added it
manually in buildAndSendPacket() function.
 
The second problem I have is that now that the packets are sent with the
extension (according to a network sniffer), the VLC player displays bad
video. 
 
I have a few questions:
1.       is the special header equivalent to the header extension?
2.       Where is the 'header extension exists' bit in the RTP header being
turned on?
3.       What did I forget? What am I doing wrong?
 
Thanks
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091103/c0c929a9/attachment-0001.html>

From Norbert.Donath at keynote-sigos.com  Tue Nov  3 08:52:02 2009
From: Norbert.Donath at keynote-sigos.com (Norbert Donath)
Date: Tue, 3 Nov 2009 17:52:02 +0100
Subject: [Live-devel] Question about 3GPP adaptive streaming
Message-ID: <20091103165159.GA24157@sigoslx204.sigos.de>

Hi Ross,

I have a question about your to-do list. We are using openRTSP in our
mobile network test system and now we have a request about adaptive
streaming which 3GPP included in release 6 (3GPP 26.234).

A quick search in the library source code showed that it is probably
not supported now. As there is also nothing on the to-do list I would
guess that you are not working on this. Is this correct?



Best Regards,
Norbert Donath



-- 
20 years - Keynote SIGOS GmbH -
1989 - 2009

Visit us at:
GSMA Asia Pacific Fraud Forum #18
18th - 19th November 2009
Kuala Lumpur, Malaysia

Keynote SIGOS GmbH
 - TESTING IS OUR COMPETENCE -
Klingenhofstrasse 50d
D-90411 Nuernberg
Fon +49 911 95168-0
www.keynote-sigos.com

HRB 9323 Nuernberg
Gerichtsstand: Nuernberg
Geschaeftsfuehrer: Adil Kaya, Martin Loehlein, Umang Gupta, Andrew Hamer

From amit.yedidia at elbitsystems.com  Tue Nov  3 09:10:12 2009
From: amit.yedidia at elbitsystems.com (Yedidia Amit)
Date: Tue, 3 Nov 2009 19:10:12 +0200
Subject: [Live-devel] how to send RTX header extension?
In-Reply-To: <009001ca5c99$1bd5f980$5381ec80$@co.il>
Message-ID: <49B2D30CB72A5A44BCCAFB026702837805C489@mailesl5.esl.corp.elbit.co.il>

1. not really, but you can use it for that purpose (like I did)
2. I am adding few template for function of MyVideoRTPSink which is
derived from H264videoRTPSink but with extension support
3. make sure that your extension header is according to the standard 
4. make sure that you are working with new VLC version (0.9 and up)
 
MyVideoRTPSink::specialHeaderSize() {
    //return the extension header size
}
 
Boolean MyVideoRTPSink::continuePlaying() {
 // First, check whether we have a 'fragmenter' class set up yet.
 // If not, create it now:
 if (fOurFragmenter == NULL) {
  fOurFragmenter = new H264FUAFragmenter(envir(), fSource,
OutPacketBuffer::maxSize,
   ourMaxPacketSize() - 12/*RTP hdr size*/ -
MY_MAX_EXTENSION_SIZE/*youre header extension size*/);
  fSource = fOurFragmenter;
 }
 
 // Then call the parent class's implementation:
 return MultiFramedRTPSink::continuePlaying();
}
 
 
/**
 * do two things
 * 1. exactly what H264videoRTPSink
 * 2. adding extension 
 */
void MyVideoRTPSink::doSpecialFrameHandling(unsigned
fragmentationOffset, unsigned char* frameStart, unsigned
numBytesInFrame, struct timeval frameTimestamp, unsigned
numRemainingBytes){
 
 // Set the RTP 'M' (marker) bit iff
 // 1/ The most recently delivered fragment was the end of
 //    (or the only fragment of) an NAL unit, and
 // 2/ This NAL unit was the last NAL unit of an 'access unit' (i.e.
video frame).
 if (fOurFragmenter != NULL) {
  H264VideoStreamFramer* framerSource
   = (H264VideoStreamFramer*)(fOurFragmenter->inputSource());
  // This relies on our fragmenter's source being a
"MPEG4VideoStreamFramer".
  if (fOurFragmenter->lastFragmentCompletedNALUnit()
   && framerSource != NULL &&
framerSource->currentNALUnitEndsAccessUnit()) {
    setMarkerBit();
  }
 
 }
 
 setTimestamp(frameTimestamp);
 
 //adding the telemetry;
  if (fOurFragmenter != NULL) {
  DveH264VideoStreamDiscreteFramer* framerSource
   = (DveH264VideoStreamDiscreteFramer*)(fOurFragmenter->inputSource());
  
   
   
  if (/* you want to ad the extension now){
    unsigned char*  ptrExt = /* pointer to your extension structure*/;
    int size = /*size of your extension structure*/

   setSpecialHeaderBytes(ptrExt ,size);
   setExtensionBit();
  }
 }
  
 

________________________________

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Tsahi Etziony
Sent: Tuesday, November 03, 2009 5:20 PM
To: live-devel at ns.live555.com
Subject: [Live-devel] how to send RTX header extension?


I am using the wis-streamer to send h.264 frames over rtp/rtsp, and
testing it by watching the stream with VLC player.
I wanted to add RTP header extension to the RTP packets, and I have some
problems.
 
I have  RTPSink class that inherits from the MultiFramedRTPSink class,
and I implemented the following two virtual functions:
-          doSpecialFrameHandling() - it adds words to the special
header (which I understood it is the RTP header extension), and then
calls the original doSpecialFrameHandling() function.
-          specialHeaderSize() - it returns the size of the special
header in 32bit words.
 
the first problem I have is that I didn't find any section of the code
that turns on the 'header extension exists' bit in the RTP header. I
added it manually in buildAndSendPacket() function.
 
The second problem I have is that now that the packets are sent with the
extension (according to a network sniffer), the VLC player displays bad
video. 
 
I have a few questions:
1.       is the special header equivalent to the header extension? 
  
2.       Where is the 'header extension exists' bit in the RTP header
being turned on?
3.       What did I forget? What am I doing wrong?
 
Thanks
 

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/20091103/a6ffa693/attachment-0001.html>

From finlayson at live555.com  Tue Nov  3 22:12:35 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 3 Nov 2009 22:12:35 -0800
Subject: [Live-devel] how to send RTX header extension?
In-Reply-To: <009001ca5c99$1bd5f980$5381ec80$@co.il>
References: <009001ca5c99$1bd5f980$5381ec80$@co.il>
Message-ID: <f06240806c716cacbeb3c@[66.80.62.44]>

>I have  RTPSink class that inherits from the MultiFramedRTPSink 
>class, and I implemented the following two virtual functions:
>-          doSpecialFrameHandling() - it adds words to the special 
>header (which I understood it is the RTP header extension)

Actually, no.  The "special header" here is a payload-format-specific 
header that appears at the start of the RTP payload.  It is *not* the 
"RTP header extension".  We currently don't implement this.


>the first problem I have is that I didn't find any section of the 
>code that turns on the 'header extension exists' bit in the RTP 
>header. I added it manually in buildAndSendPacket() function.

Yes, for now you will need to modify the code to support (sending and 
receiving the RTP header extension, because we don't yet support it 
in the supplied code.

>  The second problem I have is that now that the packets are sent 
>with the extension (according to a network sniffer), the VLC player 
>displays bad video.

I don't know why this would happen, because VLC uses our code to 
receive RTP packets, and our code simply ignores (i.e, skips over) 
RTP header extensions.
-- 

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

From finlayson at live555.com  Tue Nov  3 23:19:27 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 3 Nov 2009 23:19:27 -0800
Subject: [Live-devel] Question about 3GPP adaptive streaming
In-Reply-To: <20091103165159.GA24157@sigoslx204.sigos.de>
References: <20091103165159.GA24157@sigoslx204.sigos.de>
Message-ID: <f06240802c716db4eca0f@[66.80.62.44]>

>I have a question about your to-do list. We are using openRTSP in our
>mobile network test system and now we have a request about adaptive
>streaming which 3GPP included in release 6 (3GPP 26.234).

Which Internet Standard document (i.e., a public IETF RFC or 
Internet-Draft) describes this?
-- 

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

From matteo.trotti at elsagdatamat.com  Wed Nov  4 06:10:09 2009
From: matteo.trotti at elsagdatamat.com (Trotti Matteo)
Date: Wed, 4 Nov 2009 15:10:09 +0100
Subject: [Live-devel] rtsp/rtp port management
Message-ID: <CE2B64DA80D5F940882BE3F02B2D12320236836E@GRPGEPWMX0012.grptop.net>

Hi guys,

I am building a streaming server and I am using liveMedia code to manage
the core part  of rtsp/rtp transmission.

I will have multiple clients requesting media to server, and each client
is able to get more than one streams at a time, 

so I am trying to figure out how to manage (server side) rtsp/rtp
connections.

For each file that I want to stream at the same time, I set up a rtsp
session with unique server port number and name. 

Then server will start streaming to client via rtp. 

If same client requests another video, server will start another rtsp
session with rtp transmission and another rtp destination port (previous
rtp port number +2).

When a client disconnects, rtsp port and rtp port become available again
.

Is this the right way to manage connections to a streaming server from
multiple clients?

Sorry if it looks like a newbie question,

Thanks for helping

 

Matteo Trotti

Videosurveillance Lab

Elsag Datamat Spa

Genova, Italy

 

 



"Questo messaggio ed ogni suo allegato sono confidenziali e possono essere riservati o, comunque, protetti dall'essere diffusi. Se il ricevente non ? il destinatario diretto del presente messaggio, ? pregato di contattare l'originario mittente e di cancellare questo messaggio ed ogni suo allegato dal sistema di posta. Se il ricevente non ? il destinatario diretto del presente messaggio, sono vietati l'uso, la riproduzione e la stampa di questo messaggio e di ogni suo allegato, nonch? la diffusione del loro contenuto a qualsiasi altro soggetto"
*****
"This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please contact the sender and delete this message and any attachment from your system. If you are not the intended recipient you must not use, copy or print this message or attachment or disclose the contents to any other person."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091104/c4d010d0/attachment.html>

From Norbert.Donath at keynote-sigos.com  Wed Nov  4 08:19:43 2009
From: Norbert.Donath at keynote-sigos.com (Norbert Donath)
Date: Wed, 4 Nov 2009 17:19:43 +0100
Subject: [Live-devel] Question about 3GPP adaptive streaming
In-Reply-To: <f06240802c716db4eca0f@[66.80.62.44]>
References: <20091103165159.GA24157@sigoslx204.sigos.de>
	<f06240802c716db4eca0f@[66.80.62.44]>
Message-ID: <20091104161943.GA13504@sigoslx204.sigos.de>

On Di, Nov 03, 2009 at 11:19:27 -0800, Ross Finlayson wrote:

>> I have a question about your to-do list. We are using openRTSP in our
>> mobile network test system and now we have a request about adaptive
>> streaming which 3GPP included in release 6 (3GPP 26.234).
> 
> Which Internet Standard document (i.e., a public IETF RFC or 
> Internet-Draft) describes this?

It's only specified by 3GPP, not by IETF. However, 3GPP specs are also
public standards.

If you are interested:
http://www.3gpp.org/ftp/Specs/2009-09/Rel-6/26_series/26234-6e0.zip



I will interpret your question as "no it's not on my to-do list".




Best Regards,
Norbert Donath



-- 
20 years - Keynote SIGOS GmbH -
1989 - 2009

Visit us at:
GSMA Asia Pacific Fraud Forum #18
18th - 19th November 2009
Kuala Lumpur, Malaysia

Keynote SIGOS GmbH
 - TESTING IS OUR COMPETENCE -
Klingenhofstrasse 50d
D-90411 Nuernberg
Fon +49 911 95168-0
www.keynote-sigos.com

HRB 9323 Nuernberg
Gerichtsstand: Nuernberg
Geschaeftsfuehrer: Adil Kaya, Martin Loehlein, Umang Gupta, Andrew Hamer

From finlayson at live555.com  Wed Nov  4 22:14:15 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 4 Nov 2009 22:14:15 -0800
Subject: [Live-devel] Question about 3GPP adaptive streaming
In-Reply-To: <20091104161943.GA13504@sigoslx204.sigos.de>
References: <20091103165159.GA24157@sigoslx204.sigos.de>
	<f06240802c716db4eca0f@[66.80.62.44]>
	<20091104161943.GA13504@sigoslx204.sigos.de>
Message-ID: <f06240800c7181d83cd45@[66.80.62.44]>

>If you are interested:
>http://www.3gpp.org/ftp/Specs/2009-09/Rel-6/26_series/26234-6e0.zip

Which specific part(s) of this document describes the "adaptive 
streaming" feature that you're asking about?
-- 

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

From finlayson at live555.com  Wed Nov  4 22:18:17 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 4 Nov 2009 22:18:17 -0800
Subject: [Live-devel] rtsp/rtp port management
In-Reply-To: <CE2B64DA80D5F940882BE3F02B2D12320236836E@GRPGEPWMX0012.grptop.net>
References: <CE2B64DA80D5F940882BE3F02B2D12320236836E@GRPGEPWMX0012.grptop.net>
Message-ID: <f06240801c7181df2e777@[66.80.62.44]>

>For each file that I want to stream at the same time, I set up a 
>rtsp session with unique server port number and name.
>Then server will start streaming to client via rtp.
>If same client requests another video, server will start another 
>rtsp session with rtp transmission and another rtp destination port 
>(previous rtp port number +2).
>When a client disconnects, rtsp port and rtp port become available again .

As far as I can tell, the existing code (specifically, the 
implementation of the "OnDemandServerMediaSubsession" class) already 
does exactly what you are asking for.

Why do you feel that you need to write new code, when our existing 
RTSP server implementation already works?
-- 

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

From luo_isaiah at qq.com  Thu Nov  5 01:04:39 2009
From: luo_isaiah at qq.com (=?gbk?B?wt7S+te/?=)
Date: Thu, 5 Nov 2009 17:04:39 +0800
Subject: [Live-devel] Question About The Macro IMN_PIM
Message-ID: <tencent_001FEB377DAF30D528D0E951@qq.com>

Hi Ross,
     I have a question about the macro "IMN_PIM". I see it in the file "NetCommon.h" and etc. But they only judge whether the macro "IMN_PIM" had been defined. And my question is where did this macro "IMN_PIM" come from. What's the use of this macro, eg. to distinguish the OS between Windows and Linux, or other uses? And another question is where could I find the file "IMN_PIMNetCommon.h", because I didn't find it in the "live" folder and subfolders, which is extracted from the file "live.2009.09.28.tar.tar". Thank you!
     Best regards,
     Isaiah Luo
     Nov. 5th, 2009
  
  ------------------
  Wish the God gives you his joy and peace!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091105/5886b8e5/attachment.html>

From matteo.trotti at elsagdatamat.com  Thu Nov  5 01:30:49 2009
From: matteo.trotti at elsagdatamat.com (Trotti Matteo)
Date: Thu, 5 Nov 2009 10:30:49 +0100
Subject: [Live-devel] R:  rtsp/rtp port management
In-Reply-To: <f06240801c7181df2e777@[66.80.62.44]>
References: <CE2B64DA80D5F940882BE3F02B2D12320236836E@GRPGEPWMX0012.grptop.net>
	<f06240801c7181df2e777@[66.80.62.44]>
Message-ID: <CE2B64DA80D5F940882BE3F02B2D123202368CCA@GRPGEPWMX0012.grptop.net>

Thank you for your answer Ross,
you are right I wrote exactly to know where I had to write new code and where existing code was enough already.
My goal is to build a server (windows platform) which streams mp4/h264 files to multiple clients, with seeking and other common trickplay capabilities: as far as I understood, to do that I have to write new code because existing live555 vod server implementation doesn't fully support mp4/h264 (anyway, live555 is a really great product!).

Matteo Trotti
Videosurveillance Lab
Elsag Datamat Spa
Genova, Italy

-----Messaggio originale-----
Da: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Per conto di Ross Finlayson
Inviato: gioved? 5 novembre 2009 7.18
A: LIVE555 Streaming Media - development & use
Oggetto: Re: [Live-devel] rtsp/rtp port management

>For each file that I want to stream at the same time, I set up a 
>rtsp session with unique server port number and name.
>Then server will start streaming to client via rtp.
>If same client requests another video, server will start another 
>rtsp session with rtp transmission and another rtp destination port 
>(previous rtp port number +2).
>When a client disconnects, rtsp port and rtp port become available again .

As far as I can tell, the existing code (specifically, the 
implementation of the "OnDemandServerMediaSubsession" class) already 
does exactly what you are asking for.

Why do you feel that you need to write new code, when our existing 
RTSP server implementation already works?
-- 

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


"Questo messaggio ed ogni suo allegato sono confidenziali e possono essere riservati o, comunque, protetti dall'essere diffusi. Se il ricevente non ? il destinatario diretto del presente messaggio, ? pregato di contattare l'originario mittente e di cancellare questo messaggio ed ogni suo allegato dal sistema di posta. Se il ricevente non ? il destinatario diretto del presente messaggio, sono vietati l'uso, la riproduzione e la stampa di questo messaggio e di ogni suo allegato, nonch? la diffusione del loro contenuto a qualsiasi altro soggetto"
*****
"This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please contact the sender and delete this message and any attachment from your system. If you are not the intended recipient you must not use, copy or print this message or attachment or disclose the contents to any other person."

From finlayson at live555.com  Thu Nov  5 01:34:55 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 5 Nov 2009 01:34:55 -0800
Subject: [Live-devel] Question About The Macro IMN_PIM
In-Reply-To: <tencent_001FEB377DAF30D528D0E951@qq.com>
References: <tencent_001FEB377DAF30D528D0E951@qq.com>
Message-ID: <f06240800c7184c323f5b@[66.80.62.44]>

>     I have a question about the macro "IMN_PIM". I see it in the 
>file "NetCommon.h" and etc. But they only judge whether the macro 
>"IMN_PIM" had been defined. And my question is where did this macro 
>"IMN_PIM" come from.

We used it - several years ago - to help support a customer's 
specialized hardware.  It can be completely ignored (and will be 
removed from some future version of the code, because it's completely 
useless now).
-- 

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

From Norbert.Donath at keynote-sigos.com  Thu Nov  5 04:08:19 2009
From: Norbert.Donath at keynote-sigos.com (Norbert Donath)
Date: Thu, 5 Nov 2009 13:08:19 +0100
Subject: [Live-devel] Question about 3GPP adaptive streaming
In-Reply-To: <f06240800c7181d83cd45@[66.80.62.44]>
References: <20091103165159.GA24157@sigoslx204.sigos.de>
	<f06240802c716db4eca0f@[66.80.62.44]>
	<20091104161943.GA13504@sigoslx204.sigos.de>
	<f06240800c7181d83cd45@[66.80.62.44]>
Message-ID: <20091105120818.GA16170@sigoslx204.sigos.de>

On Mi, Nov 04, 2009 at 10:14:15 -0800, Ross Finlayson wrote:
> >If you are interested:
> >http://www.3gpp.org/ftp/Specs/2009-09/Rel-6/26_series/26234-6e0.zip
> 
> Which specific part(s) of this document describes the "adaptive 
> streaming" feature that you're asking about?

Chapters 5 and 6 and probably the examples in annex A. For a client
implementation you can skip over almost all text in chapter 5.2. A
client would have to give a X-Wap-Profile header with a URI to an XML
file as specified in this chapter. So most important are the chapters
5.3 and 6 (excluding 6.3).

The idea is to extend the RTCP RR in order to give the server
additional information about the remaining data in the client
buffers. With this information the server can react with reducing the
data rate of one or all subsessions before the client runs out of
packets in case the data rate of a radio bearer is decreasing.



Regards,
Norbert Donath


-- 
20 years - Keynote SIGOS GmbH -
1989 - 2009

Visit us at:
GSMA Asia Pacific Fraud Forum #18
18th - 19th November 2009
Kuala Lumpur, Malaysia

Keynote SIGOS GmbH
 - TESTING IS OUR COMPETENCE -
Klingenhofstrasse 50d
D-90411 Nuernberg
Fon +49 911 95168-0
www.keynote-sigos.com

HRB 9323 Nuernberg
Gerichtsstand: Nuernberg
Geschaeftsfuehrer: Adil Kaya, Martin Loehlein, Umang Gupta, Andrew Hamer

From rajeshawate2001 at gmail.com  Thu Nov  5 05:23:42 2009
From: rajeshawate2001 at gmail.com (RAJESH AWATE)
Date: Thu, 5 Nov 2009 18:53:42 +0530
Subject: [Live-devel] MPEG4 dynamic live streaming
Message-ID: <ef6f1bad0911050523x2b0fe52cm3874cf4e46399bbf@mail.gmail.com>

hi
i m using Live555 tool testMPEG4VideoStreamer.exe for streaming from a file.
But i want to use it now read data from some dyanamic thing instead of from
static local file(e.g. some port).
Please guide me with respect to my query...

Thanking You,

Rajesh Awate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091105/b5d15d08/attachment.html>

From finlayson at live555.com  Thu Nov  5 18:54:05 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 5 Nov 2009 18:54:05 -0800
Subject: [Live-devel] MPEG4 dynamic live streaming
In-Reply-To: <ef6f1bad0911050523x2b0fe52cm3874cf4e46399bbf@mail.gmail.com>
References: <ef6f1bad0911050523x2b0fe52cm3874cf4e46399bbf@mail.gmail.com>
Message-ID: <f06240803c7193f38dd26@[66.80.62.44]>

>i m using Live555 tool testMPEG4VideoStreamer.exe for streaming from a file.
>But i want to use it now read data from some dyanamic thing instead 
>of from static local file(e.g. some port).

If your input device is named in the file system (e.g., 
"/dev/something"), then you can just use the same code as before; 
just change the variable "inputFileName".

If your input device is not named in the file system, but you have 
(or can create) an open file (i.e., a "FILE*") for it, then simply 
use this "FILE*" instead of the file name in the call to 
"ByteStreamFileSource::createNew()".

Also, see <http://www.live555.com/liveMedia/faq.html#liveInput>
-- 

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

From daqingzd at gmail.com  Thu Nov  5 20:06:23 2009
From: daqingzd at gmail.com (=?GB2312?B?1cW088fs?=)
Date: Fri, 6 Nov 2009 12:06:23 +0800
Subject: [Live-devel] Can live555MediaServer.exe run on win2003 r2 sp2
Message-ID: <56f487690911052006w4481a43fw3664e4f98812e15e@mail.gmail.com>

Hi erveryone,

I meet a big problem,can anyone help me? :)

When I try to run the live555MediaServer.exe on win2003 r2 sp2, I found the
RTSP client to play the video very bad, I think may the packet is lost.


After I investigate the problem, I found maybe the *Asynchronous Transfer
mode network on win2003* is the reason.

And is there anyone know how to run the live555 on the win2003 r2?

article from microsoft maybe help you.
http://technet.microsoft.com/en-us/library/cc756793(WS.10).aspx#w2k3tr_atm_how_rrjp

and other mail from live555 maillist
http://lists.live555.com/pipermail/live-devel/2007-April/006636.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091106/304c4406/attachment.html>

From bikramjeet.singh at logiceastern.co.in  Thu Nov  5 21:24:28 2009
From: bikramjeet.singh at logiceastern.co.in (Bikramjeet Singh)
Date: Fri, 6 Nov 2009 10:54:28 +0530
Subject: [Live-devel] MPEG4 dynamic live streaming
In-Reply-To: <f06240803c7193f38dd26@66.80.62.44>
References: <ef6f1bad0911050523x2b0fe52cm3874cf4e46399bbf@mail.gmail.com>
	<f06240803c7193f38dd26@66.80.62.44>
Message-ID: <8278acf00911052124r502159c0labff4357365b574b@mail.gmail.com>

I think u should go with "MPEG Relay" application. It recieves a multicast
stream from a IP:Port and retransmit it on some another IP:Port.

On Fri, Nov 6, 2009 at 8:24 AM, Ross Finlayson <finlayson at live555.com>wrote:

> i m using Live555 tool testMPEG4VideoStreamer.exe for streaming from a
>> file.
>> But i want to use it now read data from some dyanamic thing instead of
>> from static local file(e.g. some port).
>>
>
> If your input device is named in the file system (e.g., "/dev/something"),
> then you can just use the same code as before; just change the variable
> "inputFileName".
>
> If your input device is not named in the file system, but you have (or can
> create) an open file (i.e., a "FILE*") for it, then simply use this "FILE*"
> instead of the file name in the call to "ByteStreamFileSource::createNew()".
>
> Also, see <http://www.live555.com/liveMedia/faq.html#liveInput>
> --
>
> 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
>



-- 
Thanks and Regards
Bikramjeet singh

Logic Eastern India Private Limited
B-2, Sec- 31, Noida
http: www.logiceastern.com
Phone: +0120-2455112
ext: 212
Mobile +919971030527
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091106/248d2b49/attachment.html>

From rajeshawate2001 at gmail.com  Thu Nov  5 23:41:22 2009
From: rajeshawate2001 at gmail.com (RAJESH AWATE)
Date: Fri, 6 Nov 2009 13:11:22 +0530
Subject: [Live-devel] Need more clarification about
	testMPEG4VideoStreamer.exe application.
Message-ID: <ef6f1bad0911052341u6fb12657heb251b34c5d1ba03@mail.gmail.com>

Hello All,
Firstly thank you Ross & Bikramjeet for your reply.

I just want some more clarification from you on testMPEG4VideoStreamer.exe
application. This application reads the input from test.m4e file and stream
the data.
But my requirement is, continous data is coming over some muticast address
and stream it using this application. Is it possible to customize this test
application
to read data from muticast address and stream it.
My development enviornment is Windows.
FYI, my data is coming over some muticast address, so there is no hardware
input device connected to machine.
Can you please elaborate the following point,
"
If your input device is not named in the file system, but you have (or can
create) an open file (i.e., a "FILE*") for it, then simply use this "FILE*"
instead of the file name in the call to "ByteStreamFileSource::createNew()".
"
Is it possible to create "FILE*" for incoming data over multicast address?,
so that I can use the same in testMPEG4VideoStreamer.exe.

Is there any other testPrograms/Utility available in Live555 which will help
me to achieve this task.

Thanks and appreciate your response,
Rajesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091106/37e679b3/attachment.html>

From bikramjeet.singh at logiceastern.co.in  Fri Nov  6 00:16:44 2009
From: bikramjeet.singh at logiceastern.co.in (Bikramjeet Singh)
Date: Fri, 6 Nov 2009 13:46:44 +0530
Subject: [Live-devel] Need more clarification about
	testMPEG4VideoStreamer.exe application.
In-Reply-To: <ef6f1bad0911052341u6fb12657heb251b34c5d1ba03@mail.gmail.com>
References: <ef6f1bad0911052341u6fb12657heb251b34c5d1ba03@mail.gmail.com>
Message-ID: <8278acf00911060016l448b6c6eh30df9a6d46787acb@mail.gmail.com>

As i have mentioned in the last thread....
just check out the "testRelay.exe"  this is the exectly u want. even u dont
need to change the code. It exactly matches ur requirement.

And nxt time post ur counter reply in the same thread.



On Fri, Nov 6, 2009 at 1:11 PM, RAJESH AWATE <rajeshawate2001 at gmail.com>wrote:

> Hello All,
> Firstly thank you Ross & Bikramjeet for your reply.
>
> I just want some more clarification from you on testMPEG4VideoStreamer.exe
> application. This application reads the input from test.m4e file and stream
> the data.
> But my requirement is, continous data is coming over some muticast address
> and stream it using this application. Is it possible to customize this test
> application
> to read data from muticast address and stream it.
> My development enviornment is Windows.
> FYI, my data is coming over some muticast address, so there is no hardware
> input device connected to machine.
> Can you please elaborate the following point,
> "
> If your input device is not named in the file system, but you have (or can
> create) an open file (i.e., a "FILE*") for it, then simply use this "FILE*"
> instead of the file name in the call to "ByteStreamFileSource::createNew()".
> "
> Is it possible to create "FILE*" for incoming data over multicast address?,
> so that I can use the same in testMPEG4VideoStreamer.exe.
>
> Is there any other testPrograms/Utility available in Live555 which will
> help me to achieve this task.
>
> Thanks and appreciate your response,
> Rajesh
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>


-- 
Thanks and Regards
Bikramjeet singh

Logic Eastern India Private Limited
B-2, Sec- 31, Noida
http: www.logiceastern.com
Phone: +0120-2455112
ext: 212
Mobile +919971030527
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091106/9606525d/attachment-0001.html>

From finlayson at live555.com  Fri Nov  6 01:18:03 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 6 Nov 2009 01:18:03 -0800
Subject: [Live-devel] MPEG4 dynamic live streaming
In-Reply-To: <8278acf00911052124r502159c0labff4357365b574b@mail.gmail.com>
References: <ef6f1bad0911050523x2b0fe52cm3874cf4e46399bbf@mail.gmail.com>
	<f06240803c7193f38dd26@66.80.62.44>
	<8278acf00911052124r502159c0labff4357365b574b@mail.gmail.com>
Message-ID: <f06240800c71999f60d3b@[66.80.62.44]>

>I think u should go with "MPEG Relay" application. It recieves a 
>multicast stream from a IP:Port and retransmit it on some another 
>IP:Port.

That will work only if the incoming multicast stream is RTP.  If, 
instead, it's raw UDP, then you can't just relay this 'as is', 
because few - if any - media player clients will be able to play it.
-- 

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

From bikramjeet.singh at logiceastern.co.in  Fri Nov  6 02:06:56 2009
From: bikramjeet.singh at logiceastern.co.in (Bikramjeet Singh)
Date: Fri, 6 Nov 2009 15:36:56 +0530
Subject: [Live-devel] MPEG4 dynamic live streaming
In-Reply-To: <f06240800c71999f60d3b@66.80.62.44>
References: <ef6f1bad0911050523x2b0fe52cm3874cf4e46399bbf@mail.gmail.com>
	<f06240803c7193f38dd26@66.80.62.44>
	<8278acf00911052124r502159c0labff4357365b574b@mail.gmail.com>
	<f06240800c71999f60d3b@66.80.62.44>
Message-ID: <8278acf00911060206h1734cde5odc3beb40de2e6d4d@mail.gmail.com>

Then u just make a simple application. In which u will open a socket and
configure it to receive a multicast stream and then resend the packets on
some another IP:Port without opening the packet content. code will not be
more than 80 lines.
To capture a multicast stream u will find a number of example on web.



On Fri, Nov 6, 2009 at 2:48 PM, Ross Finlayson <finlayson at live555.com>wrote:

> I think u should go with "MPEG Relay" application. It recieves a multicast
>> stream from a IP:Port and retransmit it on some another IP:Port.
>>
>
> That will work only if the incoming multicast stream is RTP.  If, instead,
> it's raw UDP, then you can't just relay this 'as is', because few - if any -
> media player clients will be able to play it.
>
> --
>
> 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
>



-- 
Thanks and Regards
Bikramjeet singh

Logic Eastern India Private Limited
B-2, Sec- 31, Noida
http: www.logiceastern.com
Phone: +0120-2455112
ext: 212
Mobile +919971030527
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091106/fe58675e/attachment.html>

From rajeshawate2001 at gmail.com  Fri Nov  6 05:05:42 2009
From: rajeshawate2001 at gmail.com (RAJESH AWATE)
Date: Fri, 6 Nov 2009 18:35:42 +0530
Subject: [Live-devel] Need more information on testRelay application.
Message-ID: <ef6f1bad0911060505v262a9d7eg1eb1a707acf37136@mail.gmail.com>

To all,

I am trying to use testRelay application. It is taking udp multicast stream
over some port and relaying it to some other port.
I tested this with VLC media player, and it is working ok. But this may work
on few media player. I need to stream this data for BlackBerry mobile
device, and I'm not sure will this stream work on BlackBerry device. Any
idea?
Also, I am trying to modify the test*Streamer.exe application to read data
from this udp port instead from file. For this I am using the part of code
as in testRelay.exe to read data from udp, but that code is not working as
soon as I start the process it stops.
When I applied debugger, code stops after this line

env->taskScheduler().doEventLoop(); // does not return

Am I doing it right? I just want to modify test*streamer application to
stream data, but need to read data from muticast address.
Any suggestions?

Thanks and appreciate your response,
Rajesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091106/0ed0331d/attachment.html>

From rajeshawate2001 at gmail.com  Fri Nov  6 23:17:44 2009
From: rajeshawate2001 at gmail.com (RAJESH AWATE)
Date: Sat, 7 Nov 2009 12:47:44 +0530
Subject: [Live-devel] MPEG4 dynamic live streaming
In-Reply-To: <8278acf00911060206h1734cde5odc3beb40de2e6d4d@mail.gmail.com>
References: <ef6f1bad0911050523x2b0fe52cm3874cf4e46399bbf@mail.gmail.com>
	<f06240803c7193f38dd26@66.80.62.44>
	<8278acf00911052124r502159c0labff4357365b574b@mail.gmail.com>
	<f06240800c71999f60d3b@66.80.62.44>
	<8278acf00911060206h1734cde5odc3beb40de2e6d4d@mail.gmail.com>
Message-ID: <ef6f1bad0911062317u4af98a24y48eef357649a6df0@mail.gmail.com>

Hello All,

As I said earlier, I am trying to stream continous MPEG4 Stream data coming
over some port using testMPEG4VideoStreamer.exe. But this application reads
data from test.*.
So, as per your suggstions, I find testrelay.exe which matches with my
need(at least input part i.e reading from udp port), so I copied the input
part from testRelay.exe(till getting FramedSource object) in
testMPEG4VideoStreamer.exe, like this
"
  // Then create a liveMedia 'source' object, encapsulating this groupsock:
  FramedSource* source = BasicUDPSource::createNew(*env, &inputGroupsock);
"
And I kept the remaining code in testMPEG4VideoStreamer.exe as it is.

But program stops at following line
env->taskScheduler().doEventLoop(); // does not return

Any idea what may be going wrong here?
Am I doing it correctly?

Is there any other utility/application available in Live555 which reads
continous data over some udp port and stream it.

Thanks and appreciate your response,
Rajesh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091107/4c4e8b58/attachment-0001.html>

From Sathish.Manohar at aricent.com  Mon Nov  9 22:04:40 2009
From: Sathish.Manohar at aricent.com (Sathish Kumar Manohar)
Date: Tue, 10 Nov 2009 11:34:40 +0530
Subject: [Live-devel] Queries related to Streaming MP3 clips using LIVE
	server.
Message-ID: <ABD1D03E7BEB13449FF313BB7AEFE6F3051530@GUREXMB02.ASIAN.AD.ARICENT.COM>

Hi Ross,

I have some doubts regarding the RTP Payload for MP3.

1) When I received the payload it's something like this
    00 00 00 00 ff e3 e8 .....
    The valid data starts only after 4 bytes in all the cases. Why is that so?

2) I tried streamed a clip with the following configuration
       MPEG 2.5 Layer III
       160kbps , strereo,
       Sampling Rate: 8000 hz

     In this case, the size of the Computed frame is 1440. So single frame comes in 2 RTP packets.
     The payload length in the first packet is 1436. The payload looked like this
     00 00 00 00 ff e3 e8 ....

    In the second RTP packet, the payload length was 12. And the 12 bytes looks like this
    00 00 05 98 00 00 00 00 00 00 00 00.

    Now I have to give 1440 bytes to my decoder. From the first packet the valid data starts after 4 bytes,
    So the valid data would be of size 1432 bytes. From the Second packet which 8 bytes should I give the
    decoder?. First 8 bytes or last 8 bytes.


  I have attached the ethreal logs also.  Kindly look into them and give your suggestions.
 Also let me know the general rule in handling the continuation frames,  coming in multiple RTP Packets.



Regards
Sathish Kumar M

________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091110/4d1ae220/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MP3_LiveMedia_ethreal.pcap
Type: application/octet-stream
Size: 211935 bytes
Desc: MP3_LiveMedia_ethreal.pcap
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091110/4d1ae220/attachment-0001.obj>

From achokshi9 at gmail.com  Tue Nov 10 10:38:53 2009
From: achokshi9 at gmail.com (Aakash Chokshi)
Date: Tue, 10 Nov 2009 13:38:53 -0500
Subject: [Live-devel] PS File does not work
Message-ID: <77cbcf180911101038s2dfa8aao4ec243cbb3356fdf@mail.gmail.com>

I have uploaded my test file that I am trying to get working with live55
media server. It is a sample recording of TV in 720p60 HD, stored as a
program stream.

http://rapidshare.com/files/305093667/test.mpg.html

I would appreciate some feedback as to why this particular PS is not working
(the same with other PS files I have) or a way to determine why. The file
plays back correctly in VLC, wmp (with klite), and any other player I have
tried. It does work with mp3 files.

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

From linkfanel at yahoo.fr  Tue Nov 10 16:25:17 2009
From: linkfanel at yahoo.fr (Pierre Ynard)
Date: Wed, 11 Nov 2009 01:25:17 +0100
Subject: [Live-devel] [PATCH] Fix type of too long constant
Message-ID: <20091111002517.GA11189@via.ecp.fr>

This fixes the error:

GroupsockHelper.cpp:731: error: integer constant is too large for 'long' type


diff -urp live.orig/groupsock/GroupsockHelper.cpp live/groupsock/GroupsockHelper.cpp
--- live.orig/groupsock/GroupsockHelper.cpp	2009-09-28 17:16:16.000000000 +0200
+++ live/groupsock/GroupsockHelper.cpp	2009-11-11 01:10:28.000000000 +0100
@@ -728,7 +728,7 @@ char const* timestampString() {
 int gettimeofday(struct timeval* tp, int* /*tz*/) {
 #if defined(_WIN32_WCE)
   /* FILETIME of Jan 1 1970 00:00:00. */
-  static const unsigned __int64 epoch = 116444736000000000L;
+  static const unsigned __int64 epoch = 116444736000000000LL;
 
   FILETIME    file_time;
   SYSTEMTIME  system_time;


Regards,

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

From finlayson at live555.com  Wed Nov 11 00:12:35 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 11 Nov 2009 17:12:35 +0900
Subject: [Live-devel] [PATCH] Fix type of too long constant
In-Reply-To: <20091111002517.GA11189@via.ecp.fr>
References: <20091111002517.GA11189@via.ecp.fr>
Message-ID: <f06240800c72022616363@[66.80.62.44]>

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

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

From zelalems at hotmail.com  Wed Nov 11 00:49:26 2009
From: zelalems at hotmail.com (Zelalem Sintayehu)
Date: Wed, 11 Nov 2009 11:49:26 +0300
Subject: [Live-devel] RTSP Stack
Message-ID: <BAY120-W38AEF8817370C00C27DE45CAAA0@phx.gbl>


Hi, trying to develop an rtsp proxy server and was looking for an rtsp stack. I'm completely new to Live and got confused. Which part of the application shall I use. I only want an rtsp stack, but want to have access to all the options. Like I want to change the host address and port. I don't want the play functionality. The client will do that. The proxy will be used to forward the request and response back and forth from client to server and server to client. Please anyone suggest which part of the package I should look into.

Thank you.

Best regards, 

- Zelalem S. 


 		 	   		  
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091111/a555227c/attachment.html>

From Sathish.Manohar at aricent.com  Wed Nov 11 01:07:36 2009
From: Sathish.Manohar at aricent.com (Sathish Kumar Manohar)
Date: Wed, 11 Nov 2009 14:37:36 +0530
Subject: [Live-devel] Queries related to Streaming MP3 clips using LIVE
 server.
In-Reply-To: <ABD1D03E7BEB13449FF313BB7AEFE6F3051530@GUREXMB02.ASIAN.AD.ARICENT.COM>
Message-ID: <ABD1D03E7BEB13449FF313BB7AEFE6F3061BFE@GUREXMB02.ASIAN.AD.ARICENT.COM>

One more update on this:

Moreover from the Initial 1 or 2 bytes of the payload, I am not able to find any valid ADU Descriptor Information.
Is there any problem in sending that information from the server?

________________________________
From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Sathish Kumar Manohar
Sent: Tuesday, November 10, 2009 11:35 AM
To: live-devel at lists.live555.com
Subject: [Live-devel] Queries related to Streaming MP3 clips using LIVE server.

Hi Ross,

I have some doubts regarding the RTP Payload for MP3.

1) When I received the payload it's something like this
    00 00 00 00 ff e3 e8 .....
    The valid data starts only after 4 bytes in all the cases. Why is that so?

2) I tried streamed a clip with the following configuration
       MPEG 2.5 Layer III
       160kbps , strereo,
       Sampling Rate: 8000 hz

     In this case, the size of the Computed frame is 1440. So single frame comes in 2 RTP packets.
     The payload length in the first packet is 1436. The payload looked like this
     00 00 00 00 ff e3 e8 ....

    In the second RTP packet, the payload length was 12. And the 12 bytes looks like this
    00 00 05 98 00 00 00 00 00 00 00 00.

    Now I have to give 1440 bytes to my decoder. From the first packet the valid data starts after 4 bytes,
    So the valid data would be of size 1432 bytes. From the Second packet which 8 bytes should I give the
    decoder?. First 8 bytes or last 8 bytes.


  I have attached the ethreal logs also.  Kindly look into them and give your suggestions.
 Also let me know the general rule in handling the continuation frames,  coming in multiple RTP Packets.



Regards
Sathish Kumar M

________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091111/7bc1a5c0/attachment.html>

From finlayson at live555.com  Wed Nov 11 21:17:06 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 12 Nov 2009 14:17:06 +0900
Subject: [Live-devel] RTSP Stack
In-Reply-To: <BAY120-W38AEF8817370C00C27DE45CAAA0@phx.gbl>
References: <BAY120-W38AEF8817370C00C27DE45CAAA0@phx.gbl>
Message-ID: <f06240802c7214ab64963@[66.80.62.44]>

>Hi, trying to develop an rtsp proxy server and was looking for an rtsp stack.

Sorry, but our software doesn't support RTSP proxying (at least, not 
without a lot of programming).
-- 

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

From finlayson at live555.com  Wed Nov 11 17:43:19 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 12 Nov 2009 10:43:19 +0900
Subject: [Live-devel] Queries related to Streaming MP3 clips using LIVE
 server.
In-Reply-To: <ABD1D03E7BEB13449FF313BB7AEFE6F3051530@GUREXMB02.ASIAN.AD.ARICENT.COM>
References: <ABD1D03E7BEB13449FF313BB7AEFE6F3051530@GUREXMB02.ASIAN.AD.ARICENT.COM>
Message-ID: <f06240801c721175cd9a3@[66.80.62.44]>

>I have some doubts regarding the RTP Payload for MP3.
>
>1) When I received the payload it's something like this 
>     00 00 00 00 ff e3 e8 .....
>     The valid data starts only after 4 bytes in all the cases. Why is that so?

Because these first 4 bytes are the "MPEG Audio-specific header" 
defined for the RTP payload format for MPEG-1 or 2 Elementary Stream 
audio (which includes MP3), defined in RFC 2250 (see section 3.5).

If you transmit your data using the "MPEG1or2AudioRTPSink" class, and 
receive it using the "MPEG1or2AudioRTPSource" class, then the 
inserting and removing of this header is done automatically, and you 
don't have to know or care about it.

See the code for the "testMP3Streamer" and "testMP3Receiver" for 
examples of how this is done (over multicast, in this case).
-- 

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/20091112/95f3f64c/attachment.html>

From zelalems at hotmail.com  Wed Nov 11 04:48:19 2009
From: zelalems at hotmail.com (Zelalem Sintayehu)
Date: Wed, 11 Nov 2009 15:48:19 +0300
Subject: [Live-devel]  How to install live555 on ubuntu.
In-Reply-To: <BAY120-W38AEF8817370C00C27DE45CAAA0@phx.gbl>
References: <BAY120-W38AEF8817370C00C27DE45CAAA0@phx.gbl>
Message-ID: <BAY120-W35239798A7A4FF6253831ECAAA0@phx.gbl>


Hi, I don't know if it the proper forum to ask this question. I just downloaded the live555-latest.tar.gz file and unzipped it and created a make file using genMakefile script. Then when I run the make command it failed. I got two errors, which are CC: command not found and also [rtcp_from_spec.o] error 127. I changed the C compiler from cc to gcc (which is what i have on my ubuntu hardy machine) and also for cpp compiler, i changed g++ in the conf.linux file. But without success. Could you please tell me how to install teh package in Ubuntu Hardy?

Thank you.

Best regards,

- Zelalem S. 


 		 	   		  
_________________________________________________________________
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091111/025cede7/attachment.html>

From linkfanel at yahoo.fr  Wed Nov 11 21:14:24 2009
From: linkfanel at yahoo.fr (Pierre Ynard)
Date: Thu, 12 Nov 2009 06:14:24 +0100
Subject: [Live-devel] [RFC] Guard against _setmode() on WinCE
Message-ID: <20091112051424.GA30677@via.ecp.fr>

This allows live555 to compile with the mingw32ce toolchain of the CeGCC
project, that doesn't define _setmode(). However am I not sure that
this is the right thing to do, since I found documentation saying that
_setmode() should be available on WinCE.


diff -urp live.orig/liveMedia/InputFile.cpp live/liveMedia/InputFile.cpp
--- live.orig/liveMedia/InputFile.cpp	2009-09-28 17:16:16.000000000 +0200
+++ live/liveMedia/InputFile.cpp	2009-11-11 01:06:45.000000000 +0100
@@ -35,7 +35,7 @@ FILE* OpenInputFile(UsageEnvironment& en
   // Check for a special case file name: "stdin"
   if (strcmp(fileName, "stdin") == 0) {
     fid = stdin;
-#if defined(__WIN32__) || defined(_WIN32)
+#if (defined(__WIN32__) || defined(_WIN32)) && !defined(_WIN32_WCE)
     _setmode(_fileno(stdin), _O_BINARY); // convert to binary mode
 #endif
   } else {
diff -urp live.orig/liveMedia/OutputFile.cpp live/liveMedia/OutputFile.cpp
--- live.orig/liveMedia/OutputFile.cpp	2009-09-28 17:16:16.000000000 +0200
+++ live/liveMedia/OutputFile.cpp	2009-11-11 01:07:50.000000000 +0100
@@ -35,12 +35,12 @@ FILE* OpenOutputFile(UsageEnvironment& e
   // Check for special case 'file names': "stdout" and "stderr"
   if (strcmp(fileName, "stdout") == 0) {
     fid = stdout;
-#if defined(__WIN32__) || defined(_WIN32)
+#if (defined(__WIN32__) || defined(_WIN32)) && !defined(_WIN32_WCE)
     _setmode(_fileno(stdout), _O_BINARY);       // convert to binary mode
 #endif
   } else if (strcmp(fileName, "stderr") == 0) {
     fid = stderr;
-#if defined(__WIN32__) || defined(_WIN32)
+#if (defined(__WIN32__) || defined(_WIN32)) && !defined(_WIN32_WCE)
     _setmode(_fileno(stderr), _O_BINARY);       // convert to binary mode
 #endif
   } else {


Ross, I am sorry for upsetting you by taking one full day to bring up
this issue on this mailing-list. I guess that I am just careful with
what I send you.

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

From amadorim at vdavda.com  Thu Nov 12 00:05:44 2009
From: amadorim at vdavda.com (Marco Amadori)
Date: Thu, 12 Nov 2009 09:05:44 +0100
Subject: [Live-devel] How to install live555 on ubuntu.
In-Reply-To: <BAY120-W35239798A7A4FF6253831ECAAA0@phx.gbl>
References: <BAY120-W38AEF8817370C00C27DE45CAAA0@phx.gbl>
	<BAY120-W35239798A7A4FF6253831ECAAA0@phx.gbl>
Message-ID: <200911120905.45110.amadorim@vdavda.com>

On Wednesday 11 November 2009, 13:48:19, Zelalem Sintayehu wrote:

> Hi, I don't know if it the proper forum to ask this question. I just
>  downloaded the live555-latest.tar.gz file and unzipped it and created a
>  make file using genMakefile script.

You could try rebuilding debian unstable package:

$ dget 
http://ftp.de.debian.org/debian/pool/main/libl/liblivemedia/liblivemedia_2008.07.25-2.dsc

$ cd liblivemedia
$ debuild -us -uc -b

This should create a .deb for you.

If you miss deps and do not find them, look at debian/control and adjust the 
names according the packages you have.

If you are successful you can use the debian directory also with latest 
live555 tree.

-- 
basta vi prego -> http://it.wikipedia.org/wiki/Top-posting
avoid that please! -> http://en.wikipedia.org/wiki/Posting_style#Top-posting
ESC:wq

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


From finlayson at live555.com  Thu Nov 12 00:55:23 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 12 Nov 2009 17:55:23 +0900
Subject: [Live-devel] [RFC] Guard against _setmode() on WinCE
In-Reply-To: <20091112051424.GA30677@via.ecp.fr>
References: <20091112051424.GA30677@via.ecp.fr>
Message-ID: <f06240800c7217d20cc09@[66.80.62.44]>

Thanks for posting these proposed changes.  These changes will also 
appear in the next release of the software.
-- 

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

From finlayson at live555.com  Thu Nov 12 01:27:39 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 12 Nov 2009 18:27:39 +0900
Subject: [Live-devel] How to install live555 on ubuntu.
In-Reply-To: <200911120905.45110.amadorim@vdavda.com>
References: <BAY120-W38AEF8817370C00C27DE45CAAA0@phx.gbl>
	<BAY120-W35239798A7A4FF6253831ECAAA0@phx.gbl>
	<200911120905.45110.amadorim@vdavda.com>
Message-ID: <f06240800c721851eab91@[66.80.62.44]>

If - for whatever reason - the existing "config.linux" configuration 
file doesn't work for 'ubuntu', then please propose either (i) a 
modified version (that also continues to work with other types of 
Linux), or (ii) a new configuration file "config.ubuntu" that works 
for 'ubuntu'.
-- 

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

From salvatore.frandina at gmail.com  Thu Nov 12 06:49:48 2009
From: salvatore.frandina at gmail.com (Salvatore Frandina)
Date: Thu, 12 Nov 2009 15:49:48 +0100
Subject: [Live-devel] Sip user that send jpeg image
Message-ID: <d116c1f90911120649q538f6d94s9bcc8aefbcb538bd@mail.gmail.com>

Hi,

I would like to create (if not exist) a software that make a sip call and
send a video stream made-up by jpeg picture. Can i use *LIVE555 Streaming
Media*? If yes is difficult, I'm not expert programmer...

Thank you very much

-- 
_______________________________________
Salvatore Frandina
website: http://frandinas.altervista.org
mail: salvatore.frandina at gmail.com

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

From finlayson at live555.com  Thu Nov 12 12:54:15 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 13 Nov 2009 05:54:15 +0900
Subject: [Live-devel] New version (2009.11.12) released;
 eliminates "select()" errors on some platforms
Message-ID: <f06240802c72225ba3d3c@[66.80.62.44]>

I have just installed a new version (2009.11.12) of the "LIVE555 
Streaming Media" code that works around what appears to be a compiler 
error on some platforms (e.g., Mac OS X) that was leading to error 
messages of the form:

	select() fails: Invalid argument

If you have been seeing such error messages (and perhaps even if you 
haven't), you should upgrade to the newest version of the code.
-- 

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

From finlayson at live555.com  Thu Nov 12 12:56:26 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 13 Nov 2009 05:56:26 +0900
Subject: [Live-devel] PS File does not work
In-Reply-To: <77cbcf180911101038s2dfa8aao4ec243cbb3356fdf@mail.gmail.com>
References: <77cbcf180911101038s2dfa8aao4ec243cbb3356fdf@mail.gmail.com>
Message-ID: <f06240803c722269d7262@[66.80.62.44]>

Thanks for the report.  I'm currently investigating this.

I haven't come to any firm conclusions yet, but I suspect that there 
may be a problem with the audio that's in your Program Stream file. 
Are you sure that this is MPEG-1 or MPEG-2 audio?  If it's any other 
kind of audio, then this might be causing the problems that you're 
seeing.
-- 

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

From finlayson at live555.com  Thu Nov 12 14:03:01 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 13 Nov 2009 07:03:01 +0900
Subject: [Live-devel] PS File does not work
Message-ID: <f06240804c72235f27296@[66.80.62.44]>

OK, I've looked at this some more, and the problem is definitely the 
audio that's in your Program Stream file.  It's something other than 
MPEG-1 or MPEG-2 (perhaps it's AC-3?).  Because of this, you can't 
use our regular Program Stream streaming tools to stream it.

However, what you *can* do instead is convert the Program Stream file 
into a Transport Stream file, using our 
"testMPEG1or2ProgramToTransportStream" demo application, and then 
stream the Transport Stream file.
-- 

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

From finlayson at live555.com  Thu Nov 12 14:07:01 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 13 Nov 2009 07:07:01 +0900
Subject: [Live-devel] Sip user that send jpeg image
In-Reply-To: <d116c1f90911120649q538f6d94s9bcc8aefbcb538bd@mail.gmail.com>
References: <d116c1f90911120649q538f6d94s9bcc8aefbcb538bd@mail.gmail.com>
Message-ID: <f06240805c7223747c2c0@[66.80.62.44]>

>I would like to create (if not exist) a software that make a sip 
>call and send a video stream made-up by jpeg picture. Can i use 
>LIVE555 Streaming Media?

Sorry, no.


>  If yes is difficult, I'm not expert programmer...

Unfortunately this software is intended for expert programmers.
-- 

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/20091113/acfcf062/attachment-0001.html>

From sebastien-devel at celeos.eu  Fri Nov 13 05:24:23 2009
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Fri, 13 Nov 2009 14:24:23 +0100
Subject: [Live-devel] scale pause and play
Message-ID: <1258118663.4afd5e07169cf@imp.celeos.eu>



Hi,

I would like to know how I should unpause a stream when a scale command has been
sent before the pause.

For example :
Play scale=2.0
Pause
Play

The last Play is sent with the function playMediaSession with no scale value, so
a default value of 1.0 is sent by live555

My question is :
Is there something that should be fixed in live555, or should I set the scale
value each time I use playMediaSession ?

Regards,

Seb.


From finlayson at live555.com  Fri Nov 13 11:01:15 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 14 Nov 2009 04:01:15 +0900
Subject: [Live-devel] scale pause and play
In-Reply-To: <1258118663.4afd5e07169cf@imp.celeos.eu>
References: <1258118663.4afd5e07169cf@imp.celeos.eu>
Message-ID: <f06240800c7235d179cfc@[66.80.62.44]>

>The last Play is sent with the function playMediaSession with no 
>scale value, so
>a default value of 1.0 is sent by live555
>
>My question is :
>Is there something that should be fixed in live555, or should I set the scale
>value each time I use playMediaSession ?

The latter.  The library does not 'remember' the scale value that it 
previously used; it assumes that the client will specify the desired 
value (default value: 1) each time it calls "playMediaS(ubs)ession()".
-- 

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

From satish.annauniv at gmail.com  Thu Nov 12 22:53:19 2009
From: satish.annauniv at gmail.com (Sathish Kumar)
Date: Fri, 13 Nov 2009 12:23:19 +0530
Subject: [Live-devel] Doubts reagrding the SDP informations sent for MP3
Message-ID: <b6ec296d0911122253n78740196n95933a1e0a855044@mail.gmail.com>

Hi Ross,



May I know why the LiveMediaServer is not sending rtpmap information?

With the Helix server, I tried streaming a Mp3 clip using VLC player.

The SDP Information sent by the Helix Server is as follows,



a=rtpmap:101 X-MP3-draft-00/44100/2





In our Application, If this information is coming through SDP then major
overhead can be avoided.

This information comes even for 3gp clips why not for mp3??

Kindly through some light on this.



Regards

Sathish Kumar


-- 
Regards
Sathish Kumar M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091113/3a4ca522/attachment.html>

From zelalems at hotmail.com  Fri Nov 13 08:16:42 2009
From: zelalems at hotmail.com (Zelalem Sintayehu)
Date: Fri, 13 Nov 2009 19:16:42 +0300
Subject: [Live-devel]  How to install live55 in ubuntu
In-Reply-To: <f06240805c7223747c2c0@[66.80.62.44]>
References: <d116c1f90911120649q538f6d94s9bcc8aefbcb538bd@mail.gmail.com>,
	<f06240805c7223747c2c0@[66.80.62.44]>
Message-ID: <BAY120-W495DCF3A7C324EA535677CCAA80@phx.gbl>


Hi all, I couldn't install live55 in ubuntu hardy. I get the following error:

/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
make[1]: *** [testMP3Streamer] Error 1
make[1]: Leaving directory '/home/zelalem/live/testProgs'
make: *** [all] Erro 2

I think it relates to the linker. How can I configure the linker in the configuration file. Pleae help me. This is the third day that i am battling.

Thank you.

Best regards,

- Zelalem S. 
Grahamstown, SA


 		 	   		  
_________________________________________________________________
Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail?.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091113/6f6a3782/attachment.html>

From albalber at yahoo.com  Fri Nov 13 08:30:44 2009
From: albalber at yahoo.com (Alberto Alberici)
Date: Fri, 13 Nov 2009 08:30:44 -0800 (PST)
Subject: [Live-devel] problem (?) when outputting raw H264 stream with
	openRTSP
In-Reply-To: <mailman.4.1258129371.870.live-devel@lists.live555.com>
Message-ID: <873423.38079.qm@web114119.mail.gq1.yahoo.com>

Hi.When I capture a rtsp h264 stream with openRTSP and save it into a .mp4
file (-4 option), I can reproduce it with common players (vlc, mplayer
etc.)However, if I save the captured stream into a "raw" file (i.e video-H264-1) I cannot see it with any player. Why ?


In addition: in the produced raw file, I don't see any nal marker (00
00 00 01), even if H264FileSink seems to insert them (I made a small
debug.). Why? 


Thanks in advance,Alberto




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

From finlayson at live555.com  Fri Nov 13 14:51:18 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 14 Nov 2009 07:51:18 +0900
Subject: [Live-devel] Doubts reagrding the SDP informations sent for MP3
In-Reply-To: <b6ec296d0911122253n78740196n95933a1e0a855044@mail.gmail.com>
References: <b6ec296d0911122253n78740196n95933a1e0a855044@mail.gmail.com>
Message-ID: <f06240801c723907847ed@[66.80.62.44]>

>
>May I know why the LiveMediaServer is not sending rtpmap information?
>
>With the Helix server, I tried streaming a Mp3 clip using VLC player.
>
>The SDP Information sent by the Helix Server is as follows,
>
>a=rtpmap:101 X-MP3-draft-00/44100/2
>
>In our Application, If this information is coming through SDP then 
>major overhead can be avoided.
>
>This information comes even for 3gp clips why not for mp3??
>
>Kindly through some light on this.

The "a=rtpmap:" line is needed only for dynamic payload type numbers 
(e.g., 101 in this case), for which a RTP payload format is not 
already defined.  For MPEG-1 or 2 audio (including 'mp3'), however, a 
static payload type of 14 is already defined for this RTP payload 
format (see Table 4 in RFC 3551), and we use that instead (note the 
line "m=audio 0 RTP/AVP 14").  Because of this, a "a=rtpmap:" line is 
not needed.

Note that receivers that use our code do not need to concern 
themselves with this, because we handle the SDP description 
automatically.

(Note also that the "X-MP3-draft-00" in the Helix server's SDP line 
tells us that it using an experimental RTP payload format; not an 
IETF standard one.  Standard receivers therefore cannot be expected 
to receive that stream.)
-- 

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

From finlayson at live555.com  Fri Nov 13 16:21:29 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 14 Nov 2009 09:21:29 +0900
Subject: [Live-devel] problem (?) when outputting raw H264 stream with
 openRTSP
In-Reply-To: <873423.38079.qm@web114119.mail.gq1.yahoo.com>
References: <873423.38079.qm@web114119.mail.gq1.yahoo.com>
Message-ID: <f06240800c723a822d3c6@[66.80.62.44]>

>Hi.When I capture a rtsp h264 stream with openRTSP and save it into 
>a .mp4 file (-4 option), I can reproduce it with common players 
>(vlc, mplayer etc.)However, if I save the captured stream into a 
>"raw" file (i.e video-H264-1) I cannot see it with any player. Why ?

Because those media players (which are not our software, BTW) happen 
not to support playing a 'raw' H.264 file.


>In addition: in the produced raw file, I don't see any nal marker 
>(00 00 00 01), even if H264FileSink seems to insert them (I made a 
>small debug.). Why?

I don't know.  If you find a bug in this code, please let us know.
-- 

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

From sebastien-devel at celeos.eu  Sat Nov 14 00:57:42 2009
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Sat, 14 Nov 2009 09:57:42 +0100
Subject: [Live-devel] scale pause and play
In-Reply-To: <f06240800c7235d179cfc@[66.80.62.44]>
References: <1258118663.4afd5e07169cf@imp.celeos.eu>
	<f06240800c7235d179cfc@[66.80.62.44]>
Message-ID: <1258189062.4afe7106d7806@imp.celeos.eu>

Quoting Ross Finlayson <finlayson at live555.com>:

> The latter.  The library does not 'remember' the scale value that it
> previously used; it assumes that the client will specify the desired
> value (default value: 1) each time it calls "playMediaS(ubs)ession()".

And couldn't the library not send any value, if the client don't give this
parameter ?


From jnoring at logitech.com  Sat Nov 14 11:03:49 2009
From: jnoring at logitech.com (Jeremy Noring)
Date: Sat, 14 Nov 2009 11:03:49 -0800
Subject: [Live-devel] problem (?) when outputting raw H264 stream with
	openRTSP
In-Reply-To: <873423.38079.qm@web114119.mail.gq1.yahoo.com>
References: <mailman.4.1258129371.870.live-devel@lists.live555.com>
	<873423.38079.qm@web114119.mail.gq1.yahoo.com>
Message-ID: <988ed6930911141103v68912723q8abd13b0fd359108@mail.gmail.com>

On Fri, Nov 13, 2009 at 8:30 AM, Alberto Alberici <albalber at yahoo.com>wrote:

>
> In addition: in the produced raw file, I don't see any nal marker (00 00 00
> 01), even if H264FileSink seems to insert them (I made a small debug.). Why?
>
>
>
Well, if this is true then it's unsurprising that the file doesn't play back
(for raw H264, start codes must be present for parsing).  I am not sure why
this wouldn't work, so you'll have to debug it.  I'd also make sure your
SPS/PPS info is being written at the start of the file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091114/53551f96/attachment.html>

From dushi310 at 163.com  Sun Nov 15 07:34:18 2009
From: dushi310 at 163.com (=?gbk?B?tsXKsQ==?=)
Date: Sun, 15 Nov 2009 23:34:18 +0800 (CST)
Subject: [Live-devel] How to free memory in the function
 ByteStreamFileSource::doReadFromFile()
Message-ID: <28418090.269201258299258697.JavaMail.coremail@app182.163.com>

Hi,Ross
Thanks for your help.
I use live555 Server to stream H.264 live data which receive from the IP camera.
If there is no data from the IP camera, I want to close this ServerMediaSession. 
But this situation just occured in the function ByteStreamFileSource::doReadFromFile() as the follow code.

I have read some answer from the pipermail, you have said when fFrameSize ==0 invoke the
handleClosure(this) function can not free anything.
>"FramedSource::handleClosure" doesn't delete anything.  Instead, its 
>purpose is to tell the downstream object that the flow of data has ended.
>To actually reclaim a 'media' object (i.e., a subclass of "Medium"), call 
>"Medium::close()" on it.
Question:
   You said reclaim a 'media' object and call "Medium::close()" on it,
Does you mean use the following code
if(fFrameSize==0)
{
	Medium::close(this);
}
instead of
if(fFrame)
{
	handleClosure(this);
}



So I want to know what should I do when I want to close this ServerMediaSession.
especially, how to free the memory whick allocated before.

When the fFrameSize=0,I trace the code, I found that it will enter the following function
void StreamState::reclaim()
{
  // Delete allocated media objects
  Medium::close(fRTCPInstance) /* will send a RTCP BYE */; fRTCPInstance = NULL;
  Medium::close(fRTPSink); fRTPSink = NULL;
  Medium::close(fUDPSink); fUDPSink = NULL;
  fMaster.closeStreamSource(fMediaSource); fMediaSource = NULL;
  delete fRTPgs; fRTPgs = NULL;
  delete fRTCPgs; fRTCPgs = NULL;
}
It seems that It could free some memory which allocated before.But I can not sure all the memory allocated before are free .


Beacause my bad english, So I want to explain by code.
Thanks in advance.

void ByteStreamFileSource::doReadFromFile() 
{
  // Try to read as many bytes as will fit in the buffer provided
  // (or "fPreferredFrameSize" if less)
  DATAPACKETHEADER DataPacket;
  int port_i,ret;
  if (fPreferredFrameSize > 0 && fPreferredFrameSize < fMaxSize) 
  {
    fMaxSize = fPreferredFrameSize;
  }
  
  if (m_live_s==1234)
  {
	  port_i=m_h264_port_num;
  }

  if(port_i>=0&&port_i<MP4Sys_MAX_SUPPORTS&&m_live_s==1234)
  {
	if (g_Mp4PlayStream[port_i]->m_nPacketNum>0)
	{
		Get_Frame_Data[port_i]=0;
		GetPacket(port_i,&DataPacket,0,NULL);
	}
	else
	{
		while(g_Mp4PlayStream[port_i]->m_nPacketNum<=0)
		{
			Get_Frame_Data[port_i]++;
			if (Get_Frame_Data[port_i]>30)
			{
				fFrameSize=0;
				Get_Frame_Data[port_i]=0;
				printf("port=%d will goto clost the stream\n",port_i);
				goto Frame_End;
			}
		    usleep(33000);
		}
		GetPacket(port_i,&DataPacket,0,NULL);
		if((DataPacket.DataPacketStartCode)==0xc7010000)
		{
			memcpy(fTo,g_Mp4PlayStream[port_i]->m_DecodeSrc,DataPacket.nOverloadLen);
			fFrameSize=DataPacket.nOverloadLen;
		}
	}
  }

Frame_End:
  if (fFrameSize == 0) 
  {
////////////////////////////////////////////////////////////////////////////////
/////////////////here what should I do to free the memory whick allocated before
////////////////////////////////////////////////////////////////////////////////
    handleClosure(this);
    return;
  }
  // Set the 'presentation time':
  if (fPlayTimePerFrame > 0 && fPreferredFrameSize > 0) 
.............
}



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

From finlayson at live555.com  Sun Nov 15 02:38:13 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 15 Nov 2009 19:38:13 +0900
Subject: [Live-devel] How to free memory in the function
 ByteStreamFileSource::doReadFromFile()
In-Reply-To: <28418090.269201258299258697.JavaMail.coremail@app182.163.com>
References: <28418090.269201258299258697.JavaMail.coremail@app182.163.com>
Message-ID: <f06240804c7258937555a@[66.80.62.44]>

First, you should *not* be modifying the existing code (e.g., 
"ByteStreamFileSource::doReadFromFile()"), because that makes it 
difficult to upgrade to new versions of the code.  Instead, if you 
want to modify the existing code, you should use a new class name 
(and a new file name).

The only place a class (subclassed from "Medium") should be deleting 
heap-allocated memory is in its destructor.  (The destructor will be 
called automatically when"Medium::close()" is called.)
-- 

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

From finlayson at live555.com  Sun Nov 15 21:59:20 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 15 Nov 2009 21:59:20 -0800
Subject: [Live-devel] scale pause and play
In-Reply-To: <1258189062.4afe7106d7806@imp.celeos.eu>
References: <1258118663.4afd5e07169cf@imp.celeos.eu>
	<f06240800c7235d179cfc@[66.80.62.44]>
	<1258189062.4afe7106d7806@imp.celeos.eu>
Message-ID: <f06240800c72699fefa31@[66.80.62.44]>

>  > The latter.  The library does not 'remember' the scale value that it
>>  previously used; it assumes that the client will specify the desired
>>  value (default value: 1) each time it calls "playMediaS(ubs)ession()".
>
>And couldn't the library not send any value, if the client don't give this
>parameter ?

No, because it's not clear what this would mean.  Some servers might 
interpret this to mean "leave the scale value the way it was"; others 
might interpret it to mean "assume that the scale value is 1".  (The 
RTSP specification is not clear on this point.)

In any case, the client software is the one thing that knows - with 
certainty - what the scale factor is, so it's the one that sets the 
value.
-- 

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

From tsahi at vicon.co.il  Mon Nov 16 01:55:27 2009
From: tsahi at vicon.co.il (Tsahi Etziony)
Date: Mon, 16 Nov 2009 11:55:27 +0200
Subject: [Live-devel] how do I know this is the first fragment of the frame?
Message-ID: <002101ca66a2$ecc41910$c64c4b30$@co.il>

As I understand, doSpecialFrameHandling() and frameSpecificHeaderSize() are
being called for each RTP packet, and not once per frame.
I am sending H264 over RTP and I want to add data to the first fragment of
the frame. Which Boolean expression should I use in doSpecialFrameHandling()
and in frameSpecificHeaderSize() in order to know that this is the RTP
packet that holds the first fragment?
 
thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091116/9047e5ed/attachment-0001.html>

From dmaljur at elma.hr  Mon Nov 16 02:39:53 2009
From: dmaljur at elma.hr (Dario)
Date: Mon, 16 Nov 2009 11:39:53 +0100
Subject: [Live-devel] Appropriate way to shutdown task scheduler and usage
	environment.
Message-ID: <000a01ca66a9$24cab110$ec03000a@gen47>

I wrote a video client that at one point needs to shut down all incoming mpeg4 streams and delete usage environent 
and task scheduler. 
After that it needs to allocate new set of RTSPClient and start streaming all over again.

The only way I managed to get task scheduler to work after the first set of streams is shut downed is
by deleting the task scheduler and usage environent. For some reason if I don't create new task scheduler and env
the loop gets stuck and no frames are streaming.

But now there is a problem where I use: 

  usageEnvironment->reclaim();
  delete scheduler;
  scheduler = NULL;

  scheduler = BasicTaskScheduler::createNew();
  usageEnvironent = BasicUsageEnvironment::createNew(*scheduler);

after starting event loop there's a 12kb leak which is not dealocated with reclaim.
So I guess I did something wrong here. Can someone point me where?

Also, why can't I use the same task scheduler after I shutdowned all active streams?

Thanks.


 


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/20091116/cecc733d/attachment.html>

From albalber at yahoo.com  Mon Nov 16 05:27:48 2009
From: albalber at yahoo.com (Alberto Alberici)
Date: Mon, 16 Nov 2009 05:27:48 -0800 (PST)
Subject: [Live-devel] problem (?) when outputting raw H264 stream with
	openRTSP
In-Reply-To: <f06240800c723a822d3c6@[66.80.62.44]>
References: <873423.38079.qm@web114119.mail.gq1.yahoo.com>
	<f06240800c723a822d3c6@[66.80.62.44]>
Message-ID: <5707.82277.qm@web114107.mail.gq1.yahoo.com>






________________________________
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com>
Sent: Sat, November 14, 2009 1:21:29 AM
Subject: Re: [Live-devel] problem (?) when outputting raw H264 stream with openRTSP

> > Hi.When I capture a rtsp h264 stream with openRTSP and save it into a .mp4 file (-4 option), I can reproduce it with common players (vlc, mplayer etc.)However, if I save the captured stream into a "raw" file (i.e video-H264-1) I cannot see it with any player. Why ?

> Because those media players (which are not our software, BTW) happen not to support playing a 'raw' H.264 file.

at least ffplay (in ffmpeg stuff) supports raw h264 files, and I've played some of them (I encoded a raw h264 file with x264 and then played it with ffplay, and it's ok)



>> In addition: in the produced raw file, I don't see any nal marker (00 00 00 01), even if H264FileSink seems to insert them (I made a small debug.). Why?

> I don't know.  If you find a bug in this code, please let us know.

I confirm the bug.
addData() with the nal marker passed as parameter is called, but strangely there're not nal markers in the resulting file (or files, if -m option is used).


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

From finlayson at live555.com  Mon Nov 16 07:04:31 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 16 Nov 2009 07:04:31 -0800
Subject: [Live-devel] how do I know this is the first fragment of the
 frame?
In-Reply-To: <002101ca66a2$ecc41910$c64c4b30$@co.il>
References: <002101ca66a2$ecc41910$c64c4b30$@co.il>
Message-ID: <f06240800c727196e945e@[66.80.62.44]>

We *already* implement the RTP payload format for H.264 video - in 
the class "H264VideoRTPSink".  You don't need to implement any 
RTP-specific code yourself to stream H.264.  Instead, just feed H.264 
NAL units into a "H264VideoRTPSink", and everything will work.  These 
NAL units will come from a subclass of "H264VideoStreamFramer" that 
you *do* implement .

In other words, the only thing you need to implement to stream H.264 
video is a subclass of "H264VideoStreamFramer" (and any upstream 
objects) that will feed H.264 NAL units into a "H264VideoRTPSink".
-- 

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

From ganeshamutha at gmail.com  Mon Nov 16 20:25:19 2009
From: ganeshamutha at gmail.com (Ganesh kumar)
Date: Tue, 17 Nov 2009 09:55:19 +0530
Subject: [Live-devel] RTSP: is there RTSP slow forward available ?
Message-ID: <f0878d1b0911162025yb3dd2bdr19eb72f0dbdf0dc9@mail.gmail.com>

Hi,

I tried with openRTSP and live555 server with the scale of "0.5" but the
response was always nearest whole number.
is there patch to fix this issue? is the live555 would not support slow
forward ?

Please kindly let me know your command.


Thanks and Regards,
Ganesh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091117/14a88f29/attachment.html>

From finlayson at live555.com  Mon Nov 16 22:43:19 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 16 Nov 2009 22:43:19 -0800
Subject: [Live-devel] RTSP: is there RTSP slow forward available ?
In-Reply-To: <f0878d1b0911162025yb3dd2bdr19eb72f0dbdf0dc9@mail.gmail.com>
References: <f0878d1b0911162025yb3dd2bdr19eb72f0dbdf0dc9@mail.gmail.com>
Message-ID: <f06240801c727f5453f53@[66.80.62.44]>

>I tried with openRTSP and live555 server with the scale of "0.5" but 
>the response was always nearest whole number.
>is there patch to fix this issue? is the live555 would not support 
>slow forward ?

No, our RTSP server implementation currently does not support 
fractional "scale" values - for any media type.

Which media type(s) are you interested in streaming with a scale of 0.5?
-- 

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

From zelalems at hotmail.com  Mon Nov 16 23:47:03 2009
From: zelalems at hotmail.com (Zelalem Sintayehu)
Date: Tue, 17 Nov 2009 10:47:03 +0300
Subject: [Live-devel]  Question about tesRelay
In-Reply-To: <5707.82277.qm@web114107.mail.gq1.yahoo.com>
References: <873423.38079.qm@web114119.mail.gq1.yahoo.com>,
	<f06240800c723a822d3c6@[66.80.62.44]>,
	<5707.82277.qm@web114107.mail.gq1.yahoo.com>
Message-ID: <BAY120-W28E5171B5D9B9A0EF88058CAA40@phx.gbl>


Hi, can I use the testRelay example to relay request from a client to server and response from a server back to client. That is, 
     client ->testRelay->server (request)
     server->testRelay->client (response)

I want to use it to dvp an application. I saw the code and it talks about multicast (group) address. That is teh reason why I'm asking this question. If so, how can I use it.

Thank you.

Best regards,

- Zelalem S. 

 		 	   		  
_________________________________________________________________
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091117/8da7080d/attachment.html>

From finlayson at live555.com  Tue Nov 17 01:47:17 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 17 Nov 2009 01:47:17 -0800
Subject: [Live-devel] Question about tesRelay
In-Reply-To: <BAY120-W28E5171B5D9B9A0EF88058CAA40@phx.gbl>
References: <873423.38079.qm@web114119.mail.gq1.yahoo.com>,
	<f06240800c723a822d3c6@[66.80.62.44]>,
	<5707.82277.qm@web114107.mail.gq1.yahoo.com>
	<BAY120-W28E5171B5D9B9A0EF88058CAA40@phx.gbl>
Message-ID: <f06240802c72821670ca3@[66.80.62.44]>

>Hi, can I use the testRelay example to relay request from a client 
>to server and response from a server back to client. That is,
>      client ->testRelay->server (request)
>      server->testRelay->client (response)

No.  The "testRelay" demo application is used to relay a multicast 
stream.  It can't be used as a unicast relay (or 'proxy').  Sorry.
-- 

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

From dmaljur at elma.hr  Tue Nov 17 03:41:37 2009
From: dmaljur at elma.hr (Dario)
Date: Tue, 17 Nov 2009 12:41:37 +0100
Subject: [Live-devel] SingleStep getting stuck in Select
Message-ID: <003901ca677a$ec49a1c0$ec03000a@gen47>

I have multiple threads each with it's own UsageEnvironment and TaskScheduler.
Depending on user input I start and stop each event loop.

But when I stop the execution od event loop using the watch variable and try to start it again
by reseting the variable to 0 and rerunning the event loop, the loop get's 2 passes and then
get's forever suck in Select in SingleStep.

This happens even If I reclaim the environemnt. 


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/20091117/d4d5c6c0/attachment-0001.html>

From dmaljur at elma.hr  Tue Nov 17 04:36:32 2009
From: dmaljur at elma.hr (Dario)
Date: Tue, 17 Nov 2009 13:36:32 +0100
Subject: [Live-devel] SingleStep getting stuck in Select
References: <003901ca677a$ec49a1c0$ec03000a@gen47>
Message-ID: <004f01ca6782$9b284f00$ec03000a@gen47>

Disregard this.  I fixed the probem.

  ----- Original Message ----- 
  From: Dario 
  To: live-devel at ns.live555.com 
  Sent: Tuesday, November 17, 2009 12:41 PM
  Subject: [Live-devel] SingleStep getting stuck in Select


  I have multiple threads each with it's own UsageEnvironment and TaskScheduler.
  Depending on user input I start and stop each event loop.

  But when I stop the execution od event loop using the watch variable and try to start it again
  by reseting the variable to 0 and rerunning the event loop, the loop get's 2 passes and then
  get's forever suck in Select in SingleStep.

  This happens even If I reclaim the environemnt. 



------------------------------------------------------------------------------
  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


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/20091117/2f668ab8/attachment.html>

From zelalems at hotmail.com  Tue Nov 17 23:48:09 2009
From: zelalems at hotmail.com (Zelalem Sintayehu)
Date: Wed, 18 Nov 2009 10:48:09 +0300
Subject: [Live-devel] Question about tesRelay
In-Reply-To: <f06240802c72821670ca3@[66.80.62.44]>
References: <873423.38079.qm@web114119.mail.gq1.yahoo.com>, ,
	<f06240800c723a822d3c6@[66.80.62.44]>, ,
	<5707.82277.qm@web114107.mail.gq1.yahoo.com>,
	<BAY120-W28E5171B5D9B9A0EF88058CAA40@phx.gbl>,
	<f06240802c72821670ca3@[66.80.62.44]>
Message-ID: <BAY120-W29BD674BC63B0443EB4AD5CAA30@phx.gbl>


Hi Ross, thank you for your response. So, is it difficult to change it to work for unicast address? If it can be done, which part shall I modify? 

Thank you.

Best regards,

- Zelalem S. 


> Date: Tue, 17 Nov 2009 01:47:17 -0800
> To: live-devel at ns.live555.com
> From: finlayson at live555.com
> Subject: Re: [Live-devel] Question about tesRelay
> 
> >Hi, can I use the testRelay example to relay request from a client 
> >to server and response from a server back to client. That is,
> >      client ->testRelay->server (request)
> >      server->testRelay->client (response)
> 
> No.  The "testRelay" demo application is used to relay a multicast 
> stream.  It can't be used as a unicast relay (or 'proxy').  Sorry.
> -- 
> 
> 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
 		 	   		  
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091118/a859f738/attachment.html>

From mproxi at orangemail.sk  Wed Nov 18 15:18:26 2009
From: mproxi at orangemail.sk (mproxi at orangemail.sk)
Date: Wed, 18 Nov 2009 15:18:26
Subject: [Live-devel] Slow connection problem with RTP over RTSP/TCP
Message-ID: <20091118151826.32799A7B4C@pwww3.ispfe.orange.sk>

Hello,

I have tested LIVE555 and I found one problem. Clients connecting to live server over slow network have problems receiving data with RTSP TCP encapsulation turned on. If bitrate of the video is bigger, than available network bandwidth, Live server discards packed randomly. This keeps network busy sending data, but client receives few or none whole 
frames.

I found problem in function sendRTPOverTCP in file RTPInterface.cpp. If send() function is unable to send data, because OS buffer is full, it simply discards rest of the data. This is not very good solution, because it waste bandwidth and breaks frames. On some video sources and for some type of application it is possible to reduce framerate, so you can watch video on slow network. It is better to send whole frame, then 
skip some frames and again send whole frame.

My solution for this problem is to try to repeat send for the same data, if there was no space for them in OS buffers. I tried to determine, if it is possible to send data with function select() and then send them or schedule this data for sending in another time. This solution is valid only with sources, that can change framerate, like web camera, it does not help with file sources that much, except it seems to be more stable for them on slow networks.

I found out that this solution also helps with really big frames, which were not send sometime even on LAN.

I do not know how to make proper patch file, so you can test it with live.2009.11.12.tar.gz. I attached some diff file generated by svn, with my changes. Maybe someone will find this information useful.

Martin

Index: .liveMediaincludeRTPInterface.hh
===================================================================
--- .liveMediaincludeRTPInterface.hh
+++ .liveMediaincludeRTPInterface.hh
@@ -63,7 +63,7 @@
 
   void setClientSession(void* clientSession){rtspClientSession = clientSession;}
 
-  void sendPacket(unsigned char* packet, unsigned packetSize);
+  int sendPacket(unsigned char* packet, unsigned packetSize);
   void startNetworkReading(TaskScheduler::BackgroundHandlerProc*
                            handlerProc);
   bool handleRead(unsigned char* buffer, unsigned bufferMaxSize,
Index: .liveMediaincludeMultiFramedRTPSink.hh
===================================================================
--- .liveMediaincludeMultiFramedRTPSink.hh
+++ .liveMediaincludeMultiFramedRTPSink.hh
@@ -99,6 +99,7 @@
   void sendPacketIfNecessary();
   static void sendNext(void* firstArg);
   friend void sendNext(void*);
+  static void sendThisAgain(void* firstArg);
 
   static void afterGettingFrame(void* clientData,
 				unsigned numBytesRead, unsigned numTruncatedBytes,
Index: .liveMediaRTPInterface.cpp
===================================================================
--- .liveMediaRTPInterface.cpp
+++ .liveMediaRTPInterface.cpp
@@ -34,7 +34,7 @@
 // Helper routines and data structures, used to implement
 // sendingreceiving RTPRTCP over a TCP socket:
 
-static void sendRTPOverTCP(unsigned char* packet, unsigned packetSize,
+static int sendRTPOverTCP(unsigned char* packet, unsigned packetSize,
 			   int socketNum, unsigned char streamChannelId);
 
 // Reading RTP-over-TCP is implemented using two levels of hash tables.
@@ -166,16 +166,18 @@
   }
 }
 
-void RTPInterface::sendPacket(unsigned char* packet, unsigned packetSize) {
+int RTPInterface::sendPacket(unsigned char* packet, unsigned packetSize) {
   // Normal case: Send as a UDP packet:
   fGS->output(envir(), fGS->ttl(), packet, packetSize);
+  int iSend = packetSize;
 
   // Also, send over each of our TCP sockets:
   for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
        streams = streams->fNext) {
-    sendRTPOverTCP(packet, packetSize,
+    iSend = sendRTPOverTCP(packet, packetSize,
 		   streams->fStreamSocketNum, streams->fStreamChannelId);
   }
+ return iSend;
 }
 
 void RTPInterface
@@ -256,7 +258,7 @@
 
 ////////// Helper Functions - Implementation ////////
 
-void sendRTPOverTCP(unsigned char* packet, unsigned packetSize,
+int sendRTPOverTCP(unsigned char* packet, unsigned packetSize,
                     int socketNum, unsigned char streamChannelId) {
 #ifdef DEBUG
   fprintf(stderr, "sendRTPOverTCP: %d bytes over channel %d (socket %d)n",
@@ -265,6 +267,21 @@
   // Send RTP over TCP, using the encoding defined in
   // RFC 2326, section 10.12:
   do {
+
+    //This code is trying to check if we are able to send data over TCP
+    //in some case we cannot send data, because winows buffers are full of our previous data
+    fd_set wrts;
+	struct timeval timeout;
+	timeout.tv_sec = 0;
+	timeout.tv_usec = 1;
+	FD_ZERO(&wrts);
+	FD_SET(socketNum,&wrts);
+	select(NULL, NULL, &wrts, NULL, &timeout);
+	if (!FD_ISSET(socketNum, &wrts))
+	{
+		return 0;
+	}
+
     char const dollar = '$';
     if (send(socketNum, &dollar, 1, 0) != 1) break;
     if (send(socketNum, (char*)&streamChannelId, 1, 0) != 1) break;
@@ -280,13 +297,17 @@
     fprintf(stderr, "sendRTPOverTCP: completedn"); fflush(stderr);
 #endif
 
-    return;
+    if (packetSize != 0)
+		return packetSize;
+	else
+		return 1;
   } while (0);
 
   RTPOverTCP_OK = false; // HACK #####
 #ifdef DEBUG
   fprintf(stderr, "sendRTPOverTCP: failed!n"); fflush(stderr);
 #endif
+  return -1;
 }
 
 SocketDescriptor::SocketDescriptor(UsageEnvironment& env, int socketNum)
Index: .liveMediaMultiFramedRTPSink.cpp
===================================================================
--- .liveMediaMultiFramedRTPSink.cpp
+++ .liveMediaMultiFramedRTPSink.cpp
@@ -357,7 +357,12 @@
 #ifdef TEST_LOSS
     if ((our_random()%10) != 0) // simulate 10% packet loss #####
 #endif
-    fRTPInterface.sendPacket(fOutBuf->packet(), fOutBuf->curPacketSize());
+    if (fRTPInterface.sendPacket(fOutBuf->packet(), fOutBuf->curPacketSize()) == 0)
+	{
+		//if I was unable to send data through TCP, try to send them later
+		nextTask() = envir().taskScheduler().scheduleDelayedTask (100, (TaskFunc*)sendThisAgain, this);
+		return;
+	}
     ++fPacketCount;
     fTotalOctetCount += fOutBuf->curPacketSize();
     fOctetCount += fOutBuf->curPacketSize()
@@ -411,6 +416,12 @@
   sink->buildAndSendPacket(false);
 }
 
+// The following is called after TCP was unable to send data
+void MultiFramedRTPSink::sendThisAgain(void* firstArg) {
+  MultiFramedRTPSink* sink = (MultiFramedRTPSink*)firstArg;
+  sink->sendPacketIfNecessary();
+}
+
 void MultiFramedRTPSink::ourHandleClosure(void* clientData) {
   MultiFramedRTPSink* sink = (MultiFramedRTPSink*)clientData;
   // There are no frames left, but we may have a partially built packet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: live.diff
Type: application/octet-stream
Size: 5019 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091118/75c128ca/attachment.obj>

From finlayson at live555.com  Wed Nov 18 07:49:58 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 18 Nov 2009 07:49:58 -0800
Subject: [Live-devel] Slow connection problem with RTP over RTSP/TCP
In-Reply-To: <20091118151826.32799A7B4C@pwww3.ispfe.orange.sk>
References: <20091118151826.32799A7B4C@pwww3.ispfe.orange.sk>
Message-ID: <f06240801c729c5588ea4@[66.80.62.44]>

No, this is nonsense.  TCP is intended to be a reliable byte-stream 
protocol; it's the job of the operating system's TCP implementation - 
not application-level code (such as LIVE555) - to provide reliable 
delivery.  If, however, your stream's bitrate is too large for your 
network, then you're inevitably going to get packet loss (usually 
because an OS buffer in the sender OS will overflow).  There's 
nothing you can do to avoid this.  If your stream's bitrate is really 
too large for your network, then you should not be sending it (and 
you should certainly not be sending it over TCP).

If, however, your stream's *average* bitrate is within the capacity 
of your network, you can reduce the probability of your server OS's 
TCP implementation losing data by increasing its OS socket buffer. 
Note that we provide a function "increaseSendBufferTo()" that does 
this.  Our RTSP server implementation - by default - sets this buffer 
size (for each server and stream socket) to 50 kBytes (search for 
"increaseSendBufferTo" in the code).  However, you could use a larger 
value this (e.g., by subclassing "RTSPServer").
-- 

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

From matt at schuckmannacres.com  Wed Nov 18 08:33:40 2009
From: matt at schuckmannacres.com (Matt Schuckmann)
Date: Wed, 18 Nov 2009 08:33:40 -0800
Subject: [Live-devel] Slow connection problem with RTP over RTSP/TCP
In-Reply-To: <f06240801c729c5588ea4@[66.80.62.44]>
References: <20091118151826.32799A7B4C@pwww3.ispfe.orange.sk>
	<f06240801c729c5588ea4@[66.80.62.44]>
Message-ID: <4B0421E4.7080908@schuckmannacres.com>

Ross, I have to disagree with you a little here.
Shouldn't it be the servers responsibility to provide the best possible 
experience to the client given the network conditions, the content 
delivery method and the content requested by the client.
And if the server can detect that the network is to slow or congested to 
send all of the requested data (by detecting that the network buffers in 
the OS are full) make an attempt to intelligently send enough data to 
provide a working, all be it degraded, experience to the client rather 
than just randomly dropping parts of frames so that nothing may work.

I haven't looked at his patch so I can't say if it's good or bad but I 
do know we ended up doing something similar for our branch of the 
RTSPServer because we can not guarantee all the conditions our product 
will be used in and we wanted to the best we could to provide a working 
system as much as possible.

Matt S.


Ross Finlayson wrote:
> No, this is nonsense.  TCP is intended to be a reliable byte-stream 
> protocol; it's the job of the operating system's TCP implementation - 
> not application-level code (such as LIVE555) - to provide reliable 
> delivery.  If, however, your stream's bitrate is too large for your 
> network, then you're inevitably going to get packet loss (usually 
> because an OS buffer in the sender OS will overflow).  There's nothing 
> you can do to avoid this.  If your stream's bitrate is really too 
> large for your network, then you should not be sending it (and you 
> should certainly not be sending it over TCP).
>
> If, however, your stream's *average* bitrate is within the capacity of 
> your network, you can reduce the probability of your server OS's TCP 
> implementation losing data by increasing its OS socket buffer. Note 
> that we provide a function "increaseSendBufferTo()" that does this.  
> Our RTSP server implementation - by default - sets this buffer size 
> (for each server and stream socket) to 50 kBytes (search for 
> "increaseSendBufferTo" in the code).  However, you could use a larger 
> value this (e.g., by subclassing "RTSPServer").

From coffsolo at hotmail.com  Wed Nov 18 20:28:37 2009
From: coffsolo at hotmail.com (HQ Wang)
Date: Thu, 19 Nov 2009 04:28:37 +0000
Subject: [Live-devel] Issue on forwarding UDP datagram to VLC
In-Reply-To: <f06240801c729c5588ea4@[66.80.62.44]>
References: <20091118151826.32799A7B4C@pwww3.ispfe.orange.sk>,
	<f06240801c729c5588ea4@[66.80.62.44]>
Message-ID: <SNT101-W242036305336B55AC156A3DCA20@phx.gbl>


Hi all,

 

I am tring to forward the H.264 stream from a H.264 RTSP server to VLC by live555. Since I don't care the type of UDP payload, I don't want to unpack&repack the H.264 stream over RTP. Can I forward the UDP datagram directly to VLC?

 

Just made an attemption, it couldn't play on VLC -- the Input Demuxed kept increasing, but the decoded blocks and display frames were always 0. 

 

Thanks in advance for your help,

Wilson
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with Microsoft's powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/
http://clk.atdmt.com/GBL/go/177141664/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091119/d9aa12ce/attachment.html>

From mproxi at orangemail.sk  Thu Nov 19 08:56:12 2009
From: mproxi at orangemail.sk (mproxi at orangemail.sk)
Date: Thu, 19 Nov 2009 08:56:12
Subject: [Live-devel]  Slow connection problem with RTP over RTSP/TCP
Message-ID: <20091119085612.7DE1AFFC9@pwww6.ispfe.orange.sk>


>No, this is nonsense.  TCP is intended to be a reliable
>byte-stream protocol; it's the job of the operating system's
>TCP implementation - not application-level code (such as 
>LIVE555) - to provide reliable delivery.  

Yes it is true, but problem is that LIVE is loosing the data, not the OS. LIVE is using non blocking sockets. If you are unable to send data, send() returns with number of data send and you discard the rest. That implementation would work for blocking sockets, because you are guarantee to really send the data, but not here.

This generate traffic on the network, but as packet are discarded randomly, you must discard many incomplete frames on the client, so much of the network traffic is wasted.

>If, however, your stream's bitrate is too large for your 
>network, then you're inevitably going to get packet loss 
>(usually because an OS buffer in the sender OS will 
>overflow).  There's nothing you can do to avoid this.  If your
>stream's bitrate is really too large for your network, then you 
>should not be sending it (and you should certainly not be 
>sending it over TCP).

In some cases you can change bitrate of the video by changing framerate. So you can save the day even if original setup was unsuitable for network bandwidth. This is true if you are compressing video on the fly and do not care, that much about framerate.

>If, however, your stream's *average* bitrate is within the
>capacity of your network, you can reduce the probability of
>your server OS's 

I have very  little knowledge about portability, but I can think, you can support it at least for some OS, by #ifdef.

>Note that we provide a function "increaseSendBufferTo()" that 
>does this.  Our RTSP server implementation - by default - 
>sets this buffer size (for each server and stream socket) to 
>50 kBytes (search for "increaseSendBufferTo" in the code).  
>However, you could use a larger value this (e.g., by 
>subclassing "RTSPServer").

"Free size" of the OS buffer is dependent also on the TCP window size on the server and on the client, so you have no power over "free size" in OS buffer.

Martin

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

From finlayson at live555.com  Thu Nov 19 02:31:53 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 19 Nov 2009 02:31:53 -0800
Subject: [Live-devel] Slow connection problem with RTP over RTSP/TCP
In-Reply-To: <4B0421E4.7080908@schuckmannacres.com>
References: <20091118151826.32799A7B4C@pwww3.ispfe.orange.sk>
	<f06240801c729c5588ea4@[66.80.62.44]>
	<4B0421E4.7080908@schuckmannacres.com>
Message-ID: <f06240800c72acdef4751@[66.80.62.44]>

>And if the server can detect that the network is to slow or 
>congested to send all of the requested data (by detecting that the 
>network buffers in the OS are full) make an attempt to intelligently 
>send enough data to provide a working, all be it degraded, 
>experience to the client rather than just randomly dropping parts of 
>frames so that nothing may work.

Yes, at some point it would be nice to support the IETF's RTP/AVPF 
profile, and an associated feedback-based retransmission (and/or 
media rescaling) scheme.  But this, of course, is on top of UDP. 
Trying to implement a loss-mitigation scheme over TCP is retarded.
-- 

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

From jnoring at logitech.com  Thu Nov 19 10:14:57 2009
From: jnoring at logitech.com (Jeremy Noring)
Date: Thu, 19 Nov 2009 10:14:57 -0800
Subject: [Live-devel] Slow connection problem with RTP over RTSP/TCP
In-Reply-To: <f06240800c72acdef4751@66.80.62.44>
References: <20091118151826.32799A7B4C@pwww3.ispfe.orange.sk>
	<f06240801c729c5588ea4@66.80.62.44>
	<4B0421E4.7080908@schuckmannacres.com>
	<f06240800c72acdef4751@66.80.62.44>
Message-ID: <988ed6930911191014l430b35c4oacaa0c2f386d2179@mail.gmail.com>

On Thu, Nov 19, 2009 at 2:31 AM, Ross Finlayson <finlayson at live555.com>wrote:

> And if the server can detect that the network is to slow or congested to
>> send all of the requested data (by detecting that the network buffers in the
>> OS are full) make an attempt to intelligently send enough data to provide a
>> working, all be it degraded, experience to the client rather than just
>> randomly dropping parts of frames so that nothing may work.
>>
>
> Yes, at some point it would be nice to support the IETF's RTP/AVPF profile,
> and an associated feedback-based retransmission (and/or media rescaling)
> scheme.  But this, of course, is on top of UDP. Trying to implement a
> loss-mitigation scheme over TCP is retarded.


I agree.

Furthermore, basically the patch implements a "retransmit" on the RTP stack
level, which is wholly incompatible with any RTP specification I know of.
RTP uses application level framing, which means some of the behaviors are
specifically not defined, and should be implemented by the application
level.  If my video stream is live, "retransmitting" is likely a waste of
time because the data is already obsolete.  And mostly likely I can only
start a stream on keyframe boundaries, so retransmitting some intermediate
frame is also a waste of time if there's already been previous loss. (hence
"application level framing"--only the calling application knows what sort of
loss mitigation plan it should implement)

Question: does Live555 provide a feedback mechanisms for loss, jitter, etc.
(basically some way of getting the RTCP stats) so I can tweak the encoder in
real-time to fit network conditions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091119/f50a74d0/attachment.html>

From finlayson at live555.com  Thu Nov 19 18:53:28 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 19 Nov 2009 18:53:28 -0800
Subject: [Live-devel] Slow connection problem with RTP over RTSP/TCP
In-Reply-To: <988ed6930911191014l430b35c4oacaa0c2f386d2179@mail.gmail.com>
References: <20091118151826.32799A7B4C@pwww3.ispfe.orange.sk>
	<f06240801c729c5588ea4@66.80.62.44>
	<4B0421E4.7080908@schuckmannacres.com>
	<f06240800c72acdef4751@66.80.62.44>
	<988ed6930911191014l430b35c4oacaa0c2f386d2179@mail.gmail.com>
Message-ID: <f06240802c72bb410f62b@[66.80.62.44]>

>Question: does Live555 provide a feedback mechanisms for loss, 
>jitter, etc. (basically some way of getting the RTCP stats) so I can 
>tweak the encoder in real-time to fit network conditions?

Yes - note the classes "RTPTransmissionStatsDB" and 
"RTPTransmissionStats", defined in "liveMedia/include/RTPSink.hh".

There's no application code that demonstrates how to use this, but 
similar classes (for 'reception stats') are used by the "openRTSP" 
demo client (see "testProgs/playCommon.cpp").  If you search for 
"RTPReceptionStats" in that file, you should be able to figure out 
how to access the "RTPTransmissionStats" in your server code.
-- 

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

From guillaume.grimaldi at c-s.fr  Fri Nov 20 00:26:18 2009
From: guillaume.grimaldi at c-s.fr (Guillaume Grimaldi)
Date: Fri, 20 Nov 2009 09:26:18 +0100
Subject: [Live-devel] problem (?) when outputting raw H264 stream with
 openRTSP
In-Reply-To: <f06240800c723a822d3c6@[66.80.62.44]>
References: <873423.38079.qm@web114119.mail.gq1.yahoo.com>
	<f06240800c723a822d3c6@[66.80.62.44]>
Message-ID: <4B0652AA.1010008@c-s.fr>

Ross Finlayson a ?crit :
>> Hi.When I capture a rtsp h264 stream with openRTSP and save it into a 
>> .mp4 file (-4 option), I can reproduce it with common players (vlc, 
>> mplayer etc.)However, if I save the captured stream into a "raw" file 
>> (i.e video-H264-1) I cannot see it with any player. Why ?
>
> Because those media players (which are not our software, BTW) happen 
> not to support playing a 'raw' H.264 file.
>
Hi everybody.
Did you say that common players like vlc can not read h264 raw stream ? 
So if I stream a H264VideoRTP, I can not read my stream with those media 
players. Just only with a H264VideoRTPSource. I say that because I'm 
trying to play with vlc my h264 stream, but, despite receving many 
packets, no video bloc are decoded.
Can you confirm this sentence please ?

Another point. I just want to stream on RTP and not on RTSP. Can I do 
that with liveMedia ? All of your example implement RTSP Server but I do 
not that on my implementation. This is maybe why I can not read my 
stream.. What do you think about that ?

Thank you very much.


From finlayson at live555.com  Fri Nov 20 01:10:54 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 20 Nov 2009 01:10:54 -0800
Subject: [Live-devel] problem (?) when outputting raw H264 stream with
 openRTSP
In-Reply-To: <4B0652AA.1010008@c-s.fr>
References: <873423.38079.qm@web114119.mail.gq1.yahoo.com>
	<f06240800c723a822d3c6@[66.80.62.44]> <4B0652AA.1010008@c-s.fr>
Message-ID: <f06240801c72c0c0fabd7@[66.80.62.44]>

>Ross Finlayson a ?crit :
>>>Hi.When I capture a rtsp h264 stream with 
>>>openRTSP and save it into a .mp4 file (-4 
>>>option), I can reproduce it with common 
>>>players (vlc, mplayer etc.)However, if I save 
>>>the captured stream into a "raw" file (i.e 
>>>video-H264-1) I cannot see it with any player. 
>>>Why ?
>>
>>Because those media players (which are not our 
>>software, BTW) happen not to support playing a 
>>'raw' H.264 file.
>>
>Hi everybody.
>Did you say that common players like vlc can not read h264 raw stream ?

No, I said that they cannot play a H.264 raw 
*file* (but you'd have to ask their developers to 
be sure).


>  So if I stream a H264VideoRTP, I can not read 
>my stream with those media players.

Yes you can (at least with VLC), because it 
implements RTSP/RTP, and the RTP payload format 
for H.264.


>Another point. I just want to stream on RTP and 
>not on RTSP. Can I do that with liveMedia ? All 
>of your example implement RTSP Server but I do 
>not that on my implementation. This is maybe why 
>I can not read my stream.. What do you think 
>about that ?

Yes, that's quite possible, because without a 
RTSP server, the client (media player) might not 
get the SPS and PPS NAL unit data that it needs 
to properly decode the H.264 stream.

You should be using a RTSP server.
-- 

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

From vim.garg at gmail.com  Fri Nov 20 02:52:08 2009
From: vim.garg at gmail.com (Vimal Garg)
Date: Fri, 20 Nov 2009 16:22:08 +0530
Subject: [Live-devel] RTP packet arraival notification.
Message-ID: <2faaac140911200252w64181270u897873d6678f9e88@mail.gmail.com>

Hi,

I am interested in writing a client application which would establish an
RTSP connection with the server and then start receiving streams. The
streams could be either H.264 or MPEG4.

Once the RTP payload is received I need to strip the RTP header and get the
frame into buffer which would be used by the next module.

I would like to know whether I can get only the frame into the buffer or I
need to get the RTP packet and extract the frame one by one.

secondly is there a mechanism in live555 library to register for an event on
RTP packet arrival.

Thanks in advance.
Vimal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091120/c9fb709f/attachment.html>

From guillaume.grimaldi at c-s.fr  Fri Nov 20 02:55:25 2009
From: guillaume.grimaldi at c-s.fr (Guillaume Grimaldi)
Date: Fri, 20 Nov 2009 11:55:25 +0100
Subject: [Live-devel] problem when outputting raw H264 stream
In-Reply-To: <f06240801c72c0c0fabd7@[66.80.62.44]>
References: <873423.38079.qm@web114119.mail.gq1.yahoo.com>	<f06240800c723a822d3c6@[66.80.62.44]>
	<4B0652AA.1010008@c-s.fr> <f06240801c72c0c0fabd7@[66.80.62.44]>
Message-ID: <4B06759D.9080506@c-s.fr>

Ross Finlayson a ?crit :
>> Ross Finlayson a ?crit :
>>>> Hi.When I capture a rtsp h264 stream with openRTSP and save it into 
>>>> a .mp4 file (-4 option), I can reproduce it with common players 
>>>> (vlc, mplayer etc.)However, if I save the captured stream into a 
>>>> "raw" file (i.e video-H264-1) I cannot see it with any player. Why ?
>>>
>>> Because those media players (which are not our software, BTW) happen 
>>> not to support playing a 'raw' H.264 file.
>>>
>> Hi everybody.
>> Did you say that common players like vlc can not read h264 raw stream ?
>
> No, I said that they cannot play a H.264 raw *file* (but you'd have to 
> ask their developers to be sure).
>
>
>>  So if I stream a H264VideoRTP, I can not read my stream with those 
>> media players.
>
> Yes you can (at least with VLC), because it implements RTSP/RTP, and 
> the RTP payload format for H.264.
>
>
>> Another point. I just want to stream on RTP and not on RTSP. Can I do 
>> that with liveMedia ? All of your example implement RTSP Server but I 
>> do not that on my implementation. This is maybe why I can not read my 
>> stream.. What do you think about that ?
>
> Yes, that's quite possible, because without a RTSP server, the client 
> (media player) might not get the SPS and PPS NAL unit data that it 
> needs to properly decode the H.264 stream.
>
> You should be using a RTSP server.
ok, thank you for your advice.
But where can I specify SPS and PPS NAL ? When I try to connect with my 
client to "rtsp://localhost:1025/liveMedia0", it say me "waiting for 
SPS/PPS".
I think I specify this in my RTSPServer, but I do not know where exactly 
( This is maybe a attribute of a ServerMediaSession or must I create a 
sdp file ?)

Thank you for your help.




From finlayson at live555.com  Fri Nov 20 06:56:29 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 20 Nov 2009 06:56:29 -0800
Subject: [Live-devel] problem when outputting raw H264 stream
In-Reply-To: <4B06759D.9080506@c-s.fr>
References: <873423.38079.qm@web114119.mail.gq1.yahoo.com>
	<f06240800c723a822d3c6@[66.80.62.44]>	<4B0652AA.1010008@c-s.fr>
	<f06240801c72c0c0fabd7@[66.80.62.44]> <4B06759D.9080506@c-s.fr>
Message-ID: <f06240800c72c5d984f47@[66.80.62.44]>

>But where can I specify SPS and PPS NAL ?

As the "sprop_parameter_sets_str" parameter to "H264VideoRTPSink::createNew()".

This (string) parameter is formed by
1/ encoding the SPS NAL unit with Base64 (note that we have a 
function "base64Encode()" that will do this for you),
2/ encoding the PPS NAL unit with Base64, and then
3/ concatenating the two strings together, separated by a comma (i.e. 
',') character

The resulting string should then be passed as the 
"sprop_parameter_sets_str" parameter to 
"H264VideoRTPSink::createNew()".
-- 

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

From finlayson at live555.com  Fri Nov 20 20:17:11 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 20 Nov 2009 20:17:11 -0800
Subject: [Live-devel] Please explain all these "@zeusmail.org" subscriptions
Message-ID: <f06240804c72d18627d61@[66.80.62.44]>

Over the last few days I've seen several people subscribe to this 
mailing list with "@zeusmail.org" email addresses.  I hadn't seen 
such addresses before, but a web search suggests that such addresses 
might be used by spammers.

Because of this, could someone who's subscribed with such an address 
please send a brief note to this list, saying who you are, and what 
organization or school you belong to.  (Note that, in general, 
questions posted by people using unprofessional hobbyist email 
addresses - e.g., "@hotmail", "@yahoo" , "@gmail" etc. - are 
considered very low priority, and often do not get responded to.)

If noone with a "@zeusmail.org" email address responds within the 
next day or so, I'll remove all of these addresses from the mailing 
list.
-- 

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

From ottavio at videotec.com  Wed Nov 25 06:43:37 2009
From: ottavio at videotec.com (Ottavio Campana)
Date: Wed, 25 Nov 2009 15:43:37 +0100
Subject: [Live-devel] question about streaming h264 video and binary data
Message-ID: <4B0D4299.5090802@videotec.com>

I implemented an RTSP server with live555 to stream a h264 video and it
works well.

Now I would like to stream some custom data with the video stream, thus
I wrote a subclass of DeviceSource that feeds the custom data to a
subclass of OnDemandServerMediaSubsession .

When I try to play the stream with a "normal" player such as mplayer or
vlc I expect them to drop the auxiliary binary data and to display the
h264-encoded video. But it does not work, it seams packets are not
correctly received (dropped?).

Do you think that this problem can be related to the way I stream video
and data? Did you ever stream binary data with live555?

Here is the SDP of what I'm trying to stream

Opened URL "rtsp://192.168.0.100:8554/video_stream", returning a SDP
description:
v=0
o=- 1259156055210752 1 IN IP4 192.168.0.100
s=Video session
i=LIVE555 Streaming Media v
t=0 0
a=tool:LIVE555 Streaming Media v2009.06.02
a=type:broadcast
a=control:*
a=source-filter: incl IN IP4 * 192.168.0.100
a=rtcp-unicast: reflection
a=range:npt=0-
a=x-qt-text-nam:Video session
a=x-qt-text-inf:LIVE555 Streaming Media v
m=video 18888 RTP/AVP 96
c=IN IP4 232.83.250.127/255
a=rtpmap:96 H264/90000
a=fmtp:96
packetization-mode=1;profile-level-id=000042;sprop-parameter-sets=Z0KAHtoC0EkQ,aM48gA==
a=control:track1
m=application 18892 RTP/AVP 97
c=IN IP4 232.83.250.127/255
a=rtpmap:97 MYDATA/90000
a=control:track2

Created receiver for "video/H264" subsession (client ports 18888-18889)
Unable to create receiver for "application/MYDATA" subsession: RTP
payload format unknown or not supported
Setup "video/H264" subsession (client ports 18888-18889)
Created output file: "video-H264-1"
Started playing session
Receiving streamed data (signal with "kill -HUP 11927" or "kill -USR1
11927" to terminate)...

From belloni at imavis.com  Wed Nov 25 08:55:43 2009
From: belloni at imavis.com (Cristiano Belloni)
Date: Wed, 25 Nov 2009 17:55:43 +0100
Subject: [Live-devel] GET_PARAMETERS used as a ping request and VLC
Message-ID: <4B0D618F.1050709@imavis.com>

Hi to all,

I've got a liveMedia RTSP server and VLC as a client. I need the server 
to stream on TCP (and so, use the RTSP connection to stream video).

What happens is that VLC sends GET_PARAMETERS rtsp commands with empty 
body to the server during streaming.
The server does not respond to this command, because liveMedia is unable 
to process rtsp commands after a play, as stated here: 
http://www.mail-archive.com/live-devel at lists.live555.com/msg00651.html 
by Ross:

> Note, though, that if you requested RTP-over-TCP streaming, then 
> (because of software limitations) the server will not see any RTSP 
> requests after "PLAY".  However, incoming RTCP "RR" packets will 
> always be handled (and used to indicate client liveness).
>   

Maybe vlc is sending GET_PARAMETERS to "ping" the server, as stated in 
RFC 2326 par. 10.8. The problem is that, since the server simply does 
not respond, VLC seems to conclude that the server is dead and discards 
packets with the infamous "Discarding interleaved RTP or RTCP packet".

Now, server OPTIONS' response is: Public: OPTIONS, DESCRIBE, SETUP, 
TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER.
I think it's not quite correct not answering the client GET_PARAMETER 
requests, since this option is publicized in the OPTIONS response, but I 
understand it's a major limit in liveMedia RTSP/TCP design, and nothing 
can be done.

My questions are:

1) Is there a way to change the OPTIONS response? Maybe if we don't 
publicize the GET_PARAMETER option, vlc client won't try to use it, only 
to find the server unable to handle it after a PLAY.

2) Is there some other work-around for this situation? Please note I 
can't change VLC code, as we don't distribute VLC, but let every client 
download it (its browser-plugin, in fact) straight from the site. 
Conversely, I cant' just switch to UDP, as TCP streaming is the only 
things that just works in case of blocking firewalls, routers, and all 
the sweet things you can encounter on the modern Internet.

Thanks,
Best Regards,
Cristiano Belloni.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>

From a.nemec at atlas.cz  Wed Nov 25 07:28:12 2009
From: a.nemec at atlas.cz (=?utf-8?B?TsSbbWVjIEFsZXhhbmRy?=)
Date: Wed, 25 Nov 2009 15:28:12 GMT
Subject: [Live-devel] 64 bit portability
Message-ID: <5316c4af65874cb1aaf5e4e5c289533c@584e4fceeffd4e11829579c64f6b777c>

An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091125/8d7045eb/attachment.html>
-------------- next part --------------
Hi Live555 community,
I have successfully compiled Live555 media library on Windows using VS2005. My question is as follows: Is the Live555 media library fully 64 bit compatible? I am asking because the VS 2005 compiler detects a lot of 64 bit portability issues and presents them as warnings. Also, if you look into the code, you will find a lot of lines with type casts between pointers and 32-bit ints or vice versa. This can be (not necessarily) dangerous when running the library on a 64 bit platform. Does anybody know more about the 64 bit portability?
Best regads
Alex

From finlayson at live555.com  Wed Nov 25 15:58:47 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 25 Nov 2009 15:58:47 -0800
Subject: [Live-devel] 64 bit portability
In-Reply-To: <5316c4af65874cb1aaf5e4e5c289533c@584e4fceeffd4e11829579c64f6b777c>
References: <5316c4af65874cb1aaf5e4e5c289533c@584e4fceeffd4e11829579c64f6b777c>
Message-ID: <f06240803c73374dab4d1@[66.80.62.44]>

>I have successfully compiled Live555 media library on Windows using 
>VS2005. My question is as follows: Is the Live555 media library 
>fully 64 bit compatible? I am asking because the VS 2005 compiler 
>detects a lot of 64 bit portability issues and presents them as 
>warnings. Also, if you look into the code, you will find a lot of 
>lines with type casts between pointers and 32-bit ints or vice 
>versa. This can be (not necessarily) dangerous when running the 
>library on a 64 bit platform. Does anybody know more about the 64 
>bit portability?

The code is intended to be portable to 64-bit systems, and several 
other people have compiled and run the code on 64-bit systems (though 
I haven't yet done this myself).

If you (or anyone else) discovers any 64-bit problems with the code, 
please let us know.
-- 

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

From finlayson at live555.com  Wed Nov 25 16:19:30 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 25 Nov 2009 16:19:30 -0800
Subject: [Live-devel] question about streaming h264 video and binary data
In-Reply-To: <4B0D4299.5090802@videotec.com>
References: <4B0D4299.5090802@videotec.com>
Message-ID: <f06240804c7337919b397@[66.80.62.44]>

>Now I would like to stream some custom data with the video stream, thus
>I wrote a subclass of DeviceSource that feeds the custom data to a
>subclass of OnDemandServerMediaSubsession .
>
>When I try to play the stream with a "normal" player such as mplayer or
>vlc I expect them to drop the auxiliary binary data and to display the
>h264-encoded video. But it does not work, it seams packets are not
>correctly received (dropped?).

If you want to stream 'custom data' that isn't in the form of H.264 
NAL units, then you can't include this data in the H.264 RTP packets 
(because any receiver of these packets will expect the data to be 
formatted according to the standard RTP payload format for H.264 
video).  Instead, you must use a separate RTP payload format number, 
and a separate port number, and a separate "m=" line in the SDP 
description.

In any case, I'm going to give support only for standard RTP payload formats.
-- 

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

From finlayson at live555.com  Wed Nov 25 16:28:11 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 25 Nov 2009 16:28:11 -0800
Subject: [Live-devel] GET_PARAMETERS used as a ping request and VLC
In-Reply-To: <4B0D618F.1050709@imavis.com>
References: <4B0D618F.1050709@imavis.com>
Message-ID: <f06240805c7337aca191c@[66.80.62.44]>

>1) Is there a way to change the OPTIONS response?

Yes, by modifying the code in "RTSPServer.cpp" :-)

Until we fix the problem (at least at the server end), that's the 
only way I can see to overcome this issue - unless VLC is fixed to 
not use "GET_PARAMETER" as a client liveness indicator.  It doesn't 
really need to do this, because RTCP already acts as a (much better) 
client liveness indicator.  But perhaps the VLC developers did this 
in order to support some other (broken) server implementation that 
didn't recognize RTCP "RR" packets from the clients??
-- 

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

From ottavio at videotec.com  Thu Nov 26 00:47:54 2009
From: ottavio at videotec.com (Ottavio Campana)
Date: Thu, 26 Nov 2009 09:47:54 +0100
Subject: [Live-devel] question about streaming h264 video and binary data
In-Reply-To: <f06240804c7337919b397@[66.80.62.44]>
References: <4B0D4299.5090802@videotec.com>
	<f06240804c7337919b397@[66.80.62.44]>
Message-ID: <4B0E40BA.7060304@videotec.com>

Ross Finlayson ha scritto:
>> Now I would like to stream some custom data with the video stream, thus
>> I wrote a subclass of DeviceSource that feeds the custom data to a
>> subclass of OnDemandServerMediaSubsession .
>>
>> When I try to play the stream with a "normal" player such as mplayer or
>> vlc I expect them to drop the auxiliary binary data and to display the
>> h264-encoded video. But it does not work, it seams packets are not
>> correctly received (dropped?).
> 
> If you want to stream 'custom data' that isn't in the form of H.264 NAL 
> units, then you can't include this data in the H.264 RTP packets 
> (because any receiver of these packets will expect the data to be 
> formatted according to the standard RTP payload format for H.264 
> video).  Instead, you must use a separate RTP payload format number, and 
> a separate port number, and a separate "m=" line in the SDP description.
> 
> In any case, I'm going to give support only for standard RTP payload 
> formats.

Thanks Ross for the answer, I don't want to bother you with my 
implementation, but maybe you can give me a hint about what I should 
expect from the RTP protocol.

I mean, the SDP already does what you said:

Opened URL "rtsp://192.168.0.100:8554/video_stream", returning a SDP
description:
v=0
o=- 1259156055210752 1 IN IP4 192.168.0.100
s=Video session
i=LIVE555 Streaming Media v
t=0 0
a=tool:LIVE555 Streaming Media v2009.06.02
a=type:broadcast
a=control:*
a=source-filter: incl IN IP4 * 192.168.0.100
a=rtcp-unicast: reflection
a=range:npt=0-
a=x-qt-text-nam:Video session
a=x-qt-text-inf:LIVE555 Streaming Media v
m=video 18888 RTP/AVP 96
c=IN IP4 232.83.250.127/255
a=rtpmap:96 H264/90000
a=fmtp:96
packetization-mode=1;profile-level-id=000042;sprop-parameter-sets=Z0KAHtoC0EkQ,aM48gA==
a=control:track1
m=application 18892 RTP/AVP 97
c=IN IP4 232.83.250.127/255
a=rtpmap:97 MYDATA/90000
a=control:track2

and in fact, I defined a dinamic payload such as in the case of H264 
also for the data.

I tried following the stream with wireshark, and packets are sent 
correctly every 40ms, one for H264 and one for data. The only thing that 
surprises me is that the same sequence for the number of the packets is 
used for the two streams. Thus, h264 packets have even sequence number 
and data packets have odd sequence number. Is this correct for the 
protocol? Or can this be the reason why the client does not receive the 
video stream correctly, maybe thinking that half of the packets are lost?

Ottavio

From ottavio at videotec.com  Thu Nov 26 01:10:24 2009
From: ottavio at videotec.com (Ottavio Campana)
Date: Thu, 26 Nov 2009 10:10:24 +0100
Subject: [Live-devel] question about streaming h264 video and binary data
In-Reply-To: <4B0E40BA.7060304@videotec.com>
References: <4B0D4299.5090802@videotec.com>	<f06240804c7337919b397@[66.80.62.44]>
	<4B0E40BA.7060304@videotec.com>
Message-ID: <4B0E4600.8080909@videotec.com>

Ottavio Campana ha scritto:
> I tried following the stream with wireshark, and packets are sent 
> correctly every 40ms, one for H264 and one for data. The only thing that 
> surprises me is that the same sequence for the number of the packets is 
> used for the two streams. Thus, h264 packets have even sequence number 
> and data packets have odd sequence number. Is this correct for the 
> protocol? Or can this be the reason why the client does not receive the 
> video stream correctly, maybe thinking that half of the packets are lost?

By the way, by reading RFC 3550 at ?5.2 there's written

"separate audio and video streams SHOULD NOT be carried in a single RTP 
session and demultiplexed based on the payload type or SSRC fields."

How can this be achieved with live555? I currently have a single 
ServerMediaSession, with two PassiveServerMediaSubsession, one for video 
and one for data. Is this correct or should I create two ServerMediaSession?

Ottavio

From belloni at imavis.com  Thu Nov 26 09:21:54 2009
From: belloni at imavis.com (Cristiano Belloni)
Date: Thu, 26 Nov 2009 18:21:54 +0100
Subject: [Live-devel] GET_PARAMETERS used as a ping request and VLC
In-Reply-To: <f06240805c7337aca191c@[66.80.62.44]>
References: <4B0D618F.1050709@imavis.com> <f06240805c7337aca191c@[66.80.62.44]>
Message-ID: <4B0EB932.5010500@imavis.com>

Ross Finlayson wrote:
>> 1) Is there a way to change the OPTIONS response?
>
> Yes, by modifying the code in "RTSPServer.cpp" :-)
>
> Until we fix the problem (at least at the server end), that's the only 
> way I can see to overcome this issue - unless VLC is fixed to not use 
> "GET_PARAMETER" as a client liveness indicator.  It doesn't really 
> need to do this, because RTCP already acts as a (much better) client 
> liveness indicator.  But perhaps the VLC developers did this in order 
> to support some other (broken) server implementation that didn't 
> recognize RTCP "RR" packets from the clients??
Yes, indeed.

The smart implementation on VLC part would be falling back on SR checks 
for liveness if the server does not respond to GET_PARAMETER.
I will try to file a bug, but I bet I'll have an hard time, because 
formally VLC developers are right (if the option is listed, VLC has the 
right to use it), even if it's a brain-dead schema.

Regards,
Cristiano.


-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>

From slaine at slaine.org  Thu Nov 26 03:38:09 2009
From: slaine at slaine.org (Glen Gray)
Date: Thu, 26 Nov 2009 11:38:09 +0000
Subject: [Live-devel] GET_PARAMETERS used as a ping request and VLC
In-Reply-To: <f06240805c7337aca191c@[66.80.62.44]>
References: <4B0D618F.1050709@imavis.com> <f06240805c7337aca191c@[66.80.62.44]>
Message-ID: <4B0E68A1.8070103@slaine.org>

On 26/11/09 00:28, Ross Finlayson wrote:
> Yes, by modifying the code in "RTSPServer.cpp" :-)
>
> Until we fix the problem (at least at the server end), that's the only 
> way I can see to overcome this issue - unless VLC is fixed to not use 
> "GET_PARAMETER" as a client liveness indicator.  It doesn't really 
> need to do this, because RTCP already acts as a (much better) client 
> liveness indicator.  But perhaps the VLC developers did this in order 
> to support some other (broken) server implementation that didn't 
> recognize RTCP "RR" packets from the clients??

Yes, the K word would follow here. However, if I recall correctly, it 
only ever sends the GET_PARAMETER messages as a keep alive if the server 
reports back a timeout value as part of the setup.

-- 
Glen Gray<slaine at slaine.org>
http://slaine.org


From a.nemec at atlas.cz  Wed Nov 25 22:21:27 2009
From: a.nemec at atlas.cz (=?utf-8?B?TsSbbWVjIEFsZXhhbmRy?=)
Date: Thu, 26 Nov 2009 06:21:27 GMT
Subject: [Live-devel] openrtsp
Message-ID: <f30d3984b3ca4dcaa31c689a30e2e087@ecf3bf4a4d2c456ca3f78e1aff6d0f2a>

An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091126/e521b905/attachment.html>
-------------- next part --------------
Hi all,
I have built and tested the openrtsp command line utility. It works fine for most of the most commonly used payload formats. I also tried to use the -t and -T options to use a RTP over RTSP (or HTTP) tunnel and again it works very nice. My question is as follows - I have a special camera with in-built RTSP server and I can receive video with no problems. According to the camera manufacturer they also support the TCP tunnel but when I use the -t option some error ocurrs (see below). Does anybody recognize whats wrong here? Thanks in advance. I am afraid it can be a firmware problem of the camera.
D:\Resources\LiveMedia\testProgs>openrtsp -t rtsp://10.0.0.122/ioImage/1
Sending request: OPTIONS rtsp://10.0.0.122/ioImage/1 RTSP/1.0
CSeq: 1
User-Agent: openrtsp (LIVE555 Streaming Media v2009.09.28)
Received OPTIONS response: RTSP/1.0 200 OK
Server: IOImage RTSP Server
CSeq: 1
Public: DESCRIBE,SETUP,TEARDOWN,PLAY,PAUSE
Sending request: DESCRIBE rtsp://10.0.0.122/ioImage/1 RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: openrtsp (LIVE555 Streaming Media v2009.09.28)
Received DESCRIBE response: RTSP/1.0 200 OK
Server: IOImage RTSP Server
CSeq: 2
Content-Type: application/sdp
Content-Length: 190
Need to read 190 extra bytes
Read 190 extra bytes: v=0
o=- 1 1 IN IP4 127.0.0.1
s=RTP session
e=NONE
b=RR:0
t=0 0
m=video 0 RTP/AVP 26
a=rtpmap:26 JPEG/1000
a=framerate:25
a=x-dimensions:352,288
a=x-algoTarget:P
a=control:video
Opened URL "rtsp://10.0.0.122/ioImage/1", returning a SDP description:
v=0
o=- 1 1 IN IP4 127.0.0.1
s=RTP session
e=NONE
b=RR:0
t=0 0
m=video 0 RTP/AVP 26
a=rtpmap:26 JPEG/1000
a=framerate:25
a=x-dimensions:352,288
a=x-algoTarget:P
a=control:video
Created receiver for "video/JPEG" subsession (client ports 1450-1451)
Sending request: SETUP rtsp://10.0.0.122/ioImage/1/video RTSP/1.0
CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: openrtsp (LIVE555 Streaming Media v2009.09.28)
Received SETUP response: RTSP/1.0 200 OK
Server: IOImage RTSP Server
CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;server_port=0;ssrc=0000167e
x-Dynamic_Rate: 1
Session: 3830
Setup "video/JPEG" subsession (client ports 1450-1451)
Created output file: "video-JPEG-1"
Sending request: PLAY rtsp://10.0.0.122/ioImage/1 RTSP/1.0
CSeq: 4
Session: 3830
Range: npt=0.000-
User-Agent: openrtsp (LIVE555 Streaming Media v2009.09.28)
Discarding interleaved RTP or RTCP packet (48133 bytes, channel id 0)
Received PLAY response: ?H???2???K???????%&shy;??????>/?&amp;?sC>\?=???W?`O??>???=?5???
?d????h??;WR????x?h?????"?5OSK?t?|9&shy;?R???????????-q?????#????&shy;????<W 
Failed to start playing session: no response code in line: "?H???2???K???????%&shy;
?????>/?&amp;?sC>\?=???W?`O??>???=?5?????d????h??;WR????x?h?????"?5OSK?t?|9&shy;?R?????
?????-q?????#????&shy;????<W "
Sending request: TEARDOWN rtsp://10.0.0.122/ioImage/1 RTSP/1.0
CSeq: 5
Session: 3830
User-Agent: openrtsp (LIVE555 Streaming Media v2009.09.28)

From finlayson at live555.com  Thu Nov 26 12:29:25 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 26 Nov 2009 12:29:25 -0800
Subject: [Live-devel] openrtsp
In-Reply-To: <f30d3984b3ca4dcaa31c689a30e2e087@ecf3bf4a4d2c456ca3f78e1aff6d0f2a>
References: <f30d3984b3ca4dcaa31c689a30e2e087@ecf3bf4a4d2c456ca3f78e1aff6d0f2a>
Message-ID: <f06240802c73494a7b049@[66.80.62.44]>

>I have built and tested the openrtsp command 
>line utility. It works fine for most of the most 
>commonly used payload formats. I also tried to 
>use the -t and -T options to use a RTP over RTSP 
>(or HTTP) tunnel and again it works very nice. 
>My question is as follows - I have a special 
>camera with in-built RTSP server and I can 
>receive video with no problems. According to the 
>camera manufacturer they also support the TCP 
>tunnel but when I use the -t option some error 
>ocurrs (see below). Does anybody recognize whats 
>wrong here? Thanks in advance. I am afraid it 
>can be a firmware problem of the camera.

[...]


>Sending request: PLAY rtsp://10.0.0.122/ioImage/1 RTSP/1.0
>CSeq: 4
>Session: 3830
>Range: npt=0.000-
>User-Agent: openrtsp (LIVE555 Streaming Media v2009.09.28)
>
>
>Discarding interleaved RTP or RTCP packet (48133 bytes, channel id 0)
>Received PLAY response: 
>?H?????2????K???????%????????>/??&?sC>\?=????W?`O???>????=?5????
>??d?????h??;WR???????x?h??????"?5OSK?t??|9???R???????????????-q?????????#??????????'Failed 
>to start playing session: no response code in 
>line: "?H?????2????K???????%??
>?????>/??&?sC>\?=????W?`O???>????=?5????????d?????h??;WR???????x?h??????"?5OSK?t??|9???R?????????
>?????-q?????????#??????????'

Yes, there seems to be a problem with your 
server's implementation of RTP-over-TCP.  In this 
mode, your server is apparently not sending back 
a response to the client's "PLAY" command. 
Instead, it appears to start sending back 
RTP/RTCP data over the RTSP (TCP) connection, but 
without first sending back a response to the 
"PLAY" command.

You will need to contact your server manufacturer 
to get this fixed (perhaps a firmware upgrade is 
available?).
-- 

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/20091126/bc67481a/attachment-0001.html>

From belloni at imavis.com  Fri Nov 27 02:00:56 2009
From: belloni at imavis.com (Cristiano Belloni)
Date: Fri, 27 Nov 2009 11:00:56 +0100
Subject: [Live-devel] GET_PARAMETERS used as a ping request and VLC
In-Reply-To: <4B0E68A1.8070103@slaine.org>
References: <4B0D618F.1050709@imavis.com> <f06240805c7337aca191c@[66.80.62.44]>
	<4B0E68A1.8070103@slaine.org>
Message-ID: <4B0FA358.1000803@imavis.com>

Glen Gray wrote:
> On 26/11/09 00:28, Ross Finlayson wrote:
>> Yes, by modifying the code in "RTSPServer.cpp" :-)
>>
>> Until we fix the problem (at least at the server end), that's the 
>> only way I can see to overcome this issue - unless VLC is fixed to 
>> not use "GET_PARAMETER" as a client liveness indicator.  It doesn't 
>> really need to do this, because RTCP already acts as a (much better) 
>> client liveness indicator.  But perhaps the VLC developers did this 
>> in order to support some other (broken) server implementation that 
>> didn't recognize RTCP "RR" packets from the clients??
>
> Yes, the K word would follow here. However, if I recall correctly, it 
> only ever sends the GET_PARAMETER messages as a keep alive if the 
> server reports back a timeout value as part of the setup.
>
That's good news. Eventually, how could one choose not to send the 
timeout value? RTSPServer.cpp modify or there's a better solution?

Regards,
Cristiano.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>

From finlayson at live555.com  Fri Nov 27 02:29:07 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 27 Nov 2009 02:29:07 -0800
Subject: [Live-devel] GET_PARAMETERS used as a ping request and VLC
Message-ID: <f06240803c73559bcf262@[66.80.62.44]>

>Glen Gray wrote:
>>On 26/11/09 00:28, Ross Finlayson wrote:
>>>Yes, by modifying the code in "RTSPServer.cpp" :-)
>>>
>>>Until we fix the problem (at least at the server end), that's the 
>>>only way I can see to overcome this issue - unless VLC is fixed to 
>>>not use "GET_PARAMETER" as a client liveness indicator.  It 
>>>doesn't really need to do this, because RTCP already acts as a 
>>>(much better) client liveness indicator.  But perhaps the VLC 
>>>developers did this in order to support some other (broken) server 
>>>implementation that didn't recognize RTCP "RR" packets from the 
>>>clients??
>>
>>Yes, the K word would follow here. However, if I recall correctly, 
>>it only ever sends the GET_PARAMETER messages as a keep alive if 
>>the server reports back a timeout value as part of the setup.
>>
>That's good news. Eventually, how could one choose not to send the 
>timeout value? RTSPServer.cpp modify or there's a better solution?

Glen was talking about a 'Kasenna' server, I think.  Our RTSP server 
implementation *does not* specify a "timeout =" parameter at all.

Anyway, I've now installed a new version (2009.11.27) of the code 
that hacks the RTSP server's "OPTIONS" response to *not* include 
"GET_PARAMETER" in the list of available commands.  This will stop 
VLC from using "GET_PARAMETER" as a client 'liveness' indicator, 
which we don't need, because we already use the client's RTCP "RR" 
packets as a 'liveness' indicator.

(This hack will be removed when we fix the problem with RTP-over-TCP 
(RSN, I hope).)
-- 

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

From finlayson at live555.com  Fri Nov 27 03:05:29 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 27 Nov 2009 03:05:29 -0800
Subject: [Live-devel] question about streaming h264 video and binary data
In-Reply-To: <4B0E40BA.7060304@videotec.com>
References: <4B0D4299.5090802@videotec.com>
	<f06240804c7337919b397@[66.80.62.44]> <4B0E40BA.7060304@videotec.com>
Message-ID: <f06240804c735621ce8ef@[66.80.62.44]>

>The only thing that surprises me is that the same sequence for the 
>number of the packets is used for the two streams. Thus, h264 
>packets have even sequence number and data packets have odd sequence 
>number.

The only way this could happen is if you are using the same "RTPSink" 
(subclass) object for the two streams.  You cannot do this!  Each 
stream must have separate "groupsock" objects, "RTPSink" objects, and 
"RTCPInstance" objects.


>I currently have a single ServerMediaSession, with two 
>PassiveServerMediaSubsession, one for video and one for data. Is 
>this correct

Yes.  However, as noted above, you *must* use separate "RTPSink" and 
"RTCPInstance" objects for each subsession.

-- 

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

From belloni at imavis.com  Fri Nov 27 03:25:54 2009
From: belloni at imavis.com (Cristiano Belloni)
Date: Fri, 27 Nov 2009 12:25:54 +0100
Subject: [Live-devel] GET_PARAMETERS used as a ping request and VLC
In-Reply-To: <f06240803c73559bcf262@[66.80.62.44]>
References: <f06240803c73559bcf262@[66.80.62.44]>
Message-ID: <4B0FB742.7050909@imavis.com>

Ross Finlayson wrote:
>> Glen Gray wrote:
>>> On 26/11/09 00:28, Ross Finlayson wrote:
>>>> Yes, by modifying the code in "RTSPServer.cpp" :-)
>>>>
>>>> Until we fix the problem (at least at the server end), that's the 
>>>> only way I can see to overcome this issue - unless VLC is fixed to 
>>>> not use "GET_PARAMETER" as a client liveness indicator.  It doesn't 
>>>> really need to do this, because RTCP already acts as a (much 
>>>> better) client liveness indicator.  But perhaps the VLC developers 
>>>> did this in order to support some other (broken) server 
>>>> implementation that didn't recognize RTCP "RR" packets from the 
>>>> clients??
>>>
>>> Yes, the K word would follow here. However, if I recall correctly, 
>>> it only ever sends the GET_PARAMETER messages as a keep alive if the 
>>> server reports back a timeout value as part of the setup.
>>>
>> That's good news. Eventually, how could one choose not to send the 
>> timeout value? RTSPServer.cpp modify or there's a better solution?
>
> Glen was talking about a 'Kasenna' server, I think.  Our RTSP server 
> implementation *does not* specify a "timeout =" parameter at all.
>
> Anyway, I've now installed a new version (2009.11.27) of the code that 
> hacks the RTSP server's "OPTIONS" response to *not* include 
> "GET_PARAMETER" in the list of available commands.  This will stop VLC 
> from using "GET_PARAMETER" as a client 'liveness' indicator, which we 
> don't need, because we already use the client's RTCP "RR" packets as a 
> 'liveness' indicator.
>
> (This hack will be removed when we fix the problem with RTP-over-TCP 
> (RSN, I hope).)
Great! Thank you!

Regards,
Cristiano.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>

From yooval.from.elta at gmail.com  Mon Nov 30 06:21:24 2009
From: yooval.from.elta at gmail.com (Yooval Shabi)
Date: Mon, 30 Nov 2009 16:21:24 +0200
Subject: [Live-devel] Problem connecting openRTSP to VLC
Message-ID: <91a92a830911300621o49832057pf58b269cceb642@mail.gmail.com>

I'm new to the subject of RTP and streaming and I plan to use live555 as
part of the application I develop.
My RTP server is VLC player which streams an mp3 file.
When I try to connect with the openRTSP I get an error as follows:
Failed to get a SDP description from URL "rtsp://128.129.83.38:6666":
connect() failed: Unknown error

Can you please help me?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091130/720a2bfc/attachment.html>

From finlayson at live555.com  Mon Nov 30 17:55:08 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 30 Nov 2009 17:55:08 -0800
Subject: [Live-devel] Problem connecting openRTSP to VLC
In-Reply-To: <91a92a830911300621o49832057pf58b269cceb642@mail.gmail.com>
References: <91a92a830911300621o49832057pf58b269cceb642@mail.gmail.com>
Message-ID: <f06240800c73a27b19ba2@[66.80.62.44]>

>My RTP server is VLC player which streams an mp3 file.
>When I try to connect with the openRTSP I get an error as follows:
>Failed to get a SDP description from URL 
>"rtsp://<http://128.129.83.38:6666>128.129.83.38:6666": connect() 
>failed: Unknown error

Do you get the same error if you use "testOnDemandRTSPServer" (with a 
file named "test.mp3") or "live555MediaServer" as your server?

Also, what OS are you running?
-- 

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/20091130/77a1e80d/attachment.html>

From galaxy at novosun.com  Mon Nov 30 18:30:23 2009
From: galaxy at novosun.com (Kam Wai-ip)
Date: Tue, 1 Dec 2009 10:30:23 +0800
Subject: [Live-devel] Problem when streaming large size frames
In-Reply-To: <mailman.2437.1259578132.854.live-devel@lists.live555.com>
References: <mailman.2437.1259578132.854.live-devel@lists.live555.com>
Message-ID: <3e8c80350911301830y12b4445egc601bc6dbcfb7118@mail.gmail.com>

Hi, I am currently working on something that needs to streaming live mjpeg,
mpeg4 and h264 videos to client player(usually mplayer).
My program gets number of frames of one the those three videos per second,
it works very well when the frame size is small.
However, when the size of frame increased(by increasing resolution, bitrate
and framerate), but it no longer run smoothly anymore, which i get lots
glitches on mplayer, this problem usually happen on h264 and mpeg4, it seems
mjpeg still works fine.
Therefore I use openRTSP to record the video into avi file, but no luck.
Is there anything to do about the performance of live555? I cant really
figure out the problem, please help.
Thanks for your time
Wai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20091201/5a29ebfe/attachment.html>

From kevin.liu at innosofts.com  Mon Nov 30 21:24:39 2009
From: kevin.liu at innosofts.com (Kevin.Liu)
Date: Tue, 1 Dec 2009 13:24:39 +0800
Subject: [Live-devel] no readable socket for select() problem
Message-ID: <000c01ca7246$95c36c10$c14a4430$@liu@innosofts.com>

Hi  everybody ,

   I have migrated the live555 to wince(wm6.1) and I can send rtsp request
also can get the sdp response but I cannot receive any media data from the
live555 rtsp server. And I found that the select() function of the
BasicTaskScheduler::SingleStep() always return '0' not matter what is the
value of timeval . It means no socket is readable but I used 'wireshark' to
see the detail network information and I found the server has sent the media
data to me but the select() also return 0. I am really confused . Do you get
the same problem ? if so ,please give me some help. J

Thank you first.

 

Best regards,

Kevin Liu

 

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

From sukhbir.singh20 at gmail.com  Mon Nov 30 20:31:18 2009
From: sukhbir.singh20 at gmail.com (Sukhbir Singh)
Date: Tue, 1 Dec 2009 10:01:18 +0530
Subject: [Live-devel] AMR RTP Payload Vs AMR Interface Format
Message-ID: <3b2878e60911302031n116bd49q6a9d98bfcf9bab83@mail.gmail.com>

Hi All,

   Can someone define the difference between RTP Payload for AMR
(Bandwidth Efficient & Octet Aligned) and AMR Interface Format (IF1 &
IF2).
   Any help would be appreciable.

Thanks in Advance.

From vim.garg at gmail.com  Mon Nov 30 20:56:08 2009
From: vim.garg at gmail.com (Vimal Garg)
Date: Tue, 1 Dec 2009 10:26:08 +0530
Subject: [Live-devel] setAuxilliaryReadHandler: Core dumps
In-Reply-To: <2faaac140911300151x2da5f9beg622c25cb17764c8c@mail.gmail.com>
References: <2faaac140911300151x2da5f9beg622c25cb17764c8c@mail.gmail.com>
Message-ID: <2faaac140911302056p28ede19w7df81edeaefd1b0d@mail.gmail.com>

Hi,

I am working on a project where I need to record video from an IP camera and
process it. My job is to capture the stream and pass it on to next module.

After long discussion and research we had decided to make use of live555
stack as it is widely used (and tested). I have gone through the
openRTSP.cpp which actually saves all the streams to a file. I do not want
to record streams in a file and read from the file as this will have
latency.

I believe it is possible to have the streams in buffer but not clear how? I
went through RTPSource class which has a function
pointer setAuxilliaryReadHandler(). As I understand this is for registering
a handler for processing RTP read.

so I did the following in my code.

RTPSource *rtp = subsession->rtpSource();
rtp->setAuxilliaryReadHandler(ReadRTPPacket, clientData);

I was surprised when I ran my program. It crashed at above line. Can anyone
help me out with this issue.

Thanks in advance.

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

From finlayson at live555.com  Mon Nov 30 22:24:13 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 30 Nov 2009 22:24:13 -0800
Subject: [Live-devel] Problem when streaming large size frames
In-Reply-To: <3e8c80350911301830y12b4445egc601bc6dbcfb7118@mail.gmail.com>
References: <mailman.2437.1259578132.854.live-devel@lists.live555.com>
	<3e8c80350911301830y12b4445egc601bc6dbcfb7118@mail.gmail.com>
Message-ID: <f06240802c73a66f03d0a@[66.80.62.44]>

You're probably seeing packet loss; see 
http://www.live555.com/liveMedia/faq.html#packet-loss
-- 

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

From finlayson at live555.com  Mon Nov 30 22:46:09 2009
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 30 Nov 2009 22:46:09 -0800
Subject: [Live-devel] setAuxilliaryReadHandler: Core dumps
In-Reply-To: <2faaac140911302056p28ede19w7df81edeaefd1b0d@mail.gmail.com>
References: <2faaac140911300151x2da5f9beg622c25cb17764c8c@mail.gmail.com>
	<2faaac140911302056p28ede19w7df81edeaefd1b0d@mail.gmail.com>
Message-ID: <f06240803c73a6b26399e@[66.80.62.44]>

>I believe it is possible to have the streams in buffer but not clear 
>how? I went through RTPSource class which has a function 
>pointer setAuxilliaryReadHandler(). As I understand this is for 
>registering a handler for processing RTP read.

"setAuxilliaryReadHandler()" is a hack that should not be used.  I 
don't think anyone uses it anymore, and it will likely be removed 
from a future release of the code.  In any case, it provides access 
to raw RTP packets (i.e., including RTP headers) - and that's *not* 
what you want.


>After long discussion and research we had decided to make use of 
>live555 stack as it is widely used (and tested). I have gone through 
>the openRTSP.cpp which actually saves all the streams to a file. I 
>do not want to record streams in a file and read from the file as 
>this will have latency.

OK, then your solution is straightforward.  You need to write your 
own subclass of "MediaSink" that does whatever you want to do with 
the incoming data, and use that *instead of* "FileSink".

(Or, if your incoming stream is video-only (or audio-only), then you 
could use the "-v" (or "-a") option to "openRTSP", and pipe it into a 
separate application (that reads from stdin) that processes it.)
-- 

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

From galaxy at novosun.com  Mon Nov 30 23:45:15 2009
From: galaxy at novosun.com (Kam Wai-ip)
Date: Tue, 1 Dec 2009 15:45:15 +0800
Subject: [Live-devel] Problem when streaming large size frames
In-Reply-To: <f06240802c73a66f03d0a@66.80.62.44>
References: <mailman.2437.1259578132.854.live-devel@lists.live555.com>
	<3e8c80350911301830y12b4445egc601bc6dbcfb7118@mail.gmail.com>
	<f06240802c73a66f03d0a@66.80.62.44>
Message-ID: <3e8c80350911302345i7dcd681bk2dfdf817312d1d88@mail.gmail.com>

Yes, I guessed so, I saw significant frames loss, however, I did try to use
*increaseReceiveBufferTo() *in createRTPSink, but i did not see any
improvement, could you think of any other reasons that may cause this
problem, thx.

On Tue, Dec 1, 2009 at 2:24 PM, Ross Finlayson <finlayson at live555.com>wrote:

> You're probably seeing packet loss; see
> http://www.live555.com/liveMedia/faq.html#packet-loss
>
> --
>
> 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/20091201/7bfb944c/attachment.html>