From robin.penea at gmail.com  Wed Jan  2 07:04:35 2008
From: robin.penea at gmail.com (Robin Penea)
Date: Wed, 2 Jan 2008 16:04:35 +0100
Subject: [Live-devel] MPEG4 streaming source to FIFO/Buffer
Message-ID: <ad4c2ee20801020704u2810eee5j9a70de1005e1a0bb@mail.gmail.com>

Hi everyone,

I've been spending a few hours to find any technical solution to this
problem :

I want to send the MPEG4 stream I get from an IP Camera (Axis) to my piece
of software which does motion analysis.
Until now I've been able get the MPEG4 stream and save it to a file using a
sligthly modified version of openRTSP.
 Then I open the file in my program and I extract the frames using the
library OpenCV (in fact it uses ffmpeg to do it).
I have tried to do more or less the same using testMpeg1or2VideoReceiver,
but I can't see where i can input the username
and password (it is absolutely mandatory to have it for me) for the camera.

1. My goal is to avoid the file saving, because I need a live processing, so
I thought about using a named pipe... Could you
give me any clue about the subclasses I should create or modify ? I've read
about FramedSource and DeviceSource.. but
I'm not sure of which one I should modify. This library is quite big, and I
don't know from which side start !

2. My other question is about the named pipe... I also thought I should use
a "home made" buffer (a char* or anything...).
This way i could have a complete control on the flow of data (i already did
that in MJPEG). Linked to the preceding question,
what class should I study/modify/grow ? Can you tell me which solution is
the most reliable ?

3. Bonus question : do you think ffmpeg is able to decompress frames coming
from a buffer ? I made a few try on a file, but I have no ideas on
the behavior when it is in this particular context.

Thanks in advance.

-- 
Robin Penea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080102/69e9144b/attachment-0001.html 

From finlayson at live555.com  Wed Jan  2 14:39:50 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 2 Jan 2008 14:39:50 -0800
Subject: [Live-devel] MPEG4 streaming source to FIFO/Buffer
In-Reply-To: <ad4c2ee20801020704u2810eee5j9a70de1005e1a0bb@mail.gmail.com>
References: <ad4c2ee20801020704u2810eee5j9a70de1005e1a0bb@mail.gmail.com>
Message-ID: <f06240804c3a1c1c4ead1@[66.80.62.44]>

>I want to send the MPEG4 stream I get from an IP Camera (Axis) to my 
>piece of software which does motion analysis.
>Until now I've been able get the MPEG4 stream and save it to a file 
>using a sligthly modified version of openRTSP.
>  Then I open the file in my program and I extract the frames using 
>the library OpenCV (in fact it uses ffmpeg to do it).
>I have tried to do more or less the same using testMpeg1or2VideoReceiver

That will never work, because the stream is not MPEG-1 or MPEG-2 video.

>, but I can't see where i can input the username
>and password (it is absolutely mandatory to have it for me) for the camera.

You should continue to use "openRTSP", using the "-u <username> 
<password>" option.

>
>1. My goal is to avoid the file saving, because I need a live 
>processing, so I thought about using a named pipe... Could you
>give me any clue about the subclasses I should create or modify ?

You should not need to write any more LIVE555 code; "openRTSP" should 
already be able to give you what you want.  Just run it with the "-v" 
option, to tell it to output the receive video stream to 'stdout'. 
Then, write your analysis application so that it reads from 'stdin', 
and just run

	openRTSP -v -u username password  rtsp://whatever | 
your-analysis-application

Notice the "|" character, which tells the shell to pipe 'stdout' from 
"openRTSP" into 'stdin' of your-analysis-application.  You should not 
need 'named pipes' for this, if your analysis application reads from 
'stdin'.
-- 

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

From hanzheng at rogers.com  Wed Jan  2 11:17:52 2008
From: hanzheng at rogers.com (Zheng Han)
Date: Wed, 2 Jan 2008 14:17:52 -0500 (EST)
Subject: [Live-devel] Help
Message-ID: <782728.71506.qm@web88310.mail.re4.yahoo.com>

 Hi All:
  
 I am new to Live555. I am currently  working on a project that need to streaming multiple files one by one. Can any  body tell me how to implement this? I try to use stdin in a child process (I use  a pipe and redirect parent?s out to child?s in). The parent reads PS mpeg2 files  and writes them to the pipe one by one and the child reads from the pipe and  plays them. The child did play the file, but only played the first one. I hope  it can play them one by one as the parent writes them one by one.  
  
 Is there anything wrong with my  idea? Can anybody help me with this issue?
  
 BTW, my project is running on  WinXp.
  
 Thanks,
  
  
 Vincent  Han
  
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080102/d11cca6d/attachment.html 

From finlayson at live555.com  Wed Jan  2 15:12:22 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 2 Jan 2008 15:12:22 -0800
Subject: [Live-devel] Help
In-Reply-To: <782728.71506.qm@web88310.mail.re4.yahoo.com>
References: <782728.71506.qm@web88310.mail.re4.yahoo.com>
Message-ID: <f06240805c3a1ca95fbe0@[66.80.62.44]>

>I am new to Live555. I am currently working on a project that need 
>to streaming multiple files one by one. Can any body tell me how to 
>implement this?

The easiest way is to use the "ByteStreamMultiFileSource" class in 
place of "ByteStreamFileSource".
-- 

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/20080102/7be30f95/attachment.html 

From nikhiln at paxit.com  Wed Jan  2 15:25:03 2008
From: nikhiln at paxit.com (Nikhil Naik)
Date: Wed, 2 Jan 2008 17:25:03 -0600
Subject: [Live-devel] Unicast streaming over the Internet using LIVE555
Message-ID: <000601c84d96$b45372a0$1cfa57e0$@com>

Hi Ross,

 

I have developed a RTSP Server and I can get it to stream just fine

over the LAN. However when I try to stream over the internet, I see a 

connection but do not see an image come through. I can send commands 

to and fro. I can see the DESCRIBE, SETUP, PLAY and TEARDOWN pass just 

fine. 

 

Any idea what might be going on?  Any suggestions on setting up unicast 

streaming, since I have a feeling maybe I might not be getting it to stream 

Unicast and Multicast does not work for me with an external IP. Currently I 

am setting char* sessionAddressStr = "0.0.0.0"; as explained in post below, 

to force it to go unicast. Do I need to set different ports for unicast? 

 

http://www.livecaster.com/liveMedia/doxygen/html/testMPEG1or2VideoReceiver_8
cpp.html 

 

Also a point to not is that I m on Windows Vista OS and if this might in 

any way be blocking anything (I have all firewalls turned OFF).

 

Any help would be greatly appreciated,

 

Thanks,

 

Nikhil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080102/e698be23/attachment.html 

From finlayson at live555.com  Wed Jan  2 16:29:59 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 2 Jan 2008 16:29:59 -0800
Subject: [Live-devel] Unicast streaming over the Internet using LIVE555
In-Reply-To: <000601c84d96$b45372a0$1cfa57e0$@com>
References: <000601c84d96$b45372a0$1cfa57e0$@com>
Message-ID: <f06240800c3a1dca15579@[66.80.62.44]>

>I have developed a RTSP Server and I can get it to stream just fine
>over the LAN. However when I try to stream over the internet, I see a
>connection but do not see an image come through. I can send commands
>to and fro. I can see the DESCRIBE, SETUP, PLAY and TEARDOWN pass just
>fine.

Have you tried using our existing unicast RTSP server applications: 
"testOnDemandRTSPServer" and "live555MediaServer"?  Do those work for 
you?
-- 

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

From ntlkhuong at yahoo.com  Wed Jan  2 17:26:29 2008
From: ntlkhuong at yahoo.com (Khuong Nguyen)
Date: Wed, 2 Jan 2008 17:26:29 -0800 (PST)
Subject: [Live-devel] The quality of video is not good with streaming MPEG-2
Message-ID: <608350.34255.qm@web61025.mail.yahoo.com>



Hi , 


I tried the live555MediaServer.exe in window to stream
the MPEG-2 video  .

And then I used openRTSP commandlive to receive that
stream .

The result , I got the video-MPV-2 file and I used VLC
to watch .. 
The quality of this video is not good , there are many
green color on the video ..

I don't know what happened .. 

So , I tried with the MPEG-1 video , the quality is
better , no display green color ..


Could you show me the problem ???


Thanks a lot ..
Khuong




      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

From finlayson at live555.com  Wed Jan  2 17:30:39 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 2 Jan 2008 17:30:39 -0800
Subject: [Live-devel] The quality of video is not good with streaming
 MPEG-2
In-Reply-To: <608350.34255.qm@web61025.mail.yahoo.com>
References: <608350.34255.qm@web61025.mail.yahoo.com>
Message-ID: <f06240801c3a1eb0ab627@[66.80.62.44]>

>I tried the live555MediaServer.exe in window to stream
>the MPEG-2 video  .
>
>And then I used openRTSP commandlive to receive that
>stream .
>
>The result , I got the video-MPV-2 file and I used VLC
>to watch ..
>The quality of this video is not good , there are many
>green color on the video ..
>
>I don't know what happened ..
>
>So , I tried with the MPEG-1 video , the quality is
>better , no display green color ..
>
>
>Could you show me the problem ???

Most likely network packet loss.  MPEG-2 video is usually at a 
significantly higher bit rate than MPEG-1 video.
-- 

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

From finlayson at live555.com  Wed Jan  2 17:53:54 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 2 Jan 2008 17:53:54 -0800
Subject: [Live-devel] The quality of video is not good with streaming
 MPEG-2
Message-ID: <f06240802c3a1f081fe0d@[66.80.62.44]>

Also, a reminder that "openRTSP" has an option "-Q" for reporting 
quality-of-service statistics, including packet loss.

See http://www.live555.com/openRTSP/#other-options
-- 

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

From g.kiranjyothi at einfochips.com  Wed Jan  2 20:46:39 2008
From: g.kiranjyothi at einfochips.com (Kiranjyothi)
Date: Thu, 3 Jan 2008 10:16:39 +0530
Subject: [Live-devel] Does Live support WM9 streaming
Message-ID: <004901c84dc3$a2b1ec70$a3016e0a@KIRANJYOTHI>

Hi ,

I want to know whether Live55 has support of WM9 streaming or not.When i was looking into the code i didnt find such support.So Please clarify my query.

Thanks,
Kiran..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080102/1275a6b0/attachment-0001.html 

From finlayson at live555.com  Thu Jan  3 00:20:15 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 3 Jan 2008 00:20:15 -0800
Subject: [Live-devel] Does Live support WM9 streaming
In-Reply-To: <004901c84dc3$a2b1ec70$a3016e0a@KIRANJYOTHI>
References: <004901c84dc3$a2b1ec70$a3016e0a@KIRANJYOTHI>
Message-ID: <f06240804c3a24b00c05b@[66.80.62.44]>

>I want to know whether Live55 has support of WM9 streaming or not.

No, because "WM9" is a proprietary codec that does not have a 
publicaly -defined RTP payload format.
-- 

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/20080103/6b75ab70/attachment.html 

From robin.penea at gmail.com  Thu Jan  3 00:31:30 2008
From: robin.penea at gmail.com (Robin Penea)
Date: Thu, 3 Jan 2008 09:31:30 +0100
Subject: [Live-devel] MPEG4 streaming source to FIFO/Buffer
In-Reply-To: <f06240804c3a1c1c4ead1@66.80.62.44>
References: <ad4c2ee20801020704u2810eee5j9a70de1005e1a0bb@mail.gmail.com>
	<f06240804c3a1c1c4ead1@66.80.62.44>
Message-ID: <ad4c2ee20801030031va1273d1rb58c6397d4cd5a97@mail.gmail.com>

First I would like to thank you for your attention !

> You should not
>need 'named pipes' for this, if your analysis application reads from
>'stdin'.

The problem is that my application doesn't read from stdin, it reads from a
file,
this i why I thought using the named pipe. And also I can't rely on command
lines
operation, because my application might be ported to windows - crying - ...

>openRTSP -v -u username password  rtsp://whatever |
>your-analysis-application

I already piped openRTSP to other commands, and it works great, but
I need to completely integrate "openRTSP -v -u username password
 rtsp://whatever | "
into my piece of code. it has to be "standalone". That is why I am searching
to
subclass your code :-).

-- 
Robin Penea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080103/45e824a5/attachment.html 

From sony at mht.bme.hu  Thu Jan  3 00:35:51 2008
From: sony at mht.bme.hu (Tran Minh Son)
Date: Thu, 03 Jan 2008 09:35:51 +0100
Subject: [Live-devel] Muxing AVC into TS
Message-ID: <477C9E67.6080703@mht.bme.hu>

Dear all,
First of all, wishing you all a new year full of happiness and 
successes, especially with a lot of advanced features for live555 system.
I would like to have your confirmation on the creation of Transport 
stream (TS) containing AVC (Mpeg-4 part 10 for video) elementary stream 
in Live555. Is it true that live555 can create TS only from MPEG-1 / 2 
video (from PS stream) as in the test program 
testMPEG1or2ProgramToTransportStream? To support AVC (Bytestream 
AnnexB), I should derive the dedicated classes from 
MPEG2TransportStreamMultiplexor (as class 
MPEG2TransportStreamFromPESSource for MPEG-1/2) and from 
ByteStreamFileSource to deal with  NAL  file and  TS from NAL source ...
Thanks
Son

From g.kiranjyothi at einfochips.com  Thu Jan  3 04:13:13 2008
From: g.kiranjyothi at einfochips.com (Kiranjyothi)
Date: Thu, 3 Jan 2008 17:43:13 +0530
Subject: [Live-devel] Presentation time stamp calculation
Message-ID: <007d01c84e02$03f3f580$a3016e0a@KIRANJYOTHI>

Hi,

If i m streaming an mpeg4 file through LIVE ,i want to know whether the presentation time stamp calculated based on the frames per second value of mpeg4 input file or is the frames per second(fps) value hardcoded to any default value?

Regards
gkj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080103/831b9918/attachment.html 

From finlayson at live555.com  Thu Jan  3 05:48:48 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 3 Jan 2008 05:48:48 -0800
Subject: [Live-devel] Presentation time stamp calculation
In-Reply-To: <007d01c84e02$03f3f580$a3016e0a@KIRANJYOTHI>
References: <007d01c84e02$03f3f580$a3016e0a@KIRANJYOTHI>
Message-ID: <f06240806c3a298044d26@[66.80.62.44]>

>If i m streaming an mpeg4 file through LIVE ,i want to know 
>whether the presentation time stamp calculated based on the frames 
>per second value of mpeg4 input file

Yes.  Note the "MPEG4VideoStreamParser" class (in 
"MPEG4VideoStreamFramer.cpp").
-- 

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/20080103/6549e6ed/attachment.html 

From robin.penea at gmail.com  Thu Jan  3 10:09:21 2008
From: robin.penea at gmail.com (Robin Penea)
Date: Thu, 3 Jan 2008 19:09:21 +0100
Subject: [Live-devel] FIFO samples
Message-ID: <ad4c2ee20801031009hf7022cfj28e904263204a70b@mail.gmail.com>

Hi,

I've seen on the mailing-list archives that some people managed
to implement a FIFO in liveMedia. I would be very interested in
getting any clue about the modifications you have done to the original
code. Even more, I would be pleased to get your source code :-D or
any samples that might help me to do the same stuff !

Thanks !


-- 
Robin Penea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080103/ee74e157/attachment.html 

From nikhiln at paxit.com  Thu Jan  3 12:28:17 2008
From: nikhiln at paxit.com (Nikhil Naik)
Date: Thu, 3 Jan 2008 14:28:17 -0600
Subject: [Live-devel] Unicast streaming over the Internet using LIVE555
In-Reply-To: <f06240800c3a1dca15579@[66.80.62.44]>
References: <000601c84d96$b45372a0$1cfa57e0$@com>
	<f06240800c3a1dca15579@[66.80.62.44]>
Message-ID: <000601c84e47$2d1ed8e0$875c8aa0$@com>

Hi Ross,

Thanks for your speedy reply. Yes I have tried using those two and they work
just fine with saved files.
However I m trying to stream a live source and am setting up a RTSP Server
using Groupsock class. 

My current setup works just fine for Multicast on the LAN (as expected). 

However when trying to allow Muti-unicast over the Internet 

I set:   		    ReceivingInterfaceAddr =
our_inet_addr("0.0.0.0"); 

Then I call:
                      sms->addSubsession(PassiveServerMediaSubsession
		                      ::createNew(*sessionState.sink));

Finally before startPlaying I call: 

	
sessionState.rtpGroupsock->addDestination(unicastAddress, newrtpPort);
	
sessionState.rtcpGroupsock->addDestination(unicastAddress, newrtcpPort);

Based on the comment in the Groupsock class I assume that the ports have to
be different for Unicast.

I saw a note in one of your previous posts which talks about: SDP
description should contain the
special address 0.0.0.0, not a specific Unicast address.

Now should this be done using "setServerAddressAndPortForSDP" on the
ServerMediaSubsession, if yes
Then would this call follow addSubsession or addDestination.

Once again thanks for all the help and guidance, any help in this matter
would be extremely helpful.

Sincerely,

Nikhil.

-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Wednesday, January 02, 2008 6:30 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Unicast streaming over the Internet using LIVE555

>I have developed a RTSP Server and I can get it to stream just fine
>over the LAN. However when I try to stream over the internet, I see a
>connection but do not see an image come through. I can send commands
>to and fro. I can see the DESCRIBE, SETUP, PLAY and TEARDOWN pass just
>fine.

Have you tried using our existing unicast RTSP server applications: 
"testOnDemandRTSPServer" and "live555MediaServer"?  Do those work for 
you?
-- 

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


From finlayson at live555.com  Thu Jan  3 12:38:23 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 3 Jan 2008 12:38:23 -0800
Subject: [Live-devel] Unicast streaming over the Internet using LIVE555
In-Reply-To: <000601c84e47$2d1ed8e0$875c8aa0$@com>
References: <000601c84d96$b45372a0$1cfa57e0$@com>
	<f06240800c3a1dca15579@[66.80.62.44]>
	<000601c84e47$2d1ed8e0$875c8aa0$@com>
Message-ID: <f06240807c3a2f7bdfc85@[66.80.62.44]>

>Thanks for your speedy reply. Yes I have tried using those two and they work
>just fine with saved files.
>However I m trying to stream a live source

See
	http://www.live555.com/liveMedia/faq.html#liveInput
	http://www.live555.com/liveMedia/faq.html#liveInput-unicast

You should be able to get what you want using the existing unicast 
RTSP server code.  This is much easier than trying to start from 
multicast server code.
-- 

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

From sony at mht.bme.hu  Thu Jan  3 12:50:54 2008
From: sony at mht.bme.hu (Tran Minh Son)
Date: Thu, 3 Jan 2008 21:50:54 +0100 (CET)
Subject: [Live-devel] Muxing AVC into TS
In-Reply-To: <477C9E67.6080703@mht.bme.hu>
References: <477C9E67.6080703@mht.bme.hu>
Message-ID: <Pine.LNX.4.64.0801032149500.16934@mht.mht.bme.hu>


Hi All,

On Thu, 3 Jan 2008, Tran Minh Son wrote:

> Dear all,
> First of all, wishing you all a new year full of happiness and
> successes, especially with a lot of advanced features for live555 system.
> I would like to have your confirmation on the creation of Transport
> stream (TS) containing AVC (Mpeg-4 part 10 for video) elementary stream
> in Live555. Is it true that live555 can create TS only from MPEG-1 / 2
> video (from PS stream) as in the test program
> testMPEG1or2ProgramToTransportStream? To support AVC (Bytestream
> AnnexB), I should derive the dedicated classes from
> MPEG2TransportStreamMultiplexor (as class
> MPEG2TransportStreamFromPESSource for MPEG-1/2) and from
> ByteStreamFileSource to deal with  NAL  file and  TS from NAL source ...

No one can help me to shed a little light on my problems?
Thank you in advance
Regards
Son

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

From wegaia at bitsgen.com  Fri Jan  4 05:05:23 2008
From: wegaia at bitsgen.com (YH Park)
Date: Fri, 4 Jan 2008 22:05:23 +0900
Subject: [Live-devel] where is doGetNextFrame() of MPEG4VideoStreamFramer
	class
Message-ID: <003c01c84ed2$77a6add0$4600a8c0@LocalHost>

Hi everyone

i'm a newbie here.

i've been trying to understand the liveMedia library structure by inspecting the "testOnDemandRTSPServer" test program.
it seems to use MPEG4VideoStreamFramer as a frame source(it creates a ByteStreamFileSource as a internal source).
i followed the call sequences in a typical RTSP conversation between a Server and a Client.
after a client send 'PLAY', the server starts series of codes and it reaches fRTPSink->startPlaying();  and
it calls MediaSink::startPlaying(). in turn, MultiFramedRTPSink::continuePlaying()...fSource->getNextFrame() ... finally FramedSource::getNextFrame()
in it, it calls doGetNextFrame() (not fInputSource->doGetNextFrame()).  but in MPEG4VideoStreamFramer.cpp, i can't find the function. only found in MPEGVideoStreamFramer.cpp
(and in MPEG4VideoStreamDiscreteFramer.cpp)
but it(doGetNextFrame() in MPEGVideoStreamFrame.cpp) doesn't call any function in the ByteStreamFileSource for getting a real data(frame) from a file.
i thought i miss a link in the calling sequence. but after i checked several times, still i can't find that link.

could you tell me what i missed?


thanks and regards,
Park
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080104/61b1f600/attachment-0001.html 

From finlayson at live555.com  Fri Jan  4 06:24:42 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 4 Jan 2008 06:24:42 -0800
Subject: [Live-devel] where is doGetNextFrame() of
 MPEG4VideoStreamFramer class
In-Reply-To: <003c01c84ed2$77a6add0$4600a8c0@LocalHost>
References: <003c01c84ed2$77a6add0$4600a8c0@LocalHost>
Message-ID: <f06240801c3a3f16095ea@[66.80.62.44]>

All subclasses of "FramedSource" must provide an implementation of 
the virtual function "doGetNextFrame()".

For the "MPEG4VideoStreamFramer" class, that implementation occurs in 
its parent class "MPEGVideoStreamFramer" (see 
"MPEGVideoStreamFramer.cpp").
-- 

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

From ashish_singhal2000 at yahoo.com  Tue Jan  8 05:56:08 2008
From: ashish_singhal2000 at yahoo.com (Ashish Singhal)
Date: Tue, 8 Jan 2008 05:56:08 -0800 (PST)
Subject: [Live-devel] Regarding OpenRTSP
In-Reply-To: <mailman.0.1199800116.22893.live-devel@lists.live555.com>
Message-ID: <590665.98178.qm@web36802.mail.mud.yahoo.com>

Hi,

I was trying to integrate openRTSP with my own
application. I am currently facing a problem. The
streaming server is a Hava Wireless HD. OpenRTSP is
able to discover the connection, extract the SDP, open
client ports and start playing session but there is no
content stored in the files.

Is the Hava server a problem?

Thanks,
-Ashish



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

From finlayson at live555.com  Tue Jan  8 07:02:19 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 8 Jan 2008 07:02:19 -0800
Subject: [Live-devel] Regarding OpenRTSP
In-Reply-To: <590665.98178.qm@web36802.mail.mud.yahoo.com>
References: <590665.98178.qm@web36802.mail.mud.yahoo.com>
Message-ID: <f06240805c3a9409c97f9@[66.80.62.44]>

>I was trying to integrate openRTSP with my own
>application. I am currently facing a problem. The
>streaming server is a Hava Wireless HD. OpenRTSP is
>able to discover the connection, extract the SDP, open
>client ports and start playing session but there is no
>content stored in the files.

You most likely have a firewall that is blocking UDP packets from 
your server to your client ("openRTSP").

Either fix your firewall, or else re-run "openRTSP" with the "-t" 
option, to request RTP-over-TCP streaming.
-- 

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

From ashish_singhal2000 at yahoo.com  Tue Jan  8 08:03:41 2008
From: ashish_singhal2000 at yahoo.com (Ashish Singhal)
Date: Tue, 8 Jan 2008 08:03:41 -0800 (PST)
Subject: [Live-devel] Regarding OpenRTSP
In-Reply-To: <f06240805c3a9409c97f9@[66.80.62.44]>
Message-ID: <587274.51897.qm@web36813.mail.mud.yahoo.com>

Hey Ross,

I have disabled the client firewall. I have also tried
the -t option. It still is not storing data in the
file.

The command that I am using is:

> ./openRTSP -F abc -t "rtsp://157.254.39.27"

Thanks,
-Ashish

--- Ross Finlayson <finlayson at live555.com> wrote:

> >I was trying to integrate openRTSP with my own
> >application. I am currently facing a problem. The
> >streaming server is a Hava Wireless HD. OpenRTSP is
> >able to discover the connection, extract the SDP,
> open
> >client ports and start playing session but there is
> no
> >content stored in the files.
> 
> You most likely have a firewall that is blocking UDP
> packets from 
> your server to your client ("openRTSP").
> 
> Either fix your firewall, or else re-run "openRTSP"
> with the "-t" 
> option, to request RTP-over-TCP streaming.
> -- 
> 
> 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
> 



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


From slaine at slaine.org  Tue Jan  8 08:19:47 2008
From: slaine at slaine.org (Glen Gray)
Date: Tue, 8 Jan 2008 16:19:47 +0000
Subject: [Live-devel] Conditional Access support ?
Message-ID: <E016F93A-A120-42E2-8FA0-204C2A6CAEB3@slaine.org>

Hey Ross,

Was wondering if live555 media server would have a problem streaming  
mpeg2-ts files that have been encrypted. I've not had the opportunity  
to test this yet, but if we wanted to replace a Kasenna server with a  
live555 server, we'd need to be able serve out encrypted content.

Thanks in advance
--
Glen Gray
slaine at slaine.org





From finlayson at live555.com  Tue Jan  8 13:12:54 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 8 Jan 2008 13:12:54 -0800
Subject: [Live-devel] Regarding OpenRTSP
In-Reply-To: <587274.51897.qm@web36813.mail.mud.yahoo.com>
References: <587274.51897.qm@web36813.mail.mud.yahoo.com>
Message-ID: <f06240800c3a99606b3b2@[66.80.62.44]>

>I have disabled the client firewall. I have also tried
>the -t option. It still is not storing data in the
>file.
>
>The command that I am using is:
>
>  > ./openRTSP -F abc -t "rtsp://157.254.39.27"

It seems then, that there may be a problem with your server.

Please post the diagnostic ('stderr') output that "openRTSP" printed 
when you ran it (i.e., showing the RTSP protocol exchange).  That 
might give us a clue as to what is going wrong.
-- 

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

From finlayson at live555.com  Tue Jan  8 13:16:30 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 8 Jan 2008 13:16:30 -0800
Subject: [Live-devel] Conditional Access support ?
In-Reply-To: <E016F93A-A120-42E2-8FA0-204C2A6CAEB3@slaine.org>
References: <E016F93A-A120-42E2-8FA0-204C2A6CAEB3@slaine.org>
Message-ID: <f06240801c3a998092c32@[66.80.62.44]>

>Was wondering if live555 media server would have a problem streaming
>mpeg2-ts files that have been encrypted.

It depends what you mean by "encrypted".  The Transport Stream file 
must be well-formed, with proper Transport Stream headers and PCR 
timestamps.  However, the server is completely agnostic about the 
actual payload data that's in the Transport Stream.  If the PES data 
contained within the Transport Stream is encrypted, but the Transport 
Stream itself is well-formed, then there should be no problem.
-- 

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

From ashish_singhal2000 at yahoo.com  Tue Jan  8 13:43:18 2008
From: ashish_singhal2000 at yahoo.com (Ashish Singhal)
Date: Tue, 8 Jan 2008 13:43:18 -0800 (PST)
Subject: [Live-devel] Regarding OpenRTSP
In-Reply-To: <f06240800c3a99606b3b2@[66.80.62.44]>
Message-ID: <644399.7294.qm@web36802.mail.mud.yahoo.com>

Ross,

Please find the attached file.

Thanks,
-Ashish

--- Ross Finlayson <finlayson at live555.com> wrote:

> >I have disabled the client firewall. I have also
> tried
> >the -t option. It still is not storing data in the
> >file.
> >
> >The command that I am using is:
> >
> >  > ./openRTSP -F abc -t "rtsp://157.254.39.27"
> 
> It seems then, that there may be a problem with your
> server.
> 
> Please post the diagnostic ('stderr') output that
> "openRTSP" printed 
> when you ran it (i.e., showing the RTSP protocol
> exchange).  That 
> might give us a clue as to what is going wrong.
> -- 
> 
> 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
> 



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stderrcapture.txt
Url: http://lists.live555.com/pipermail/live-devel/attachments/20080108/00db8b9b/attachment.txt 

From finlayson at live555.com  Tue Jan  8 13:53:10 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 8 Jan 2008 13:53:10 -0800
Subject: [Live-devel] Regarding OpenRTSP
In-Reply-To: <644399.7294.qm@web36802.mail.mud.yahoo.com>
References: <644399.7294.qm@web36802.mail.mud.yahoo.com>
Message-ID: <f06240803c3a9a1002da0@[66.80.62.44]>

This looks OK to me.  Are you *certain* that your server is not 
transmitting any RTP/UDP packets on its local network?  If so, then 
there is definitely a problem with your server, and you will need to 
contact your server's manufacturer for support.
-- 

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

From slaine at slaine.org  Tue Jan  8 14:13:34 2008
From: slaine at slaine.org (Glen Gray)
Date: Tue, 8 Jan 2008 22:13:34 +0000
Subject: [Live-devel] Conditional Access support ?
In-Reply-To: <f06240801c3a998092c32@[66.80.62.44]>
References: <E016F93A-A120-42E2-8FA0-204C2A6CAEB3@slaine.org>
	<f06240801c3a998092c32@[66.80.62.44]>
Message-ID: <15BB3DAB-EA40-4386-989E-9FED9D72D509@slaine.org>

That's music to my ears Ross,

Thanks,
--
Glen Gray
slaine at slaine.org




On 8 Jan 2008, at 21:16, Ross Finlayson wrote:

>> Was wondering if live555 media server would have a problem streaming
>> mpeg2-ts files that have been encrypted.
>
> It depends what you mean by "encrypted".  The Transport Stream file
> must be well-formed, with proper Transport Stream headers and PCR
> timestamps.  However, the server is completely agnostic about the
> actual payload data that's in the Transport Stream.  If the PES data
> contained within the Transport Stream is encrypted, but the Transport
> Stream itself is well-formed, then there should be no problem.
> -- 
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel


From mrec123.ashok at gmail.com  Tue Jan  8 15:50:01 2008
From: mrec123.ashok at gmail.com (Ashok jain)
Date: Wed, 9 Jan 2008 05:20:01 +0530
Subject: [Live-devel] URGENT QUERY
Message-ID: <1995a8a40801081550o5a72d641he9ad4111ca23341a@mail.gmail.com>

Hello

I am facing some problem in using the live source code.
PLS HELP ME. Its urgent for my project.

*testMPEG1or2VideoStreamer* reads a MPEG-1 or 2 Program Stream file (named "
test.mpg"), extracts from this an video Elementary Stream, and streams
these, using RTP, to the unicast IP.
So in *testMPEG1or2VideoReceiver, *I have set the IP = 0.0.0.0. It is taking
from RTP source & saving to .mpg file sink.

I run both *testMPEG1or2VideoStreamer* & *testMPEG1or2VideoReceiver.*
After finishing file transfer following are the results-
*1. testMPEG1or2VideoStreamer* stops properly & executes the function "void
*afterPlaying*(void* clientData)" which is used in
videoSink->startPlaying(*videoSource, *afterPlaying*, videoSink);
AND I GET MESSAGE ---->>> *env << "...done reading from file\n";

2. *testMPEG1or2VideoReceiver - *It doesnot executes "void *afterPlaying*(void*
clientData)" function.
It remans in loop even after data transfer finshes also.

HOW CAN I EXECUTE THE afterPlaying() function ??????????????

Pls rply soon.

Regards
Ashok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080108/ad2a7a94/attachment-0001.html 

From finlayson at live555.com  Tue Jan  8 16:42:53 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 8 Jan 2008 16:42:53 -0800
Subject: [Live-devel] URGENT QUERY
In-Reply-To: <1995a8a40801081550o5a72d641he9ad4111ca23341a@mail.gmail.com>
References: <1995a8a40801081550o5a72d641he9ad4111ca23341a@mail.gmail.com>
Message-ID: <f06240805c3a9c8aff712@[66.80.62.44]>

>testMPEG1or2VideoStreamer reads a MPEG-1 or 2 Program Stream file 
>(named "test.mpg"), extracts from this an video Elementary Stream, 
>and streams these, using RTP, to the unicast IP.
>So in testMPEG1or2VideoReceiver, I have set the IP = <http://0.0.0.0/>0.0.0.0.

Don't do that.  "testMPEG1or2VideoStreamer" is used to stream to a 
*multicast* IP address.  Leave it the way it is.

(If instead you want to do unicast streaming, then use 
"testOnDemandRTSPServer" (as the server) and "openRTSP" (as the 
client) instead.)
-- 

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/20080108/dee0e205/attachment.html 

From mrec123.ashok at gmail.com  Tue Jan  8 17:09:15 2008
From: mrec123.ashok at gmail.com (Ashok jain)
Date: Wed, 9 Jan 2008 06:39:15 +0530
Subject: [Live-devel] Source code - MPEG2 TS by RTP
Message-ID: <1995a8a40801081709x167cb9cfud9fc6f599842d187@mail.gmail.com>

Hello

I need to do following activities. pls help.
1. Sender Side - Send MPEG2 Transport Stream through RTP from
*input.ts*file to a
*unicast IP RTP sink*.
2. Receiver Side - Receive the MPEG2 Transport Stream from RTP source and
save it to out.ts.

Pls send me a running source code.
Its very urgent for me in my project.

Thanks & Regards
Ashok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080108/44205a05/attachment.html 

From finlayson at live555.com  Tue Jan  8 17:11:59 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 8 Jan 2008 17:11:59 -0800
Subject: [Live-devel] Source code - MPEG2 TS by RTP
In-Reply-To: <1995a8a40801081709x167cb9cfud9fc6f599842d187@mail.gmail.com>
References: <1995a8a40801081709x167cb9cfud9fc6f599842d187@mail.gmail.com>
Message-ID: <f06240806c3a9cfae9af5@[66.80.62.44]>

>I need to do following activities. pls help.
>1. Sender Side - Send MPEG2 Transport Stream through RTP from 
>input.ts file to a unicast IP RTP sink.
>2. Receiver Side - Receive the MPEG2 Transport Stream from RTP 
>source and save it to out.ts.

Use "live555MediaServer" <http://www.live555.com/mediaServer/> as 
your server, and use "openRTSP" <http://www.live555.com/openRTSP/> as 
your client.
-- 

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/20080108/b83171ed/attachment.html 

From belloni at imavis.com  Wed Jan  9 04:28:01 2008
From: belloni at imavis.com (Cristiano Belloni)
Date: Wed, 09 Jan 2008 13:28:01 +0100
Subject: [Live-devel] Lot of late pictures skipped by VLC
Message-ID: <4784BDD1.8010900@imavis.com>

Hi to everybody,

I'm implementing a live rtsp server with liveMedia libraries.

I subclassed H263plusVideoFileServerMediaSubsession, so that any time an 
RTSP client makes a request, it starts a thread which takes frames from 
an analog camera and encode the frames in h263+ format (encoding is done 
by ffmpeg library with the 'h263p' codec).

As any encoded frame is ready, the thread write()s it on a unix named 
pipe (fifo) and goes on encoding the next frame available, while the 
main thread streams the contents of the fifo, which I previously added 
as a subsession.

In wireshark, the servers seems to send RTP/UDP packets correctly, with 
consequential timestamps.
Anyways, it seems the UDP checksum value is not correct. Wireshark keeps 
complaining something like: "Checksum: 0x89ac [incorrect, should be 
0x2017 (maybe caused by "UDP checksum offload"?)]" for every packet sent 
(obviously, checksum values differ).

When I try to view the stream with vlc, it decodes 4-5 frames then 
starts saying "[00000332] main video output warning: late picture 
skipped (979326)" for 20-30 frames (and the video blocks), then decodes 
another 4-5 frames and so on.

You may say: vlc's problems (and I will probably post this in vlc's 
mailing list too).

But the strange thing is that when I stream - with the same (slightly 
modified) liveMedia server - the same exact frames stored in a file 
(acquired the same way, encoded the same way, saved in a regular file), 
vlc magically plays it perfectly, with no frame skipped.

Maybe there's some thing I don't know, or possibily a parameter I don't 
define or define wrongly, in the way liveMedia libraries interact with 
non-regular, non-seekable files in which liveMedia read()s may block 
until the thread write()s  the freshly encoded frames in the fifo?

Or maybe it is something about concurrent threading? I already tried to 
start another process instead of a thread to do the encoding and writing 
on the fifo, but I had no luck. same behaviour.

Did it ever happen to any of you?

Thanks!

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

From ashish_singhal2000 at yahoo.com  Wed Jan  9 05:33:20 2008
From: ashish_singhal2000 at yahoo.com (Ashish Singhal)
Date: Wed, 9 Jan 2008 05:33:20 -0800 (PST)
Subject: [Live-devel] Regarding OpenRTSP
In-Reply-To: <f06240803c3a9a1002da0@[66.80.62.44]>
Message-ID: <317457.67631.qm@web36814.mail.mud.yahoo.com>

Hi Ross,

Yes I am cerain about that because I am able to view
media on the windows machine which has the hava client
installed. I just wanted to know whether the
'DESCRIBE' and SDP are being interpreted correctly or
not. 

Thanks,
-Ashish

--- Ross Finlayson <finlayson at live555.com> wrote:

> This looks OK to me.  Are you *certain* that your
> server is not 
> transmitting any RTP/UDP packets on its local
> network?  If so, then 
> there is definitely a problem with your server, and
> you will need to 
> contact your server's manufacturer for support.
> -- 
> 
> 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
> 



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

From finlayson at live555.com  Wed Jan  9 07:59:00 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 9 Jan 2008 07:59:00 -0800
Subject: [Live-devel] Lot of late pictures skipped by VLC
In-Reply-To: <4784BDD1.8010900@imavis.com>
References: <4784BDD1.8010900@imavis.com>
Message-ID: <f06240807c3aa9ee885f0@[66.80.62.44]>

>In wireshark, the servers seems to send RTP/UDP packets correctly, with
>consequential timestamps.
>Anyways, it seems the UDP checksum value is not correct.

UDP checksumming is done inside the OS, not by any user-level 
software (like ours).


>But the strange thing is that when I stream - with the same (slightly
>modified) liveMedia server - the same exact frames stored in a file
>(acquired the same way, encoded the same way, saved in a regular file),
>vlc magically plays it perfectly, with no frame skipped.

That's good; you have something similar that works.

I suggest that you begin by using "openRTSP" as your client, rather 
than VLC.  That way, you will be able to save the incoming data into 
a file, and examine it.


>Or maybe it is something about concurrent threading?

I hope you have read the FAQ entry about threads.
-- 

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

From dimazzz80 at mail.ru  Thu Jan 10 00:36:28 2008
From: dimazzz80 at mail.ru (=?koi8-r?Q?=E4=C9=CD=C1_=FA=C9=CE=DE=C5=CE=CB=CF?=)
Date: Thu, 10 Jan 2008 11:36:28 +0300
Subject: [Live-devel]
	=?koi8-r?b?TG90IG9mIGxhdGUgcGljdHVyZXMgc2tpcHBlZCBi?=
	=?koi8-r?b?eSBWTEM=?=
In-Reply-To: <4784BDD1.8010900@imavis.com>
References: <4784BDD1.8010900@imavis.com>
Message-ID: <E1JCsto-000KI0-00.dimazzz80-mail-ru@f98.mail.ru>

Hi!
I think we had similar problem but on the receiving side of the software. We had a goal to create Java application to receive and display several MJPEG streams from Live server. The available Java soft was unable to receive Live stream, so we decided to link modified Live openRTSP code to Java through JNI. We had a thread with Live code to receive the stream and put in the named pipe (on both Windows/Linux) and Java thread to read from the named pipe and display the image. Actually Java was unable to properly read from the pipes, so we used some C functions again linked through JNI to actually read and pass the buffer to Java. Anyway, the problem was that the reading part often started to read from pipe BEFORE the frame was fully written, which caused sequences of 2 buffers with wrong content (splitted JPEG) to appear. Our quick and ugly solution was to use second pipe to write 1 byte after main pipe was written, so reading part was blocked until it received that 1 byte and only after that it read from image pipe. We planned to pass presentation time information through this pipe actually because it isn't contained in JPEG. But then we realized that Java was very slow at displaying the received image and this part was abandoned completely.

-----Original Message-----
From: Cristiano Belloni <belloni at imavis.com>
To: live-devel at ns.live555.com
Date: Wed, 09 Jan 2008 13:28:01 +0100
Subject: [Live-devel] Lot of late pictures skipped by VLC

> 
> Hi to everybody,
> 
> I'm implementing a live rtsp server with liveMedia libraries.
> 
> I subclassed H263plusVideoFileServerMediaSubsession, so that any time an 
> RTSP client makes a request, it starts a thread which takes frames from 
> an analog camera and encode the frames in h263+ format (encoding is done 
> by ffmpeg library with the 'h263p' codec).
> 
> As any encoded frame is ready, the thread write()s it on a unix named 
> pipe (fifo) and goes on encoding the next frame available, while the 
> main thread streams the contents of the fifo, which I previously added 
> as a subsession.
> 
> In wireshark, the servers seems to send RTP/UDP packets correctly, with 
> consequential timestamps.
> Anyways, it seems the UDP checksum value is not correct. Wireshark keeps 
> complaining something like: "Checksum: 0x89ac [incorrect, should be 
> 0x2017 (maybe caused by "UDP checksum offload"?)]" for every packet sent 
> (obviously, checksum values differ).
> 
> When I try to view the stream with vlc, it decodes 4-5 frames then 
> starts saying "[00000332] main video output warning: late picture 
> skipped (979326)" for 20-30 frames (and the video blocks), then decodes 
> another 4-5 frames and so on.
> 
> You may say: vlc's problems (and I will probably post this in vlc's 
> mailing list too).
> 
> But the strange thing is that when I stream - with the same (slightly 
> modified) liveMedia server - the same exact frames stored in a file 
> (acquired the same way, encoded the same way, saved in a regular file), 
> vlc magically plays it perfectly, with no frame skipped.
> 
> Maybe there's some thing I don't know, or possibily a parameter I don't 
> define or define wrongly, in the way liveMedia libraries interact with 
> non-regular, non-seekable files in which liveMedia read()s may block 
> until the thread write()s  the freshly encoded frames in the fifo?
> 
> Or maybe it is something about concurrent threading? I already tried to 
> start another process instead of a thread to do the encoding and writing 
> on the fifo, but I had no luck. same behaviour.
> 
> Did it ever happen to any of you?
> 
> Thanks!
> 
> -- 
> Belloni Cristiano
> Imavis Srl.
> www.imavis.com <http://www.imavis.com>
> belloni at imavis.com <mailto://belloni at imavis.com>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
> 


From belloni at imavis.com  Thu Jan 10 04:13:23 2008
From: belloni at imavis.com (Cristiano Belloni)
Date: Thu, 10 Jan 2008 13:13:23 +0100
Subject: [Live-devel] Possible bug in liveMedia + info request about H263 /
	H263plus compatibility
Message-ID: <47860BE3.8040900@imavis.com>

Greetings to all,

As I explained in the previous emails, I'm trying to set up an rtsp 
server that streams h263 video, taken from a process that writes the 
stream on a unix named pipe.

The "encoder" process sets up ffmpeg libraries, takes video frames from 
an analog camera and encodes them in h263 format, writing them on a 
named pipe (fifo) on the filesystem.

The server process adds an H263plusVideoFileServerMediaSubsession, using 
the filename of the named pipe as the second parameter.

When I start the encoder process, it sets itself up and blocks opening 
the fifo write only. That's ok, because no one has yet opened the fifo 
for reading.

Then I start the server, and start an rtsp client to do the right request.

The server then open()s the fifo for reading. Consequently the encoder 
process unblocks and starts encoding frames and writing them on the fifo.

The odd thing is that, then, the server close()s the fifo, only to re - 
open() it after a bit.

After the server close()s, and before it re - open(s) them, the encoder 
process has encoded some frames and tries to write them on the fifo. But 
the other end of the fifo is now closed, and the encoder process gets a 
SIGPIPE  and dies.

The strace of the server process goes like this:

open("camera0fifo", O_RDONLY|O_LARGEFILE) = 5    -->(opens the fifo for 
the 1st time)
[...]
close(5)     -->(closes fd 5, which is the fifo  descriptor)
[...]
---> Here the encoder process tries to write() on the fifo, and gets the 
SIGPIPE
[...]
open("camera0fifo", O_RDONLY|O_LARGEFILE) = 5 -  ->(opens the fifo 
again, for the last time)

If I make the encoder process sleep() for two seconds, however - that's 
bad practice, I know, but just to prove my point - the server has time 
to re - open() the read end of the fifo, and all consequent write()s on 
it are successful.

To avoid this, I would either ignore the SIGPIPE or poll the file 
descriptor until its read end is opened again, but I don't particularly 
like these solutions.

Is there a particular reason why liveMedia open()s the file descriptor 
twice? Is it meant to be like this or is it misbehaving?

And if it's meant, how would you recommend to handle this situation? 
Maybe I'm missing something, and someone could be kind and enlighten me :)

The second part of the question is a bit trickier.

Server sends correctly H263plus packets, as far I can see. 
Unfortunately, my implementation is meant to stream to cellular phones 
using the standard realplayer.

Realplayer behaves well with the server in rtsp/rtp interaction, but it 
won't read H263plus packets as encoded by ffmpeg. Instead, it would read 
H263 (non-plus, first version, with fixed screen sizes).
When I try to stream H263 streams with an 
H263plusVideoFileServerMediaSubsession, it behaves quite oddly: servers 
sends packets very slowly, with short bursts of rtp packets interleaved 
with 2/3 seconds of sending nothing, as I could observe in wireshark.

As it consumes much slower than the encoder process produces, the fifo 
gets filled, the writes block, then the server finally consumes its 
buffer (taking minutes), and the encoder process fills the fifo again 
and so on.

I realize H263plusVideoFileServerMediaSubsession is meant to send H263+ 
streams, which it does, but I thought H263+ was backwards compatible 
with H263.

Anyone managed to stream pure H263 first version with liveMedia?
Anyone knows how can I achieve this goal?

Thanks to everybody.

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

From martin at startwars.org  Thu Jan 10 05:25:39 2008
From: martin at startwars.org (Martin Lindhe)
Date: Thu, 10 Jan 2008 14:25:39 +0100
Subject: [Live-devel] Possible bug in liveMedia + info request about
 H263 /	H263plus compatibility
In-Reply-To: <47860BE3.8040900@imavis.com>
References: <47860BE3.8040900@imavis.com>
Message-ID: <47861CD3.90604@startwars.org>

An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080110/7bd0794e/attachment-0001.html 

From finlayson at live555.com  Thu Jan 10 05:26:38 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 10 Jan 2008 05:26:38 -0800
Subject: [Live-devel] Possible bug in liveMedia + info request about
 H263 / H263plus compatibility
In-Reply-To: <47860BE3.8040900@imavis.com>
References: <47860BE3.8040900@imavis.com>
Message-ID: <f06240801c3abc811d4ae@[66.80.62.44]>

>As I explained in the previous emails, I'm trying to set up an rtsp
>server that streams h263 video, taken from a process that writes the
>stream on a unix named pipe.

I suggest that you first get your server to stream from a file 
(containing pre-encoded H.263 video data).  Only once you have that 
working properly, should you move to the more difficult step of 
streaming from a live encoder.


>The "encoder" process sets up ffmpeg libraries, takes video frames from
>an analog camera and encodes them in h263 format, writing them on a
>named pipe (fifo) on the filesystem.

Because you are streaming from a live source, be sure to set the 
"reuseFirstSource" parameter to True.


>Then I start the server, and start an rtsp client to do the right request.
>
>The server then open()s the fifo for reading. Consequently the encoder
>process unblocks and starts encoding frames and writing them on the fifo.
>
>The odd thing is that, then, the server close()s the fifo, only to re -
>open() it after a bit.

The server code does the initial 'open'+'close' on the source object 
in order to generate a SDP description for the stream.  (This SDP 
description, which can - in general - depend upon properties of the 
source data, is then returned to the client as the response to its 
RTSP "DESCRIBE" command.)  The server then does another 'open' on the 
source in order to do the actual streaming.

The good news is that because you set "reuseFirstSource" to True, 
this 'close+reopen' will happen only once, regardless of the number 
of ciients that you have.  However, it's unavoidable (and not a bug), 
so you're going to have to find a way to live with it.

Also, we can't really help you with any problems that you might be 
having with the 'RealPlayer' client; you'd need to ask RealNetworks 
for help with that.  However, I suggest that you first debug your 
server usng VLC and QuickTime Player as clients.  They should both be 
able to decode/play H.263 RTP streams OK.
-- 

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

From finlayson at live555.com  Thu Jan 10 05:55:58 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 10 Jan 2008 05:55:58 -0800
Subject: [Live-devel] Possible bug in liveMedia + info request about
 H263 /	H263plus compatibility
In-Reply-To: <47861CD3.90604@startwars.org>
References: <47860BE3.8040900@imavis.com> <47861CD3.90604@startwars.org>
Message-ID: <f06240802c3abd3998890@[66.80.62.44]>

>Cristiano Belloni skrev:
>
>>I realize H263plusVideoFileServerMediaSubsession is meant to send H263+
>>streams, which it does, but I thought H263+ was backwards compatible
>>with H263.
>>
>>
>I'm sorry i cannot answer your full mail, but the H263 and H263+ 
>uses different
>format when it is sent over RTP

No, not necessarily.  Note that H.263 *can* (and, in fact, now 
*should*) be sent using the H.263+ RTP payload format (which is what 
we implement in our code).

Note the introduction to RFC 2429, which explains this.
-- 

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

From belloni at imavis.com  Thu Jan 10 06:11:24 2008
From: belloni at imavis.com (Cristiano Belloni)
Date: Thu, 10 Jan 2008 15:11:24 +0100
Subject: [Live-devel] Possible bug in liveMedia + info request about
 H263 /	H263plus compatibility
In-Reply-To: <47860BE3.8040900@imavis.com>
References: <47860BE3.8040900@imavis.com>
Message-ID: <4786278C.6010409@imavis.com>

>he good news is that because you set "reuseFirstSource" to True, 
>this 'close+reopen' will happen only once, regardless of the number 
>of ciients that you have.  However, it's unavoidable (and not a bug), 
>so you're going to have to find a way to live with it.

Ok.

> I suggest that you first get your server to stream from a file 
> (containing pre-encoded H.263 video data).  Only once you have that 
> working properly, should you move to the more difficult step of 
> streaming from a live encoder.

Did it right now: server sends the prerecorded H263 raw file, and openRTSP receives it.

It's still running, because the server sends a single frame (rtp packets + last marked packet) exactly every 8 seconds:

[...]

packet
packet
packet + marked

[8 seconds of nothing]

packet
packet + marked

[8 seconds of nothing]

packet
packet
packet + marked

[8 seconds of nothing]

[...]

What can the problem be? Also the timestamps of RTP packet seemp to reflect this gap. It's like the server is trying to send 0.125 (1/8) frames per second.

Did you ever try to send H263 instead H263plus data with liveMedia?

If not, can anyone try with a prerecorded file, preferibly encoded with ffmpeg's 'h263' (NOT 'h263p') video codec to confirm this behaviour?

> No, not necessarily.  Note that H.263 *can* (and, in fact, now 
> *should*) be sent using the H.263+ RTP payload format (which is what 
> we implement in our code).

This relieves me :) I was starting to fear I would have to write H263VideoFileServerMediaSubsession.

Thanks.

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

From gbonneau at matrox.com  Thu Jan 10 07:17:48 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Thu, 10 Jan 2008 10:17:48 -0500
Subject: [Live-devel] Audio and Video Synchronization Streaming
Message-ID: <007601c8539b$f5ac5f90$8642a8c0@dorvalmatrox.matrox.com>

Hello,

 

I developed a testing application using LiveMedia to multicast a live Audio
and Video feed. Video is compressed to an Mpeg elementary stream and Audio
is PCM 2 channels 16 bits sampled at 48000 Hz. I am using VLC and SMPlayer
as a client that receive the streams. When audio or video is streamed alone
over IP then VLC and SMPlayer both play fine the stream. However when I
stream both audio and video together I ran into synchronization problem and
both VLC and SMPlayer drop either the video and or audio stream. And
playback become jerky.

 

I suspect that I might have missing something when initializing LiveMedia in
a context of playing a mixed bag of audio and video stream together. Any
hints where I should pay attention to keep both stream synchronized. 

 

Thanks

Guy Bonneau

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080110/d6051bb7/attachment.html 

From belloni at imavis.com  Thu Jan 10 08:07:03 2008
From: belloni at imavis.com (Cristiano Belloni)
Date: Thu, 10 Jan 2008 17:07:03 +0100
Subject: [Live-devel] Possible bug in liveMedia + info request about
 H263 /	H263plus compatibility
In-Reply-To: <4786278C.6010409@imavis.com>
References: <47860BE3.8040900@imavis.com> <4786278C.6010409@imavis.com>
Message-ID: <478642A7.9010105@imavis.com>

Using strace (it's difficult to debug liveMedia with a debugger when 
it's running and sending packets), I found that the library seems to 
block for several seconds on a select(), waiting for three fd, 
corresponding to sockets and then timeout on the select.

(opens the sockets)
17718 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
[...]
17718 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
[...]
17718 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 7
[...]
(sends a frame)
17718 select(8, [3 4 7], NULL, NULL, {0, 0}) = 0 (Timeout)
17718 sendto(6, 
"\200`\35m\31\17\373i\300-FR\0\0\206N\275\307\341\227\356"..., 1448, 0, 
{sa_family=AF_INET, sin_port=htons(34982), 
sin_addr=inet_addr("217.133.231.30")}, 16) = 1448
17718 gettimeofday({1199980402, 562859}, NULL) = 0
17718 gettimeofday({1199980402, 562905}, NULL) = 0
17718 select(8, [3 4 7], NULL, NULL, {0, 0}) = 0 (Timeout)
17718 sendto(6, 
"\200`\35n\31\17\373i\300-FR\0\0\304\335N\305\301\233j0"..., 1448, 0, 
{sa_family=AF_INET, sin_port=htons(34982), 
sin_addr=inet_addr("217.133.231.30")}, 16) = 1448
17718 gettimeofday({1199980402, 563127}, NULL) = 0
17718 gettimeofday({1199980402, 563174}, NULL) = 0
17718 select(8, [3 4 7], NULL, NULL, {0, 0}) = 0 (Timeout)
17718 sendto(6, 
"\200\340\35o\31\17\373i\300-FR\0\0=\2\316~\224\364*\203"..., 754, 0, 
{sa_family=AF_INET, sin_port=htons(34982), 
sin_addr=inet_addr("217.133.231.30")}, 16) = 754
17718 gettimeofday({1199980402, 563391}, NULL) = 0
17718 gettimeofday({1199980402, 563441}, NULL) = 0
17718 select(8, [3 4 7], NULL, NULL, {0, 0}) = 0 (Timeout)
[...]
(blocks on the selects without sending anything)
17718 gettimeofday({1199980402, 563706}, NULL) = 0
17718 gettimeofday({1199980402, 563753}, NULL) = 0
17718 select(8, [3 4 7], NULL, NULL, {0, 0}) = 0 (Timeout)
17718 sendto(6, 
"\200\340\35q\31\32\3277\300-FR\0\0o\360S\372\v\261\35N"..., 451, 0, 
{sa_family=AF_INET, sin_port=htons(34982), 
sin_addr=inet_addr("217.133.231.30")}, 16) = 451
17718 gettimeofday({1199980402, 564062}, NULL) = 0
17718 gettimeofday({1199980402, 564109}, NULL) = 0
17718 gettimeofday({1199980402, 564159}, NULL) = 0
17718 select(8, [3 4 7], NULL, NULL, {2, 320353}) = 0 (Timeout)
17718 gettimeofday({1199980404, 885982}, NULL) = 0
17718 gettimeofday({1199980404, 886090}, NULL) = 0
17718 gettimeofday({1199980404, 886195}, NULL) = 0
17718 gettimeofday({1199980404, 886302}, NULL) = 0
17718 gettimeofday({1199980404, 886407}, NULL) = 0
17718 select(8, [3 4 7], NULL, NULL, {0, 664458}) = 0 (Timeout)

I think this is the reason why it sends one frame, then nothing for 8 
seconds, then another frame. It took me ~ 1000 seconds to send a 320Kb 
raw file from the server to openRTSP (on the loopback interface!)

This is only when i send a pre-recorded raw H263 stream.

Have you idea on what could go wrong?

Thanks.

-- 
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  Thu Jan 10 11:51:52 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 10 Jan 2008 11:51:52 -0800
Subject: [Live-devel] Audio and Video Synchronization Streaming
In-Reply-To: <007601c8539b$f5ac5f90$8642a8c0@dorvalmatrox.matrox.com>
References: <007601c8539b$f5ac5f90$8642a8c0@dorvalmatrox.matrox.com>
Message-ID: <f06240803c3ac27436f74@[66.80.62.44]>

>I developed a testing application using LiveMedia to multicast a 
>live Audio and Video feed. Video is compressed to an Mpeg elementary 
>stream and Audio is PCM 2 channels 16 bits sampled at 48000 Hz. I am 
>using VLC and SMPlayer as a client that receive the streams. When 
>audio or video is streamed alone over IP then VLC and SMPlayer both 
>play fine the stream. However when I stream both audio and video 
>together I ran into synchronization problem and both VLC and 
>SMPlayer drop either the video and or audio stream. And playback 
>become jerky.
>
>I suspect that I might have missing something when initializing 
>LiveMedia in a context of playing a mixed bag of audio and video 
>stream together. Any hints where I should pay attention to keep both 
>stream synchronized.

You need to make sure that your presentation timestamps (i.e., the 
value of the "fPresentationTime" field that you set in each source 
object when implementing "doGetNextFrame()") is accurate, and aligned 
with 'wallclock' time (i.e., the time that you would get if you were 
to call "gettimeofday()").

If the "fPresentationTime" field - for both your audio and video 
sources - is not set correctly (or not set at all), then you will 
never get proper A/V synchronization.
-- 

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/20080110/12f0c94b/attachment.html 

From finlayson at live555.com  Thu Jan 10 12:06:05 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 10 Jan 2008 12:06:05 -0800
Subject: [Live-devel] Possible bug in liveMedia + info request about
 H263 /	H263plus compatibility
In-Reply-To: <4786278C.6010409@imavis.com>
References: <47860BE3.8040900@imavis.com> <4786278C.6010409@imavis.com>
Message-ID: <f06240804c3ac27f899f7@[66.80.62.44]>

>  > I suggest that you first get your server to stream from a file
>>  (containing pre-encoded H.263 video data).  Only once you have that
>>  working properly, should you move to the more difficult step of
>>  streaming from a live encoder.
>
>Did it right now: server sends the prerecorded H263 raw file, and 
>openRTSP receives it.
>
>It's still running, because the server sends a single frame (rtp 
>packets + last marked packet) exactly every 8 seconds:

The problem here is that the timestamp data in your H.263 data is 
(somehow) telling our server that it needs to delay 8 seconds between 
each frame.  In particular, something in your data is causing the 
calculation of "fPresentationTime" (in 
"H263plusVideoStreamFramer.cpp", line 113) to get set incorrectly. 
In particular, the setting of the "currentDuration" 'out' parameter 
in the call to "H263plusVideoStreamParser::parse()" (in 
"H263plusVideoStreamParser.cpp", line 82) is incorrect.

You will need to figure our what about your data is causing the 
parsing to fail.  (It is also not inconceivable that our parsing code 
is in error; if so, let is know.)


>What can the problem be? Also the timestamps of RTP packet seemp to 
>reflect this gap. It's like the server is trying to send 0.125 (1/8) 
>frames per second.

Yes, because that's what your data is telling our code.


>Did you ever try to send H263 instead H263plus data with liveMedia?

Yes.  It works just fine (if the source data is OK).
-- 

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

From Lin.Dong at quixotecorp.com  Thu Jan 10 12:08:41 2008
From: Lin.Dong at quixotecorp.com (Lin.Dong at quixotecorp.com)
Date: Thu, 10 Jan 2008 15:08:41 -0500
Subject: [Live-devel] about mpeg4 stream project
Message-ID: <41E16D542244C24F97752590527EF9BB01FD9A92@flsv1065.pal.quixote.prv>

Hi all,

I am doing a mpeg4 stream project on embedded Linux system, the MPEG4
data come from a circular buffer or ping-pong buffer in my embedded
device, It seems I can start from testOnDemandRTSCServer.cpp, but my
problem is how I can make the memory buffer as a file in Linux system or
do I need to write my own deviceSource code. 

Thanks

Lin 



* C O N F I D E N T I A L I T Y N O T I C E *
-----------------------------------------------------------
The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080110/2df2f4f4/attachment.html 

From finlayson at live555.com  Thu Jan 10 12:10:04 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 10 Jan 2008 12:10:04 -0800
Subject: [Live-devel] Possible bug in liveMedia + info request about
 H263 /	H263plus compatibility
In-Reply-To: <478642A7.9010105@imavis.com>
References: <47860BE3.8040900@imavis.com> <4786278C.6010409@imavis.com>
	<478642A7.9010105@imavis.com>
Message-ID: <f06240805c3ac2bd88266@[66.80.62.44]>

>Using strace (it's difficult to debug liveMedia with a debugger when
>it's running and sending packets), I found that the library seems to
>block for several seconds on a select(), waiting for three fd,
>corresponding to sockets and then timeout on the select.

This is all a Red Herring.  Our base server code is working fine. 
The problem is - as I noted in my previous response - that your 
*source data* is telling the server code that each frame has a 
duration of 8 seconds.
-- 

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

From finlayson at live555.com  Thu Jan 10 13:39:40 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 10 Jan 2008 13:39:40 -0800
Subject: [Live-devel] about mpeg4 stream project
In-Reply-To: <41E16D542244C24F97752590527EF9BB01FD9A92@flsv1065.pal.quixote.prv>
References: <41E16D542244C24F97752590527EF9BB01FD9A92@flsv1065.pal.quixote.prv>
Message-ID: <f06240800c3ac405d5bfa@[66.80.62.44]>

>I am doing a mpeg4 stream project on embedded Linux system, the 
>MPEG4 data come from a circular buffer or ping-pong buffer in my 
>embedded device, It seems I can start from 
>testOnDemandRTSCServer.cpp, but my problem is how I can make the 
>memory buffer as a file in Linux system

The easiest way to do this, IMHO, is to write an application that 
reads encoded data from your buffer, and writes it to 'stdout'.  Then 
pipe this into the "testOnDemandRTSPServer" application, by running:
	your-reader-application | testOnDemandRTSPServer

For this to work, you will need to modify the 
"testOnDemandRTSPServer.cpp" code to
1/ set "reuseFirstSource" to True
2/ use the filename "stdin" instead of "test.m4e"
-- 

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/20080110/fd20cb51/attachment.html 

From belloni at imavis.com  Fri Jan 11 00:54:34 2008
From: belloni at imavis.com (Cristiano Belloni)
Date: Fri, 11 Jan 2008 09:54:34 +0100
Subject: [Live-devel] Possible bug in liveMedia + info request about
 H263 /	H263plus compatibility
In-Reply-To: <f06240804c3ac27f899f7@[66.80.62.44]>
References: <47860BE3.8040900@imavis.com> <4786278C.6010409@imavis.com>
	<f06240804c3ac27f899f7@[66.80.62.44]>
Message-ID: <47872ECA.3000603@imavis.com>


> You will need to figure our what about your data is causing the 
> parsing to fail.  (It is also not inconceivable that our parsing code 
> is in error; if so, let is know.)
>   

Good. I'll go for it and hopefully let the list know what went wrong.
Thanks for your help!


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

From tl11305 at salle.url.edu  Fri Jan 11 02:38:56 2008
From: tl11305 at salle.url.edu (Ramon Martin de Pozuelo Genis)
Date: Fri, 11 Jan 2008 11:38:56 +0100 (CET)
Subject: [Live-devel] testMP3Streamer & SDP's
Message-ID: <1384.172.16.11.128.1200047936.squirrel@webmail.salle.url.edu>

Hi all,
I am using testMP3Streamer to send "test.mp3", and I can listen it opening SDP
file with VLC, but with QuickTime it doesn't work. Although time starts to
advance, I can't listen anything. Is it normal? Has QT some other parameter
requirements in SDP file?

Thanks in advance,

Ramon


From finlayson at live555.com  Fri Jan 11 05:16:52 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 11 Jan 2008 05:16:52 -0800
Subject: [Live-devel] testMP3Streamer & SDP's
In-Reply-To: <1384.172.16.11.128.1200047936.squirrel@webmail.salle.url.edu>
References: <1384.172.16.11.128.1200047936.squirrel@webmail.salle.url.edu>
Message-ID: <f06240801c3ad1ca26412@[66.80.62.44]>

>I am using testMP3Streamer to send "test.mp3", and I can listen it opening SDP
>file with VLC, but with QuickTime it doesn't work.

http://www.live555.com/liveMedia/faq.html#quicktime-player-mp3-bug
-- 

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

From belloni at imavis.com  Fri Jan 11 08:37:29 2008
From: belloni at imavis.com (Cristiano Belloni)
Date: Fri, 11 Jan 2008 17:37:29 +0100
Subject: [Live-devel] [Resolved] info request about H263 /	H263plus
	compatibility
In-Reply-To: <47872ECA.3000603@imavis.com>
References: <47860BE3.8040900@imavis.com>
	<4786278C.6010409@imavis.com>	<f06240804c3ac27f899f7@[66.80.62.44]>
	<47872ECA.3000603@imavis.com>
Message-ID: <47879B49.5010503@imavis.com>


Cristiano Belloni wrote:
>> You will need to figure our what about your data is causing the 
>> parsing to fail.  (It is also not inconceivable that our parsing code 
>> is in error; if so, let is know.)
>>   
>>     
>
> Good. I'll go for it and hopefully let the list know what went wrong.
> Thanks for your help!
>
>
>   


At last, I maneged figured out the problem.

Using ffmpeg to encode H263 frames, I tought I should have to send only 
the raw encoded frames, with no format information.
So I encoded the frames with ffmpeg's avcodec_encode_video and copied 
the encoded buffer into the fifo. With raw MPG4 it works.

Turns out that with H263 I need also the ffmpeg's "raw H263 format" 
(format id string = 'h263') information to be put in the encoded frames 
in order to make them valid.

Now, I encode H263 frames with ffmpeg codec id = 'h263' and format id = 
'h263' and the whole thing seems to work - even @ 25 fps on a mobile phone.

I hope this will be useful to ffmpeg and live555 future users.

Thanks Ross for your answers.

Regards,


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

From belloni at imavis.com  Fri Jan 11 09:37:58 2008
From: belloni at imavis.com (Cristiano Belloni)
Date: Fri, 11 Jan 2008 18:37:58 +0100
Subject: [Live-devel] [Resolved] info request about H263
	/	H263plus	compatibility
In-Reply-To: <47879B49.5010503@imavis.com>
References: <47860BE3.8040900@imavis.com>	<4786278C.6010409@imavis.com>	<f06240804c3ac27f899f7@[66.80.62.44]>	<47872ECA.3000603@imavis.com>
	<47879B49.5010503@imavis.com>
Message-ID: <4787A976.8040703@imavis.com>

Errr.. I mean "I managed to figure out".

> At last, I maneged figured out the problem.
>
>   
-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni at imavis.com>

From richard.zhao at besovideo.com  Tue Jan 15 00:35:47 2008
From: richard.zhao at besovideo.com (Richard Zhao)
Date: Tue, 15 Jan 2008 16:35:47 +0800
Subject: [Live-devel] How to stream speex data with live555
Message-ID: <478c702f.07ec720a.2b3f.39f3@mx.google.com>

Hi all,

I try to write an extension to live555 in order to grep raw audio data and compress it into speex format, and then stream out the compressed data.
Due to my pore knowledge about live555, could anyone provide some hint that where I can start?

BR, Richard


From finlayson at live555.com  Tue Jan 15 01:33:34 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 15 Jan 2008 01:33:34 -0800
Subject: [Live-devel] How to stream speex data with live555
In-Reply-To: <478c702f.07ec720a.2b3f.39f3@mx.google.com>
References: <478c702f.07ec720a.2b3f.39f3@mx.google.com>
Message-ID: <f06240803c3b22dd57a50@[66.80.62.44]>

>I try to write an extension to live555 in order to grep raw audio 
>data and compress it into speex format, and then stream out the 
>compressed data.
>Due to my pore knowledge about live555, could anyone provide some 
>hint that where I can start?

You would need to write a filter class (i.e., a subclass of 
"FramedFilter") that does the encoding into Speex.  You would then 
feed this into a "SimpleRTPSink".  (Because the RTP payload format 
for Speex is so simple, you don't need to write your own "RTPSink" 
subclass for this.)

So, the chain of objects would be

	ByteStreamFileSource -> YourSpeexEncoderFilter -> SimpleRTPSink
-- 

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

From gbonneau at matrox.com  Tue Jan 15 06:36:02 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Tue, 15 Jan 2008 09:36:02 -0500
Subject: [Live-devel] Streaming LPCM audio at 48K with vobStreamer
Message-ID: <007a01c85783$f3c18f20$8642a8c0@dorvalmatrox.matrox.com>

My understanding is the DVD specification has provision to support LPCM
audio sampled at 48K through private extension. I would like to know if the
vobStreamer sample application will be able to process and send such stream
through RTSP/RTP. If this is possible will VLC and MPlayer are able to
receive and play both the audio and video stream.

 

Thanks

Guy Bonneau

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080115/2686c978/attachment-0001.html 

From hpgadam at gmail.com  Tue Jan 15 10:17:51 2008
From: hpgadam at gmail.com (Hanspeter Adam)
Date: Tue, 15 Jan 2008 10:17:51 -0800
Subject: [Live-devel] Unable to unzip live.2008.01.04.tar.tar
Message-ID: <653964df0801151017u70d6c195la0a49c4113de3ccf@mail.gmail.com>

I downloaded live.2008.01.04.tar.tar. WinZip gives me the error "Error
reading header after processing 0 entries". Anyone know what wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080115/abd6d696/attachment.html 

From finlayson at live555.com  Tue Jan 15 14:21:39 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 15 Jan 2008 14:21:39 -0800
Subject: [Live-devel] Unable to unzip live.2008.01.04.tar.tar
In-Reply-To: <653964df0801151017u70d6c195la0a49c4113de3ccf@mail.gmail.com>
References: <653964df0801151017u70d6c195la0a49c4113de3ccf@mail.gmail.com>
Message-ID: <f06240805c3b2e26d349a@[66.80.62.44]>

>I downloaded "live.2008.01.04.tar.tar"

The correct file name is "live.2008.01.04.tar.gz".  (You can also 
download the latest version, at any time, as 
<http://www.live555.com/liveMedia/public/live555-latest.tar.gz>)
-- 

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

From finlayson at live555.com  Tue Jan 15 14:40:32 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 15 Jan 2008 14:40:32 -0800
Subject: [Live-devel] Streaming LPCM audio at 48K with vobStreamer
In-Reply-To: <007a01c85783$f3c18f20$8642a8c0@dorvalmatrox.matrox.com>
References: <007a01c85783$f3c18f20$8642a8c0@dorvalmatrox.matrox.com>
Message-ID: <f06240806c3b2e5c4fd01@[66.80.62.44]>

>My understanding is the DVD specification has provision to support 
>LPCM audio sampled at 48K through private extension. I would like to 
>know if the vobStreamer sample application will be able to process 
>and send such stream through RTSP/RTP

No, but it could easily be modified to do so.  Streaming PCM audio is 
easy; just use a "SimpleRTPSink" (instead of a "AC3AudioRTPSink"). 
See, for example our "testWAVAudioStreamer" demo application.

One thing to watch out for: PCM data streamed within RTP packets must 
be big-endian.  If, instead, your source PCM data is in little-endian 
order, then you will need to add a byte-swapping filter before 
streaming it.  (There is also an example of this in the 
"testWAVAudioStreamer" code.)
-- 

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

From howard.robert4 at gmail.com  Tue Jan 15 23:08:09 2008
From: howard.robert4 at gmail.com (Robert Howard)
Date: Wed, 16 Jan 2008 12:38:09 +0530
Subject: [Live-devel] Quicktime player with Live555
Message-ID: <8ffea5380801152308j459575f4j56af28031b29663e@mail.gmail.com>

Hi

I want to play streaming MPEG4 video (using Live555) on the quick time
player. From the ethereal logs it appears that Quicktime is able to exchange
SDP with the streamer but it is unable to play the video. I see the timer
ticking on the player but no video at all. Has someone done this integration
in past? Any pointers...

-Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080115/60f9fefb/attachment.html 

From finlayson at live555.com  Tue Jan 15 23:59:25 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 15 Jan 2008 23:59:25 -0800
Subject: [Live-devel] Quicktime player with Live555
In-Reply-To: <8ffea5380801152308j459575f4j56af28031b29663e@mail.gmail.com>
References: <8ffea5380801152308j459575f4j56af28031b29663e@mail.gmail.com>
Message-ID: <f06240808c3b368386195@[66.80.62.44]>

>I want to play streaming MPEG4 video (using Live555) on the quick 
>time player. From the ethereal logs it appears that Quicktime is 
>able to exchange SDP with the streamer but it is unable to play the 
>video. I see the timer ticking on the player but no video at all. 
>Has someone done this integration in past?

It works fine.  If you're having problems, it might be because the 
version (profile) of MPEG-4 video that you're using doesn't match 
that which QuickTime Player understands.

You could also try using VLC as a client.

See <http://www.live555.com/liveMedia/public/m4e/> for some examples 
of MPEG-4 Elementary Stream Video (".m4e") files that can be streamed 
- by "live555MediaServer" - to either VLC or QuickTime Player.
-- 

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

From howard.robert4 at gmail.com  Wed Jan 16 02:40:08 2008
From: howard.robert4 at gmail.com (Robert Howard)
Date: Wed, 16 Jan 2008 16:10:08 +0530
Subject: [Live-devel] Quicktime player with Live555
In-Reply-To: <f06240808c3b368386195@66.80.62.44>
References: <8ffea5380801152308j459575f4j56af28031b29663e@mail.gmail.com>
	<f06240808c3b368386195@66.80.62.44>
Message-ID: <8ffea5380801160240o4bd2b1d3vad06476789c8c88d@mail.gmail.com>

I am using profile 4. Any idea would Quicktime support that? Moreover I am
able to play using VLC.

- Rob

On Jan 16, 2008 1:29 PM, Ross Finlayson <finlayson at live555.com> wrote:

>  >I want to play streaming MPEG4 video (using Live555) on the quick
> >time player. From the ethereal logs it appears that Quicktime is
> >able to exchange SDP with the streamer but it is unable to play the
> >video. I see the timer ticking on the player but no video at all.
> >Has someone done this integration in past?
>
> It works fine.  If you're having problems, it might be because the
> version (profile) of MPEG-4 video that you're using doesn't match
> that which QuickTime Player understands.
>
> You could also try using VLC as a client.
>
> See <http://www.live555.com/liveMedia/public/m4e/> for some examples
> of MPEG-4 Elementary Stream Video (".m4e") files that can be streamed
> - by "live555MediaServer" - to either VLC or QuickTime Player.
> --
>
> 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/20080116/3fc855e6/attachment.html 

From finlayson at live555.com  Wed Jan 16 04:12:33 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 16 Jan 2008 04:12:33 -0800
Subject: [Live-devel] Quicktime player with Live555
In-Reply-To: <8ffea5380801160240o4bd2b1d3vad06476789c8c88d@mail.gmail.com>
References: <8ffea5380801152308j459575f4j56af28031b29663e@mail.gmail.com>
	<f06240808c3b368386195@66.80.62.44>
	<8ffea5380801160240o4bd2b1d3vad06476789c8c88d@mail.gmail.com>
Message-ID: <f06240800c3b3a515875f@[66.80.62.44]>

>I am using profile 4. Any idea would Quicktime support that?

I don't know.  I suggest asking on a QuickTime mailing list.
-- 

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

From gbonneau at matrox.com  Wed Jan 16 07:21:36 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Wed, 16 Jan 2008 10:21:36 -0500
Subject: [Live-devel] Streaming an Mpeg-2 program stream
Message-ID: <018c01c85853$7c094010$8642a8c0@dorvalmatrox.matrox.com>

It seems LiveMedia doesn't have provision to stream an Mpeg-2 Program Stream
without demuxing to elementary streams. Yet RTP has provision to stream an
Mpeg-2 program stream without demuxing. This is useful for example in cases
when a program Mpeg-2 stream might include private data that LiveMedia
doesn't recognize. Any reason why streaming of an Mpeg-2 program stream
haven't been implemented?

 

Regards

Guy Bonneau

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080116/72da892b/attachment.html 

From belloni at imavis.com  Wed Jan 16 08:04:29 2008
From: belloni at imavis.com (Cristiano Belloni)
Date: Wed, 16 Jan 2008 17:04:29 +0100
Subject: [Live-devel] Server doesn't interleave reads from pipe and sending
 packets?
Message-ID: <478E2B0D.1030600@imavis.com>

Hi, I'm streaming with liveMedia RTSP server from a FIFO (a separate 
process encodes frames and writes in it).

I noticed with strace that my server, to which i add a 
H263plusVideoFileServerMediaSubsession, does a lot of read()s from the 
fifo in a row and then a lot of send()s to the socket.

So, there's about two seconds in which the server is reading from the 
fifo (and _not_ streaming) and about two seconds in which the server is 
streaming (and _not_ reading from the FIFO).

This cause two-second pauses in the client (that receives nothing while 
the server is consuming the fifo) and blocked write(s) in the fifo (that 
becomes full while the server is streaming).

Maybe it has something to do with the estBitrate in 
H263plusVideoFileServerMediaSubsession (too large or too short)? Should 
I subclass and change it?

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  Wed Jan 16 18:07:59 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 16 Jan 2008 18:07:59 -0800
Subject: [Live-devel] Server doesn't interleave reads from pipe and
 sending packets?
In-Reply-To: <478E2B0D.1030600@imavis.com>
References: <478E2B0D.1030600@imavis.com>
Message-ID: <f06240804c3b46756288f@[66.80.62.44]>

First, you should make sure that if the same data is stored in a 
regular file - rather than on a FIFO - then you can stream it OK. 
This will help ensure that you don't have problems with bad 
timestamps in your data.

Second, when you read from a FIFO, you must make sure that reads from 
the FIFO are *asynchronous* - i.e., non-blocking, and handled within 
the event loop.  If the read end of your FIFO - as seen from your 
server - is a normal open file, then this should happen 
automatically, *unless* you are running Windows.  (Windows is 
brain-damaged, and doesn't always treat open files as being 
select()able sockets, so reads on open files in Windows are 
synchronous by default.)

Apart from this, because you're working with your own custom code, 
there's not a whole lot more I can suggest.
-- 

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

From finlayson at live555.com  Wed Jan 16 18:14:16 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 16 Jan 2008 18:14:16 -0800
Subject: [Live-devel] Streaming an Mpeg-2 program stream
In-Reply-To: <018c01c85853$7c094010$8642a8c0@dorvalmatrox.matrox.com>
References: <018c01c85853$7c094010$8642a8c0@dorvalmatrox.matrox.com>
Message-ID: <f06240806c3b4698eadb9@[66.80.62.44]>

>It seems LiveMedia doesn't have provision to stream an Mpeg-2 
>Program Stream without demuxing to elementary streams. Yet RTP has 
>provision to stream an Mpeg-2 program stream without demuxing.

Yes, but noone implements this (at either the server or client ends), 
so it's not useful.  It would also be nontrivial to implement at the 
server end, because we would need to parse timestamp data within the 
Program Stream.


>  This is useful for example in cases when a program Mpeg-2 stream 
>might include private data that LiveMedia doesn't recognize.

If you want to do this, then you should convert your Program Stream 
data to Transport Stream files (e.g., using our 
"testMPEG1or2ProgramToTransportStream" demo application), and stream 
the Transport Stream files.  Streaming MPEG Transport Stream files is 
very common, and well-supported by both servers and clients.
-- 

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/20080116/42adbfc9/attachment.html 

From belloni at imavis.com  Thu Jan 17 00:44:46 2008
From: belloni at imavis.com (Cristiano Belloni)
Date: Thu, 17 Jan 2008 09:44:46 +0100
Subject: [Live-devel] Server doesn't interleave reads from pipe and
 sending packets?
In-Reply-To: <f06240804c3b46756288f@[66.80.62.44]>
References: <478E2B0D.1030600@imavis.com> <f06240804c3b46756288f@[66.80.62.44]>
Message-ID: <478F157E.7080806@imavis.com>

Ross Finlayson wrote:
> First, you should make sure that if the same data is stored in a 
> regular file - rather than on a FIFO - then you can stream it OK. 
> This will help ensure that you don't have problems with bad 
> timestamps in your data.
>   
I can.
> Second, when you read from a FIFO, you must make sure that reads from 
> the FIFO are *asynchronous* - i.e., non-blocking, and handled within 
> the event loop.
The library handles this: The server is very simple:

TaskScheduler* scheduler = BasicTaskScheduler::createNew();
env = BasicUsageEnvironment::createNew(*scheduler);

RTSPServer* rtspServer = RTSPServer::createNew(*env, 554, authDB, 45);

[..]
  
H263plusVideoFileServerMediaSubsession* mss = 
H263plusVideoFileServerMediaSubsession::createNew(*env, inputFileName, 
reuseFirstSource);
   
sms->addSubsession(mss);
   
rtspServer->addServerMediaSession(sms);

  }

 env->taskScheduler().doEventLoop();

I omitted the variable initizations; inputFileName is obviously filename 
of the FIFO. And, yes, I set reuseFirstSource to true.
>  If the read end of your FIFO - as seen from your 
> server - is a normal open file, then this should happen 
> automatically, *unless* you are running Windows.  (Windows is 
> brain-damaged, and doesn't always treat open files as being 
> select()able sockets, so reads on open files in Windows are 
> synchronous by default.)
>   
Nope, I'm running Linux.
> Apart from this, because you're working with your own custom code, 
> there's not a whole lot more I can suggest.
>   
Do you see any errors in the server code I posted?

Thanks,

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  Thu Jan 17 05:27:56 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 17 Jan 2008 05:27:56 -0800
Subject: [Live-devel] Server doesn't interleave reads from pipe and
 sending packets?
In-Reply-To: <478F157E.7080806@imavis.com>
References: <478E2B0D.1030600@imavis.com>
	<f06240804c3b46756288f@[66.80.62.44]> <478F157E.7080806@imavis.com>
Message-ID: <f06240800c3b5085026fe@[66.80.62.44]>

>Do you see any errors in the server code I posted?

No.
-- 

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

From belloni at imavis.com  Thu Jan 17 11:48:40 2008
From: belloni at imavis.com (belloni at imavis.com)
Date: Thu, 17 Jan 2008 20:48:40 +0100 (CET)
Subject: [Live-devel] RTSP Client subclassing questions.
Message-ID: <34831.213.140.21.234.1200599320.squirrel@imaserver.imavis.com>

Hi, parallel to my RTSP server I'm developing a client to interface with
some ip-cams.
I read openRTSP source, and I modified it to my needs, and it works
wonderfully.

However, I need some info: the camera I'm contacting does not send normal
video frames, but custom ones. I need to unpack every RTP packet (_in
order_), read the custom headers, reconstruct the frames and decode them
on the fly.

The question is: what method of what class should I subclass to have
access to every single packet in sequence order? I noticed RTPSource's
getNextFrame *afterGettingFunc parameter, should I replace getNextFrame
method and set afterGettingFunc to my "unpacker" function?

Notice I'd like to process every packet in arrival order (alternatively,
if it's not possible at all, i think i can look into the whole frame and
parse it to extract the packets).

Another quick question: instead of passing a starting UDP port to the
client, can I pass an already-open UDP socket? The cameras will send
packets to the same ports, if I let them decide, and if two or more
instances of the client run at once, it will bring chaos & destruction,
because they will try to bind to the same port.

Many thanks as usual,

Cristiano.


From finlayson at live555.com  Thu Jan 17 13:52:19 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 17 Jan 2008 13:52:19 -0800
Subject: [Live-devel] RTSP Client subclassing questions.
In-Reply-To: <34831.213.140.21.234.1200599320.squirrel@imaserver.imavis.com>
References: <34831.213.140.21.234.1200599320.squirrel@imaserver.imavis.com>
Message-ID: <f06240802c3b57b63010a@[66.80.62.44]>

>However, I need some info: the camera I'm contacting does not send normal
>video frames, but custom ones. I need to unpack every RTP packet (_in
>order_), read the custom headers, reconstruct the frames and decode them
>on the fly.

Because your 'custom headers' are not RTP-specific, but are instead 
part of your payload, you should not write any new RTP-specific code 
for this.  Instead, just have the object that reads from your 
"RTPSource" (subclass) object do the processing/decoding of these 
custom frames.


>The question is: what method of what class should I subclass to have
>access to every single packet in sequence order?

You don't need to write any new code for this.  Our RTP reception 
code automatically ensures that incoming RTP packets are delivered in 
the correct order (based on RTP sequence number).


>Another quick question: instead of passing a starting UDP port to the
>client, can I pass an already-open UDP socket? The cameras will send
>packets to the same ports, if I let them decide, and if two or more
>instances of the client run at once, it will bring chaos & destruction,
>because they will try to bind to the same port.

I'm not sure I totally understand this question.  However, if you 
look at how "openRTSP" implements the "-p <startingPortNumber>" 
option, then that should give you the information you need.
-- 

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

From Lin.Dong at quixotecorp.com  Thu Jan 17 15:02:37 2008
From: Lin.Dong at quixotecorp.com (Lin.Dong at quixotecorp.com)
Date: Thu, 17 Jan 2008 18:02:37 -0500
Subject: [Live-devel] about mpeg4 stream project
Message-ID: <41E16D542244C24F97752590527EF9BB01FD9A9D@flsv1065.pal.quixote.prv>

Hi Ross and all,

Thank you for your advice.

I did some simulation tests today as you advised (
your-reader-application | testOnDemandRTSPServer), 
but somehow I did get stream video success, the VLC player could not get
any data from my application.

the first thing I did was I changed testOnDemandRTSPServer.cpp as you
advised, when I run the program, I did see "stream from the file "stdin"
"  came out on my screen, I think this program has no problem; The real
problem might come from my "your-reader-application.c". In this program,
I read a mpeg4 data file to my internal buffer and then I write these
data to "stdout".

I used  
strIn = fopen("test.m4e", "rb") to open a stream io;
and fread(buf, sizeof(unsigned char), 1024*1024, strIn) to get data in
my buffer;

I check the data in the buffer, they are OK. 

I used a couple of "c" functions to send data out, such as
fprinf(stdout, "%x", data) and fwrite( &data, sizeof(unsigned char),
data_size)...... 
but none of them make the program working. I think the data type may be
wrong from my first program to sendcond program.

I guess the type of data sending to "stdout" is binary, and next
program's "stdin" will read binary data too. some how I do not know how
to make the "stdout" as a binary stream io. In window program, I can use
_setmode() to change stream io property. 

Please help.

Thank you in advance.     

Lin Dong 
Quixote Corp.


Ross Finlayson finlayson at live555.com
<mailto:live-devel%40lists.live555.com?Subject=%5BLive-devel%5D%20about%
20mpeg4%20stream%20project&In-Reply-To=41E16D542244C24F97752590527EF9BB0
1FD9A92%40flsv1065.pal.quixote.prv> 
Thu Jan 10 13:39:40 PST 2008 
*	Previous message: [Live-devel] about mpeg4 stream project
<007957.html> 
*	Next message: [Live-devel] testMP3Streamer & SDP's
<007961.html> 
*	Messages sorted by: [ date ] <date.html>  [ thread ]
<thread.html>  [ subject ] <subject.html>  [ author ] <author.html>  

>I am doing a mpeg4 stream project on embedded Linux system, the 
>MPEG4 data come from a circular buffer or ping-pong buffer in my 
>embedded device, It seems I can start from 
>testOnDemandRTSCServer.cpp, but my problem is how I can make the 
>memory buffer as a file in Linux system

The easiest way to do this, IMHO, is to write an application that 
reads encoded data from your buffer, and writes it to 'stdout'.  Then 
pipe this into the "testOnDemandRTSPServer" application, by running:
	your-reader-application | testOnDemandRTSPServer

For this to work, you will need to modify the 
"testOnDemandRTSPServer.cpp" code to
1/ set "reuseFirstSource" to True
2/ use the filename "stdin" instead of "test.m4e"
-- 

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/20080110/fd20c
b51/attachment.html 




* C O N F I D E N T I A L I T Y N O T I C E *
-----------------------------------------------------------
The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080117/5eb5c695/attachment.html 

From finlayson at live555.com  Thu Jan 17 17:54:38 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 17 Jan 2008 17:54:38 -0800
Subject: [Live-devel] about mpeg4 stream project
In-Reply-To: <41E16D542244C24F97752590527EF9BB01FD9A9D@flsv1065.pal.quixote.prv>
References: <41E16D542244C24F97752590527EF9BB01FD9A9D@flsv1065.pal.quixote.prv>
Message-ID: <f06240800c3b5b694246f@[66.80.62.44]>

I assume that your "test.m4e" file plays OK on VLC when you stream it 
using the original, unmodified "testOnDemandRTSPServer".  If so, then 
- when you modify "testOnDemandRTSPServer" to (i) read from "stdin" 
instead of "test.m4e", and (ii) set "reuseFirstSource" to True - you 
should also be able to run
	testOnDemandRTSPServer < test.m4e

If that also works, then you should be able to run
	your-reader-application | testOnDemandRTSPServer
but I can't help you with that, because that's your own code.
-- 

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

From finlayson at live555.com  Fri Jan 18 02:14:42 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 18 Jan 2008 02:14:42 -0800
Subject: [Live-devel] How to get NPT of a received RTP Packet in openRTSP
In-Reply-To: <9219A756FBA09B4D8CE75D4D7987D6CB563275@KABEX01.sharpamericas.com>
References: <9219A756FBA09B4D8CE75D4D7987D6CB563275@KABEX01.sharpamericas.com>
Message-ID: <f06240803c3b62bccce08@[66.80.62.44]>

>How does one obtain the current NPT (normal playing time) of a
>received packet?

FYI, the latest release (2008.01.18) of the "LIVE555 Streaming Media" 
code adds support for this.  Specifically, there is a new member 
function
	MediaSubsession::getNormalPlayTime()
which - given a stream's current presentation time - returns the 
"Normal Play Time" - as defined in RFC 2326, section 3.6.  This is 
useful for RTSP-initiated streams.

For more information, see the definition in 
"liveMedia/include/MediaSession.hh".
-- 

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

From belloni at imavis.com  Fri Jan 18 04:00:36 2008
From: belloni at imavis.com (Cristiano Belloni)
Date: Fri, 18 Jan 2008 13:00:36 +0100
Subject: [Live-devel] RTSP Client subclassing questions.
In-Reply-To: <f06240802c3b57b63010a@[66.80.62.44]>
References: <34831.213.140.21.234.1200599320.squirrel@imaserver.imavis.com>
	<f06240802c3b57b63010a@[66.80.62.44]>
Message-ID: <479094E4.5010002@imavis.com>

Ross Finlayson wrote:
>> However, I need some info: the camera I'm contacting does not send normal
>> video frames, but custom ones. I need to unpack every RTP packet (_in
>> order_), read the custom headers, reconstruct the frames and decode them
>> on the fly.
>>     
>
> Because your 'custom headers' are not RTP-specific, but are instead 
> part of your payload, you should not write any new RTP-specific code 
> for this.  Instead, just have the object that reads from your 
> "RTPSource" (subclass) object do the processing/decoding of these 
> custom frames.
>
>   

Ehm, sorry, I didn't understand your answer. Do you mean I should 
subclass RTPSource?
What's exactly the object that reads from it?

-- 
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 Jan 18 06:45:01 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 18 Jan 2008 06:45:01 -0800
Subject: [Live-devel] RTSP Client subclassing questions.
In-Reply-To: <479094E4.5010002@imavis.com>
References: <34831.213.140.21.234.1200599320.squirrel@imaserver.imavis.com>
	<f06240802c3b57b63010a@[66.80.62.44]> <479094E4.5010002@imavis.com>
Message-ID: <f06240805c3b66af913ec@[66.80.62.44]>

>Ross Finlayson wrote:
>>>  However, I need some info: the camera I'm contacting does not send normal
>>>  video frames, but custom ones. I need to unpack every RTP packet (_in
>>>  order_), read the custom headers, reconstruct the frames and decode them
>>>  on the fly.
>>>    
>>
>>  Because your 'custom headers' are not RTP-specific, but are instead
>>  part of your payload, you should not write any new RTP-specific code
>>  for this.  Instead, just have the object that reads from your
>>  "RTPSource" (subclass) object do the processing/decoding of these
>>  custom frames.
>>
>>  
>
>Ehm, sorry, I didn't understand your answer. Do you mean I should
>subclass RTPSource?

I'm saying that you might not need to write any new (sub)classes at 
all.  Can you tell me some more about what your data looks like - 
i.e., what video codec are you using, and how is the data different 
from the standard?
-- 

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

From belloni at imavis.com  Fri Jan 18 07:05:12 2008
From: belloni at imavis.com (Cristiano Belloni)
Date: Fri, 18 Jan 2008 16:05:12 +0100
Subject: [Live-devel] RTSP Client subclassing questions.
In-Reply-To: <f06240805c3b66af913ec@[66.80.62.44]>
References: <34831.213.140.21.234.1200599320.squirrel@imaserver.imavis.com>	<f06240802c3b57b63010a@[66.80.62.44]>
	<479094E4.5010002@imavis.com> <f06240805c3b66af913ec@[66.80.62.44]>
Message-ID: <4790C028.4000601@imavis.com>

Ross Finlayson wrote:
>> Ross Finlayson wrote:
>>     
>>>>  However, I need some info: the camera I'm contacting does not send normal
>>>>  video frames, but custom ones. I need to unpack every RTP packet (_in
>>>>  order_), read the custom headers, reconstruct the frames and decode them
>>>>  on the fly.
>>>>    
>>>>         
>>>  Because your 'custom headers' are not RTP-specific, but are instead
>>>  part of your payload, you should not write any new RTP-specific code
>>>  for this.  Instead, just have the object that reads from your
>>>  "RTPSource" (subclass) object do the processing/decoding of these
>>>  custom frames.
>>>
>>>  
>>>       
>> Ehm, sorry, I didn't understand your answer. Do you mean I should
>> subclass RTPSource?
>>     
>
> I'm saying that you might not need to write any new (sub)classes at 
> all.  Can you tell me some more about what your data looks like - 
> i.e., what video codec are you using, and how is the data different 
> from the standard?
>   
It's MPEG-4 data, 1440 bytes a packet. At the start of each packet 
there's a 16 or 6 bytes header that I must read, depending on the fact 
the packet starts a frame or is a middle/ending packet.

I'd need to analyze the payload of every RTP packet I receive, read the 
header, accumulate the MPEG-4 data following the header and, as soon as 
I have an MPEG-4 frame, pass it to a decoder.

Is there something like a function that is called everytime I get an RTP 
packet, so I can examine its payload?

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

From arnaki_sto_fourno at yahoo.gr  Fri Jan 18 08:11:34 2008
From: arnaki_sto_fourno at yahoo.gr (Tasos Kyrillidis)
Date: Fri, 18 Jan 2008 16:11:34 +0000 (GMT)
Subject: [Live-devel] JPEG2000
Message-ID: <790057.61657.qm@web26901.mail.ukl.yahoo.com>


Hi,

I already a message on this list and nobody answered. So i send it again...

I am newbie in LIVE555 and i really dont know much of how things work. But i intend to study the source code. Before i do this, i would like to ask some questions to be sure about some things.

I want to implement a Motion JPEG2000 Real-Time Transport system between two PCs (initially). I downloaded your source code and i saw that there isnt any support for JPEG2000 files.

1. Is it in your plans to implement it soon?

If not, i would like to try it. But i cannot estimate the work it needs. 

2. Besides Internet Drafts, is there any RTP implementation for JPEG2000?

Finally and most important:

3. As i am newbie in this project, could you please tell me what exactly should i do? I mean a general plan about which files should i look into, which files affect this implementation, where to pay more attention?

Thank for your time. I would be really graceful if somebody helped me. 

Tasos Kyrillidis

       
---------------------------------
 ?????????????? Yahoo!
 ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
 http://login.yahoo.com/config/mail?.intl=gr 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080118/82947453/attachment.html 

From arnaki_sto_fourno at yahoo.gr  Fri Jan 18 08:15:39 2008
From: arnaki_sto_fourno at yahoo.gr (Tasos Kyrillidis)
Date: Fri, 18 Jan 2008 16:15:39 +0000 (GMT)
Subject: [Live-devel] H.264 - How to implement an H.264 framer?
Message-ID: <575981.63127.qm@web26901.mail.ukl.yahoo.com>


Hi,

I dont know how to implement an H.264 framer. Could anybody help me?
Tasos Kyrillidis

       
---------------------------------
 ?????????????? Yahoo!
 ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? 
 http://login.yahoo.com/config/mail?.intl=gr 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080118/f40bb0fc/attachment.html 

From belloni at imavis.com  Fri Jan 18 09:03:52 2008
From: belloni at imavis.com (Cristiano Belloni)
Date: Fri, 18 Jan 2008 18:03:52 +0100
Subject: [Live-devel] RTSP Client subclassing questions.
In-Reply-To: <4790C028.4000601@imavis.com>
References: <34831.213.140.21.234.1200599320.squirrel@imaserver.imavis.com>	<f06240802c3b57b63010a@[66.80.62.44]>	<479094E4.5010002@imavis.com>
	<f06240805c3b66af913ec@[66.80.62.44]> <4790C028.4000601@imavis.com>
Message-ID: <4790DBF8.6090900@imavis.com>

Cristiano Belloni wrote:
> Ross Finlayson wrote:
>   
>>> Ross Finlayson wrote:
>>>     
>>>       
>>>>>  However, I need some info: the camera I'm contacting does not send normal
>>>>>  video frames, but custom ones. I need to unpack every RTP packet (_in
>>>>>  order_), read the custom headers, reconstruct the frames and decode them
>>>>>  on the fly.
>>>>>    
>>>>>         
>>>>>           
>>>>  Because your 'custom headers' are not RTP-specific, but are instead
>>>>  part of your payload, you should not write any new RTP-specific code
>>>>  for this.  Instead, just have the object that reads from your
>>>>  "RTPSource" (subclass) object do the processing/decoding of these
>>>>  custom frames.
>>>>
>>>>  
>>>>       
>>>>         
>>> Ehm, sorry, I didn't understand your answer. Do you mean I should
>>> subclass RTPSource?
>>>     
>>>       
>> I'm saying that you might not need to write any new (sub)classes at 
>> all.  Can you tell me some more about what your data looks like - 
>> i.e., what video codec are you using, and how is the data different 
>> from the standard?
>>   
>>     
> It's MPEG-4 data, 1440 bytes a packet. At the start of each packet 
> there's a 16 or 6 bytes header that I must read, depending on the fact 
> the packet starts a frame or is a middle/ending packet.
>
> I'd need to analyze the payload of every RTP packet I receive, read the 
> header, accumulate the MPEG-4 data following the header and, as soon as 
> I have an MPEG-4 frame, pass it to a decoder.
>
> Is there something like a function that is called everytime I get an RTP 
> packet, so I can examine its payload?
>
>   
Alternatively, I could parse a whole frame, recognize the headers and 
extract them. Maybe the way to go is to set afterGettingFunc 
<http://www.live555.com/liveMedia/doxygen/html/classFramedSource.html#e39d6c83790473cabce9b4cdb873c50d>  
inside  the RTPSource? But it seems I can't do it without subclassing.

Please note I would like to analyze packets in memory buffers in a 
packet per packet or, if it's not possible, frame - per frame fashion, 
so I don't want to use use pipes and the like (for example, to redirect 
stream to stdout and analyze it in another piped process).

-- 
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 Jan 18 14:36:16 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 18 Jan 2008 14:36:16 -0800
Subject: [Live-devel] JPEG2000
In-Reply-To: <790057.61657.qm@web26901.mail.ukl.yahoo.com>
References: <790057.61657.qm@web26901.mail.ukl.yahoo.com>
Message-ID: <f06240801c3b6d7b838c1@[66.80.62.44]>

>I already a message on this list and nobody answered. So i send it again...

Because of this, all future postings from you will be moderated.  If 
you do this again (sending the exact same message to the mailing 
list), you will be permanently banned!

Not every question that gets posted to this mailing list ends up 
getting answered.  (Note, however, that in general, questions posted 
by people with professional email addresses - i.e., *not* "@gmail", 
"@yahoo", "@hotmail" etc. - are more likely to get answered.)

But in short, there are no current plans to implement the RTP payload 
format for JPEG 2000 (as currently defined in the Internet Draft 
<http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-18.txt>). 
If you want to do this yourself, you would need to implement new 
subclasses of "MultiFramedRTPSink" (for transmission) and 
"MultiFramedRTPSource" (for reception), similar to the existing 
"JPEGVideoRTPSink" and "JPEGVideoRTPSource" classes.
-- 

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/20080118/0fb14bef/attachment.html 

From blaine1943 at hotmail.com  Fri Jan 18 15:38:03 2008
From: blaine1943 at hotmail.com (Richard Blaine)
Date: Fri, 18 Jan 2008 15:38:03 -0800
Subject: [Live-devel] liveMedia support
Message-ID: <BAY144-W134978DC86AAB3F33BC5B8CD420@phx.gbl>



_________________________________________________________________
Helping your favorite cause is as easy as instant messaging.? You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080118/f37c2c61/attachment-0001.html 

From blaine1943 at hotmail.com  Fri Jan 18 15:44:57 2008
From: blaine1943 at hotmail.com (Richard Blaine)
Date: Fri, 18 Jan 2008 15:44:57 -0800
Subject: [Live-devel] liveMedia support
Message-ID: <BAY144-W1358A927BB33B733E87B98CD420@phx.gbl>



Hi,
I am a consultant who was hired to evaluate software that was based on the liveMedia library; more specifically, my goal is to determine whether all or part of this existing software can be extended and used in a commercial medical product. This software was last modified in 2004. A few questions for you:
 
1) Is liveMedia still supported; i.e., is there still an active community of users who can answer questions about it?
2) How much has liveMedia changed since 2004?
3) Any other pertinent information that you can give me regarding my evaluation?
 
Thanks in advance,
Richard
 
 
_________________________________________________________________
Climb to the top of the charts!? Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080118/1fdb5f1a/attachment.html 

From finlayson at live555.com  Fri Jan 18 15:52:11 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 18 Jan 2008 15:52:11 -0800
Subject: [Live-devel] liveMedia support
In-Reply-To: <BAY144-W1358A927BB33B733E87B98CD420@phx.gbl>
References: <BAY144-W1358A927BB33B733E87B98CD420@phx.gbl>
Message-ID: <f06240800c3b6eb4726c7@[66.80.62.44]>

>1) Is liveMedia still supported; i.e., is there still an active 
>community of users who can answer questions about it?

Yes, and this is the mailing list for it.

>2) How much has liveMedia changed since 2004?

It has changed vastly since then.  See, for example, our changelog at 
<http://www.live555.com/liveMedia/public/changelog.txt>

Note that absolutely no support is given for old versions of the 
code, so - if you want support from this mailing list - you must 
upgrade to the latest version of the code, available from 
<http://www.live555.com/liveMedia/public/live555-latest.tar.gz>
-- 

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/20080118/74353f4c/attachment.html 

From finlayson at live555.com  Fri Jan 18 16:59:33 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 18 Jan 2008 16:59:33 -0800
Subject: [Live-devel] RTSP Client subclassing questions.
In-Reply-To: <4790C028.4000601@imavis.com>
References: <34831.213.140.21.234.1200599320.squirrel@imaserver.imavis.com>
	<f06240802c3b57b63010a@[66.80.62.44]>	<479094E4.5010002@imavis.com>
	<f06240805c3b66af913ec@[66.80.62.44]> <4790C028.4000601@imavis.com>
Message-ID: <f06240801c3b6fa9c3cf9@[66.80.62.44]>

>  > I'm saying that you might not need to write any new (sub)classes at
>>  all.  Can you tell me some more about what your data looks like -
>>  i.e., what video codec are you using, and how is the data different
>>  from the standard?
>>  
>It's MPEG-4 data, 1440 bytes a packet.

MPEG-4 frames are variable-length, and so cannot always be 1440 bytes 
in length.

It sounds like you are trying to implement your own (nonstandard) RTP 
payload format - therefore I'm not able to help you.  However, if you 
still wish to proceed down this route, then you will need to (i) 
implement your own subclass of "MultiFramedRTPSink" for transmitting 
your payload format.  And then, because your payload format won't be 
understandable by any standard client, you will also need to (ii) 
implement your own subclass of "MultiFramedRTPSource" for receiving 
your data, and use it to implement your own client.  At this point 
you're on your own.  Good luck.
-- 

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

From belloni at imavis.com  Fri Jan 18 21:04:23 2008
From: belloni at imavis.com (belloni at imavis.com)
Date: Sat, 19 Jan 2008 06:04:23 +0100 (CET)
Subject: [Live-devel] RTSP Client subclassing questions.
In-Reply-To: <f06240801c3b6fa9c3cf9@[66.80.62.44]>
References: <34831.213.140.21.234.1200599320.squirrel@imaserver.imavis.com>
	<f06240802c3b57b63010a@[66.80.62.44]> <479094E4.5010002@imavis.com>
	<f06240805c3b66af913ec@[66.80.62.44]> <4790C028.4000601@imavis.com>
	<f06240801c3b6fa9c3cf9@[66.80.62.44]>
Message-ID: <42494.213.140.21.234.1200719063.squirrel@imaserver.imavis.com>

>>  > I'm saying that you might not need to write any new (sub)classes at
>>>  all.  Can you tell me some more about what your data looks like -
>>>  i.e., what video codec are you using, and how is the data different
>>>  from the standard?
>>>
>>It's MPEG-4 data, 1440 bytes a packet.
>
> MPEG-4 frames are variable-length, and so cannot always be 1440 bytes
> in length.

Maybe there is a misunderstanding.
The server will send RTP packets, payload size of 1440 bytes if they are
starting or middle frame packet. If they are ending frame packets, packet
length will  be variable:

[...]
---frame n starts
RTP packet - 1440 bytes payload
RTP packet - 1440 bytes payload
RTP packet - ? (< 1440) bytes payload
---frame n ends
---frame n+1 starts
RTP packet - 1440 bytes payload
RTP packet - 1440 bytes payload
RTP packet - 1440 bytes payload
RTP packet - 1440 bytes payload
RTP packet - ? (< 1440) bytes payload
---frame n+1 ends
[...]

What I'm asking is:

1) Is there a way to set up a function that's called every time an RTP
packet is received?

2) If there is, will the packtes be in order (i.e. function for packet n
is called _after_ function for packet n-1 and _before_ packet n+1)?

Alternatively, packets will normally have the mark flag set to "true" to
mark the boundaries  between a frame and the next.

3) Is there a way to set up a function that's called every time an RTP
frame  is received?


From gbonneau at matrox.com  Mon Jan 21 07:07:32 2008
From: gbonneau at matrox.com (Guy Bonneau)
Date: Mon, 21 Jan 2008 10:07:32 -0500
Subject: [Live-devel] Mpeg2 Elementary Streams Muxing to Transport Stream
Message-ID: <059301c85c3f$593d8c40$8642a8c0@dorvalmatrox.matrox.com>

Hi Ross,

 

Thanks for the incredible support you are giving to this list. This is
greatly appreciated.

 

I tried to find some simple testing program demoed the muxing of elementary
streams with the MPEG2TransportStreamFromESSource implementation and
couldn't yet. If you are aware of some public testing code I would greatly
appreciate where to find it. If no such code exist could you please provide
some hints about how to use the implementation. I would like to use it to
test the multiplexing of a few Mpeg2 streams (video and audio) inside a
transport stream.

 

Regards

Guy Bonneau

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080121/386b57fd/attachment.html 

From martin at startwars.org  Mon Jan 21 08:41:34 2008
From: martin at startwars.org (Martin Lindhe)
Date: Mon, 21 Jan 2008 17:41:34 +0100
Subject: [Live-devel] H263-1996 rtp question
Message-ID: <4794CB3E.9060902@startwars.org>

Hello all :-)

I've been on this list for some weeks now although I have not posted much.

I am working on setting up a streaming environment where a number of 
different RTP payload types are involved, and currently I am looking 
into reading a H263 stream (the original "H263-1996" type, not H263+).

So I have been looking and comparing the H263 and H263+ RTP spec's to 
see how much work there would be to possibly implement it by reusing 
some of the H263+ RTP code already found in liveMedia as a base. But I 
wanted to ask the list if any work has been done in that area, or if 
anyone have some starter points?

Best regards
Martin Lindhe

From gun at xanboo.com  Mon Jan 21 13:39:08 2008
From: gun at xanboo.com (gun alppay)
Date: Mon, 21 Jan 2008 16:39:08 -0500
Subject: [Live-devel] recorded .mp4 file won't play locally in Quicktime
Message-ID: <479510FC.4040206@xanboo.com>

i've been using openRTSP to record video to be streamed back over Darwin 
later on. the video is recorded as .mp4 format and the streaming back 
works fine. however, recorded clips will not play locally in Quicktime. 
they play without any problems in VLC.

the current sourcecode i'm using is the release dated 01.17.2007 and 
i've made minor modifications to it to record a stream into multiple 
files by making cuts at Iframe boundaries. i will be updating to the 
latest sourcecode but I haven't seen any fixes in between the two 
releases that are relevant to this problem in the change log. is this a 
known problem with the current release, as well?

the recording options I'm using are:

-v -4 -w 320 -h 240 -f 15 -H -b 50000

thanks,
gun alppay


From finlayson at live555.com  Mon Jan 21 17:36:40 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 21 Jan 2008 17:36:40 -0800
Subject: [Live-devel] H263-1996 rtp question
In-Reply-To: <4794CB3E.9060902@startwars.org>
References: <4794CB3E.9060902@startwars.org>
Message-ID: <f06240801c3baf80a6f45@[66.80.62.44]>

>I am working on setting up a streaming environment where a number of
>different RTP payload types are involved, and currently I am looking
>into reading a H263 stream (the original "H263-1996" type, not H263+).

That's fine.  The newer RTP payload format can (and should) be used 
to stream either H263+ *or* the original H.263.  Therefore, to stream 
H.263, you do not need to implement anything new.  Just use our 
existing "H263plusVideoFileServerMediaSubsession" and 
"H263plusRTPSink" classes (for sending) and "H263plusVideoRTPSource" 
(for receiving).


>So I have been looking and comparing the H263 and H263+ RTP spec's to
>see how much work there would be to possibly implement it

The old H.263 RTP payload format specification (RFC 2190) is now 
*obsolete*, and should not be used.  As noted above, use our existing 
H.263+ RTP payload format (RFC 2429) implementation instead.
-- 

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

From finlayson at live555.com  Mon Jan 21 18:57:27 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 21 Jan 2008 18:57:27 -0800
Subject: [Live-devel] Mpeg2 Elementary Streams Muxing to Transport Stream
In-Reply-To: <059301c85c3f$593d8c40$8642a8c0@dorvalmatrox.matrox.com>
References: <059301c85c3f$593d8c40$8642a8c0@dorvalmatrox.matrox.com>
Message-ID: <f06240805c3bb0bb37c0e@[66.80.62.44]>

>I tried to find some simple testing program demoed the muxing of 
>elementary streams with the MPEG2TransportStreamFromESSource 
>implementation and couldn't yet.

There's an example of this in the code for our "wis-streamer" 
application (see <http://www.live555.com/wis-streamer/>).  Note, in 
particular, the file 
"WISMPEG2TransportStreamServerMediaSubsession.cpp".
-- 

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/20080121/90895ec6/attachment-0001.html 

From finlayson at live555.com  Mon Jan 21 19:07:05 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 21 Jan 2008 19:07:05 -0800
Subject: [Live-devel] recorded .mp4 file won't play locally in Quicktime
In-Reply-To: <479510FC.4040206@xanboo.com>
References: <479510FC.4040206@xanboo.com>
Message-ID: <f06240806c3bb0d03cac1@[66.80.62.44]>

>however, recorded clips will not play locally in Quicktime.
>they play without any problems in VLC.

I suggest that you also ask a QuickTime mailing list about this.  If 
you show them your file, they may be able to tell you what could be 
changed (in our code) to make QuickTime Player play it OK.
-- 

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

From mail at oliroll.de  Mon Jan 21 23:07:30 2008
From: mail at oliroll.de (Oliver Roll)
Date: Tue, 22 Jan 2008 08:07:30 +0100
Subject: [Live-devel] Dumping and viewing at one time
Message-ID: <47959632.8000204@oliroll.de>

Dear all,

I want to dump and view a stream at one time. I'm using MPlayer + 
liveMedia lib. What would be the best way to do this?
The receivers in testprogs all use a FileSink to save the incoming 
stream. But I don't know if I can use FileSink->startPlaying() in 
combination with MPlayer?  Do I have to use two different threads to 
this (one for MPlayer, one for FileSink)? Any hints?

Thanks & regards,
Oliver

From finlayson at live555.com  Tue Jan 22 00:13:20 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 22 Jan 2008 00:13:20 -0800
Subject: [Live-devel] Dumping and viewing at one time
In-Reply-To: <47959632.8000204@oliroll.de>
References: <47959632.8000204@oliroll.de>
Message-ID: <f06240809c3bb5536ca48@[66.80.62.44]>

>I want to dump and view a stream at one time. I'm using MPlayer +
>liveMedia lib. What would be the best way to do this?

You would need to modify MPlayer's LIVE555 interface code 
("libmpdemux/demux_rtp.c") to write each incoming data frame to a 
file, as well as processing it normally.  For more help on this, you 
should ask a MPlayer mailing list.
-- 

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

From martin at startwars.org  Tue Jan 22 00:22:37 2008
From: martin at startwars.org (Martin Lindhe)
Date: Tue, 22 Jan 2008 09:22:37 +0100
Subject: [Live-devel] H263-1996 rtp question
In-Reply-To: <f06240801c3baf80a6f45@[66.80.62.44]>
References: <4794CB3E.9060902@startwars.org>
	<f06240801c3baf80a6f45@[66.80.62.44]>
Message-ID: <4795A7CD.9000508@startwars.org>

An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080122/32fe5186/attachment.html 

From finlayson at live555.com  Tue Jan 22 00:39:15 2008
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 22 Jan 2008 00:39:15 -0800
Subject: [Live-devel] H263-1996 rtp question
In-Reply-To: <4795A7CD.9000508@startwars.org>
References: <4794CB3E.9060902@startwars.org>
	<f06240801c3baf80a6f45@[66.80.62.44]> <4795A7CD.9000508@startwars.org>
Message-ID: <f0624080ac3bb5c0b6446@[66.80.62.44]>

>Ross Finlayson wrote:
>
>>
>>The old H.263 RTP payload format specification (RFC 2190) is now
>>*obsolete*, and should not be used.  As noted above, use our existing
>>H.263+ RTP payload format (RFC 2429) implementation instead.
>>
>>
>Yes I am aware about H263-1996 is obsolete. However I need to 
>integrate stream duplication functionality with software already 
>producing H263-1996 stream, so I just need liveMedia to be able to 
>receive such stream, not to send it out.

Then you will need to write your own subclass of 
"MultiFramedRTPSource" to implement the old H.263 RTP payload format.
-- 

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/20080122/d61bd95a/attachment.html 

From ralf.buhlrich at rheinmetall.com  Tue Jan 22 01:29:36 2008
From: ralf.buhlrich at rheinmetall.com (Ralf Buhlrich)
Date: Tue, 22 Jan 2008 10:29:36 +0100
Subject: [Live-devel] howto build an mpeg-ts
Message-ID: <1200994176.4006.10.camel@ftlxwks003.defence-elec.de>

Hi List,

I am new at live555. My problem is as follows:

I have got a H.264 stream, a MPEG2 stream, and three metadata streams in
several queues. I have to put them all into one MPEG-TS and stream that
TS via RTP over the net. I did not find any example which shows the
mechanism of building an MPEG-TS.

Can anyone help me with example code or links?

Thanks in advance

Ralf Buhlrich




-- 

Geschäftsführung/Management Board Rheinmetall Defence Electronics GmbH:
Dipl.-Wirtsch.-Ing. Georg Morawitz
Dipl.-Ing. Luitjen Ennenga
Dipl.-Ing.Ulrich Sasse
Sitz der Gesellschaft/Registered Office: Bremen
Register/Commercial Register: Amtsgericht Bremen, HRB 9659 


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

The statements contained in this message are not legally binding unless confirmed in writing.
This message may contain confidential information. If you are not the intended recipient, or if this message and its annexes contains information which is apparently not meant for you, please notify us immediately and - to the extent you are not the intended recipient - please delete this message and all its attachments from your system and destroy any copy made therefrom.
Any unauthorized review, delivery, distribution, transmission, storage, printing or otherwise making use of the message and its attachments are strictly prohibited.
In case your systems have been infected by virus or otherwise negatively affected by this message, we will not be liable for any damage resulting therefrom unless in case of gross negligence or wilful misconduct.



Geschäftsführung/Management Board Rheinmetall Technical Publications GmbH:
Dipl.-Ing. Jörg Daniel
Sitz der Gesellschaft/Registered Office: Bremen
Register/Commercial Register: Amtsgericht Bremen, HRB 24359 HB


From gulshanchawla_2000 at yahoo.com  Tue Jan 22 02:12:49 2008
From: gulshanchawla_2000 at yahoo.com (gulshan chawla)
Date: Tue, 22 Jan 2008 02:12:49 -0800 (PST)
Subject: [Live-devel] How to unsubscribe from the mailing list !!
In-Reply-To: <f0624080ac3bb5c0b6446@[66.80.62.44]>
Message-ID: <580424.91629.qm@web35405.mail.mud.yahoo.com>

  HI ,
    I want to unsubscribe from this mailing list .Can some body tell me the procedure to do so ?
  Regards



       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080122/505f5fce/attachment.html 

From belloni at imavis.com  Tue Jan 22 02:17:21 2008
From: belloni at imavis.com (Cristiano Belloni)
D