From dsp at exacq.com  Tue Jun  1 10:52:49 2010
From: dsp at exacq.com (Doug Porter)
Date: Tue, 01 Jun 2010 17:52:49 +0000
Subject: [Live-devel] RTSP over HTTP patch
Message-ID: <21470.1275414769@yocto>

It seems that RTSP over HTTP support was broken in the May 29
release.  This patch fixes it:



diff -Naur live.orig/liveMedia/RTSPClient.cpp live/liveMedia/RTSPClient.cpp
--- live.orig/liveMedia/RTSPClient.cpp	2010-05-29 22:20:31.000000000 +0000
+++ live/liveMedia/RTSPClient.cpp	2010-06-01 17:47:48.000000000 +0000
@@ -664,6 +664,11 @@
       sprintf(extraHeaders, extraHeadersFmt,
 	      fSessionCookie);
     } else if (strcmp(request->commandName(), "POST") == 0) {
+      NetAddress destAddress;
+      portNumBits urlPortNum;
+      if (!parseRTSPURL(envir(), fBaseURL, destAddress, urlPortNum, (char const**)&cmdURL)) break;
+      if (cmdURL[0] == '\0') cmdURL = (char*)"/";
+
       protocolStr = "HTTP/1.0";
 
       char const* const extraHeadersFmt =



Thanks,
-- 
dsp

From dsp at exacq.com  Tue Jun  1 15:21:35 2010
From: dsp at exacq.com (Doug Porter)
Date: Tue, 01 Jun 2010 22:21:35 +0000
Subject: [Live-devel] New, improved "RTSPClient" interface now available
In-Reply-To: <f06240800c82763ae5de9@[66.80.62.44]>
References: <f06240800c82763ae5de9@[66.80.62.44]>
Message-ID: <30615.1275430895@yocto>

Ross Finlayson <finlayson at live555.com> writes:
> 
> I have installed a new version (2010.05.29) of the "LIVE555
> Streaming Media" code that adds the long-promised new
> 'asynchronous' (i.e., non-blocking) interface to the
> "RTSPClient" class.

Thank you for publishing this new interface; I've been looking
forward to it for a while.

I tried reworking some of my code today to use the new
asynchronous interface, but ran into a couple problems.  First, I
do not see a way to set the URL.  Should setBaseURL() be public?
Second, would it be possible to get a client data pointer on the
RTSPClient::responseHandler callback like there is with callbacks
for getNextFrame()?

If this makes sense to you, I'm happy to work up the patch.

Thanks,
-- 
dsp

From finlayson at live555.com  Wed Jun  2 00:10:40 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 2 Jun 2010 00:10:40 -0700
Subject: [Live-devel] New, improved "RTSPClient" interface now available
In-Reply-To: <30615.1275430895@yocto>
References: <f06240800c82763ae5de9@[66.80.62.44]> <30615.1275430895@yocto>
Message-ID: <f06240801c82bb2936af9@[66.80.62.44]>

>I tried reworking some of my code today to use the new
>asynchronous interface, but ran into a couple problems.  First, I
>do not see a way to set the URL.

The URL is now passed as a parameter to "RTSPClient::createNew()". 
This makes more sense than (the previous behavior of) passing it as a 
parameter to the 'describe' operation, because each "RTSPClient" 
object is intended to bew used for a single stream only.

>Second, would it be possible to get a client data pointer on the
>RTSPClient::responseHandler callback like there is with callbacks
>for getNextFrame()?

I'm not yet convinced that this is necessary.  However, upon 
reflection, I wonder if it might make sense to pass the "CSeq" value 
as a parameter to the handler function (along with the "RTSPClient" 
object), so that the handler function can identify which particular 
request this handler is for.  (Note that each of the command-sending 
member functions return a "CSeq" value as its result.

How were you intending to use the "client data" value?
-- 

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

From finlayson at live555.com  Wed Jun  2 00:19:03 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 2 Jun 2010 00:19:03 -0700
Subject: [Live-devel] RTSP over HTTP patch
In-Reply-To: <21470.1275414769@yocto>
References: <21470.1275414769@yocto>
Message-ID: <f06240802c82bb6203fcf@[66.80.62.44]>

>It seems that RTSP over HTTP support was broken in the May 29
>release.  This patch fixes it:

Thanks.  For some strange reason, RTSP-over-HTTP worked OK when I 
tested it; however, your patch makes the code more consistent with 
the previous code, so I'll include it in the next release of the 
software.
-- 

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

From marcos at a5security.com  Wed Jun  2 00:28:14 2010
From: marcos at a5security.com (Miguel Angel Arcos)
Date: Wed, 2 Jun 2010 09:28:14 +0200
Subject: [Live-devel] FPS limit
Message-ID: <AANLkTim61SMD26UTpultkqMDUM783ANbdlnkAxdu65Lw@mail.gmail.com>

Hi developers,

I'm working on an Application using live555 to obtain images from different
cameras using rtsp. I readed about the FPS or bandwith maximum on the FAQ
and I only readed the question about the packet loss. My problem not is the
packet loss, I'm suffering buffering. When I have a lot of cameras, for
example 12 cameras 320x240 25 FPS I can see buffering of 5-6 seconds in some
cases.

My code decompress all the images on different threads and the CPU have
their usage at 65% more or less. I can say that my decompress process don't
have the buffering, I debugged all a lot of time and I see the image queue
empty. Then my question is. Exist any limitation of FPS or Bandwidth on
live555? or bottle neck?

If I only use for example 6 cameras 320x240 25 fps the problem desn't
exists. All starts when I start to demand a lot of images.

Thanks in advance.

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

From dsp at exacq.com  Wed Jun  2 09:21:27 2010
From: dsp at exacq.com (Doug Porter)
Date: Wed, 02 Jun 2010 16:21:27 +0000
Subject: [Live-devel] New, improved "RTSPClient" interface now available
In-Reply-To: <f06240801c82bb2936af9@[66.80.62.44]>
References: <f06240800c82763ae5de9@[66.80.62.44]> <30615.1275430895@yocto>
	<f06240801c82bb2936af9@[66.80.62.44]>
Message-ID: <18593.1275495687@yocto>

Ross Finlayson <finlayson at live555.com> writes:
> 
> How were you intending to use the "client data" value?

Since my application has a number of concurrent RTSP sessions, I
need to be able to tie responses back to their context.  Without
a user data pointer, I can think of two options.  The first is to
keep a global map of RTSPClient object pointers to my data.  I'd
like to avoid using a global though, because it'll cause some
difficulty in this application.  The second option is to derive
from RTSPClient.  This seems like unnecessary complexity though,
for what I figure is fairly typical use of the new API.

An alternative to having a per-request user data pointer, is
providing the ability to keep one on the RTSPClient object.  That
at least keeps the clutter down on method signatures.

With regard to passing the CSeq back to the handler function,
that seems reasonable.  It doesn't solve the problem I'm trying
to address, but simplify work for some people.  It's worth noting
though that RTSP responses have to come in the same order as
requests, so I don't know that passing the CSeq to the response
handler will be a great boon.


> The URL is now passed as a parameter to
> "RTSPClient::createNew()".

Ah, thanks.  I had missed the new version of createNew().


I appreciate your help,
-- 
dsp

From finlayson at live555.com  Wed Jun  2 19:36:07 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 2 Jun 2010 19:36:07 -0700
Subject: [Live-devel] FPS limit
In-Reply-To: <AANLkTim61SMD26UTpultkqMDUM783ANbdlnkAxdu65Lw@mail.gmail.com>
References: <AANLkTim61SMD26UTpultkqMDUM783ANbdlnkAxdu65Lw@mail.gmail.com>
Message-ID: <f06240800c82cc4174faa@[66.80.62.44]>

>I'm working on an Application using live555 to obtain images from 
>different cameras using rtsp. I readed about the FPS or bandwith 
>maximum on the FAQ and I only readed the question about the packet 
>loss. My problem not is the packet loss, I'm suffering buffering. 
>When I have a lot of cameras, for example 12 cameras 320x240 25 FPS 
>I can see buffering of 5-6 seconds in some cases.
>
>My code decompress all the images on different threads and the CPU 
>have their usage at 65% more or less. I can say that my decompress 
>process don't have the buffering, I debugged all a lot of time and I 
>see the image queue empty. Then my question is. Exist any limitation 
>of FPS or Bandwidth on live555? or bottle neck?

Probably not.  At the server (sender) end, there is no significant 
delay in the LIVE555 code; it transmits each packet as soon as it is 
full.  At the receiver end, there should also be no significant 
delay, provided that your code returns to the event loop (i.e., calls 
"select()") regularly, without excessive delay.  Because your image 
decompression is done by separate threads - i.e., outside the LIVE555 
event loop - there should not be a problem.  If there is any 
'buffering' happening, then it will either be inside the receiver's 
OS (socket buffering), or (much more likely) somewhere else outside 
the LIVE555 code.

In any case, it should be fairly easy, I think, for you to instrument 
your application to figure out exactly where the delay is occurring 
(i.e., by generating and logging timestamps at various points in the 
code).
-- 

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

From Kenneth.X.Melms.-ND at espn.com  Thu Jun  3 09:13:56 2010
From: Kenneth.X.Melms.-ND at espn.com (Melms, Kenneth)
Date: Thu, 3 Jun 2010 12:13:56 -0400
Subject: [Live-devel] MPEG2TransportStreamIndexer still fails on some files
Message-ID: <2E0B44FFCD8DBD4FB9682175A2CD223C01282FA1@XCHGBRS4.corp.espn.pvt>

Greetings Program[s|mers]:

I'm still having some trouble using the MPEG2TransportStreamIndexer on MPEG2-TS files we bring down off of our ASI satellite feeds.

The tool doesn't emit any errors, and finishes with a "...done", but a 0 byte "tsx" file is created.

I've put together a small representative sampling (6 files, 1 MB each) of the TS files that won't index.

These videos are clipped off the heads of several multi-GB HD files, so I realize that 1MB is very short -however VLC properly opens and displays the codec information, as does ffmpeg - so I'm hoping that you may be able to figure out why this occurs with such regularity.

Here are the clips:

ftp://espnftp:guesty2k at ftpdrop.espn.com/public/live555%5Fwont%5Findex.zip

Thanks in advance,

Ken Melms

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

From finlayson at live555.com  Thu Jun  3 10:17:02 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 3 Jun 2010 10:17:02 -0700
Subject: [Live-devel] MPEG2TransportStreamIndexer still fails on some
 files
In-Reply-To: <2E0B44FFCD8DBD4FB9682175A2CD223C01282FA1@XCHGBRS4.corp.espn.pvt>
References: <2E0B44FFCD8DBD4FB9682175A2CD223C01282FA1@XCHGBRS4.corp.espn.pvt>
Message-ID: <f06240801c82d92c2b7a5@[66.80.62.44]>

>I'm still having some trouble using the 
>MPEG2TransportStreamIndexer on MPEG2-TS files we 
>bring down off of our ASI satellite feeds.
>
>The tool doesn't emit any errors, and finishes 
>with a "?done", but a 0 byte "tsx" file is 
>created.
>
>I've put together a small representative 
>sampling (6 files, 1 MB each) of the TS files 
>that won't index.
>
>These videos are clipped off the heads of 
>several multi-GB HD files, so I realize that 1MB 
>is very short -however VLC properly opens and 
>displays the codec information, as does ffmpeg - 
>so I'm hoping that you may be able to figure out 
>why this occurs with such regularity.
>
>Here are the clips:
>
><ftp://espnftp:guesty2k at ftpdrop.espn.com/public/live555%5Fwont%5Findex.zip>ftp://espnftp:guesty2k at ftpdrop.espn.com/public/live555%5Fwont%5Findex.zip

OK, thanks for letting me know.  I'll take a look 
at these (I'm traveling right now, so it might 
take a few days).

Note, though, that VLC can't play your "wont7.ts" 
file at all.  (It does play the remaining files - 
"want2.ts" through "want6.ts" - OK.)  So, I won't 
be checking that file (because if a media player 
can't play the file, then it's not reasonable to 
expect our indexing software to work on it).
-- 

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/20100603/2e3c6610/attachment.html>

From Kenneth.X.Melms.-ND at espn.com  Thu Jun  3 11:34:38 2010
From: Kenneth.X.Melms.-ND at espn.com (Melms, Kenneth)
Date: Thu, 3 Jun 2010 14:34:38 -0400
Subject: [Live-devel] MPEG2TransportStreamIndexer still fails on some
 files
In-Reply-To: <f06240801c82d92c2b7a5@[66.80.62.44]>
References: <2E0B44FFCD8DBD4FB9682175A2CD223C01282FA1@XCHGBRS4.corp.espn.pvt>
	<f06240801c82d92c2b7a5@[66.80.62.44]>
Message-ID: <2E0B44FFCD8DBD4FB9682175A2CD223C01282FD1@XCHGBRS4.corp.espn.pvt>

That's fine -

I don't know why that happened, but if we can work out what's up with the others I'll be a very happy camper!

Thanks Ross,

K


From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Thursday, June 03, 2010 1:17 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] MPEG2TransportStreamIndexer still fails on some files

I'm still having some trouble using the MPEG2TransportStreamIndexer on MPEG2-TS files we bring down off of our ASI satellite feeds.

The tool doesn't emit any errors, and finishes with a "?done", but a 0 byte "tsx" file is created.

I've put together a small representative sampling (6 files, 1 MB each) of the TS files that won't index.

These videos are clipped off the heads of several multi-GB HD files, so I realize that 1MB is very short -however VLC properly opens and displays the codec information, as does ffmpeg - so I'm hoping that you may be able to figure out why this occurs with such regularity.

Here are the clips:

ftp://espnftp:guesty2k at ftpdrop.espn.com/public/live555%5Fwont%5Findex.zip

OK, thanks for letting me know.  I'll take a look at these (I'm traveling right now, so it might take a few days).

Note, though, that VLC can't play your "wont7.ts" file at all.  (It does play the remaining files - "want2.ts" through "want6.ts" - OK.)  So, I won't be checking that file (because if a media player can't play the file, then it's not reasonable to expect our indexing software to work on it).

--

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

________________________________
Please consider the environment before printing this e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100603/dba8a960/attachment.html>

From sebastien-devel at celeos.eu  Fri Jun  4 05:03:56 2010
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Fri, 04 Jun 2010 14:03:56 +0200
Subject: [Live-devel] segmentation fault with latest version
Message-ID: <1275653036.4c08ebacca46d@imp.celeos.eu>



Hi

I tried to use vlc with the latest version.
I thought it would work as you say it is backward compatible, but I have a
segmentation fault.
I think the line 136 in RTSPClient.cpp is buggy because if parameterName is
NULL, sprintf segfaults.

Regards,

Seb.

Backtrace :

#0  0xb7499e00 in strcpy () from /lib/tls/i686/cmov/libc.so.6
#1  0xb62c74b3 in RTSPClient::sendGetParameterCommand (this=0x8e692f0,
session=@0x8e69a50,
    responseHandler=0xb62c05ca
<RTSPClient::responseHandlerForSyncInterface(RTSPClient*, int, char*)>,
parameterName=0x0, authenticator=0x0)
    at RTSPClient.cpp:136
#2  0xb62c75e0 in RTSPClient::getMediaSessionParameter (this=0x8e692f0,
session=@0x8e69a50, parameterName=0x0, parameterValue=@0xb60551e4)
    at RTSPClient.cpp:1832


From finlayson at live555.com  Fri Jun  4 05:15:46 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 4 Jun 2010 05:15:46 -0700
Subject: [Live-devel] segmentation fault with latest version
In-Reply-To: <1275653036.4c08ebacca46d@imp.celeos.eu>
References: <1275653036.4c08ebacca46d@imp.celeos.eu>
Message-ID: <f06240802c82e9ed3fc0e@[66.80.62.44]>

>I tried to use vlc with the latest version.
>I thought it would work as you say it is backward compatible, but I have a
>segmentation fault.
>I think the line 136 in RTSPClient.cpp is buggy because if parameterName is
>NULL, sprintf segfaults.

Oops, yes - my mistake.   This will be fixed in the next release.
-- 

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

From jnoring at logitech.com  Fri Jun  4 10:28:26 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Fri, 4 Jun 2010 10:28:26 -0700
Subject: [Live-devel] RTSP server hang
Message-ID: <AANLkTinun_cqnSY0D8FZ9Up0JWJNFcwIEf5s0qKTxvr_@mail.gmail.com>

Under load, I'm noticing our RTSP server occasionally hangs in this
location:

static int blockUntilReadable(UsageEnvironment& env,
                  int socket, struct timeval* timeout) {
  int result = -1;
  do {
    fd_set rd_set;
    FD_ZERO(&rd_set);
    if (socket < 0) break;
    FD_SET((unsigned) socket, &rd_set);
    const unsigned numFds = socket+1;

    result = select(numFds, &rd_set, NULL, NULL, timeout);  <--HANG

I added some logging and found that the select() timeout is NULL, which is
infinite.  I would expect this to unblock when data arrived on the socket,
but no amount of connection attempts seems to wake it up--it stays there,
blocking the Live555 thread from servicing any new clients.  Also, what code
would be calling this with a NULL timeout?

The other thing I notice is our netstat output:

# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:5222            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:5800            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:5000            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:5802            0.0.0.0:*               LISTEN
tcp       21      0 0.0.0.0:554             0.0.0.0:*               LISTEN

When it's in a failed state, I always see 21 on the Recv-Q, which is "The
count of bytes not copied by the user program connected to this socket."
We're using Linux (2.6.18, so a bit old).

Does anyone know why this may be, or have any suggestions for fixing it?
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100604/46c50c5a/attachment.html>

From ottavio at videotec.com  Wed Jun  9 08:38:42 2010
From: ottavio at videotec.com (Ottavio Campana)
Date: Wed, 09 Jun 2010 17:38:42 +0200
Subject: [Live-devel] doubt trying to implement a rtsp client
Message-ID: <4C0FB582.2030104@videotec.com>

Hi,

I'm trying to implement a small receiver with live555. What I basically
do is contacting a RTSP server, browse the subsessions, receive the
packets of the desired subsession and pass them to a routine that
process them. I tried following playCommon.cpp , but I'm stuck at a
point and I don't understand how to finish the program.

What I do is:

* call RTSPClient::createNew to create a client
* call RTSPClient::describeURL url get a description
* create a MediaSsesion with MediaSession::createNew and iterate through
its subsessions looking for the one that I want
* if I want to setup a session I call RTSPClient::setupMediaSubsession

but at this point I'm stuck. I think that before calling
RTSPClient::playMediaSession I need to do something so that each time
data is received my processing function is executed.

Do I need to set up a sink by subclassing MediaSink? Or do I have to do
something different?

Thank you for your help,

Ottavio

From finlayson at live555.com  Wed Jun  9 14:26:41 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 9 Jun 2010 14:26:41 -0700
Subject: [Live-devel] doubt trying to implement a rtsp client
In-Reply-To: <4C0FB582.2030104@videotec.com>
References: <4C0FB582.2030104@videotec.com>
Message-ID: <f06240802c835b2693bbe@[66.80.62.44]>

>I'm trying to implement a small receiver with live555. What I basically
>do is contacting a RTSP server, browse the subsessions, receive the
>packets of the desired subsession and pass them to a routine that
>process them. I tried following playCommon.cpp , but I'm stuck at a
>point and I don't understand how to finish the program.
>
>What I do is:
>
>* call RTSPClient::createNew to create a client
>* call RTSPClient::describeURL url get a description
>* create a MediaSsesion with MediaSession::createNew and iterate through
>its subsessions looking for the one that I want

At this point, you should call "initiate()" on the subsession object. 
This will create "RTPSource" and "RTCPInstance" objects for the 
stream.  (The "RTPSource" object is the one that actually receives 
data from the network.)

>* if I want to setup a session I call RTSPClient::setupMediaSubsession

Yes.

>but at this point I'm stuck. I think that before calling
>RTSPClient::playMediaSession I need to do something so that each time
>data is received my processing function is executed.

Yes, after calling "setupMediaSubsession()", and before calling 
"playMediaSubsession()" (note that those two functions only send RTSP 
commands; they don't actually do anything with the incoming data), 
you should do the following:

1/ Create a 'sink' object which will actually receive the incoming 
network data (from the "RTPSource" object).  This must be a subclass 
of "MediaSink", and could - for example - be a "FileSink", if you 
want to write the incoming data into a file.
2/ Call "startPlaying()" on your 'sink' object, asking it to receive 
data from the "subsession->readSource()".  See line 712 of 
"playCommon.cpp".  (Note that you should call 
"subsession->readSource()" rather than "subsession->rtpSource()", 
because for some types of stream, they are different.)

Then, after doing 1/ and 2/, you will call "playMediaSubsession()", 
to tell the server to start streaming data.

I'm sorry that the "openRTSP" code is so complicated (because the 
"openRTSP" application has so many 'bells and whistles').  At some 
point, I plan to also release a much simpler "testRTSPClient" 
application that will make it easier for developers to figure out how 
to write their own RTSP client application.  (This will also use the 
new asynchronous "RTSPClient" interface, which is what all developers 
should eventually be using.)
-- 

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

From a.ricciardi at fastwebnet.it  Thu Jun  3 04:03:08 2010
From: a.ricciardi at fastwebnet.it (Andrea Ricciardi)
Date: Thu, 3 Jun 2010 13:03:08 +0200
Subject: [Live-devel]  testOnDemandRTSPServer RTP/TCP problem
In-Reply-To: <f06240800c82cc4174faa@[66.80.62.44]>
References: <AANLkTim61SMD26UTpultkqMDUM783ANbdlnkAxdu65Lw@mail.gmail.com>
	<f06240800c82cc4174faa@[66.80.62.44]>
Message-ID: <77D131C921ED432D8F831364FC978B55@pcandrea>

Hi,
I'm developing a custom subclass of OnDemandServerMediaSubsession for a 
video encoder, and I have integrated it into the testOnDemandRTSPServer 
application. I noticed that when I try to open multiple VLC windows for 
viewing the stream (I have reuseFirstSource set to True), I can open up to 8 
windows using UDP (after that the PC starts loosing frames), while if I use 
TCP as soon as I open the second window, both videos start to behave badly 
and often stop for many seconds.
I thought the problem was in my class but then I tried streaming a small 
mpeg4 video instead of the video encoder, and opening 10 windows was ok with 
UDP but showed the same problem with TCP (it took more windows, probably 
because the bitrate is much lower than the video encoder one).
Is it a know problem of Livemedia, can you replicate it? Or maybe the 
problem is in VLC? (I cross compile Livemedia for ARM and run VLC 1.0.5 
under windows 7)
Thanks a lot,

Andrea

 


From finlayson at live555.com  Thu Jun 10 15:28:01 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 10 Jun 2010 15:28:01 -0700
Subject: [Live-devel] AMRInterleaver has MIMEType()
 "binary/octed-stream" and InitiateByMediaType() fails ?
In-Reply-To: <AANLkTinwyCM5scDQ-5ddcg92C0gktAusi4EN-VNirJGe@mail.gmail.com>
References: <AANLkTinwyCM5scDQ-5ddcg92C0gktAusi4EN-VNirJGe@mail.gmail.com>
Message-ID: <f06240800c83716872790@[66.80.62.44]>

>  I'm unable to receive AMR audio using InitiateByMediaType( 
>"audio/AMR"). The reason is readSource(), which is AMRInterleaver in 
>this case, has no MIMEType() redefined. It returns a generic 
>type, something like "binary/octed-stream" instead "audio/AMR", and 
>function fails at this line :
>
>
>// Make sure the source's MIME type is one that we handle:
>00482     if 
>(strcmp(<http://www.live555.com/liveMedia/doxygen/html/AVIFileSink_8cpp.html#25e0e015bb23ec5ef03f7e9b9be9b7f4>subsession-><http://www.live555.com/liveMedia/doxygen/html/classMediaSubsession.html#98fd05e720ca289f4f6f68ad86ec3d37>readSource()-><http://www.live555.com/liveMedia/doxygen/html/classMediaSource.html#3e7802f6dbeb9da5adde539b6c1410e5>MIMEtype(), 
>mimeType) != 0) {
>00483       if (!wasAlreadyInitiated) 
><http://www.live555.com/liveMedia/doxygen/html/AVIFileSink_8cpp.html#25e0e015bb23ec5ef03f7e9b9be9b7f4>subsession-><http://www.live555.com/liveMedia/doxygen/html/classMediaSubsession.html#d39152d0b5807cd59fb345b4308c6be5>deInitiate();
>00484       continue;
>
>Of course, I'm not sure that I'm doing everything ok, but it looks 
>like a bug to me.

Yes, you're right - we were failing to redefine the "MIMEtype()" 
virtual function for "AMRAudioSource" (of which "AMRDeinterleaver" is 
a subclass).

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

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

From christopher.schatton at gmail.com  Mon Jun  7 23:48:20 2010
From: christopher.schatton at gmail.com (Christopher Schatton)
Date: Tue, 8 Jun 2010 08:48:20 +0200
Subject: [Live-devel] MPEG2TransportStreamIndexer with H264
Message-ID: <AANLkTikmRJontiIWuTZ72N0j7qpQgpJCS6_CsRRzKuIJ@mail.gmail.com>

Hi,

I'm new in this group so: hi everyone.

I'm working on a indexer that will support H.264-in-MPEG-Transport-Stream
files. MPEG2IndexFromTransportStream code is clear but i have question:

MPEG2IndexFromTransportStream.cpp, line 220

  if (payload_unit_start_indicator) {
    // Note: The following works only for MPEG-2 data #####
    u_int8_t PES_header_data_length = fInputBuffer[totalHeaderSize+8];
    //fprintf(stderr, "PES_header_data_length: %d\n",
PES_header_data_length);//#####
    totalHeaderSize += 9 + PES_header_data_length;

Question about this '9': Why this is working only with MPEG2 data? This '9'
is specific for video coded with mpeg2? This '9' is a header length?

Thanks for help.

Best regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100608/ed100cf8/attachment.html>

From doancea at gmail.com  Sat Jun  5 05:20:45 2010
From: doancea at gmail.com (Oancea Daniel)
Date: Sat, 5 Jun 2010 13:20:45 +0100
Subject: [Live-devel] RTSP client (VLC 1.0.6 Goldeneye branch)
Message-ID: <AANLkTimNNq6axGKFzU_qo5whcLiAuG3IuWPE4pX252Tk@mail.gmail.com>

Hello everybody,

I have a problem playing MPEG-4 and X.264 file via RTSP.

For playing this files, I'm using a VLC linux client application (1.0.6
version).
The error that I got is:

[0x8131058] live555 demux error: SETUP of'video/MP4V-ES' failed Missing or
bad "Transport:" header
[0x8131058] live555 demux error: SETUP of'audio/MPEG4-GENERIC' failed
Missing or bad "Transport:" header
[0x8131058] live555 demux error: Nothing to play for rtsp://@
127.0.0.1:8554/reklam_2
[0x81319f0] main access error: no access module matched "rtsp"
[0xa0757fc0] main input error: open of `rtsp://@127.0.0.1:8554/reklam_2'
failed: no access module matched "rtsp"
[0xa0757fc0] main input error: Your input can't be opened
[0xa0757fc0] main input error: VLC is unable to open the MRL 'rtsp://@
127.0.0.1:8554/reklam_2'. Check the log for details.
[0x8290168] main playlist: stopping playback

If I'm using a VLC windows client, everything work well.

The VLC VoD server is installed on a openSuse11.2 machine.
The VLC was compiled successfully with live555 support:
vlc -l | grep live
VLC media player 1.0.6 Goldeneye
  live555               RTP/RTSP/SDP demuxer (using Live555)
  live555               RTSP/RTP access and demux

I'v been using openRTSP client application that comes with live555 package
and I got:

./openRTSP rtsp://127.0.0.1:8554/reklam_2
Opening connection to 127.0.0.1, port 8554...
...remote connection opened
Sending request: OPTIONS rtsp://127.0.0.1:8554/reklam_2 RTSP/1.0
CSeq: 2
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.05.29)


Received 124 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
Server: vlc 1.0.6
Content-Length: 0
Cseq: 2
Public: DESCRIBE,SETUP,TEARDOWN,PLAY,PAUSE,GET_PARAMETER


Sending request: DESCRIBE rtsp://127.0.0.1:8554/reklam_2 RTSP/1.0
CSeq: 3
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.05.29)
Accept: application/sdp


Received 125 new bytes of response data.
Have received 125 total bytes of a DESCRIBE RTSP response; awaiting 584
bytes more.
Received 584 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK
Content-type: application/sdp
Server: VLC Server
Content-Length: 584
CSeq: 3
Cache-Control: no-cache

v=0
o=- 61015973652 3 IN IP4 127.0.0.1
c=IN IP4 0.0.0.0
t=0 0
a=tool:vlc 1.0.6
a=range:npt=0-323.000
m=video 0 RTP/AVP 96
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=3;
config=000001b001000001b58913000001000000012000c48d8800cd0b041e1463000001b2617663322e302e31312e31313130;
a=control:rtsp://127.0.0.1:8554/reklam_2/trackID=0
m=audio 0 RTP/AVP 97
a=rtpmap:97 mpeg4-generic/48000
a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1190;
SizeLength=13;IndexLength=3; IndexDeltaLength=3; Profile=1;
a=control:rtsp://127.0.0.1:8554/reklam_2/trackID=1

Opened URL "rtsp://127.0.0.1:8554/reklam_2", returning a SDP description:
v=0
o=- 61015973652 3 IN IP4 127.0.0.1
c=IN IP4 0.0.0.0
t=0 0
a=tool:vlc 1.0.6
a=range:npt=0-323.000
m=video 0 RTP/AVP 96
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=3;
config=000001b001000001b58913000001000000012000c48d8800cd0b041e1463000001b2617663322e302e31312e31313130;
a=control:rtsp://127.0.0.1:8554/reklam_2/trackID=0
m=audio 0 RTP/AVP 97
a=rtpmap:97 mpeg4-generic/48000
a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1190;
SizeLength=13;IndexLength=3; IndexDeltaLength=3; Profile=1;
a=control:rtsp://127.0.0.1:8554/reklam_2/trackID=1

Created receiver for "video/MP4V-ES" subsession (client ports 48122-48123)
Created receiver for "audio/MPEG4-GENERIC" subsession (client ports
57872-57873)
Sending request: SETUP rtsp://127.0.0.1:8554/reklam_2/trackID=0 RTSP/1.0
CSeq: 4
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.05.29)
Transport: RTP/AVP;unicast;client_port=48122-48123


Received 160 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK
Transport: RTP/AVP/UDP;client_port=48122-48123
Server: VLC Server
Content-Length: 0
Cseq: 4
Cache-Control: no-cache
Session: 846930886


Failed to setup "video/MP4V-ES" subsession: Missing or bad "Transport:"
header
Sending request: SETUP rtsp://127.0.0.1:8554/reklam_2/trackID=1 RTSP/1.0
CSeq: 5
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.05.29)
Transport: RTP/AVP;unicast;client_port=57872-57873
Session: 846930886


Received 160 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK
Transport: RTP/AVP/UDP;client_port=57872-57873
Server: VLC Server
Content-Length: 0
Cseq: 5
Cache-Control: no-cache
Session: 846930886


Failed to setup "audio/MPEG4-GENERIC" subsession: Missing or bad
"Transport:" header
Sending request: TEARDOWN rtsp://127.0.0.1:8554/reklam_2 RTSP/1.0
CSeq: 6
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.05.29)
Session: 846930886


Received 122 new bytes of response data.
Received a complete TEARDOWN response:
RTSP/1.0 200 OK
Server: VLC Server
Content-Length: 0
CSeq: 6
Cache-Control: no-cache
Session: 846930886;timeout=5

It seams that the problem is on the client side.

Could someone give some support on this matter?

Thank you very much!

-Daniel

-- 
________
Note:  If the reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by replying to the
message and deleting it from your computer. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100605/1d480e92/attachment-0001.html>

From parveenjain at live.com  Tue Jun  8 06:57:01 2010
From: parveenjain at live.com (Parveen Jain)
Date: Tue, 8 Jun 2010 19:27:01 +0530
Subject: [Live-devel] problem while playing H263 rtp file
Message-ID: <SNT136-w5856C3D4FEB68CE830445ED4D60@phx.gbl>








   Hi All,  I am trying to write a sip application for audio/video  call using codec PCMU and H.263.I negotiate the SDP parameter with kapanga(sip softphone) and then call the Live555 API for sending the H.263 video.But somehow on receiving the H.263 video stream, Kapnga shows "Bad marker" and "header damaged" on reception of H263 packet.  I negotiate with kapanga using "h263-1998" and payload type 105 .Following is my code snippet for starting the video call:(this is almost same what has been given in live555's test program)
int PlayVideo(char *ipAddr,int videoRtpPort,int videoRtcpPort) {  // Begin by setting up our usage environment:  TaskScheduler* scheduler = BasicTaskScheduler::createNew();  env = BasicUsageEnvironment::createNew(*scheduler);
  // Create 'groupsocks' for RTP and RTCP:  char const* destinationAddressStr#ifdef USE_SSM    //= "10.0.8.32";  =ipAddr;#else    = "239.255.42.42";  // Note: This is a multicast address.  If you wish to stream using  // unicast instead, then replace this string with the unicast address  // of the (single) destination.  (You may also need to make a similar  // change to the receiver program.)#endif  const unsigned short rtpPortNum =videoRtpPort;                        // 8888;  const unsigned short rtcpPortNum = videoRtcpPort;  const unsigned char ttl = 255; // low, in case routers don't admin scope
  struct in_addr destinationAddress;  destinationAddress.s_addr = our_inet_addr(destinationAddressStr);  const Port rtpPort(rtpPortNum);  const Port rtcpPort(rtcpPortNum);
  Groupsock rtpGroupsock(*env, destinationAddress, rtpPort, ttl);  Groupsock rtcpGroupsock(*env, destinationAddress, rtcpPort, ttl);#ifdef USE_SSM  rtpGroupsock.multicastSendOnly();  rtcpGroupsock.multicastSendOnly();#endif
  // Create a 'MPEG Video RTP' sink from the RTP 'groupsock':  //videoSink = MPEG1or2VideoRTPSink::createNew(*env, &rtpGroupsock);        videoSink =H263plusVideoRTPSink::createNew(*env, &rtpGroupsock,105);
  // Create (and start) a 'RTCP instance' for this RTP sink:  const unsigned estimatedSessionBandwidth = 500; // in kbps; for RTCP b/w share  const unsigned maxCNAMElen = 100;  unsigned char CNAME[maxCNAMElen+1];  gethostname((char*)CNAME, maxCNAMElen);  CNAME[maxCNAMElen] = '\0'; // just in case#ifdef IMPLEMENT_RTSP_SERVER  RTCPInstance* rtcp =#endif
RTCPInstance::createNew(*env, &rtcpGroupsock,                              estimatedSessionBandwidth, CNAME,                              videoSink, NULL /* we're a server */, isSSM);  // Note: This starts RTCP running automatically
#ifdef IMPLEMENT_RTSP_SERVER  RTSPServer* rtspServer = RTSPServer::createNew(*env);  // Note that this (attempts to) start a server on the default RTSP server  // port: 554.  To use a different port number, add it as an extra  // (optional) parameter to the "RTSPServer::createNew()" call above.  if (rtspServer == NULL) {    *env << "Failed to create RTSP server: " << env->getResultMsg() << "\n";    exit(1);  }  ServerMediaSession* sms    = ServerMediaSession::createNew(*env, "testStream", inputFileName,                   "Session streamed by \"testMPEG1or2VideoStreamer\"",                                           isSSM);  sms->addSubsession(PassiveServerMediaSubsession::createNew(*videoSink, rtcp));  rtspServer->addServerMediaSession(sms);
  char* url = rtspServer->rtspURL(sms);  *env << "Play this stream using the URL \"" << url << "\"\n";  delete[] url;#endif
  // Finally, start the streaming:  *env << "Beginning streaming...\n";  play();
  env->taskScheduler().doEventLoop(); // does not return
  return 0; // only to prevent compiler warning}
I am also attaching the media file which I am using for streaming.Can anyone please help me for pointing out the issue ?
Best Regards,Parveen Jain
 		 	   		  
Build a bright career through MSN Education Sign up now. 		 	   		  
_________________________________________________________________
Bollywood, beauties and the latest flicks on MSN entertainment
http://entertainment.in.msn.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100608/bbd58ddd/attachment-0001.html>

From samparknisha at rediffmail.com  Mon Jun  7 22:26:58 2010
From: samparknisha at rediffmail.com (Nisha Singh)
Date: 8 Jun 2010 05:26:58 -0000
Subject: [Live-devel] =?utf-8?q?RTSP_server_hang?=
In-Reply-To: <AANLkTinun_cqnSY0D8FZ9Up0JWJNFcwIEf5s0qKTxvr_@mail.gmail.com>
Message-ID: <1275673016.S.7353.21370.H.WUplcmVteSBOb3JpbmcAW0xpdmUtZGV2ZWxdIFJUU1Agc2VydmVyIGhhbmc_.f6-144-198.old.1275974818.23662@webmail.rediffmail.com>

Hi,

I am a just a beginner in video. I want to play the video data received over IP (rtp packets) encoded by h264. I have a file in which the rtp packets have been dumped and I want to play it by vlc player, using live555 server. 

I have searched the mailing list and people have worked upon streaming the h264 data over the network. But i have not found about playing the h264 rtp packets using live555.

Can someone guide me with the steps required to perform this task?

live555 library contains some files related to h264. What I have understood till now is that I need to create H264VideoFileServerMediaSubsession and h264VideoRTPSource will be used. But I am not clear with the flow and what is supposed to be done with these classes.
Also I am in a doubt that whether the rtp packets can be used directly and can be played by vlc using live555 server?

I have tried sending mails several times but each time I am receiving a reply mail that my message is requires approval from the moderator.

Please guide me.
Looking forward to the response.

Thanks and Regards,
Nisha


On Fri, 04 Jun 2010 23:06:56 +0530  wrote
>Under load, I'm noticing our RTSP server occasionally hangs in this location:

static int blockUntilReadable(UsageEnvironment& env,
??? ??? ??? ????? int socket, struct timeval* timeout) {
? int result = -1;

? do {
??? fd_set rd_set;
??? FD_ZERO(&rd_set);
??? if (socket < 0) break;
??? FD_SET((unsigned) socket, &rd_set);
??? const unsigned numFds = socket+1;

??? result = select(numFds, &rd_set, NULL, NULL, timeout);? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100608/a106d10f/attachment.html>

From finlayson at live555.com  Thu Jun 10 17:47:44 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 10 Jun 2010 17:47:44 -0700
Subject: [Live-devel] memory leak using tcp
In-Reply-To: <20100527153405.123310@gmx.net>
References: <20100527153405.123310@gmx.net>
Message-ID: <f06240800c837378966c6@[66.80.62.44]>

>i built a RTSP-client with the latest source codes based on the 
>openRTSP-example to receive H.264, MPEG4 and MJPEG-Streams. Using 
>UDP, everything works fine and without memory leaks, but using TCP, 
>there are four small memory leaks as reported earlier by Kamil in 
>the following thread: 
>http://lists.live555.com/pipermail/live-devel/2005-September/003150.html
>
>I was wondering, if these described issues have been solved in the 
>course of time?

The thread that you're referring to is almost 5 years old - and I 
think that the questions raised there were adequately addressed at 
that time.

However, if - after rebuilding your application with the latest 
version of the "LIVE555 Streaming Media" code - you find a memory 
leak, then please let us know be telling us specifically where it is; 
not just by linking to an ancient email message.
-- 

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

From finlayson at live555.com  Thu Jun 10 18:27:57 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 10 Jun 2010 18:27:57 -0700
Subject: [Live-devel] MP4V-ES payload
In-Reply-To: <1275325531.714837.8328.nullmailer@mail1003.cent>
References: <1275325531.714837.8328.nullmailer@mail1003.cent>
Message-ID: <f06240801c837410a7b83@[66.80.62.44]>

>just one question regading the MP4V-ES payload (implemented in 
>MPEG4ESVideoRTPSource.cpp), it works very nice for every RFC 3016 
>compatible MPEG4 video source we have tried. This is a quite simple 
>payload because of the visual stream being mapped directly onto RTP 
>packets with no special header. But the cpp file says on line 25 
>//##### NOTE: INCOMPLETE!!! #####.
>
>In what way is this payload implementation incomplete? Do you only 
>mean some marginal sanity checks or similar or is anything essential 
>missing from the implementation?

It's been a while since I wrote this code, so I can't remember why I 
added the "INCOMPLETE" comment.  But I suspect that one reason is 
that we don't recognize all of the optional SDP parameters that are 
possible for such streams.
-- 

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

From finlayson at live555.com  Thu Jun 10 23:32:09 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 10 Jun 2010 23:32:09 -0700
Subject: [Live-devel] MPEG2TransportStreamIndexer still fails on some
 files
Message-ID: <f06240803c837883b908c@[66.80.62.44]>

>I'm still having some trouble using the 
>MPEG2TransportStreamIndexer on MPEG2-TS files we 
>bring down off of our ASI satellite feeds.
>
>The tool doesn't emit any errors, and finishes 
>with a "?done", but a 0 byte "tsx" file is 
>created.
>
>I've put together a small representative 
>sampling (6 files, 1 MB each) of the TS files 
>that won't index.
>
>These videos are clipped off the heads of 
>several multi-GB HD files, so I realize that 1MB 
>is very short -however VLC properly opens and 
>displays the codec information, as does ffmpeg - 
>so I'm hoping that you may be able to figure out 
>why this occurs with such regularity.
>
>Here are the clips:
>
><ftp://espnftp:guesty2k at ftpdrop.espn.com/public/live555%5Fwont%5Findex.zip>ftp://espnftp:guesty2k at ftpdrop.espn.com/public/live555%5Fwont%5Findex.zip

OK, I've just tested these, and it turns out that 
- apart from "wont7.ts" - 
"MPEG2TransportStreamIndexer" works (creating 
index files) on all of these files.  ("wont7.ts" 
doesn't even play in VLC, so it's apparently not 
even valid.)

Why did you think that 
"MPEG2TransportStreamIndexer" didn't work on the 
other files ("wont2.ts" through "wont6.ts")??  It 
works just fine for me.
-- 

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/20100610/7bb6ded7/attachment.html>

From a.nemec at atlas.cz  Thu Jun 10 23:42:20 2010
From: a.nemec at atlas.cz (=?UTF-8?B?QWxleGFuZHIgTsSbbWVj?=)
Date: Fri, 11 Jun 2010 08:42:20 +0200
Subject: [Live-devel] memory leak using tcp
In-Reply-To: <f06240800c837378966c6@[66.80.62.44]>
References: <20100527153405.123310@gmx.net>
	<f06240800c837378966c6@[66.80.62.44]>
Message-ID: <1276238540.835855.20924.nullmailer@mail1003.cent>

Dear Ross & all,

I do not believe that these memory leaks still exist in the current release, some of them are apperently solved in the code.

As it seems to me, only one of the memory leaks was not "adequately addressed" at that time. For this http://lists.live555.com/pipermail/live-devel/2005-September/003174.html?issue I could not find any answer or solution neither.

Best regards
Alex

______________________________________________________________
> Od: "Ross Finlayson" 
> Komu: LIVE555 Streaming Media - development & use 
> Datum: 11.06.2010 04:31
> P?edm?t: Re: [Live-devel] memory leak using tcp
>
>i built a RTSP-client with the latest source codes based on the 
>openRTSP-example to receive H.264, MPEG4 and MJPEG-Streams. Using 
>UDP, everything works fine and without memory leaks, but using TCP, 
>there are four small memory leaks as reported earlier by Kamil in 
>the following thread: 
>http://lists.live555.com/pipermail/live-devel/2005-September/003150.html 
> 
>I was wondering, if these described issues have been solved in the 
>course of time? 

The thread that you're referring to is almost 5 years old - and I 
think that the questions raised there were adequately addressed at 
that time. 

However, if - after rebuilding your application with the latest 
version of the "LIVE555 Streaming Media" code - you find a memory 
leak, then please let us know be telling us specifically where it is; 
not just by linking to an ancient email message. 
-- 

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/20100611/61ef3e50/attachment.html>

From finlayson at live555.com  Fri Jun 11 01:27:35 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 11 Jun 2010 01:27:35 -0700
Subject: [Live-devel] MPEG2TransportStreamIndexer with H264
In-Reply-To: <AANLkTikmRJontiIWuTZ72N0j7qpQgpJCS6_CsRRzKuIJ@mail.gmail.com>
References: <AANLkTikmRJontiIWuTZ72N0j7qpQgpJCS6_CsRRzKuIJ@mail.gmail.com>
Message-ID: <f06240805c837a2d7cd49@[66.80.62.44]>

>MPEG2IndexFromTransportStream.cpp, line 220
>
>   if (payload_unit_start_indicator) {
>     // Note: The following works only for MPEG-2 data #####
>     u_int8_t PES_header_data_length = fInputBuffer[totalHeaderSize+8];
>     //fprintf(stderr, "PES_header_data_length: %d\n", 
>PES_header_data_length);//#####
>     totalHeaderSize += 9 + PES_header_data_length;
>
>Question about this '9': Why this is working only with MPEG2 data?

I think I meant "MPEG-2" as opposed to "MPEG-1".  For MPEG-1 video, 
the PES headers are somewhat different, I believe.

Unfortunately I don't know how H.264 video is supposed to be carried 
within MPEG Transport Streams.  (Could someone please point me at the 
official document that is supposed to define this?)
-- 

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

From amadorim at vdavda.com  Fri Jun 11 02:07:27 2010
From: amadorim at vdavda.com (Marco Amadori)
Date: Fri, 11 Jun 2010 11:07:27 +0200
Subject: [Live-devel] MPEG2TransportStreamIndexer with H264
In-Reply-To: <f06240805c837a2d7cd49@[66.80.62.44]>
References: <AANLkTikmRJontiIWuTZ72N0j7qpQgpJCS6_CsRRzKuIJ@mail.gmail.com>
	<f06240805c837a2d7cd49@[66.80.62.44]>
Message-ID: <201006111107.27983.amadorim@vdavda.com>

In data venerd? 11 giugno 2010 10:27:35, Ross Finlayson ha scritto:

> Unfortunately I don't know how H.264 video is supposed to be carried
> within MPEG Transport Streams.  (Could someone please point me at the
> official document that is supposed to define this?)

http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC seems to suggest this:

http://www.atsc.org/cms/standards/a_72_part_2.pdf

At point 6.2 and following (below an extract):

6.2 Constraints on PSI

All program elements in the Transport Stream are described in the PSI and 
shall conform to the requirements of ATSC A/53 Part 3 [1] and the following:
? When the video elementary stream_type is equal to 0x1B the descriptor loop 
immediately following ES_info_length in the TS_program_map_section() shall 
contain the AVC video_descriptor() described in Section 2.6.54 of ISO/IEC 
13818-1 [4] with the AVC_24_hour_picture_flag set to ?0?. For video sequences 
that contain AVC still pictures, the AVC_still_present field shall be set to 
?1? in this descriptor; otherwise this flag shall be set to ?0?.
? When the video elementary stream_type is equal to 0x1B, the 
data_stream_alignment_descriptor is not required, except as specified in 
Section 6.4.
? When private data bytes of the adaptation field of the TS packets are in 
use, with tag, length, and data structures as defined in Section 6.4.2 of SCTE 
128 [6], the descriptor loop immediately following ES_info_length in the 
TS_program_map_section() shall contain the 
SCTE_adaptation_field_data_descriptor as described in Section 6.3.2.3 of SCTE 
128 [6]. In the absence of such adaptation field private data, the descriptor 
shall not be included in the corresponding ES_info_loop of the PMT.

I hope it could help.

-- 
ESC:wq

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



From a.nemec at atlas.cz  Fri Jun 11 02:55:36 2010
From: a.nemec at atlas.cz (=?UTF-8?B?QWxleGFuZHIgTsSbbWVj?=)
Date: Fri, 11 Jun 2010 11:55:36 +0200
Subject: [Live-devel] memory leak using tcp
In-Reply-To: <20100527153405.123310@gmx.net>
References: <20100527153405.123310@gmx.net>
Message-ID: <1276250136.157490.4290.nullmailer@mail1003.cent>

Dear Ross & all,

first of all, sorry for the broken link in my last response to this topic, the correct link follows below. My e-mail client has been playing around with the links.

http://lists.live555.com/pipermail/live-devel/2005-September/003174.html


Now. I can confirm, that this old?problem still exists in the current release of the code and thanks to Daniel that he pointed this out. The RTSP client is leaking memory when using the RTP over RTSP tunnel as described in the scenario above (see the link).?The description in that post is still valid for the current release of the code and contains all details so that it is not necessary to repeat it here.

Our simple solution for this is to prevent recreating the socket hash table in lookupSocketDescriptor when createIfNotFound is set to false and exiting with NULL before socketHashTable is called.

Also note that this bug prevents the reclaim method of the UsageEnvironment class to delete itself, so the memory leak is even stronger.

Best regards
Alex

______________________________________________________________
> Od: danielda at gmx-topmail.de
> Komu: live-devel at ns.live555.com
> Datum: 11.06.2010 02:33
> P?edm?t: [Live-devel] memory leak using tcp
>
Hi, 

i built a RTSP-client with the latest source codes based on the openRTSP-example to receive H.264, MPEG4 and MJPEG-Streams. Using UDP, everything works fine and without memory leaks, but using TCP, there are four small memory leaks as reported earlier by Kamil in the following thread: http://lists.live555.com/pipermail/live-devel/2005-September/003150.html 

I was wondering, if these described issues have been solved in the course of time? 

Best regards, 
Daniel 
-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... 
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail 
_______________________________________________ 
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/20100611/79f3e9d3/attachment.html>

From Kenneth.X.Melms.-ND at espn.com  Fri Jun 11 07:09:11 2010
From: Kenneth.X.Melms.-ND at espn.com (Melms, Kenneth)
Date: Fri, 11 Jun 2010 10:09:11 -0400
Subject: [Live-devel] MPEG2TransportStreamIndexer still fails on some
 files
In-Reply-To: <f06240803c837883b908c@[66.80.62.44]>
References: <f06240803c837883b908c@[66.80.62.44]>
Message-ID: <2E0B44FFCD8DBD4FB9682175A2CD223C012833A2@XCHGBRS4.corp.espn.pvt>

Imagine my chagrin...

I had downloaded, built and tested the updated MPEG2TransportStreamIndexer you made on 4/10 - but the one that was residing in my system path was an older version.

Please accept my most humble apologies for wasting your time on this one Ross - and thanks!

K

From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Friday, June 11, 2010 2:32 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] MPEG2TransportStreamIndexer still fails on some files

I'm still having some trouble using the MPEG2TransportStreamIndexer on MPEG2-TS files we bring down off of our ASI satellite feeds.

The tool doesn't emit any errors, and finishes with a "?done", but a 0 byte "tsx" file is created.

I've put together a small representative sampling (6 files, 1 MB each) of the TS files that won't index.

These videos are clipped off the heads of several multi-GB HD files, so I realize that 1MB is very short -however VLC properly opens and displays the codec information, as does ffmpeg - so I'm hoping that you may be able to figure out why this occurs with such regularity.

Here are the clips:

ftp://espnftp:guesty2k at ftpdrop.espn.com/public/live555%5Fwont%5Findex.zip

OK, I've just tested these, and it turns out that - apart from "wont7.ts" - "MPEG2TransportStreamIndexer" works (creating index files) on all of these files.  ("wont7.ts" doesn't even play in VLC, so it's apparently not even valid.)

Why did you think that "MPEG2TransportStreamIndexer" didn't work on the other files ("wont2.ts" through "wont6.ts")??  It works just fine for me.

--

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

________________________________
Please consider the environment before printing this e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100611/7569e131/attachment.html>

From dcharmet at uniways.fr  Fri Jun 11 08:29:33 2010
From: dcharmet at uniways.fr (Denis Charmet)
Date: Fri, 11 Jun 2010 17:29:33 +0200
Subject: [Live-devel] segmentation fault with latest version
In-Reply-To: <f06240802c82e9ed3fc0e@[66.80.62.44]>
References: <1275653036.4c08ebacca46d@imp.celeos.eu>
	<f06240802c82e9ed3fc0e@[66.80.62.44]>
Message-ID: <4C12565D.7050002@uniways.fr>

Ross Finlayson wrote:
>> I tried to use vlc with the latest version.
>> I thought it would work as you say it is backward compatible, but I 
>> have a
>> segmentation fault.
>> I think the line 136 in RTSPClient.cpp is buggy because if 
>> parameterName is
>> NULL, sprintf segfaults.
>
> Oops, yes - my mistake.   This will be fixed in the next release.
I'd like to add another (once this one is patched) in 
RTSPClient::constructSubsessionURL() on line  1169.

if prefix is NULL, it's set to "" so strlen(prefix) will return 0 so you 
try to look at prefix[-1]

Regards,

-- 
Denis Charmet

From finlayson at live555.com  Fri Jun 11 12:39:56 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 11 Jun 2010 12:39:56 -0700
Subject: [Live-devel] segmentation fault with latest version
In-Reply-To: <4C12565D.7050002@uniways.fr>
References: <1275653036.4c08ebacca46d@imp.celeos.eu>
	<f06240802c82e9ed3fc0e@[66.80.62.44]> <4C12565D.7050002@uniways.fr>
Message-ID: <f06240809c838415e10a5@[66.80.62.44]>

>I'd like to add another (once this one is patched) in 
>RTSPClient::constructSubsessionURL() on line  1169.
>
>if prefix is NULL, it's set to "" so strlen(prefix) will return 0 so 
>you try to look at prefix[-1]

OK, thanks.  This has now been fixed in the most recent release (2010.06.11).
-- 

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

From finlayson at live555.com  Fri Jun 11 12:42:12 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 11 Jun 2010 12:42:12 -0700
Subject: [Live-devel] memory leak using tcp
In-Reply-To: <1276250136.157490.4290.nullmailer@mail1003.cent>
References: <20100527153405.123310@gmx.net>
	<1276250136.157490.4290.nullmailer@mail1003.cent>
Message-ID: <f0624080ac83841dc2e28@[66.80.62.44]>

>Our simple solution for this is to prevent recreating the socket 
>hash table in lookupSocketDescriptor when createIfNotFound is set to 
>false and exiting with NULL before socketHashTable is called.

OK, I think I have fixed this now in the latest release of the code 
(2010.06.11).
-- 

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/20100611/9e2383de/attachment.html>

From caojingnju at gmail.com  Fri Jun 11 03:50:12 2010
From: caojingnju at gmail.com (Jim Cao)
Date: Fri, 11 Jun 2010 18:50:12 +0800
Subject: [Live-devel] How to repair the abnormally interrupted openRTSP
	recorded file?
Message-ID: <00c901cb0953$dff286a0$9fd793e0$@com>

Hi, All:

   I'm using openRTSP to receive live video/audio from remote web camera,
and I redirect the stdout to a local file. So I can play the recorded file
later. As we all know, we need use "kill -HUP" or "kill -USR1" to terminate
the openRTSP to make the file written properly. But in my cases, the
openRTSP processes sometimes are killed abnormally without receiving the
SIGHUP or SIGUSR1 signal. No matter how large the local file is, when the
case happens, we cannot open the recorded file. 

So I just want to know 1) what openRTSP writes to the local file after it
received the SIGHUP or SIGUSR1 signals.; 2) is there any way to repair my
local file that it can be opened by VLC or other player.

 

  Thanks a lot!

 

BRs

Jim

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

From finlayson at live555.com  Fri Jun 11 23:05:51 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 11 Jun 2010 23:05:51 -0700
Subject: [Live-devel] How to repair the abnormally interrupted openRTSP
 recorded file?
In-Reply-To: <00c901cb0953$dff286a0$9fd793e0$@com>
References: <00c901cb0953$dff286a0$9fd793e0$@com>
Message-ID: <f06240803c838d4193b30@[66.80.62.44]>

Look at the function "signalHandlerShutdown()" in "testProgs/playCommon.cpp".

Remember, You Have Complete Source Code.
-- 

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

From finlayson at live555.com  Fri Jun 11 23:47:14 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 11 Jun 2010 23:47:14 -0700
Subject: [Live-devel] New, improved "RTSPClient" interface now available
In-Reply-To: <18593.1275495687@yocto>
References: <f06240800c82763ae5de9@[66.80.62.44]> <30615.1275430895@yocto>
	<f06240801c82bb2936af9@[66.80.62.44]> <18593.1275495687@yocto>
Message-ID: <f06240800c838db6bf281@[66.80.62.44]>

>Ross Finlayson <finlayson at live555.com> writes:
>>
>>  How were you intending to use the "client data" value?
>
>Since my application has a number of concurrent RTSP sessions, I
>need to be able to tie responses back to their context.  Without
>a user data pointer, I can think of two options.  The first is to
>keep a global map of RTSPClient object pointers to my data.  I'd
>like to avoid using a global though, because it'll cause some
>difficulty in this application.  The second option is to derive
>from RTSPClient.  This seems like unnecessary complexity though,
>for what I figure is fairly typical use of the new API.

Actually, I don't think that opening more than one RTSP session 
concurrently is a 'typical' use; most applications will probably just 
open one RTSP session at a time (or only one at all).

But in any case, the intention is for there to be a single object 
(pointer) passed to the 'after' function; this object is intended to 
encapsulate all of the state needed by the function.  Having more 
than one object (pointer) is unnecessary.

For the "getNextFrame()" 'after' function, this object (pointer) is 
"clientData", which is a "void*" (but which probably could have been 
a "FramedSource*", because it's always used for "FrameSource" 
subclasses, I think).  For the RTSPClient 'after' function, this 
object (pointer) is a "RTSPClient" itself.

So if the state that you want isn't already encapsulated by the 
existing "RTSPClient" class, then you should subclass it to add the 
state that you want.  (If you need some of the fields/functions in 
the current "RTSPClass" definition changed from "private" to 
"protected", let us know.)
-- 

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

From finlayson at live555.com  Sun Jun 13 18:49:50 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 13 Jun 2010 18:49:50 -0700
Subject: [Live-devel] RTP Timestamp to UTC time
In-Reply-To: <AANLkTilgDWTC6vs14tDjyMVJOOOuQbfHAuE382OdtAEe@mail.gmail.com>
References: <o2k6d1553a51005090119yfdeeb674kaa45454e13d7f251@mail.gmail.com>
	<f06240802c80d425a18ff@66.80.62.44>
	<AANLkTilgDWTC6vs14tDjyMVJOOOuQbfHAuE382OdtAEe@mail.gmail.com>
Message-ID: <f06240801c83b363d2d32@[66.80.62.44]>

>I am not a casual hobbiest.I am using gmail id because My Official 
>mail-id is not accessible from home. I access Live555 mails from 
>home also. But if you want I will subscribe to the live555 mailing 
>list using my official id.

Yes, if you want to be taken seriously on this mailing list, you 
should use a professional email address - i.e., one whose domain name 
identifies an organization (company or school) that you're affiliated 
with, or at least a personal custom domain name.  I use the domain 
name of posters' email addresses as a first-level filter when 
deciding which messages are worth responding to.  If your only access 
to email is via a "@hotmail", "@aol", "@gmail" etc. -type address, 
then I'm going to assume (absent strong evidence to the contrary) 
that you lack the sophistication to use the "LIVE555 Streaming Media" 
software.  The hundreds of previous messages posted to this mailing 
list have borne this out.  In any case, messages from 'hobbyist' 
email addresses like these will *always* be moderated and delayed - 
sometimes for several days.


>I having following confusion:
>
>1. fSyncTime.tv_sec = ntpTimestampMSW - 0x83AA7E80; // 1/1/1900 -> 1/1/1970
>       why 0x83AA7E80 is subtracted from ntpTimestampMSW?

Because (as noted in the comment) it converts the time value from one 
'epoch' to another.  I.e., it converts the time value from the 
1/1/1900 epoch used by NTP to the 1/1/1970 epoch used by the 
Unix/Posix "gettimeofday()" function.  (This is using 32-bit values.)


>  2. double microseconds = (ntpTimestampLSW*15625.0)/0x04000000; // 10^6/2^32
>Why 15625.0 is multiplied with ntpTimestampLSW and the result is 
>divided by 0x04000000

Because (as noted in the comment) multiplying by 15625/0x04000000 is 
equivalent to multiplying by 10^6, and then dividing by 2^32 - i.e., 
converting a 32-bit binary fraction in seconds to microseconds, 
reducing the liklihood of truncation error.

But in any case (especially as you are writing a client application) 
you absolutely do not need to care about timestamps (RTP or NTP). 
All you need to care about are presentation times (and whether or not 
they have been synchronized using RTCP).

-- 

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

From finlayson at live555.com  Sun Jun 13 19:02:51 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 13 Jun 2010 19:02:51 -0700
Subject: [Live-devel] RTP/H264 low latency streaming + source change
In-Reply-To: <4BFFB0C5.4010501@robosoft.fr>
References: <4BFFB0C5.4010501@robosoft.fr>
Message-ID: <f06240803c83b3bfa8585@[66.80.62.44]>

>I am using Live555 libraries to stream H264 video provided by a 
>frame grabber, via RTP (not RTSP).
>I use VLC and VLC activeX as a RTP/H264 client.
>
>Sometimes, I need to change the camera used by the framegrabber, so 
>I close the RTP sink, the framer, the source, and I open them again 
>with the new video. Doing that, (even with the same video 
>parameters), the client often hang (but not every time), and 
>sometimes go on playing again but with a big delay.
>How can I prevent the client from freezing the video or display the 
>video with delay ? Sending some missing frames ? Special trick to 
>warn client ?
>My main objective is LOW latency, some image skips are not a problem.

I suspect that your problem is caused by the fact that each sending 
camera (server) necessarily uses a different RTP timestamp base, and 
so when you switch to receiving from a new camera, the received 
data's presentation time will briefly be inaccurate, until you 
receive a new RTCP "SR" packet from the new source.  (I'm assuming 
that your servers send RTCP as well as RTP; because you're using our 
software, that should be the case.)

One way to reduce this problem is to increase the average RTCP 
sending frequency, which you can do by increasing the "totSessionBW" 
parameter that you pass to "RTCPInstance::createNew()".  (This 
parameter is intended to represent the stream's bitrate in kbps.  It 
is used - by the RTCP code - to figure out how often to send RTCP 
packets.)
-- 

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

From finlayson at live555.com  Sun Jun 13 19:16:32 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sun, 13 Jun 2010 19:16:32 -0700
Subject: [Live-devel] RTSP server hang
In-Reply-To: <AANLkTinun_cqnSY0D8FZ9Up0JWJNFcwIEf5s0qKTxvr_@mail.gmail.com>
References: <AANLkTinun_cqnSY0D8FZ9Up0JWJNFcwIEf5s0qKTxvr_@mail.gmail.com>
Message-ID: <f06240804c83b3fe670f3@[66.80.62.44]>

>Under load, I'm noticing our RTSP server occasionally hangs in this location:
>
>static int blockUntilReadable(UsageEnvironment& env,
>                   int socket, struct timeval* timeout) {
>   int result = -1;
>   do {
>     fd_set rd_set;
>     FD_ZERO(&rd_set);
>     if (socket < 0) break;
>     FD_SET((unsigned) socket, &rd_set);
>     const unsigned numFds = socket+1;
>
>     result = select(numFds, &rd_set, NULL, NULL, timeout);  <--HANG

You know what?  Now that we have fixed "RTSPClient" so that we no 
longer do any synchronous socket reads - i.e., we now read from a 
socket only when we're notified from the event queue that new data is 
available on the socket - we should no longer ever need to call 
"blockUntilReadable()" at all!

I.e., you should be able to remove the following code from the 
implementation of "readSocket()" in "groupsock/GroupsockHelper.cpp" 
(line 265):

     int result = blockUntilReadable(env, socket, timeout);
     if (timeout != NULL && result == 0) {
       bytesRead = 0;
       break;
     } else if (result <= 0) {
       break;
     }

and I think everything will work OK (only more efficiently!).

So give this a try.  If you run into any problems, let us know.  (If 
not, I'll remove this code from the next release of the software.)
-- 

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

From jnoring at logitech.com  Mon Jun 14 08:23:17 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Mon, 14 Jun 2010 08:23:17 -0700
Subject: [Live-devel] RTSP server hang
In-Reply-To: <f06240804c83b3fe670f3@66.80.62.44>
References: <AANLkTinun_cqnSY0D8FZ9Up0JWJNFcwIEf5s0qKTxvr_@mail.gmail.com>
	<f06240804c83b3fe670f3@66.80.62.44>
Message-ID: <AANLkTikRwsYgNDt_YQz23JGWpih6bkXiDuAd_hndohdg@mail.gmail.com>

On Sun, Jun 13, 2010 at 7:16 PM, Ross Finlayson <finlayson at live555.com>wrote:

I.e., you should be able to remove the following code from the
> implementation of "readSocket()" in "groupsock/GroupsockHelper.cpp" (line
> 265):
>
>    int result = blockUntilReadable(env, socket, timeout);
>    if (timeout != NULL && result == 0) {
>      bytesRead = 0;
>      break;
>    } else if (result <= 0) {
>      break;
>    }
>
> and I think everything will work OK (only more efficiently!).
>
> So give this a try.  If you run into any problems, let us know.  (If not,
> I'll remove this code from the next release of the software.)


I had read about this on the mailing list, but I was wary to disable entire
functions.  So I ended up neutering one specific place that called
readSocket to have a null timeout;  I added a five second timeout:

Boolean Groupsock::handleRead(unsigned char* buffer, unsigned bufferMaxSize,
                  unsigned& bytesRead,
                  struct sockaddr_in& fromAddress) {
  // Read data from the socket, and relay it across any attached tunnels
  //##### later make this code more general - independent of tunnels

  bytesRead = 0;

  int maxBytesToRead = bufferMaxSize - TunnelEncapsulationTrailerMaxSize;
  timeval to;
  to.tv_sec = 5;
  to.tv_usec = 0;
  int numBytes = readSocket(env(), socketNum(),
                buffer, maxBytesToRead, fromAddress, &to);
  if (numBytes < 0) {
    if (DebugLevel >= 0) { // this is a fatal error
      env().setResultMsg("Groupsock read failed: ",
             env().getResultMsg());
    }
    return False;
  }

...and the server no longer hangs.  In general, given how the code works
with a dedicated worker thread, I think there should _never_ be anything
that can potentially block for any substantial amount of time (i.e. all
infinite timeout calls should be removed).

On a related note, here's one other hack I had to add to prevent crashing:

void RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(u_int8_t
requestByte) {
  // Add this character to our buffer; then try to handle the data that we
have buffered so far:
  if (fRequestBufferBytesLeft == 0) return;
  if (fRequestBytesAlreadySeen >= RTSP_BUFFER_SIZE ) return;    // hack:
don't let us overflow fRequestBuffer, and there's some bug
                                                                // with
sessions containing multiple subsessions, when streaming over
                                                                // TCP that
causes this to fail miserably.
  fRequestBuffer[fRequestBytesAlreadySeen] = requestByte;
  handleRequestBytes(1);
}

...I previously reported this.  When there are multiple sessions being
streamed that contain both audio and video (i.e. multiple subsessions) over
TCP, sometimes the server will crash with an access violation by walking off
the end of fRequestBuffer.  I do not understand the crash; I do know that
this code prevents it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100614/be63e608/attachment.html>

From dcharmet at uniways.fr  Mon Jun 14 08:41:27 2010
From: dcharmet at uniways.fr (Denis Charmet)
Date: Mon, 14 Jun 2010 17:41:27 +0200
Subject: [Live-devel] Another segmentation fault in latest live555
Message-ID: <4C164DA7.1030902@uniways.fr>

Hi,

I also use vlc with the latest live555 and I found a segmentation fault :

It seems that the use of getMediaSessionParameter launch a sendRequest( 
"GET_PARAMETER" ) with a NULL session and subsession.
So in sendRequest on line 696 constructSubsessionURL is called with a 
NULL subsession which cause liveMedia to crash on line 1155.

Here is the backtrace.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x4145e950 (LWP 24627)]
RTSPClient::constructSubsessionURL (this=0x16bae30, subsession=@0x0, 
prefix=@0x4145def0, separator=@0x4145dee8,
    suffix=@0x4145dee0) at RTSPClient.cpp:1155
1155    RTSPClient.cpp: No such file or directory.
    in RTSPClient.cpp
Current language:  auto; currently c++
(gdb) bt
#0  RTSPClient::constructSubsessionURL (this=0x16bae30, subsession=@0x0, 
prefix=@0x4145def0, separator=@0x4145dee8,
    suffix=@0x4145dee0) at RTSPClient.cpp:1155
#1  0x00007fd1680232dc in RTSPClient::sendRequest (this=0x16bae30, 
request=0x16d7d00) at RTSPClient.cpp:696
#2  0x00007fd168024aad in RTSPClient::sendGetParameterCommand 
(this=0x16bae30, session=<value optimized out>,
    responseHandler=0x7fd168020924 
<RTSPClient::responseHandlerForSyncInterface(RTSPClient*, int, char*)>,
    parameterName=<value optimized out>, authenticator=<value optimized 
out>) at RTSPClient.cpp:134
#3  0x00007fd168024b26 in RTSPClient::getMediaSessionParameter 
(this=0x16bae30, session=@0x0,
    parameterName=<value optimized out>, parameterValue=@0x4145dfa8) at 
RTSPClient.cpp:1828
#4  0x00007fd168018406 in Demux (p_demux=0x16b6bc8) at live555.cpp:1129
#5  0x00007fd17c3dd785 in MainLoop (p_input=0x16afec8, 
b_interactive=<value optimized out>) at input/demux.h:48
#6  0x00007fd17c3e02e5 in Run (p_this=<value optimized out>) at 
input/input.c:540
#7  0x00007fd17c417d26 in thread_entry (data=<value optimized out>) at 
misc/threads.c:58
#8  0x00007fd17c172fc7 in start_thread () from /lib/libpthread.so.0
#9  0x00007fd17bce459d in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()

Regards,

-- 
Denis Charmet

From finlayson at live555.com  Mon Jun 14 15:55:25 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 14 Jun 2010 15:55:25 -0700
Subject: [Live-devel] Another segmentation fault in latest live555
In-Reply-To: <4C164DA7.1030902@uniways.fr>
References: <4C164DA7.1030902@uniways.fr>
Message-ID: <f06240801c83c635653e7@[66.80.62.44]>

>It seems that the use of getMediaSessionParameter launch a 
>sendRequest( "GET_PARAMETER" ) with a NULL session and subsession.

Thanks for reporting this.

The fix is to change 134 from
	  unsigned result = sendRequest(new RequestRecord(++fCSeq, 
"GET_PARAMETER", responseHandler, NULL, NULL, False, 0.0, 0.0, 0.0, 
paramString));
to
	  unsigned result = sendRequest(new RequestRecord(++fCSeq, 
"GET_PARAMETER", responseHandler, &session, NULL, False, 0.0, 0.0, 
0.0, paramString));

There's a similar fix needed on line 114 for "SET_PARAMETER"

These will be fixed in the next release of the software.
-- 

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

From dlee at numirabio.com  Mon Jun 14 15:19:02 2010
From: dlee at numirabio.com (Dillon Lee)
Date: Mon, 14 Jun 2010 17:19:02 -0500
Subject: [Live-devel] Live streaming mpeg1or2
Message-ID: <17207CD959E5874196B8A8438794453C18439C5B02@34093-MBX-C16.mex07a.mlsrvr.com>

Hello everyone,

I am attempting to stream frames that are generated live via OpenGL and compressed into MPEG2 Video frames. I have created a class which inherits from FramedSource and that class overrides doGetNextFrame(). I have also created a function called deliverFrame() that is called by doGetNextFrame() when a new frame is available. deliverFrame() copies the compressed image into fTo and then calls FramedSource::afterGetting() (I'm a bit confused as to how I should use the fDurationInMicroseconds and fPresentationTime because the images do not occur at regular time intervals). My problem is that when I try to view my stream using VLC I get only one or two frames across before VLC stops updating. The two frames I get are not one right after another but rather one and then a few seconds later another one, after that VLC is stuck showing that frame. VLC does not freeze but it doesn't keep up with the streaming frames. If I press stop and play (or rewind or fastforward) on VLC then I get one or two frames and the same thing happens again. I have looked at the log for VLC and for the most part it says 'Buffering 0%'. Sometimes it will say:

libmpeg2 error: DpbUnlinkPicture called on an invalid picture
main warning: backward_pts != current_pts (-12913336635)

but that message is rare.
I am using the 'testMPEG4VideoStreamer.cpp' file for initializing all my stuff, the only difference is that I am using my derived FramedSource in the play() function. Any thoughts as to why this might be happening? Thanks in advance for your help.

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

From finlayson at live555.com  Mon Jun 14 21:44:31 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 14 Jun 2010 21:44:31 -0700
Subject: [Live-devel] Live streaming mpeg1or2
In-Reply-To: <17207CD959E5874196B8A8438794453C18439C5B02@34093-MBX-C16.mex07a.mlsrvr.co
	m>
References: <17207CD959E5874196B8A8438794453C18439C5B02@34093-MBX-C16.mex07a.mlsrvr.co
	m>
Message-ID: <f06240800c83cb42f6f11@[66.80.62.44]>

>(I'm a bit confused as to how I should use the 
>fDurationInMicroseconds and fPresentationTime because the images do 
>not occur at regular time intervals).

Because your data is coming from a live source (rather than a file, 
for example), you can probably omit setting 
"fDurationInMicroseconds".  (That variable just tells the downstream 
"RTPSink" object how long to wait after sending each packet before 
looking for new incoming data; if you don't set it, the "RTPSink" 
object will look for new incoming data immediately after sending each 
packet.  For a live data source, like yours, that is OK.)

However, you need to set "fPresentationTime" properly for each frame 
of data.  The easiest way to do this is just to call "gettimeofday()" 
when you get each frame.

I also suggest that you test your server using the "openRTSP" client 
application first - before using VLC.  (This is because "openRTSP" - 
unlike VLC - does not care about the presentation times on incoming 
data.)
-- 

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

From finlayson at live555.com  Tue Jun 15 02:55:16 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 15 Jun 2010 02:55:16 -0700
Subject: [Live-devel] RTSP server hang
In-Reply-To: <AANLkTikRwsYgNDt_YQz23JGWpih6bkXiDuAd_hndohdg@mail.gmail.com>
References: <AANLkTinun_cqnSY0D8FZ9Up0JWJNFcwIEf5s0qKTxvr_@mail.gmail.com>
	<f06240804c83b3fe670f3@66.80.62.44>
	<AANLkTikRwsYgNDt_YQz23JGWpih6bkXiDuAd_hndohdg@mail.gmail.com>
Message-ID: <f06240803c83cfb10e5cf@[66.80.62.44]>

I've now installed a new version (2010.06.15) of the code that 
completely removes the "blockUntilReadable()" function.  This means 
that "readSocket()" no longer calls "select()", which
should improve the performance of both client and server applications.


>On a related note, here's one other hack I had to add to prevent crashing:
>
>void 
>RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(u_int8_t 
>requestByte) {
>   // Add this character to our buffer; then try to handle the data 
>that we have buffered so far:
>   if (fRequestBufferBytesLeft == 0) return;
>   if (fRequestBytesAlreadySeen >= RTSP_BUFFER_SIZE ) return;    // 
>hack: don't let us overflow fRequestBuffer, and there's some bug
>                                                                 // 
>with sessions containing multiple subsessions, when streaming over
>                                                                 // 
>TCP that causes this to fail miserably.
>   fRequestBuffer[fRequestBytesAlreadySeen] = requestByte;
>   handleRequestBytes(1);
>}
>
>
>...I previously reported this.  When there are multiple sessions 
>being streamed that contain both audio and video (i.e. multiple 
>subsessions) over TCP, sometimes the server will crash with an 
>access violation by walking off the end of fRequestBuffer.  I do not 
>understand the crash; I do know that this code prevents it.

I don't understand why the "hack" line should be necessary, because 
"handleRequestBytes()" should already be testing for buffer overflow. 
However, this newest release of the code improves the handling of 
RTP/RTCP/RTSP-over-TCP, so I'm hoping that it happened to fix the bug 
as well.
-- 

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

From dcharmet at uniways.fr  Tue Jun 15 04:51:53 2010
From: dcharmet at uniways.fr (Denis Charmet)
Date: Tue, 15 Jun 2010 13:51:53 +0200
Subject: [Live-devel] Another segmentation fault in latest live555
In-Reply-To: <f06240801c83c635653e7@[66.80.62.44]>
References: <4C164DA7.1030902@uniways.fr> <f06240801c83c635653e7@[66.80.62.44]>
Message-ID: <4C176959.8040108@uniways.fr>

Hi again,

I think the line 1079 in RTSPClient.cpp is also missing some parenthesis:

while (resultLen > 0 && resultValueString[resultLen-1] == '\r' || 
resultValueString[resultLen-1] == '\n' ) --resultLen;

to

while (resultLen > 0 && ( resultValueString[resultLen-1] == '\r' || 
resultValueString[resultLen-1] == '\n') ) --resultLen;

Here is the backtrace:

1079    RTSPClient.cpp: No such file or directory.
    in RTSPClient.cpp
Current language:  auto; currently c++
(gdb) bt
#0  0x00007f8faf9a117e in RTSPClient::handleGET_PARAMETERResponse 
(this=<value optimized out>,-
    parameterName=<value optimized out>, resultValueString=@0x4158acb8) 
at RTSPClient.cpp:1079
#1  0x00007f8faf9a4604 in RTSPClient::handleResponseBytes (this=0x1872740,-
    newBytesRead=<value optimized out>) at RTSPClient.cpp:1492
#2  0x00007f8faf9a491a in RTSPClient::incomingDataHandler1 
(this=0x1872740) at RTSPClient.cpp:1287
#3  0x00007f8faf9a4929 in RTSPClient::incomingDataHandler 
(instance=0x1872a2f) at RTSPClient.cpp:1280
#4  0x00007f8faf9bd807 in BasicTaskScheduler::SingleStep (this=0x186eef0,-
    maxDelayTime=<value optimized out>) at BasicTaskScheduler.cpp:141
#5  0x00007f8faf9beeb5 in BasicTaskScheduler0::doEventLoop (this=0x186eef0,-
    watchVariable=0x1872880 "") at BasicTaskScheduler0.cpp:76
#6  0x00007f8faf9a4b65 in RTSPClient::getMediaSessionParameter 
(this=0x1872740,-
    session=<value optimized out>, parameterName=<value optimized out>, 
parameterValue=@0x4158afa8)
    at RTSPClient.cpp:1831
#7  0x00007f8faf998406 in Demux (p_demux=0x186e4d8) at live555.cpp:1129
#8  0x00007f8fc3d5d785 in MainLoop (p_input=0x1869ce8, 
b_interactive=<value optimized out>)
    at input/demux.h:48
#9  0x00007f8fc3d602e5 in Run (p_this=<value optimized out>) at 
input/input.c:540
#10 0x00007f8fc3d97d26 in thread_entry (data=<value optimized out>) at 
misc/threads.c:58
#11 0x00007f8fc3af2fc7 in start_thread () from /lib/libpthread.so.0
#12 0x00007f8fc366459d in clone () from /lib/libc.so.6
#13 0x0000000000000000 in ?? ()

(resultLen is null)

Regards,

-- 
Denis Charmet

From raphael.barbieri at eitv.com.br  Tue Jun 15 04:39:02 2010
From: raphael.barbieri at eitv.com.br (Raphael Oliveira Barbieri)
Date: Tue, 15 Jun 2010 08:39:02 -0300
Subject: [Live-devel] Fwd: testMPEG2TransportStreamer support
In-Reply-To: <AANLkTil9-ENJWpCJcqYnj6cK8SdBEDiNtO6lCZcjwUne@mail.gmail.com>
References: <AANLkTil9-ENJWpCJcqYnj6cK8SdBEDiNtO6lCZcjwUne@mail.gmail.com>
Message-ID: <AANLkTimHxE07U2RL45XYcAIP7rO0aRoz69vGiF-j0Tl3@mail.gmail.com>

Hi !!!

I was looking for an application that outputs a transport stream (188 bytes)
over network and last week I found your live555 Media software. It does
almost everything I need.
I'm running a Ubuntu server 9.10 system with a local transport stream file.

In a first moment I'm using testMPEG2TransportStreamer at testProgs folder
and the transmission looks great at RTP protocol.

I have 3 questions.

- Is it possible to transmit over udp protocol ? After reading the
testMPEG2TransportStreamer code I didn't found nothing that mention udp
protocol. Is there another example program that does this task?

- My machine has 4 ethernet devices (eth0, eth1, eth2 and eth3). How can I
select a specific device to use?

- The output rate is defined by the PCR rate in a Transport Stream, right?
In case I have a ts with more than one PCR pid, which one is choosen? Is
there a way to set a fixed output rate?

Thank you in advance!

Best regards,

Raphael Barbieri
Systems Engineer
EITV - Entretenimento e Interatividade para TV Digital
desk   +55 (19) 3579-0744
mobile +55 (19) 9111-4231
email  raphael.barbieri at eitv.com.br
skype  raphael.barbieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100615/3ea04216/attachment.html>

From finlayson at live555.com  Tue Jun 15 05:16:03 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 15 Jun 2010 05:16:03 -0700
Subject: [Live-devel] Another segmentation fault in latest live555
In-Reply-To: <4C176959.8040108@uniways.fr>
References: <4C164DA7.1030902@uniways.fr>
	<f06240801c83c635653e7@[66.80.62.44]> <4C176959.8040108@uniways.fr>
Message-ID: <f06240804c83d1f4985ec@[66.80.62.44]>

>I think the line 1079 in RTSPClient.cpp is also missing some parenthesis:
>
>while (resultLen > 0 && resultValueString[resultLen-1] == '\r' || 
>resultValueString[resultLen-1] == '\n' ) --resultLen;
>
>to
>
>while (resultLen > 0 && ( resultValueString[resultLen-1] == '\r' || 
>resultValueString[resultLen-1] == '\n') ) --resultLen;

Yes, you're right.  Thanks; this will be fixed shortly.
-- 

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

From jnoring at logitech.com  Tue Jun 15 10:07:02 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Tue, 15 Jun 2010 10:07:02 -0700
Subject: [Live-devel] RTSP server hang
In-Reply-To: <f06240803c83cfb10e5cf@66.80.62.44>
References: <AANLkTinun_cqnSY0D8FZ9Up0JWJNFcwIEf5s0qKTxvr_@mail.gmail.com>
	<f06240804c83b3fe670f3@66.80.62.44>
	<AANLkTikRwsYgNDt_YQz23JGWpih6bkXiDuAd_hndohdg@mail.gmail.com>
	<f06240803c83cfb10e5cf@66.80.62.44>
Message-ID: <AANLkTik3fDviGvW1lYbEu09Iw54WSOCyxl3puGCoxL0p@mail.gmail.com>

On Tue, Jun 15, 2010 at 2:55 AM, Ross Finlayson <finlayson at live555.com>wrote:

> I've now installed a new version (2010.06.15) of the code that completely
> removes the "blockUntilReadable()" function.  This means that "readSocket()"
> no longer calls "select()", which
> should improve the performance of both client and server applications.
>
>
>
>  On a related note, here's one other hack I had to add to prevent crashing:
>>
>> void RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(u_int8_t
>> requestByte) {
>>  // Add this character to our buffer; then try to handle the data that we
>> have buffered so far:
>>  if (fRequestBufferBytesLeft == 0) return;
>>  if (fRequestBytesAlreadySeen >= RTSP_BUFFER_SIZE ) return;    // hack:
>> don't let us overflow fRequestBuffer, and there's some bug
>>                                                                // with
>> sessions containing multiple subsessions, when streaming over
>>                                                                // TCP that
>> causes this to fail miserably.
>>  fRequestBuffer[fRequestBytesAlreadySeen] = requestByte;
>>  handleRequestBytes(1);
>> }
>>
>>
>> ...I previously reported this.  When there are multiple sessions being
>> streamed that contain both audio and video (i.e. multiple subsessions) over
>> TCP, sometimes the server will crash with an access violation by walking off
>> the end of fRequestBuffer.  I do not understand the crash; I do know that
>> this code prevents it.
>>
>
> I don't understand why the "hack" line should be necessary, because
> "handleRequestBytes()" should already be testing for buffer overflow.
> However, this newest release of the code improves the handling of
> RTP/RTCP/RTSP-over-TCP, so I'm hoping that it happened to fix the bug as
> well.


It fails on this line in handleAlternativeRequestByte1:

fRequestBuffer[fRequestBytesAlreadySeen] = requestByte;

...so no, it does not test for buffer overflow.  For whatever reason,
fRequestBuffer gets set to a very large number (i.e. greater than 10K),
which causes this function to crash with an access violation.  It doesn't
have anything to do with handleRequestBytes().
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100615/07d77a4e/attachment-0001.html>

From finlayson at live555.com  Tue Jun 15 23:05:01 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 15 Jun 2010 23:05:01 -0700
Subject: [Live-devel] RTSP server hang
In-Reply-To: <AANLkTik3fDviGvW1lYbEu09Iw54WSOCyxl3puGCoxL0p@mail.gmail.com>
References: <AANLkTinun_cqnSY0D8FZ9Up0JWJNFcwIEf5s0qKTxvr_@mail.gmail.com>
	<f06240804c83b3fe670f3@66.80.62.44>
	<AANLkTikRwsYgNDt_YQz23JGWpih6bkXiDuAd_hndohdg@mail.gmail.com>
	<f06240803c83cfb10e5cf@66.80.62.44>
	<AANLkTik3fDviGvW1lYbEu09Iw54WSOCyxl3puGCoxL0p@mail.gmail.com>
Message-ID: <f0624080bc83e197daa5e@[66.80.62.44]>

>For whatever reason, fRequestBuffer gets set to a very large number 
>(i.e. greater than 10K), which causes this function to crash with an 
>access violation.

It would be nice to figure out what this "whatever reason" actually 
is, because it's better to fix a bug than paper over it.  However, 
I've added your extra 'sanity check' to the latest release of the 
software, to hopefully make the code more robust until we can find 
the actual bug.
-- 

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

From finlayson at live555.com  Tue Jun 15 23:22:59 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 15 Jun 2010 23:22:59 -0700
Subject: [Live-devel] Fwd: testMPEG2TransportStreamer support
In-Reply-To: <AANLkTimHxE07U2RL45XYcAIP7rO0aRoz69vGiF-j0Tl3@mail.gmail.com>
References: <AANLkTil9-ENJWpCJcqYnj6cK8SdBEDiNtO6lCZcjwUne@mail.gmail.com>
	<AANLkTimHxE07U2RL45XYcAIP7rO0aRoz69vGiF-j0Tl3@mail.gmail.com>
Message-ID: <f0624080cc83e1a17ce86@[66.80.62.44]>

>In a first moment I'm using testMPEG2TransportStreamer at testProgs 
>folder and the transmission looks great at RTP protocol.
>
>I have 3 questions.
>
>- Is it possible to transmit over udp protocol ? After reading the 
>testMPEG2TransportStreamer code I didn't found nothing that mention 
>udp protocol. Is there another example program that does this task?

RTP *does* use the UDP protocol, by default.  I.e., RTP packets are 
sent as UDP packets (which, of course, are sent as IP packets).

However, are you asking instead if you can stream the Transport 
Stream data without using RTP - i.e., using raw UDP packets only? 
This is not recommended, because RTP/RTCP provides useful 
functionality.  In particular, it corrects for packets that get 
misordered over the network (because RTP contains a sequence number). 
Also, RTCP lets you monitor the stream's status (packet loss rates, 
etc).

However, if you *really* want to stream using raw UDP (the only real 
reason why you would want to do this is if you have a client - that 
you cannot change - that receives raw UDP only), then the way you can 
do this (in applications like "testMPEG2TransportStreamer") is to 
modify the application's code to use a "BasicUDPSink" instead of a 
"SimpleRTPSink".  You should also remove the code that creates a 
"RTCPInstance" (because RTCP is used only with RTP).


>- My machine has 4 ethernet devices (eth0, eth1, eth2 and eth3). How 
>can I select a specific device to use?

"testMPEG2TransportStreamer" (being a multicast streaming 
application) uses whatever network interface is configured with IP 
multicast routing - i.e., a route for 224.0.0/4 .  Therefore, if you 
want to use a different interface, you'll need to reconfigure your 
routes so that IP multicast is roufed on this new interface.


>- The output rate is defined by the PCR rate in a Transport Stream, 
>right? In case I have a ts with more than one PCR pid, which one is 
>choosen?

The PCRs from the first 'video' substream that's found within the 
Transport Stream.


>  Is there a way to set a fixed output rate?

No.
-- 

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

From Extern.Malte.Oeljeklaus at de.bucyrus.com  Wed Jun 16 01:15:26 2010
From: Extern.Malte.Oeljeklaus at de.bucyrus.com (Oeljeklaus, Malte (Extern))
Date: Wed, 16 Jun 2010 10:15:26 +0200
Subject: [Live-devel] (no subject)
Message-ID: <CC7C613D2D7DDD48B3C2A3E3A40033EF06B8A36C@bucydoex1.dbt.de>

Hello list members,

I'm currently working on a coding project for a device similar to an IP-camera which streams via rtsp using an MPEG-4 codec. I'm trying to set up a testing environment on my local PC for that I don't have the hardware available all the time. To do so, I've been experimenting with the built in rtsp streaming server in VLC. Unfortunately it turned out, that the VLC servers behaviour differs, I can connect to VLC using the ffmpeg built in rtsp handler but when I try to connect to the IP-camera using ffmpeg I get "error while parsing header" message.
Therefore I'm currently evaluating other methods of building a streaming client and since I can view the rtsp stream with VLC (as a client) and VLC is said to use the Live555 library for rtsp handling I thought it might be a good idea to take a closer look.
My basic question is whether it is sufficient to test if openRTSP can connect to my IP-camera to be able to say that Live555 supports my device and I can go on working with it.
Additionally what I've noticed during my testing is that openRTSP seems not to be able to connect to a VLC streaming server (it says "Failed to setup  subsession: Missing or bad "Transport:" header"), obviously openRTSP and VLC are not compatible (using ffmpeg as client works fine) but how can this be since both are based on the same library?
In a further step I will need the decoded frames as arrays of rgb or grayscale values, is this possible with Live555? The website says some video processing is supported.

I've tested with live.2010.06.15 and VLC 1.0.5 and FFmpeg version SVN-r23512, to setup VLC as a testing server I took the following steps from the main window: Extras->VLM configuration->Media Manager Edition: VOD

Thanks for your help

Malte

____________________________________________________________________________________________________________________
Bucyrus HEX GmbH
Sitz der Gesellschaft / Company headquarters: Dortmund
Registriert beim Amtsgericht unter / Registered at the local court Dortmund at HRB 22438
Geschaeftsfuehrer / Management Board: Dr. Heribert Bussmann, Joseph Helfrich (Chairman), Reinhard Reinartz, Stefan Rittershaus
Vorsitzender des Aufsichtsrates / Chairman of the Supervisory Board: Dr. Juergen W. Stadelhofer
____________________________________________________________________________________________________________________
NOTICE - This message and any attached files may contain information that is confidential and/or a subject of legal privilege meant only for use by the intended recipient. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient be advised that you have received this message in error and that any dissemination, copying or use of this message or attachment is strictly forbidden, as is the disclosure of the information therein. If you have received this message in error please notify the sender immediately and delete this message.

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

From finlayson at live555.com  Wed Jun 16 03:23:50 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 16 Jun 2010 03:23:50 -0700
Subject: [Live-devel] (no subject)
In-Reply-To: <CC7C613D2D7DDD48B3C2A3E3A40033EF06B8A36C@bucydoex1.dbt.de>
References: <CC7C613D2D7DDD48B3C2A3E3A40033EF06B8A36C@bucydoex1.dbt.de>
Message-ID: <f06240800c83e528cec22@[66.80.62.44]>

>My basic question is whether it is sufficient to test if openRTSP 
>can connect to my IP-camera to be able to say that Live555 supports 
>my device and I can go on working with it.

Yes, with the caveat that "openRTSP" does not care about the 
"presentation times" of each received frame.  Therefore, it's 
possible - if the stream's "presentation times" are somehow bad - 
that "openRTSP"  will receive your stream OK, but a media player may 
not.

>Additionally what I've noticed during my testing is that openRTSP 
>seems not to be able to connect to a VLC streaming server (it says 
>"Failed to setup  subsession: Missing or bad "Transport:" header"), 
>obviously openRTSP and VLC are not compatible (using ffmpeg as 
>client works fine) but how can this be since both are based on the 
>same library?

VLC uses the "LIVE555 Streaming Media" code only when it is acting as 
a RTSP *client*.  When VLC acts as a RTSP *server*, however, it uses 
a different RTSP implementation.

It appears that some recent versions of VLC have changed the way that 
they send "Transport:" headers in the response to RTSP "SETUP" 
commands - in a way which our RTSP client code did not handle 
properly.

I have now installed a new version (2010.06.16a) of the "LIVE555 
Streaming Media" code that should fix this problem.  Please download 
and use this instead for your testing.


>In a further step I will need the decoded frames as arrays of rgb or 
>grayscale values, is this possible with Live555? The website says 
>some video processing is supported.

No, I don't know where you got that impression.  Our software does 
not do any video decoding (or other video processing).  You will need 
to do that yourself.
-- 

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/20100616/30cceaf2/attachment.html>

From dlee at numirabio.com  Wed Jun 16 09:41:02 2010
From: dlee at numirabio.com (Dillon Lee)
Date: Wed, 16 Jun 2010 11:41:02 -0500
Subject: [Live-devel] Live streaming mpeg1or2
Message-ID: <17207CD959E5874196B8A8438794453C18439C6240@34093-MBX-C16.mex07a.mlsrvr.com>

Great, thanks for the info. My program now sets the fPresentationTime with gettimeofday. I am now using openRTSP instead of VLC and I have looked at the output file and that tells me that I am sending too many frames. Basically, the output looks like I am sending about 100 frames per 1 frame that I should be sending. I think my problem is that my doGetNextFrame calls my deliverFrame function everytime, even if there isn't a frame ready. If a frame isn't ready and I just simply return from doGetNextFrame without doing anything then doGetNextFrame is never called again. Is there a way to tell the program to call doGetNextFrame when a frame is ready?

Thanks for all your help,
Dillon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100616/12417350/attachment.html>

From yuri.timenkov at itv.ru  Wed Jun 16 09:15:22 2010
From: yuri.timenkov at itv.ru (Yuri Timenkov)
Date: Wed, 16 Jun 2010 20:15:22 +0400
Subject: [Live-devel] liveMedia and CMake
Message-ID: <007e01cb0d6f$1eff4d50$5cfde7f0$@timenkov@itv.ru>

Hi all,

 

There was a mail about 4 years ago (in 2006) with patch adding support for CMake build system to liveMedia, but there was no any reaction.

Are there any ideological objections against CMake?

 

The main advantage (for me :) ) of using CMake for liveMedia is excellent windows support. With same (as on linux/unix) files you can generate build system for vast set of compilers (from VC6 to VC10 and non-MS ones). Also, it easily allows you to build both static and dynamic libraries (by switching single option in GUI), which makes much easier to meet LGPL licensing requirements. Because it is C++ library, it should be built with the same compiler options as the rest of the software. (Although dynamic libraries requires some modifications in code to export necessary symbols).

 

If you are worried about extra dependencies, cmake doesn't require anything else to work, and perfectly fits into download-unpack-run scenario (on Linux, its included into many distros).

 

Regards,

Yuri

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

From finlayson at live555.com  Wed Jun 16 11:29:01 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 16 Jun 2010 11:29:01 -0700
Subject: [Live-devel] Live streaming mpeg1or2
In-Reply-To: <17207CD959E5874196B8A8438794453C18439C6240@34093-MBX-C16.mex07a.mlsrvr.co
	m>
References: <17207CD959E5874196B8A8438794453C18439C6240@34093-MBX-C16.mex07a.mlsrvr.co
	m>
Message-ID: <f06240801c83ec6058a41@[66.80.62.44]>

>Great, thanks for the info. My program now sets the 
>fPresentationTime with gettimeofday. I am now using openRTSP instead 
>of VLC and I have looked at the output file and that tells me that I 
>am sending too many frames. Basically, the output looks like I am 
>sending about 100 frames per 1 frame that I should be sending. I 
>think my problem is that my doGetNextFrame calls my deliverFrame 
>function everytime, even if there isn't a frame ready. If a frame 
>isn't ready and I just simply return from doGetNextFrame without 
>doing anything then doGetNextFrame is never called again. Is there a 
>way to tell the program to call doGetNextFrame when a frame is ready?

This is a common question (I really need to add it to the FAQ :-)

See <http://lists.live555.com/pipermail/live-devel/2008-December/009996.html>
-- 

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

From finlayson at live555.com  Wed Jun 16 15:11:58 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 16 Jun 2010 15:11:58 -0700
Subject: [Live-devel] liveMedia and CMake
In-Reply-To: <007e01cb0d6f$1eff4d50$5cfde7f0$@timenkov@itv.ru>
References: <007e01cb0d6f$1eff4d50$5cfde7f0$@timenkov@itv.ru>
Message-ID: <f06240803c83ef700e0b9@[66.80.62.44]>

>Are there any ideological objections against CMake?

No.

The only problem I have with using "CMake" (or something like it) is 
that it would impose a small burden (i.e., having to download and 
install a new utility) on most developers who use this software 
(those who develop for Unix/Posix/Linux/MacOS systems), merely 
because Microsoft apparently decided - a few years ago - to make it 
difficult for Windows developers to use "Makefiles", despite the fact 
that "Makefiles" have been the standard software configuration 
mechanism for 30 years now.

But here's what I'll do: I'll poll this mailing list to get a feel 
what people prefer, and I'll use the results of the poll (in about a 
week) to help make a decision.


So, if you're a developer who uses the "LIVE555 Streaming Media" 
software, please send email to
	support at live555.com
(*not* to this mailing list), with the following Subject: line
	CMake poll: <N>
Where <N> is one of the following:
	-1	I'm happy with the existing "genMakefiles" mechanism, 
and don't want to change.
	0	I develop only for Unix/Posix/Linux/MacOS systems, 
but would not mind switching to using "CMake" instead of the 
"genMakefiles" script.
	1	I develop for Windows (or something else other than 
Unix/Posix/Linux/MacOS), and would prefer to start using "CMake".
	2	I would prefer to switch to using something else, but 
not "CMake".  (If so, please say - in the body of your email - what 
you would prefer to use.)

The body of your email can be empty (unless you choose option 2).


Note: I will count responses only if
	- The response is sent to "support at live555.com", *not* to 
this mailing list, and
	- The email's "From:" address is that of a subscriber to the 
mailing list, and
	- This email address is a professional email address (i.e., 
not "@hotmail", "@aol", "@gmail", "@yahoo", etc.)

Any other responses *will* be ignored.
-- 

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

From jmigdal at gmail.com  Wed Jun 16 16:09:43 2010
From: jmigdal at gmail.com (Joshua Migdal)
Date: Wed, 16 Jun 2010 19:09:43 -0400
Subject: [Live-devel] liveMedia and CMake
In-Reply-To: <f06240803c83ef700e0b9@66.80.62.44>
References: <f06240803c83ef700e0b9@66.80.62.44>
Message-ID: <AANLkTilkhg-Rng6b1e2FojyBFvVYhfvhlcNcEcirm21n@mail.gmail.com>

You can use makefiles just fine in windows. nmake -f <makefile>.

But with that said, I prefer to use Visual Studio projects instead of
makefiles for my build environment. Making a visual studio project for
live555 was very easy. I'll post mine to this list (or wherever
appropriate) after I clean it up and make it suitable for distribution
along with the standard live555 checkout.

Josh


On Wed, Jun 16, 2010 at 6:11 PM, Ross Finlayson <finlayson at live555.com> wrote:
>> Are there any ideological objections against CMake?
>
> No.
>
> The only problem I have with using "CMake" (or something like it) is that it
> would impose a small burden (i.e., having to download and install a new
> utility) on most developers who use this software (those who develop for
> Unix/Posix/Linux/MacOS systems), merely because Microsoft apparently decided
> - a few years ago - to make it difficult for Windows developers to use
> "Makefiles", despite the fact that "Makefiles" have been the standard
> software configuration mechanism for 30 years now.
>
> But here's what I'll do: I'll poll this mailing list to get a feel what
> people prefer, and I'll use the results of the poll (in about a week) to
> help make a decision.
>
>
> So, if you're a developer who uses the "LIVE555 Streaming Media" software,
> please send email to
> ? ? ? ?support at live555.com
> (*not* to this mailing list), with the following Subject: line
> ? ? ? ?CMake poll: <N>
> Where <N> is one of the following:
> ? ? ? ?-1 ? ? ?I'm happy with the existing "genMakefiles" mechanism, and
> don't want to change.
> ? ? ? ?0 ? ? ? I develop only for Unix/Posix/Linux/MacOS systems, but would
> not mind switching to using "CMake" instead of the "genMakefiles" script.
> ? ? ? ?1 ? ? ? I develop for Windows (or something else other than
> Unix/Posix/Linux/MacOS), and would prefer to start using "CMake".
> ? ? ? ?2 ? ? ? I would prefer to switch to using something else, but not
> "CMake". ?(If so, please say - in the body of your email - what you would
> prefer to use.)
>
> The body of your email can be empty (unless you choose option 2).
>
>
> Note: I will count responses only if
> ? ? ? ?- The response is sent to "support at live555.com", *not* to this
> mailing list, and
> ? ? ? ?- The email's "From:" address is that of a subscriber to the mailing
> list, and
> ? ? ? ?- This email address is a professional email address (i.e., not
> "@hotmail", "@aol", "@gmail", "@yahoo", etc.)
>
> Any other responses *will* be ignored.
> --
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>


From finlayson at live555.com  Wed Jun 16 17:15:43 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 16 Jun 2010 17:15:43 -0700
Subject: [Live-devel] liveMedia and CMake
In-Reply-To: <AANLkTilkhg-Rng6b1e2FojyBFvVYhfvhlcNcEcirm21n@mail.gmail.com>
References: <f06240803c83ef700e0b9@66.80.62.44>
	<AANLkTilkhg-Rng6b1e2FojyBFvVYhfvhlcNcEcirm21n@mail.gmail.com>
Message-ID: <f06240802c83f18b531c3@[66.80.62.44]>

>Making a visual studio project for
>live555 was very easy. I'll post mine to this list (or wherever
>appropriate) after I clean it up and make it suitable for distribution
>along with the standard live555 checkout.

Feel free.  However, we will not be distributing a "Visual Studio 
Project" on our web site, because it is specific to one particular 
proprietary development system (and one specific OS).  (Also, it 
would need to change whenever we added or removed new source or 
header files.)

The only thing that we will be distributing will be 
OS/platform-independent configuration files (like the current 
"Makefile.tail" files and the "genMakefiles" script - or perhaps 
CMake configuration files if we end up going that route in the 
future).
-- 

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

From waazimreza at gmail.com  Wed Jun 16 18:01:58 2010
From: waazimreza at gmail.com (Waazim Reza)
Date: Wed, 16 Jun 2010 21:01:58 -0400
Subject: [Live-devel] Fwd: Doubts Regarding Running Test*Streamer.cpp
In-Reply-To: <mailman.1685.1276735591.852.live-devel@lists.live555.com>
References: <mailman.1685.1276735591.852.live-devel@lists.live555.com>
Message-ID: <AANLkTincAeGBuB1CRWvLy6_xNEywCun7WNcWq4OFaGky@mail.gmail.com>

Hello,

I am Waazim Reza, a Master's student from Florida Atlantic University.
I had few doubts regarding using LiveMedia Sever and the sample
applications.
I am running a windows machine with visual studio 2005 on it. After a few
attempts, I am able to successfully build and compile the code.
However I have many doubts.
1. I am able to run only the testOnDemandRTSPServer.cpp, I successfully
streamed an .m4e , .mpg 2 file and audio files(mp3,amr,wav). But am not able
to run any test*Streamer.cpp
2. I went through the FAQ and I still feel that this question is not
covered: I have a YUV file that has to be streamed to another PC. How will I
do that?



Thanks a lot.
Please reply to my questions as I am struggling with Live555.

Regards,
Waazim Reza
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100616/7b70b8f2/attachment.html>

From braitmaier at hlrs.de  Thu Jun 17 00:38:34 2010
From: braitmaier at hlrs.de (Michael Braitmaier)
Date: Thu, 17 Jun 2010 09:38:34 +0200
Subject: [Live-devel] liveMedia and CMake
In-Reply-To: <f06240803c83ef700e0b9@[66.80.62.44]>
References: <007e01cb0d6f$1eff4d50$5cfde7f0$@timenkov@itv.ru>
	<f06240803c83ef700e0b9@[66.80.62.44]>
Message-ID: <4C19D0FA.7030302@hlrs.de>

I just stumbled across this discussion and have to say that I am using 
CMake for over a year now with LiveMedia after assembling the necessary 
CMake files. It works like a charm in contrast to the previous system.
This is mostly caused by the fact that I have to target both Linux and 
Windows environments and for such a case in my opinion there is nothing 
better suited than CMake. Besides it provides perfect means for creating 
install versions of live media that I can easily package and distribute 
as runtimes (yet still leaving out the mechanisms for RPM generation).
I really consider having a GUI for configuring my compile environment a 
big plus, but this might be the case because I am originally a Windows 
guy ( blame me for that if you like ;-)

My 2 cents.

Best Regards,
Michael



Am 17.06.2010 00:11, schrieb Ross Finlayson:
>> Are there any ideological objections against CMake?
>
> No.
>
> The only problem I have with using "CMake" (or something like it) is 
> that it would impose a small burden (i.e., having to download and 
> install a new utility) on most developers who use this software (those 
> who develop for Unix/Posix/Linux/MacOS systems), merely because 
> Microsoft apparently decided - a few years ago - to make it difficult 
> for Windows developers to use "Makefiles", despite the fact that 
> "Makefiles" have been the standard software configuration mechanism 
> for 30 years now.
>
> But here's what I'll do: I'll poll this mailing list to get a feel 
> what people prefer, and I'll use the results of the poll (in about a 
> week) to help make a decision.
>
>
> So, if you're a developer who uses the "LIVE555 Streaming Media" 
> software, please send email to
>     support at live555.com
> (*not* to this mailing list), with the following Subject: line
>     CMake poll: <N>
> Where <N> is one of the following:
>     -1    I'm happy with the existing "genMakefiles" mechanism, and 
> don't want to change.
>     0    I develop only for Unix/Posix/Linux/MacOS systems, but would 
> not mind switching to using "CMake" instead of the "genMakefiles" script.
>     1    I develop for Windows (or something else other than 
> Unix/Posix/Linux/MacOS), and would prefer to start using "CMake".
>     2    I would prefer to switch to using something else, but not 
> "CMake".  (If so, please say - in the body of your email - what you 
> would prefer to use.)
>
> The body of your email can be empty (unless you choose option 2).
>
>
> Note: I will count responses only if
>     - The response is sent to "support at live555.com", *not* to this 
> mailing list, and
>     - The email's "From:" address is that of a subscriber to the 
> mailing list, and
>     - This email address is a professional email address (i.e., not 
> "@hotmail", "@aol", "@gmail", "@yahoo", etc.)
>
> Any other responses *will* be ignored.


From dlee at numirabio.com  Thu Jun 17 10:39:18 2010
From: dlee at numirabio.com (Dillon Lee)
Date: Thu, 17 Jun 2010 12:39:18 -0500
Subject: [Live-devel] Live streaming mpeg1or2
Message-ID: <17207CD959E5874196B8A8438794453C1843A72D64@34093-MBX-C16.mex07a.mlsrvr.com>

Thanks for the reply, I think I have the doGetNextFrame working properly now but I am having problems with playback. I have been using VLC and openRTSP to view my output. When I use openRTSP to save the stream to a file, it play super-fast. When I use VLC I can see the video but it's pretty choppy and jumpy. Is it possible that I'm not setting fPresentationTime properly?

gettimeofday(&fPresentationTime, 0 )

Since this is a live stream is there anything else that the RTSP protocol might need or do you think this is purely an ffmpeg encoding problem?

Thanks again,
Dillon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100617/19c3d314/attachment.html>

From finlayson at live555.com  Thu Jun 17 18:38:40 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 17 Jun 2010 18:38:40 -0700
Subject: [Live-devel] Live streaming mpeg1or2
In-Reply-To: <17207CD959E5874196B8A8438794453C1843A72D64@34093-MBX-C16.mex07a.mlsrvr.co
	m>
References: <17207CD959E5874196B8A8438794453C1843A72D64@34093-MBX-C16.mex07a.mlsrvr.co
	m>
Message-ID: <f06240801c8407d9cd98c@[66.80.62.44]>

>Thanks for the reply, I think I have the doGetNextFrame working 
>properly now but I am having problems with playback. I have been 
>using VLC and openRTSP to view my output. When I use openRTSP to 
>save the stream to a file, it play super-fast.

What do you mean by "play super-fast"?  Do you mean that "openRTSP" 
writes the incoming stream to a file at a rate faster than 'real 
time'?  If that's true, then you don't have a live data source, and 
therefore you *must* set "fDurationInMicroseconds" for each frame.


>  When I use VLC I can see the video but it's pretty choppy and 
>jumpy. Is it possible that I'm not setting fPresentationTime 
>properly?
>
>gettimeofday(&fPresentationTime, 0 )

That's correct.

>
>Since this is a live stream is there anything else that the RTSP 
>protocol might need or do you think this is purely an ffmpeg 
>encoding problem?

If "openRTSP" is recording your stream properly, but VLC is not 
playing it properly, then you will need to ask about this on a VLC 
mailing list.
-- 

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

From sebastien-devel at celeos.eu  Thu Jun 17 23:51:37 2010
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Fri, 18 Jun 2010 08:51:37 +0200
Subject: [Live-devel] regression in live555 connecting an acti camera
Message-ID: <1276843897.4c1b1779acc53@imp.celeos.eu>



Hi,

I can't connect anymore to an acti camera using latest version of live555.
I don't know since which version exactly it doesn't work.

1- output of new version not working :
http://www.celeos.eu/tmp/notworking.txt

2- output of an old working version :
http://www.celeos.eu/tmp/working.txt

Regards,
Seb.


From sebastien-devel at celeos.eu  Fri Jun 18 01:26:08 2010
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Fri, 18 Jun 2010 10:26:08 +0200
Subject: [Live-devel] regression in live555 connecting an acti camera
In-Reply-To: <1276843897.4c1b1779acc53@imp.celeos.eu>
References: <1276843897.4c1b1779acc53@imp.celeos.eu>
Message-ID: <1276849568.4c1b2da04aae9@imp.celeos.eu>

Quoting S?bastien Escudier <sebastien-devel at celeos.eu>:
> I can't connect anymore to an acti camera using latest version of live555.

I found another camera not working anymore with live555. It's a sanyo.
The issue seems different.

log of latest version not working :
http://www.celeos.eu/tmp/sanyo_notworking.txt

log of an old working version :
http://www.celeos.eu/tmp/sanyo_working.txt


From finlayson at live555.com  Fri Jun 18 02:04:18 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 18 Jun 2010 02:04:18 -0700
Subject: [Live-devel] regression in live555 connecting an acti camera
In-Reply-To: <1276849568.4c1b2da04aae9@imp.celeos.eu>
References: <1276843897.4c1b1779acc53@imp.celeos.eu>
	<1276849568.4c1b2da04aae9@imp.celeos.eu>
Message-ID: <f06240801c840e57fbfe0@[66.80.62.44]>

>I found another camera not working anymore with live555. It's a sanyo.
>The issue seems different.

Yes, it was easy to figure out the problem with the Sanyo camera; it 
was (quite rightfully) complaining because we didn't change the 
"CSeq" number when we retransmitted the DESCRIBE request following 
the initial authorization failure.

This will be fixed shortly.

The first problem (with the "acti" camera) seems less obvious.  I'll 
take a closer look at it later today.  (If you could make available a 
publically-accessible "rtsp://" URL for one of these cameras, it 
would help a lot in debugging the problem.)

Thanks for reporting these problems.
-- 

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

From yuri.timenkov at itv.ru  Fri Jun 18 02:18:41 2010
From: yuri.timenkov at itv.ru (Yuri Timenkov)
Date: Fri, 18 Jun 2010 13:18:41 +0400
Subject: [Live-devel] regression in live555 connecting an acti camera
In-Reply-To: <1276849568.4c1b2da04aae9@imp.celeos.eu>
References: <1276843897.4c1b1779acc53@imp.celeos.eu>
	<1276849568.4c1b2da04aae9@imp.celeos.eu>
Message-ID: <010c01cb0ec7$3e471e00$bad55a00$@timenkov@itv.ru>

May be it is because in "notworking" case request is resent with the same CSeq? Seems that RTSPClient doesn't touch cseq.

Also I noticed that that sendPauseCommand for SubSession sends "PLAY". Is it copy/paste error?

> -----Original Message-----
> From: live-devel-bounces at ns.live555.com [mailto:live-devel-
> bounces at ns.live555.com] On Behalf Of S?bastien Escudier
> Sent: Friday, June 18, 2010 12:26 PM
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live-devel] regression in live555 connecting an acti
> camera
> 
> Quoting S?bastien Escudier <sebastien-devel at celeos.eu>:
> > I can't connect anymore to an acti camera using latest version of
> live555.
> 
> I found another camera not working anymore with live555. It's a sanyo.
> The issue seems different.
> 
> log of latest version not working :
> http://www.celeos.eu/tmp/sanyo_notworking.txt
> 
> log of an old working version :
> http://www.celeos.eu/tmp/sanyo_working.txt
> 
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel



From david.stegbauer at acision.com  Fri Jun 18 03:10:31 2010
From: david.stegbauer at acision.com (David Stegbauer)
Date: Fri, 18 Jun 2010 12:10:31 +0200
Subject: [Live-devel] How to contribute code?
Message-ID: <201006181210.31991.david.stegbauer@acision.com>

Hello,

I use live555 library for some internal testing. I would like to contribute 
code back to you. What is the best (preferred) way to do it?

I was also not able to find any public git or svn repository for live555. Could 
you consider to make one? There are many free git hosting sites and it would 
really help even if you put there just the releases and make it read-only.

Best Regards
David Stegbauer

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.



From finlayson at live555.com  Fri Jun 18 07:03:40 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 18 Jun 2010 07:03:40 -0700
Subject: [Live-devel] regression in live555 connecting an acti camera
In-Reply-To: <010c01cb0ec7$3e471e00$bad55a00$@timenkov@itv.ru>
References: <1276843897.4c1b1779acc53@imp.celeos.eu>
	<1276849568.4c1b2da04aae9@imp.celeos.eu>
	<010c01cb0ec7$3e471e00$bad55a00$@timenkov@itv.ru>
Message-ID: <f06240802c8412cf7d9d3@[66.80.62.44]>

>May be it is because in "notworking" case request is resent with the 
>same CSeq?

Yes, that was the problem with the "Sony" camera.


>Also I noticed that that sendPauseCommand for SubSession sends 
>"PLAY". Is it copy/paste error?

Yes, but that has already been fixed in the latest version of the code.
-- 

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

From sebastien-devel at celeos.eu  Fri Jun 18 07:13:25 2010
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Fri, 18 Jun 2010 16:13:25 +0200
Subject: [Live-devel] How to contribute code?
In-Reply-To: <201006181210.31991.david.stegbauer@acision.com>
References: <201006181210.31991.david.stegbauer@acision.com>
Message-ID: <1276870405.4c1b7f057adce@imp.celeos.eu>

Quoting David Stegbauer <david.stegbauer at acision.com>:

> I was also not able to find any public git or svn repository for live555.
> Could
> you consider to make one? There are many free git hosting sites and it would
> really help even if you put there just the releases and make it read-only.

I agree this idea. It would make testing for regressions easier, like the ones I
found recently.
It's also nice to track changes between versions.
And finally it would be easier to send you patches.


From finlayson at live555.com  Fri Jun 18 07:18:24 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 18 Jun 2010 07:18:24 -0700
Subject: [Live-devel] How to contribute code?
In-Reply-To: <201006181210.31991.david.stegbauer@acision.com>
References: <201006181210.31991.david.stegbauer@acision.com>
Message-ID: <f06240803c84130359c83@[66.80.62.44]>

>I use live555 library for some internal testing. I would like to contribute
>code back to you. What is the best (preferred) way to do it?

If it's a (reasonably small) 'patch' file, then you could just post 
it to this mailing list.

Otherwise, you could make code contributions available on a 
(publically-accessible) web server, and post the URL to the mailing 
list.


>I was also not able to find any public git or svn repository for 
>live555. Could
>you consider to make one?

No.  We make available - and provide support for - the most recent 
version of the code only.
-- 

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

From finlayson at live555.com  Fri Jun 18 08:37:23 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 18 Jun 2010 08:37:23 -0700
Subject: [Live-devel] regression in live555 connecting an acti camera
In-Reply-To: <1276843897.4c1b1779acc53@imp.celeos.eu>
References: <1276843897.4c1b1779acc53@imp.celeos.eu>
Message-ID: <f06240807c84142b4f1ed@[66.80.62.44]>

>I can't connect anymore to an acti camera using latest version of live555.
>I don't know since which version exactly it doesn't work.
>
>1- output of new version not working :
>http://www.celeos.eu/tmp/notworking.txt
>
>2- output of an old working version :
>http://www.celeos.eu/tmp/working.txt


OK, I found the problem with this camera: It is sending back a bad 
"Range:" header in its response to the RTSP "PLAY" command:
	Range: ntp=0.000-
This is wrong.  It should be "npt", not "ntp".

You should contact the camera's manufacturer, asking them to fix 
their camera's RTSP server.

By the way, you were incorrect when you said that a previous version 
of our code (2009.07.27, according to your "working.txt" log) handled 
this camera correctly.  As far as I can tell, we have *never* 
accepted a "Range:" header that says "ntp" instead of "npt".  You 
must have hacked your own version of the code to accept this (broken) 
"Range:" header, and then forgotten about it.

(The Sanyo camera, however, was behaving correctly.  I have now 
installed a new version (2010.06.18) of our code that will support it 
once again.  This new version also prints a more meaningful error 
when it sees the bad "Range:" line returned by the "acti" camera.)
-- 

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

From sebastien-devel at celeos.eu  Fri Jun 18 08:51:54 2010
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Fri, 18 Jun 2010 17:51:54 +0200
Subject: [Live-devel] regression in live555 connecting an acti camera
In-Reply-To: <f06240807c84142b4f1ed@[66.80.62.44]>
References: <1276843897.4c1b1779acc53@imp.celeos.eu>
	<f06240807c84142b4f1ed@[66.80.62.44]>
Message-ID: <1276876314.4c1b961ad0e0e@imp.celeos.eu>

Quoting Ross Finlayson <finlayson at live555.com>:

> You should contact the camera's manufacturer, asking them to fix
> their camera's RTSP server.

Thank you for investigating it, I'll contact them.

> By the way, you were incorrect when you said that a previous version
> of our code (2009.07.27, according to your "working.txt" log) handled
> this camera correctly.  As far as I can tell, we have *never*
> accepted a "Range:" header that says "ntp" instead of "npt".  You
> must have hacked your own version of the code to accept this (broken)
> "Range:" header, and then forgotten about it.

I have never modified live555 to handle this. Maybe the npt was not handled
correctly, but at least, with some older versions, the play didn't fail with an
error.



From finlayson at live555.com  Fri Jun 18 12:43:43 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 18 Jun 2010 12:43:43 -0700
Subject: [Live-devel] regression in live555 connecting an acti camera
In-Reply-To: <1276876314.4c1b961ad0e0e@imp.celeos.eu>
References: <1276843897.4c1b1779acc53@imp.celeos.eu>
	<f06240807c84142b4f1ed@[66.80.62.44]>
	<1276876314.4c1b961ad0e0e@imp.celeos.eu>
Message-ID: <f06240808c8417b53b314@[66.80.62.44]>

>  > You should contact the camera's manufacturer, asking them to fix
>>  their camera's RTSP server.
>
>Thank you for investigating it, I'll contact them.

With luck, they'll have a firmware upgrade already available...


>  > By the way, you were incorrect when you said that a previous version
>>  of our code (2009.07.27, according to your "working.txt" log) handled
>>  this camera correctly.  As far as I can tell, we have *never*
>>  accepted a "Range:" header that says "ntp" instead of "npt".  You
>>  must have hacked your own version of the code to accept this (broken)
>>  "Range:" header, and then forgotten about it.
>
>I have never modified live555 to handle this. Maybe the npt was not handled
>correctly, but at least, with some older versions, the play didn't 
>fail with an
>error.

Yes, I was mistaken about this.  Although the code that checks the 
"Range:" header has not changed in a long time, it turns out that - 
in old versions of "RTSPClient" - we were silently ignoring "Range:" 
headers - like this one - that were malformed.  In our recent new 
"RTSPClient" implementation we started reporting malformed headers as 
errors - which happened to catch the bug in this camera server.
-- 

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

From yinhua.li at siemens.com  Fri Jun 18 21:53:47 2010
From: yinhua.li at siemens.com (Li, Yin Hua SLC CT NKG S)
Date: Sat, 19 Jun 2010 12:53:47 +0800
Subject: [Live-devel] File source is socket stream in RTSPServer
Message-ID: <68D227E48F4B0F4EB6161523402601BE5357C5@PEKW987A.cn001.siemens.net>

Dear All,
       First, I'm appreciate you can view my post and give me a detailed
solution. My English is not very good, so if my description is not
clear, pls let me know, thanks a lot~
       Now, I have a project about IP camera, the output from camera was
encoded by hardware to MPEG4, and this encoded stream is transferred by
socket to RTSPServer(using live555 libraries). 
       Currently, my solution is based on "testMPEG4VideoStreamer.cpp",
just modified the filesource in method 'play', code is:
    void play() {
 
  char* inputAddressStr = "0.0.0.0";
  struct in_addr inputAddress;
  inputAddress.s_addr = our_inet_addr(inputAddressStr);
 
  const Port inputPort(6666);
  unsigned char const inputTTL = 0; 
 
  inputGroupsock = new Groupsock(*env, inputAddress, inputPort,
inputTTL);


  // Then create a liveMedia 'source' object, encapsulating this
groupsock:
  FramedSource* videoES = BasicUDPSource::createNew(*env,
inputGroupsock);
 
  //FramedSource* videoES = fileSource;
 
  // Create a framer for the Video Elementary Stream:
  videoSource = MPEG4VideoStreamDiscreteFramer::createNew(*env,
videoES);
 
  // Finally, start playing:
  *env << "Beginning to read from sock...\n";
  videoSink->startPlaying(*videoSource, afterPlaying, videoSink);
}
        
       It's can work correctly, but this is via multicast, Our customer
want unicast. So I follow "testOnDemandRTSPServer.cpp", 
but this module wrapped how to get file source in method "doEventLoop",
and it seems that not support read socket as file source, because 
my file source isn't a local file, so I don't know how to get my socket
file source. If you know or have this experience, pls tell me, Thanks~ 
 
Best regards.
Li Yinhua
 


IMPORTANT NOTE: This e-mail and any attachment are confidential and may contain trade secrets and may also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are herewith informed about its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your system. You are prohibited from making use of or copying this e-mail or any attachment or disclosing the contents to any other person.

In case you become aware of any unethical business behavior or violation of laws, particularly those against the Anti-corruption laws and Anti-trust laws, Siemens Compliance HelpDesk "Tell us" can be reached at www.siemens.com.cn/compliancehelpdesk

<Disclaimer in Chinese below, characters may not be displayed correctly.>

????:???????????,???????????????????????????,????????????,?????????????????????????????????????,??????????????????????????????
?????????????????,?????????????????,????????????"Tell us"??,???www.siemens.com.cn/compliancehelpdesk


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

From finlayson at live555.com  Sat Jun 19 00:28:55 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 19 Jun 2010 00:28:55 -0700
Subject: [Live-devel] File source is socket stream in RTSPServer
In-Reply-To: <68D227E48F4B0F4EB6161523402601BE5357C5@PEKW987A.cn001.siemens.net>
References: <68D227E48F4B0F4EB6161523402601BE5357C5@PEKW987A.cn001.siemens.net>
Message-ID: <f06240800c842217b763c@[66.80.62.44]>

>        It's can work correctly, but this is via multicast, Our 
>customer want unicast. So I follow "testOnDemandRTSPServer.cpp",
>but this module wrapped how to get file source in method 
>"doEventLoop", and it seems that not support read socket as file 
>source, because 
>my file source isn't a local file, so I don't know how to get my 
>socket file source. If you know or have this experience, pls tell 
>me, Thanks~ 

See the following FAQ entry: 
http://www.live555.com/liveMedia/faq.html#liveInput-unicast
I think this will help you with your application.

If your input device is a socket, then you should be able to 
encapsulate it in a "FramedSource" subclass that uses the 
"DeviceSource.cpp" code as a model, and use 
"TaskScheduler::turnOnBackgroundReadHandling()" to schedule a handler 
that reads from the socket whenever new data arrives.   (Note the 
comments in "liveMedia/DeviceSource.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/20100619/284bae7a/attachment.html>

From yinhua.li at siemens.com  Sat Jun 19 01:29:23 2010
From: yinhua.li at siemens.com (Li, Yin Hua SLC CT NKG S)
Date: Sat, 19 Jun 2010 16:29:23 +0800
Subject: [Live-devel] File source is socket stream in RTSPServer
In-Reply-To: <f06240800c842217b763c@[66.80.62.44]>
References: <68D227E48F4B0F4EB6161523402601BE5357C5@PEKW987A.cn001.siemens.net>
	<f06240800c842217b763c@[66.80.62.44]>
Message-ID: <68D227E48F4B0F4EB6161523402601BE5357D2@PEKW987A.cn001.siemens.net>

Thanks, I have seen the FAQ you provided, I have to encapsulate it, it's
very complicated for me. so would you pls give me a step by step
instructions.
 
Detail of my socket:Port(6666)
bitrates:500
 
Thanks again~

________________________________

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Saturday, June 19, 2010 3:29 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] File source is socket stream in RTSPServer



	       It's can work correctly, but this is via multicast, Our
customer want unicast. So I follow "testOnDemandRTSPServer.cpp",

	but this module wrapped how to get file source in method
"doEventLoop", and it seems that not support read socket as file source,
because 

	my file source isn't a local file, so I don't know how to get my
socket file source. If you know or have this experience, pls tell me,
Thanks~ 


See the following FAQ entry:
http://www.live555.com/liveMedia/faq.html#liveInput-unicast
I think this will help you with your application.

If your input device is a socket, then you should be able to encapsulate
it in a "FramedSource" subclass that uses the "DeviceSource.cpp" code as
a model, and use "TaskScheduler::turnOnBackgroundReadHandling()" to
schedule a handler that reads from the socket whenever new data arrives.
(Note the comments in "liveMedia/DeviceSource.cpp")
-- 

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


IMPORTANT NOTE: This e-mail and any attachment are confidential and may contain trade secrets and may also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are herewith informed about its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your system. You are prohibited from making use of or copying this e-mail or any attachment or disclosing the contents to any other person.

In case you become aware of any unethical business behavior or violation of laws, particularly those against the Anti-corruption laws and Anti-trust laws, Siemens Compliance HelpDesk "Tell us" can be reached at www.siemens.com.cn/compliancehelpdesk

<Disclaimer in Chinese below, characters may not be displayed correctly.>

????:???????????,???????????????????????????,????????????,?????????????????????????????????????,??????????????????????????????
?????????????????,?????????????????,????????????"Tell us"??,???www.siemens.com.cn/compliancehelpdesk


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

From jnoring at logitech.com  Mon Jun 21 08:17:00 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Mon, 21 Jun 2010 08:17:00 -0700
Subject: [Live-devel] How to contribute code?
In-Reply-To: <f06240803c84130359c83@66.80.62.44>
References: <201006181210.31991.david.stegbauer@acision.com>
	<f06240803c84130359c83@66.80.62.44>
Message-ID: <AANLkTinxmob3m8yR8CJmMid8uzgpzKW4bNTKASi7F8R1@mail.gmail.com>

On Fri, Jun 18, 2010 at 7:18 AM, Ross Finlayson <finlayson at live555.com>wrote:

> I was also not able to find any public git or svn repository for live555.
>> Could
>> you consider to make one?
>>
>
> No.  We make available - and provide support for - the most recent version
> of the code only.
>

Just because you use source control doesn't mean you have to support any
random release of the code.  Almost no open source projects I know function
this way; there are clear releases and supported versions.  Is there some
other reason you're opposed to public source code?  It's really difficult
not having a history of changes made (and a changelog is a poor substitute
for source control history), or being able to roll back the library to a
previous version to locate regression.

My $0.02: if you've gone this long without source control, then I don't
expect you're about to change, but you should really reconsider this
decision at some point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100621/6ba8f024/attachment.html>

From kenneth at ljungh.net  Mon Jun 21 13:09:37 2010
From: kenneth at ljungh.net (Kenneth Ljungh)
Date: Mon, 21 Jun 2010 22:09:37 +0200
Subject: [Live-devel] openRTSP segfault on max osx
Message-ID: <CE42D5A0-66C1-4015-9B28-E1565E6CC034@ljungh.net>

Hi

running openRTSP -q -w 704 -h 576 rtsp://192.168.0.101/axis-media/media.amp >test.mov  & 
and sending kill -HUP sometimes ends with a segfault. This is with live555 2010.06.18 but I didn't see this with 2010.04.09

Regards

Kenneth

crash log:

Code Type:       X86-64 (Native)
Parent Process:  bash [17661]

Date/Time:       2010-06-21 20:55:29.059 +0200
OS Version:      Mac OS X 10.6.4 (10F569)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib             	0x00007fffffe00800 __memcpy + 96
1   libSystem.B.dylib             	0x00007fff846e51ae __sfvwrite + 429
2   libSystem.B.dylib             	0x00007fff84736579 fwrite + 128
3   openRTSP                      	0x000000010002253f SubsessionIOState::useFrame(SubsessionBuffer&) + 529
4   openRTSP                      	0x0000000100022f4a SubsessionIOState::afterGettingFrame(unsigned int, timeval) + 512
5   openRTSP                      	0x0000000100022fd9 QuickTimeFileSink::afterGettingFrame(void*, unsigned int, unsigned int, timeval, unsigned int) + 75
6   openRTSP                      	0x0000000100004ab7 FramedSource::afterGetting(FramedSource*) + 59
7   openRTSP                      	0x000000010000e056 MultiFramedRTPSource::doGetNextFrame1() + 532
8   openRTSP                      	0x000000010000e34c MultiFramedRTPSource::networkReadHandler(MultiFramedRTPSource*, int) + 670
9   openRTSP                      	0x000000010002b8a8 BasicTaskScheduler::SingleStep(unsigned int) + 666
10  openRTSP                      	0x000000010002acd8 BasicTaskScheduler0::doEventLoop(char*) + 38
11  openRTSP                      	0x0000000100018630 RTSPClient::teardownMediaSession(MediaSession&) + 68
12  openRTSP                      	0x00000001000016e6 clientTearDownSession(Medium*, MediaSession*) + 26
13  openRTSP                      	0x0000000100002428 tearDownStreams() + 28
14  openRTSP                      	0x00000001000024b4 shutdown(int) + 138
15  openRTSP                      	0x00000001000024f5 signalHandlerShutdown(int) + 34
16  libSystem.B.dylib             	0x00007fff8473335a _sigtramp + 26
17  libSystem.B.dylib             	0x00007fff84716dce select$DARWIN_EXTSN + 10
18  openRTSP                      	0x000000010002b708 BasicTaskScheduler::SingleStep(unsigned int) + 250
19  openRTSP                      	0x000000010002acd8 BasicTaskScheduler0::doEventLoop(char*) + 38
20  openRTSP                      	0x0000000100004344 main + 5841
21  openRTSP                      	0x00000001000016c4 start + 52




From finlayson at live555.com  Mon Jun 21 19:50:01 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 21 Jun 2010 19:50:01 -0700
Subject: [Live-devel] How to contribute code?
In-Reply-To: <AANLkTinxmob3m8yR8CJmMid8uzgpzKW4bNTKASi7F8R1@mail.gmail.com>
References: <201006181210.31991.david.stegbauer@acision.com>
	<f06240803c84130359c83@66.80.62.44>
	<AANLkTinxmob3m8yR8CJmMid8uzgpzKW4bNTKASi7F8R1@mail.gmail.com>
Message-ID: <f06240802c845d0de604c@[66.80.62.44]>

I don't use any revision control system myself.  When I'm developing 
this code, I use exactly two commands: "emacs" and "make".

Each source code release - in "tar.gz" form - is less than 500 kBytes 
in size.  These days, that's not a significant amount of data to 
download in order to get the latest revision, and any bandwidth 
savings obtained by downloading from a revision control system 
instead would be insignificant.  And people should not be using any 
version of the code other than the latest one, because that's all 
that we support.

I suspect that the real reason why some people want to use a revision 
control system is that they want to easily update to the latest 
version of the code after they've made custom modifications to it 
(i.e., without losing their modifications).  I'm sorry, but this is 
something that I explicitly want to discourage.  People *should not* 
be making modifications to the released "LIVE555 Streaming Media" 
code (i.e., inside the "live" directory).  Instead, they should be 
leaving that directory as it is, and instead putting their own code 
in a separate directory (using subclassing, if necessary).

If there are parts of the code that make it difficult for people to 
customize via subclassing - e.g., some class members that should be 
"protected:" instead of "private:", then please let us know.
-- 

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

From finlayson at live555.com  Mon Jun 21 23:21:53 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 21 Jun 2010 23:21:53 -0700
Subject: [Live-devel] openRTSP segfault on max osx
In-Reply-To: <CE42D5A0-66C1-4015-9B28-E1565E6CC034@ljungh.net>
References: <CE42D5A0-66C1-4015-9B28-E1565E6CC034@ljungh.net>
Message-ID: <f06240800c84603e8554b@[66.80.62.44]>

>running openRTSP -q -w 704 -h 576 
>rtsp://192.168.0.101/axis-media/media.amp >test.mov  &
>and sending kill -HUP sometimes ends with a segfault. This is with 
>live555 2010.06.18 but I didn't see this with 2010.04.09

Aha!  You've found a bug in the "openRTSP" code.  We're closing the 
output file(s) too soon.  (This bug turned out to be a problem only 
with the new "RTSPClient" implementation, because - in this new 
implementation - we go to the event loop (potentially handling 
incoming RTP data) while awaiting the response to the RTSP "TEARDOWN" 
command.)

Please try the following, which should fix this problem:

In "testProgs/playCommon.cpp", line 1104, move the statement
	closeMediaSinks();
down 5 lines, so that it now takes place after
	Medium::close(session);
-- 

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

From sebastien-devel at celeos.eu  Tue Jun 22 01:25:17 2010
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Tue, 22 Jun 2010 10:25:17 +0200
Subject: [Live-devel] regression in live555 connecting an acti camera
In-Reply-To: <f06240807c84142b4f1ed@[66.80.62.44]>
References: <1276843897.4c1b1779acc53@imp.celeos.eu>
	<f06240807c84142b4f1ed@[66.80.62.44]>
Message-ID: <1277195117.4c20736d0944f@imp.celeos.eu>

Quoting Ross Finlayson <finlayson at live555.com>:

> This is wrong.  It should be "npt", not "ntp".

I just found another camera not working anymore.
The error message is still about invalid range header, but this time npt is well
written.
It seems live555 doesn't accept "now-" :

Received 119 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK
CSeq: 5
Session: 0285612765
Range: npt=now-
RTP-Info: url=trackID=1;seq=1297;rtptime=2172096889


Failed to start playing session: Bad "Range:" header


From finlayson at live555.com  Tue Jun 22 01:39:25 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 22 Jun 2010 01:39:25 -0700
Subject: [Live-devel] regression in live555 connecting an acti camera
In-Reply-To: <1277195117.4c20736d0944f@imp.celeos.eu>
References: <1276843897.4c1b1779acc53@imp.celeos.eu>
	<f06240807c84142b4f1ed@[66.80.62.44]>
	<1277195117.4c20736d0944f@imp.celeos.eu>
Message-ID: <f0624080ac84626ca827f@[66.80.62.44]>

>I just found another camera not working anymore.
>The error message is still about invalid range header, but this time 
>npt is well
>written.
>It seems live555 doesn't accept "now-" :

OK, this is definitely a bug in our code, because "npt=now-" is 
legal, according to the RTSP specification.

This will be fixed in the next release.
-- 

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

From finlayson at live555.com  Tue Jun 22 02:26:58 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 22 Jun 2010 02:26:58 -0700
Subject: [Live-devel] openRTSP segfault on max osx
In-Reply-To: <f06240800c84603e8554b@[66.80.62.44]>
References: <CE42D5A0-66C1-4015-9B28-E1565E6CC034@ljungh.net>
	<f06240800c84603e8554b@[66.80.62.44]>
Message-ID: <f0624080cc846314df92c@[66.80.62.44]>

>Please try the following, which should fix this problem:
>
>In "testProgs/playCommon.cpp", line 1104, move the statement
>	closeMediaSinks();
>down 5 lines, so that it now takes place after
>	Medium::close(session);

It turns out that I didn't have this quite right.  The correct 
sequence of statements - starting at line 1104 - should be:

	tearDownStreams();
	closeMediaSinks();
	Medium::close(session);

I have now installed a new version (2010.06.22) of the code that 
fixes this bug (as well as Sebastien Escudier's latest "RTSPClient" 
bug).
-- 

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

From jens.binder at hhi.fraunhofer.de  Tue Jun 22 03:11:09 2010
From: jens.binder at hhi.fraunhofer.de (Jens Binder)
Date: Tue, 22 Jun 2010 12:11:09 +0200
Subject: [Live-devel] Speicherplatz
Message-ID: <hvq27t$mob$1@dough.gmane.org>

Zugangsdaten f?r den mmg-server1:

Username: ebel
Passwort: ebel

freier Platz auf /Datastore/public/ebel/

jens.


From david.stegbauer at acision.com  Tue Jun 22 05:30:57 2010
From: david.stegbauer at acision.com (David Stegbauer)
Date: Tue, 22 Jun 2010 14:30:57 +0200
Subject: [Live-devel] How to contribute code?
In-Reply-To: <f06240802c845d0de604c@[66.80.62.44]>
References: <201006181210.31991.david.stegbauer@acision.com>
	<AANLkTinxmob3m8yR8CJmMid8uzgpzKW4bNTKASi7F8R1@mail.gmail.com>
	<f06240802c845d0de604c@[66.80.62.44]>
Message-ID: <201006221430.57206.david.stegbauer@acision.com>

On Tuesday 22 June 2010 04:50:01 Ross Finlayson wrote:
> I don't use any revision control system myself.  When I'm developing
> this code, I use exactly two commands: "emacs" and "make".

Well, I see myself several years ago :-) Lately I have learned git and now I'm 
using it for every project. But it is just my personal opinion, no pressure to 
you.

> And people should not be using any
> version of the code other than the latest one, because that's all
> that we support.

Nobody obliges you to support anything you don't want to. OTOH Debian stable 
uses live.2007.02.20 (see http://packages.debian.org/lenny/livemedia-utils), 
and even Debian unstable is behind (2010.04.09).

> I suspect that the real reason why some people want to use a revision
> control system is that they want to easily update to the latest
> version of the code after they've made custom modifications to it
> (i.e., without losing their modifications).

Yes :-), at least in my case.
You are releasing new versions often. You also don't support anything but the 
newest. So I have to be in sync with you. I also don't want to lose my 
modifications which I'll contribute back when they are ready.

So I've settled with local git repository for now. In one branch I follow your 
releases, in the other I do my changes. It makes bit overhead, bit of 
discomfort and bit of fear I miss some release. But I can live with it.

I respect your decision regarding release strategy even if I think there are 
better ones. So thank you for the code, I'll prepare patches in next days to 
see if they are acceptable for you.

Best Regards
David Stegbauer

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.



From kenneth at ljungh.net  Tue Jun 22 11:21:20 2010
From: kenneth at ljungh.net (Kenneth Ljungh)
Date: Tue, 22 Jun 2010 20:21:20 +0200
Subject: [Live-devel] openRTSP segfault on max osx
In-Reply-To: <f0624080cc846314df92c@[66.80.62.44]>
References: <CE42D5A0-66C1-4015-9B28-E1565E6CC034@ljungh.net>
	<f06240800c84603e8554b@[66.80.62.44]>
	<f0624080cc846314df92c@[66.80.62.44]>
Message-ID: <5BDAA300-006C-4058-93C3-E8157187544C@ljungh.net>

22 jun 2010 kl. 11.26 skrev Ross Finlayson:

>> Please try the following, which should fix this problem:
>> 
>> In "testProgs/playCommon.cpp", line 1104, move the statement
>> 	closeMediaSinks();
>> down 5 lines, so that it now takes place after
>> 	Medium::close(session);
> 
> It turns out that I didn't have this quite right.  The correct sequence of statements - starting at line 1104 - should be:
> 
> 	tearDownStreams();
> 	closeMediaSinks();
> 	Medium::close(session);
> 
> I have now installed a new version (2010.06.22) of the code that fixes this bug (as well as Sebastien Escudier's latest "RTSPClient" bug).
> -- 
> 
> 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

Works perfectly. Thanks for your quick fix and effort, it's great software.

Kenneth



From finlayson at live555.com  Tue Jun 22 14:20:33 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 22 Jun 2010 14:20:33 -0700
Subject: [Live-devel] How to contribute code?
In-Reply-To: <201006221430.57206.david.stegbauer@acision.com>
References: <201006181210.31991.david.stegbauer@acision.com>
	<AANLkTinxmob3m8yR8CJmMid8uzgpzKW4bNTKASi7F8R1@mail.gmail.com>
	<f06240802c845d0de604c@[66.80.62.44]>
	<201006221430.57206.david.stegbauer@acision.com>
Message-ID: <f06240800c846d887f61e@[66.80.62.44]>

>  > I suspect that the real reason why some people want to use a revision
>>  control system is that they want to easily update to the latest
>>  version of the code after they've made custom modifications to it
>>  (i.e., without losing their modifications).
>
>Yes :-), at least in my case.
>You are releasing new versions often. You also don't support anything but the
>newest. So I have to be in sync with you. I also don't want to lose my
>modifications which I'll contribute back when they are ready.

If any of your "modifications" are bug fixes, then please share them 
with us ASAP.

However, if they're really just custom modifications for your 
environment (and are not of general applicability), then you should 
try to find a way to move them into your own code, rather than 
modifying the installed code.  (As I noted earlier, if there are 
modifications that we can make (e.g., "private:" -> "protected:") 
that can make that easier, let us know.)

-- 

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

From brilliantov at byterg.ru  Wed Jun 23 01:19:12 2010
From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich)
Date: Wed, 23 Jun 2010 12:19:12 +0400
Subject: [Live-devel] VLC can't decode MJPEG stream
Message-ID: <4C21C380.2040401@byterg.ru>

Hello!
I have used vlc 0.8.6h and 1.0.5 to watch MJPEG RTSP-stream.
I successfully connect to server, but I don't see image, I see green or
black square.

Information about stream:
$ openRTSP rtsp://192.168.10.253/jpeg
Opened URL "rtsp://192.168.10.253/jpeg", returning a SDP description:
v=0
o=- 8717677423 1 IN IP4 192.168.10.253
s=streamed by MJPEG
i=JPEG
t=0 0
a=tool:LIVE555 Streaming Media v2009.04.20
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:streamed by MJPEG
a=x-qt-text-inf:JPEG
m=video 0 RTP/AVP 26
c=IN IP4 0.0.0.0
a=x-dimensions:640,480
a=control:track1
m=metadata 0 RTP/AVP 97
c=IN IP4 0.0.0.0
a=rtpmap:97 META/90000
a=control:track2

Created receiver for "video/JPEG" subsession (client ports 55810-55811)
Unable to create receiver for "metadata/META" subsession: RTP payload
format unknown or not supported
Setup "video/JPEG" subsession (client ports 55810-55811)
Created output file: "video-JPEG-1"
Started playing session
Receiving streamed data (signal with "kill -HUP 18170" or "kill -USR1
18170" to terminate)...
^C

$ mplayer rtsp://192.168.10.253/jpeg
MPlayer 1.0rc2-4.3.2-DFSG-free (C) 2000-2007 MPlayer Team
CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (Family: 15, Model: 4, Stepping: 1)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote
control.

Playing rtsp://192.168.10.253/jpeg.
Connecting to server 192.168.10.253[192.168.10.253]: 554...
rtsp_session: unsupported RTSP server. Server type is 'unknown'.
STREAM_LIVE555, URL: rtsp://192.168.10.253/jpeg
Stream not seekable!
 file format detected.
Initiated "video/JPEG" RTP subsession on port 59638
demux_rtp: Guessed the video frame rate as 20 frames-per-second.
        (If this is wrong, use the "-fps <frame-rate>" option instead.)
VIDEO:  [MJPG]  0x0  0bpp  20.000 fps    0.0 kbps ( 0.0 kbyte/s)
[VO_XV] It seems there is no Xvideo support for your video card available.
[VO_XV] Run 'xvinfo' to verify its Xv support and read
[VO_XV] DOCS/HTML/en/video.html#xv!
[VO_XV] See 'mplayer -vo help' for other (non-xv) video out drivers.
[VO_XV] Try -vo x11.
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffmjpeg] vfm: ffmpeg (FFmpeg MJPEG decoder)
==========================================================================
Audio: no sound
Starting playback...
VDec: vo config request - 640 x 480 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 3)
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO: [x11] 640x480 => 640x480 Planar YV12
[swscaler @ 0xb776c3f8]SwScaler: using unscaled yuv420p -> rgb32 special
convert
er
[mjpeg @ 0xb75a3b50]error count: 64
[mjpeg @ 0xb75a3b50]error y=0 x=33
[mjpeg @ 0xb75a3b50]error count: 64
[mjpeg @ 0xb75a3b50]error y=0 x=33
[mjpeg @ 0xb75a3b50]error count: 64
[mjpeg @ 0xb75a3b50]error y=0 x=33
..............................

RTSP-stream dump:
No.     Time        Source                Destination           Protocol
Info
    531 40.897661   192.168.10.253        192.168.10.3          JPEG
 JPEG message

Frame 531 (1490 bytes on wire, 1490 bytes captured)
    Arrival Time: Jun 22, 2010 13:51:45.104001000
    [Time delta from previous captured frame: 0.046061000 seconds]
    [Time delta from previous displayed frame: 0.046061000 seconds]
    [Time since reference or first frame: 40.897661000 seconds]
    Frame Number: 531
    Frame Length: 1490 bytes
    Capture Length: 1490 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:ip:udp:rtp:jpeg]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: 3com_03:04:05 (00:01:02:03:04:05), Dst:
Giga-Byt_ce:b1:28 (00:0f:ea:ce:b1:28)
    Destination: Giga-Byt_ce:b1:28 (00:0f:ea:ce:b1:28)
        Address: Giga-Byt_ce:b1:28 (00:0f:ea:ce:b1:28)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Source: 3com_03:04:05 (00:01:02:03:04:05)
        Address: 3com_03:04:05 (00:01:02:03:04:05)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 192.168.10.253 (192.168.10.253), Dst:
192.168.10.3 (192.168.10.3)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 1476
    Identification: 0x0000 (0)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (0x11)
    Header checksum: 0x9ed8 [correct]
        [Good: True]
        [Bad : False]
    Source: 192.168.10.253 (192.168.10.253)
    Destination: 192.168.10.3 (192.168.10.3)
User Datagram Protocol, Src Port: 6970 (6970), Dst Port: 48218 (48218)
    Source port: 6970 (6970)
    Destination port: 48218 (48218)
    Length: 1456
    Checksum: 0xaec1 [correct]
        [Good Checksum: True]
        [Bad Checksum: False]
Real-Time Transport Protocol
    [Stream setup by RTSP (frame 385)]
        [Setup frame: 385]
        [Setup Method: RTSP]
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    0... .... = Marker: False
    Payload type: JPEG-compressed video (26)
    Sequence number: 57296
    [Extended sequence number: 57296]
    Timestamp: 2176382441
    Synchronization Source identifier: 0x4f6b30c3 (1332424899)
RFC 2435 JPEG
    Main Header
        Type Specific: 0
        Fragement Offset: 0
        Type: 1
        Q: 75
        Width: 640
        Height: 480
    Payload: FFDA000C03010002110311003F00F9FE8AC8F8B720A28337...

0000  00 0f ea ce b1 28 00 01 02 03 04 05 08 00 45 00   .....(........E.
0010  05 c4 00 00 40 00 40 11 9e d8 c0 a8 0a fd c0 a8   .... at .@.........
0020  0a 03 1b 3a bc 5a 05 b0 ae c1 80 1a df d0 81 b8   ...:.Z..........
0030  f5 e9 4f 6b 30 c3 00 00 00 00 01 4b 50 3c ff da   ..Ok0......KP<..
0040  00 0c 03 01 00 02 11 03 11 00 3f 00 f9 fe 8a c8   ..........?.....
0050  f8 b7 20 a2 83 37 20 a2 82 1c 82 8a 09 b8 51 40   .. ..7 .......Q@
0060  ee 14 50 52 0a 28 2d 05 14 8d 10 51 41 b2 0a 28   ..PR.(-....QA..(
0070  34 4c 28 a0 d6 21 45 05 a6 14 50 68 98 51 41 49   4L(..!E...Ph.QAI
0080  85 14 14 98 51 41 57 0a 28 18 51 40 ee 14 50 01   ....QAW.(.Q at ..P.
0090  45 01 70 a2 80 b8 51 40 ae 14 50 2b 85 14 05 c2   E.p...Q at ..P+....
00a0  8a 04 14 50 2b 85 14 12 d8 51 41 2d 85 14 12 d8   ...P+....QA-....
00b0  51 41 0d 85 14 19 c9 85 14 19 85 14 c1 05 14 8d   QA..............
00c0  10 51 41 aa 0a 29 16 14 53 13 0a 28 33 61 45 06   .QA..)..S..(3aE.
00d0  6c 28 a0 80 a2 99 e6 b9 05 14 10 e4 14 50 2b 85   l(...........P+.
00e0  14 05 c2 8a 0a 41 45 05 a0 a2 82 d0 51 48 d2 2c   .....AE.....QH.,
00f0  28 a0 d5 30 a2 99 a2 61 45 23 44 c2 8a 0d 13 0a   (..0...aE#D.....
0100  28 34 4c 28 a0 a4 14 50 55 c2 8a 07 70 a2 81 dc   (4L(...PU...p...
0110  28 a0 77 0a 28 0b 85 14 05 c2 8a 18 5c 28 a0 57   (.w.(.......\(.W
0120  0a 28 13 61 45 0c 2e 14 50 26 c2 8a 05 70 a2 81   .(.aE...P&...p..
0130  36 14 50 4b 0a 28 25 85 14 12 d8 51 41 9b 0a 28   6.PK.(%....QA..(
0140  20 28 a0 68 28 a0 d1 05 14 8d 50 51 41 56 0a 29    (.h(.....PQAV.)
0150  89 85 14 19 b0 a2 83 36 14 50 43 0a 29 9e 3b 90   .......6.PC.).;.
0160  51 40 ae 14 50 17 0a 28 28 28 a0 a4 c2 8a 0a 41   Q at ..P..(((.....A
0170  45 05 a6 14 52 2d 30 a2 83 54 c2 8a 0d 53 0a 28   E...R-0..T...S.(
0180  34 4c 28 a0 b4 c2 8a 0d 13 0a 28 2d 30 a2 81 dc   4L(.......(-0...
0190  28 a0 ab 85 14 c2 e1 45 21 dc 28 a0 2e 14 53 0b   (......E!.(...S.
01a0  85 14 85 70 a2 81 5c 28 a0 2e 14 50 1a 05 14 0a   ...p..\(...P....
01b0  e1 45 02 b8 51 43 13 61 45 02 6c 28 a0 96 14 50   .E..QC.aE.l(...P
01c0  4b 61 45 33 36 c2 8a 42 0a 28 29 05 14 1a c5 05   KaE36..B.().....
01d0  14 8d 50 51 4c ab 05 14 10 c2 8a 0c 98 51 41 01   ..PQL........QA.
01e0  45 04 b0 a2 99 e1 5c 28 a0 68 28 a0 68 28 a0 a0   E.....\(.h(.h(..
01f0  a2 81 85 14 15 70 a2 82 d0 51 41 69 85 14 8d 22   .....p...QAi..."
0200  c2 8a 66 a9 85 14 8d 13 0a 29 9a 26 14 50 5a 61   ..f......).&.PZa
0210  45 22 d3 0a 29 95 70 a2 80 b8 51 40 ee 14 52 0b   E"..).p...Q at ..R.
0220  85 14 c7 70 a2 81 5c 28 a0 2e 14 50 17 0a 29 09   ...p..\(...P..).
0230  b0 a2 80 4c 28 a0 57 0a 29 85 c2 8a 42 b8 51 40   ...L(.W.)...B.Q@
0240  82 8a 04 c2 8a 08 61 45 04 30 a2 98 20 a2 91 68   ......aE.0.. ..h
0250  28 a0 d6 28 28 a0 d5 20 a2 81 85 14 12 d0 51 41   (..((.. ......QA
0260  8b 0a 28 21 85 14 12 14 53 3c 10 a2 81 85 14 0c   ..(!....S<......
0270  28 a0 a4 14 50 34 14 50 52 0a 28 2d 05 14 16 98   (...P4.PR.(-....
0280  51 41 68 28 a0 d1 30 a2 83 44 c2 8a 0d 13 0a 28   QAh(..0..D.....(
0290  2d 30 a2 82 ee 14 50 3b 85 14 0d 30 a2 90 ee 14   -0....P;...0....
02a0  50 01 45 03 b8 51 4c 57 0a 29 05 c2 8a 61 70 a2   P.E..QLW.)...ap.
02b0  90 5c 28 a0 57 0a 28 00 a2 81 5c 28 a6 17 0a 28   .\(.W.(...\(...(
02c0  15 c2 8a 42 0a 29 92 d8 51 41 0c 28 a0 10 51 48   ...B.)..QA.(..QH
02d0  d2 21 45 06 f1 41 45 06 a8 28 a0 6c 28 a0 ce 41   .!E..AE..(.l(..A
02e0  45 06 32 0a 28 21 85 14 12 14 53 3c 00 a2 81 85   E.2.(!....S<....
02f0  14 0c 28 a0 a0 a2 81 a0 a2 82 ee 14 50 34 14 50   ..(.........P4.P
0300  5a 61 45 05 a6 14 50 5a 0a 28 34 4c 28 a0 b4 c2   ZaE...PZ.(4L(...
0310  8a 0d 13 0a 28 2e e1 45 03 b8 51 40 5c 28 a0 ab   ....(..E..Q@\(..
0320  85 14 82 e1 45 31 dc 28 a0 2e 14 50 2b 85 14 0e   ....E1.(...P+...
0330  e1 45 02 b8 51 48 02 8a 60 14 50 01 45 20 b8 51   .E..QH..`.P.E .Q
0340  4c 41 45 02 61 45 04 85 14 10 c2 8a 06 82 8a 46   LAE.aE.........F
0350  d1 0a 28 37 88 51 41 aa 41 45 01 60 a2 83 29 05   ..(7.QA.AE.`..).
0360  14 19 48 28 a0 cd 85 14 12 14 53 3c 00 a2 81 85   ..H(......S<....
0370  14 0c 28 a0 68 28 a0 a4 14 50 50 51 40 d0 51 41   ..(.h(...PPQ at .QA
0380  48 28 a0 b4 14 50 52 61 45 06 89 85 14 16 98 51   H(...PRaE......Q
0390  41 69 85 14 16 98 51 41 41 45 03 b8 51 40 ee 14   Ai....QAAE..Q at ..
03a0  50 30 a2 80 b8 51 40 05 14 05 c2 8a 00 28 a0 2e   P0...Q at ......(..
03b0  14 50 01 45 01 70 a2 80 0a 28 10 51 40 05 14 03   .P.E.p...(.Q at ...
03c0  0a 28 24 28 a0 9b 85 14 14 82 8a 46 d1 0a 28 3a   .($(.......F..(:
03d0  22 82 8a 0d 6c 14 50 26 14 50 65 20 a2 83 16 14   "...l.P&.Pe ....
03e0  50 64 c2 8a 09 0a 29 9e 08 51 40 c2 8a 00 28 a0   Pd....)..Q at ...(.
03f0  61 45 05 05 14 14 82 8a 0a 41 45 03 41 45 05 20   aE.......AE.AE.
0400  a2 82 90 51 41 69 85 14 16 98 51 41 68 28 a0 bb   ...QAi....QAh(..
0410  85 14 14 98 51 41 57 0a 28 1d c2 8a 07 70 a2 80   ....QAW.(....p..
0420  b8 51 40 5c 28 a0 77 0a 28 0b 85 14 05 c2 8a 00   .Q@\(.w.(.......
0430  28 a0 57 0a 28 00 a2 80 0a 28 00 a2 81 30 a2 82   (.W.(....(...0..
0440  58 51 41 21 45 06 88 28 a0 de 21 45 23 a2 28 28   XQA!E..(..!E#.((
0450  a0 d5 05 14 09 85 14 18 c8 28 a0 c1 85 14 19 b0   .........(......
0460  a2 82 02 8a 67 84 14 50 30 a2 80 0a 28 18 51 41   ....g..P0...(.QA
0470  48 28 a0 61 45 05 26 14 50 3b 85 14 14 14 50 34   H(.aE.&.P;....P4
0480  14 50 5a 0a 28 2d 30 a2 82 93 0a 28 28 28 a0 b4   .PZ.(-0....(((..
0490  c2 8a 0a 41 45 05 5c 28 a0 61 45 01 70 a2 81 85   ...AE.\(.aE.p...
04a0  14 00 51 40 05 14 00 51 40 05 14 00 51 40 05 14   ..Q at ...Q@...Q at ..
04b0  00 51 48 02 8a 62 b8 51 41 2f 60 a2 81 05 14 1a   .QH..b.QA/`.....
04c0  44 28 a4 74 c5 05 14 1d 11 41 45 06 a9 05 14 12   D(.t.....AE.....
04d0  c2 8a 0c 26 14 50 73 c8 28 a0 cd 85 14 11 70 a2   ...&.Ps.(.....p.
04e0  99 e1 05 14 14 82 8a 00 28 a0 61 45 03 0a 28 28   ........(.aE..((
04f0  28 a0 61 45 05 05 14 0c 28 a0 a4 14 50 50 51 41   (.aE....(...PPQA
0500  48 28 a0 a4 c2 8a 0b 4c 28 a0 a4 c2 8a 0a 4c 28   H(.....L(.....L(
0510  a0 ab 85 14 0c 28 a0 61 45 03 0a 28 00 a2 80 0a   .....(.aE..(....
0520  28 00 a2 80 0a 28 00 a2 80 0a 28 00 a2 80 0a 28   (....(....(....(
0530  15 c2 8a 44 85 14 02 0a 29 9a c4 28 a0 e9 80 51   ...D....)..(...Q
0540  48 e9 88 51 41 a2 0a 28 21 85 14 18 49 85 14 1c   H..QA..(!...I...
0550  f2 0a 28 32 61 45 04 85 14 cf 08 28 a0 61 45 03   ..(2aE.....(.aE.
0560  0a 28 18 51 40 c2 8a 06 14 50 30 a2 82 90 51 40   .(.Q at ....P0...Q@
0570  c2 8a 0a 0a 28 29 05 14 14 14 50 34 c2 8a 0a 0a   ....()....P4....
0580  28 2a e1 45 05 20 a2 82 93 0a 28 1d c2 8a 0a 41   (*.E. ....(....A
0590  45 03 b8 51 40 05 14 0c 28 a0 02 8a 00 28 a0 02   E..Q at ...(....(..
05a0  8a 00 28 a0 02 8a 42 0a 28 00 a2 99 2c 28 a0 a4   ..(...B.(...,(..
05b0  14 52 36 8a 0a 28 3a 20 14 50 74 c4 28 a0 a0 a2   .R6..(: .Pt.(...
05c0  82 24 14 50 61 20 a2 83 09 05 14 19 30 a2 82 42   .$.Pa ......0..B
05d0  8a 67                                             .g

No.     Time        Source                Destination           Protocol
Info
    532 40.899246   192.168.10.253        192.168.10.3          JPEG
 JPEG message

Frame 532 (89 bytes on wire, 89 bytes captured)
    Arrival Time: Jun 22, 2010 13:51:45.105586000
    [Time delta from previous captured frame: 0.001585000 seconds]
    [Time delta from previous displayed frame: 0.001585000 seconds]
    [Time since reference or first frame: 40.899246000 seconds]
    Frame Number: 532
    Frame Length: 89 bytes
    Capture Length: 89 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:ip:udp:rtp:jpeg]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: 3com_03:04:05 (00:01:02:03:04:05), Dst:
Giga-Byt_ce:b1:28 (00:0f:ea:ce:b1:28)
    Destination: Giga-Byt_ce:b1:28 (00:0f:ea:ce:b1:28)
        Address: Giga-Byt_ce:b1:28 (00:0f:ea:ce:b1:28)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Source: 3com_03:04:05 (00:01:02:03:04:05)
        Address: 3com_03:04:05 (00:01:02:03:04:05)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 192.168.10.253 (192.168.10.253), Dst:
192.168.10.3 (192.168.10.3)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 75
    Identification: 0x0000 (0)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (0x11)
    Header checksum: 0xa451 [correct]
        [Good: True]
        [Bad : False]
    Source: 192.168.10.253 (192.168.10.253)
    Destination: 192.168.10.3 (192.168.10.3)
User Datagram Protocol, Src Port: 6970 (6970), Dst Port: 48218 (48218)
    Source port: 6970 (6970)
    Destination port: 48218 (48218)
    Length: 55
    Checksum: 0xfb30 [correct]
        [Good Checksum: True]
        [Bad Checksum: False]
Real-Time Transport Protocol
    [Stream setup by RTSP (frame 385)]
        [Setup frame: 385]
        [Setup Method: RTSP]
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    1... .... = Marker: True
    Payload type: JPEG-compressed video (26)
    Sequence number: 57297
    [Extended sequence number: 57297]
    Timestamp: 2176382441
    Synchronization Source identifier: 0x4f6b30c3 (1332424899)
RFC 2435 JPEG
    Main Header
        Type Specific: 0
        Fragement Offset: 1428
        Type: 1
        Q: 75
        Width: 640
        Height: 480
    Payload: 84145030A281A0A281851400514141450341450341450505...

0000  00 0f ea ce b1 28 00 01 02 03 04 05 08 00 45 00   .....(........E.
0010  00 4b 00 00 40 00 40 11 a4 51 c0 a8 0a fd c0 a8   .K.. at .@..Q......
0020  0a 03 1b 3a bc 5a 00 37 fb 30 80 9a df d1 81 b8   ...:.Z.7.0......
0030  f5 e9 4f 6b 30 c3 00 00 05 94 01 4b 50 3c 84 14   ..Ok0......KP<..
0040  50 30 a2 81 a0 a2 81 85 14 00 51 41 41 45 03 41   P0........QAAE.A
0050  45 03 41 45 05 05 14 0d 05                        E.AE.....

How can I solve this problem?
Thank you and excuse me for my bad english.

-- 
? ?????????,
??????????? ?????? ????????????
?????????????????????????
???????????, ??????????? ?????
??? ?????????
??????????? ??? ? ????????????? ???????? ???????
?????????????????????????
+7(495)221-66-22 ???.122
http://www.byterg.ru    http://www.bestdvr.ru

From finlayson at live555.com  Wed Jun 23 01:54:24 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 23 Jun 2010 01:54:24 -0700
Subject: [Live-devel] VLC can't decode MJPEG stream
In-Reply-To: <4C21C380.2040401@byterg.ru>
References: <4C21C380.2040401@byterg.ru>
Message-ID: <f06240805c84776dd76b4@[66.80.62.44]>

>I have used vlc 0.8.6h and 1.0.5 to watch MJPEG RTSP-stream.
>I successfully connect to server, but I don't see image, I see green or
>black square.

This is not a VLC mailing list, and our software does not do any JPEG 
(or other) decoding - it implements only the RTSP/RTP/RTCP protocols. 
Also, I don't know anything about the server (except that, according 
to the SDP description, it appears to be using our software).

However, you might try using the "openRTSP" client application to 
receive the motion-JPEG stream, writing each received JPEG frame to a 
separate file (a JPEG image file that you could then try viewing). 
I.e., you can add the "-m" option to "openRTSP"; see 
http://www.live555.com/openRTSP/#other-options
-- 

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

From samparknisha at rediffmail.com  Wed Jun 23 02:22:35 2010
From: samparknisha at rediffmail.com (Nisha Singh)
Date: 23 Jun 2010 09:22:35 -0000
Subject: [Live-devel] =?utf-8?q?vlc_getting_crashed_while_streaming_h264_e?=
	=?utf-8?q?ncoded_video_data?=
Message-ID: <20100623092235.36705.qmail@f6mail-145-190.rediffmail.com>

Hi,

I have a file (wireshark dump) which contains the rtp packets containing the h264 data. 
I have dumped the h264 NAL units into a file and each unit is separated by 0x00000001 bytes. That data from the file is to be streamed to the vlc. I have implemented a subclass of H264VideoStreamFramer which identifies the h264 units, identifies the fCurrentNalUnitEndsAccessUnit, sets the fPresentationTime and fDurationInMicroseconds. 
After 7-8 packets have been sent to the vlc it is getting crashed. I am unable to identify the reason. The h264 units are being extracted correctly, the marker bit is also being set properly to identify the end of a h264 frame. 

what could be the reason of vlc getting crashed after 7-8 packets of rtp have been transffered to the vlc.

Regards,
Nisha

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

From finlayson at live555.com  Wed Jun 23 18:05:22 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Wed, 23 Jun 2010 18:05:22 -0700
Subject: [Live-devel] vlc getting crashed while streaming h264 encoded
 video data
In-Reply-To: <20100623092235.36705.qmail@f6mail-145-190.rediffmail.com>
References: <20100623092235.36705.qmail@f6mail-145-190.rediffmail.com>
Message-ID: <f06240802c8485faff2ed@[66.80.62.44]>

>what could be the reason of vlc getting crashed after 7-8 packets of 
>rtp have been transffered to the vlc.

I don't know; this is not a VLC mailing list!
-- 

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

From brilliantov at byterg.ru  Thu Jun 24 00:19:20 2010
From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich)
Date: Thu, 24 Jun 2010 11:19:20 +0400
Subject: [Live-devel] VLC can't decode MJPEG stream
Message-ID: <4C2306F8.3000300@byterg.ru>

Hello Ross and thank you for your reply!

I know that this isn't VLC maillist. I build RTSP-stream using live555
and I try to understand where I have error - in the capture, encode or
streaming process.

If I save data after encode, before streaming, I see correct color JPG.

I have used your solution and captured stream using openRTSP key -m. I
have tried it, but I see only grey screen.

Thank you and excuse me for my bad english.

---
? ?????????,
??????????? ?????? ????????????
?????????????????????????
???????????, ??????????? ?????
??? ?????????
??????????? ??? ? ????????????? ???????? ???????
?????????????????????????
+7(495)221-66-22 ???.122
http://www.byterg.ru    http://www.bestdvr.ru

From yuri.timenkov at itv.ru  Thu Jun 24 00:54:52 2010
From: yuri.timenkov at itv.ru (Yuri Timenkov)
Date: Thu, 24 Jun 2010 11:54:52 +0400
Subject: [Live-devel] VLC can't decode MJPEG stream
In-Reply-To: <4C2306F8.3000300@byterg.ru>
References: <4C2306F8.3000300@byterg.ru>
Message-ID: <00ec01cb1372$86ff7840$94fe68c0$@timenkov@itv.ru>

You could try to analyze received frames with jpegsnoop utility (http://www.impulseadventure.com/photo/jpeg-snoop.html). It can help to understand what pieces of picture are missing/invalid.

> -----Original Message-----
> From: live-devel-bounces at ns.live555.com [mailto:live-devel-
> bounces at ns.live555.com] On Behalf Of Brilliantov Kirill Vladimirovich
> Sent: Thursday, June 24, 2010 11:19 AM
> To: live-devel at ns.live555.com
> Subject: [Live-devel] VLC can't decode MJPEG stream
> 
> Hello Ross and thank you for your reply!
> 
> I know that this isn't VLC maillist. I build RTSP-stream using live555
> and I try to understand where I have error - in the capture, encode or
> streaming process.
> 
> If I save data after encode, before streaming, I see correct color JPG.
> 
> I have used your solution and captured stream using openRTSP key -m. I
> have tried it, but I see only grey screen.
> 
> Thank you and excuse me for my bad english.
> 
> ---
> ? ?????????,
> ??????????? ?????? ????????????
> ?????????????????????????
> ???????????, ??????????? ?????
> ??? ?????????
> ??????????? ??? ? ????????????? ???????? ???????
> ?????????????????????????
> +7(495)221-66-22 ???.122
> http://www.byterg.ru    http://www.bestdvr.ru
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel


From brilliantov at byterg.ru  Thu Jun 24 04:48:59 2010
From: brilliantov at byterg.ru (Brilliantov Kirill Vladimirovich)
Date: Thu, 24 Jun 2010 15:48:59 +0400
Subject: [Live-devel]  VLC can't decode MJPEG stream
Message-ID: <4C23462B.5000909@byterg.ru>

I set MAX_BUFFER_SIZE (256 * 1024) and OutPacketBuffer::maxSize =
MAX_BUFFER_SIZE.
But anyway I see that image sends in two parts. Resolution of image
640x480 and size 8544 bytes if I save it before rtsp-stream.
But openRTSP captures files with 8.0K sizes.
Why?

-- 
? ?????????,
??????????? ?????? ????????????
?????????????????????????
???????????, ??????????? ?????
??? ?????????
??????????? ??? ? ????????????? ???????? ???????
?????????????????????????
+7(495)221-66-22 ???.122
http://www.byterg.ru    http://www.bestdvr.ru

From finlayson at live555.com  Thu Jun 24 06:25:14 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 24 Jun 2010 06:25:14 -0700
Subject: [Live-devel] VLC can't decode MJPEG stream
In-Reply-To: <4C23462B.5000909@byterg.ru>
References: <4C23462B.5000909@byterg.ru>
Message-ID: <f06240800c84909ae8d34@[66.80.62.44]>

>I set MAX_BUFFER_SIZE (256 * 1024) and OutPacketBuffer::maxSize =
>MAX_BUFFER_SIZE.
>But anyway I see that image sends in two parts. Resolution of image
>640x480 and size 8544 bytes if I save it before rtsp-stream.
>But openRTSP captures files with 8.0K sizes.
>Why?

When JPEG images are streamed via RTP, they're not sent 'as is'. 
Instead, the JPEG header is stripped from the image, and sent - at 
the front of the RTP packet - in 'compressed' form.  (This is defined 
by RFC 2435.)

Remember, You Have Complete Source Code.  To understand what your 
receiving application is doing, you should look at 
"JPEGVideoRTPSource.cpp", which implements the receiving of JPEG data 
over RTP.

(Also, because your server appears to be implemented using our 
software, it is likely using "JPEGVideoRTPSink.cpp", which implements 
the sending of JPEG data over RTP.
-- 

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

From jnoring at logitech.com  Thu Jun 24 08:02:22 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Thu, 24 Jun 2010 08:02:22 -0700
Subject: [Live-devel] How to contribute code?
In-Reply-To: <f06240802c845d0de604c@66.80.62.44>
References: <201006181210.31991.david.stegbauer@acision.com>
	<f06240803c84130359c83@66.80.62.44>
	<AANLkTinxmob3m8yR8CJmMid8uzgpzKW4bNTKASi7F8R1@mail.gmail.com>
	<f06240802c845d0de604c@66.80.62.44>
Message-ID: <AANLkTinQiZPvQt9QBspbLrq4DBuGnnUUZ1bQsm-HZvyE@mail.gmail.com>

On Mon, Jun 21, 2010 at 7:50 PM, Ross Finlayson <finlayson at live555.com>wrote:

> I don't use any revision control system myself.  When I'm developing this
> code, I use exactly two commands: "emacs" and "make".
>
> Each source code release - in "tar.gz" form - is less than 500 kBytes in
> size.  These days, that's not a significant amount of data to download in
> order to get the latest revision, and any bandwidth savings obtained by
> downloading from a revision control system instead would be insignificant.
>  And people should not be using any version of the code other than the
> latest one, because that's all that we support.
>

It's not about bandwidth, it's about having a clear history of all changes
made to the project, and when.  It is extraordinarily difficult to isolate
regression without this.


>
> I suspect that the real reason why some people want to use a revision
> control system is that they want to easily update to the latest version of
> the code after they've made custom modifications to it (i.e., without losing
> their modifications).  I'm sorry, but this is something that I explicitly
> want to discourage.  People *should not* be making modifications to the
> released "LIVE555 Streaming Media" code (i.e., inside the "live" directory).
>  Instead, they should be leaving that directory as it is, and instead
> putting their own code in a separate directory (using subclassing, if
> necessary).
>

This is simply not true--I do not want source control so I can "easily
update to the latest version of the code."  I want it so I can easily have a
history of all changes made, readily available diff files, and an easy way
to see when changes have been made.

Furthermore, most programmers *refuse* to use trunk (this is considered
extraordinarily unwise by every decent program I know), which is basically
the policy you're advocating.  The open source project I manage has detailed
download statistics, and the results are clear: people prefer sanctioned
releases as opposed to trunk.  So I'm going to have to disagree with you; I
think your hypothesis here is flat-out wrong.


> If there are parts of the code that make it difficult for people to
> customize via subclassing - e.g., some class members that should be
> "protected:" instead of "private:", then please let us know.


Has absolutely nothing to do with this.  It's more like, the only way I can
get a diff view of the changes made to the project is to cache away the
various releases you put out on a bi-monthly basis into my source control,
so I can do a compare.

I don't expect you to find these arguments compelling, and that's fine--I'll
continue to cache away versions of the library so I can roll back to work
around regression introduced in subsequent releases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100624/3acc388f/attachment.html>

From gbonneau at miranda.com  Thu Jun 24 09:00:45 2010
From: gbonneau at miranda.com (BONNEAU Guy)
Date: Thu, 24 Jun 2010 12:00:45 -0400
Subject: [Live-devel] How to contribute code?
In-Reply-To: <AANLkTinQiZPvQt9QBspbLrq4DBuGnnUUZ1bQsm-HZvyE@mail.gmail.com>
References: <201006181210.31991.david.stegbauer@acision.com><f06240803c84130359c83@66.80.62.44><AANLkTinxmob3m8yR8CJmMid8uzgpzKW4bNTKASi7F8R1@mail.gmail.com><f06240802c845d0de604c@66.80.62.44>
	<AANLkTinQiZPvQt9QBspbLrq4DBuGnnUUZ1bQsm-HZvyE@mail.gmail.com>
Message-ID: <6353CA579307224BAFDE9495906E691604BC7BE3@ca-ops-mail>

Jeremy,

 

Since you already manage an open source project would you be available
to setup and manage an open source public repository for live555. We
could commit the sources as Ross release them since they are of public
domain. I could offer some help if you want. Ross would only need to
setup an URL link in the FAQ section for those people that want an
history browsing of the changes for whatever reason.

 

Guy

 

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeremy Noring
Sent: Thursday, June 24, 2010 11:02
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] How to contribute code?

 

On Mon, Jun 21, 2010 at 7:50 PM, Ross Finlayson <finlayson at live555.com>
wrote:

	I don't use any revision control system myself.  When I'm
developing this code, I use exactly two commands: "emacs" and "make".
	
	Each source code release - in "tar.gz" form - is less than 500
kBytes in size.  These days, that's not a significant amount of data to
download in order to get the latest revision, and any bandwidth savings
obtained by downloading from a revision control system instead would be
insignificant.  And people should not be using any version of the code
other than the latest one, because that's all that we support.


It's not about bandwidth, it's about having a clear history of all
changes made to the project, and when.  It is extraordinarily difficult
to isolate regression without this.
 

	
	I suspect that the real reason why some people want to use a
revision control system is that they want to easily update to the latest
version of the code after they've made custom modifications to it (i.e.,
without losing their modifications).  I'm sorry, but this is something
that I explicitly want to discourage.  People *should not* be making
modifications to the released "LIVE555 Streaming Media" code (i.e.,
inside the "live" directory).  Instead, they should be leaving that
directory as it is, and instead putting their own code in a separate
directory (using subclassing, if necessary).


This is simply not true--I do not want source control so I can "easily
update to the latest version of the code."  I want it so I can easily
have a history of all changes made, readily available diff files, and an
easy way to see when changes have been made.

Furthermore, most programmers *refuse* to use trunk (this is considered
extraordinarily unwise by every decent program I know), which is
basically the policy you're advocating.  The open source project I
manage has detailed download statistics, and the results are clear:
people prefer sanctioned releases as opposed to trunk.  So I'm going to
have to disagree with you; I think your hypothesis here is flat-out
wrong.
 

	If there are parts of the code that make it difficult for people
to customize via subclassing - e.g., some class members that should be
"protected:" instead of "private:", then please let us know.


Has absolutely nothing to do with this.  It's more like, the only way I
can get a diff view of the changes made to the project is to cache away
the various releases you put out on a bi-monthly basis into my source
control, so I can do a compare.

I don't expect you to find these arguments compelling, and that's
fine--I'll continue to cache away versions of the library so I can roll
back to work around regression introduced in subsequent releases.

 

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

From finlayson at live555.com  Thu Jun 24 12:02:33 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Thu, 24 Jun 2010 12:02:33 -0700
Subject: [Live-devel] How to contribute code?
In-Reply-To: <6353CA579307224BAFDE9495906E691604BC7BE3@ca-ops-mail>
References: <201006181210.31991.david.stegbauer@acision.com><f06240803c84130359c83@66.
	80.62.44><AANLkTinxmob3m8yR8CJmMid8uzgpzKW4bNTKASi7F8R1@mail.gmail.com><f0
	6240802c845d0de604c@66.80.62.44>
	<AANLkTinQiZPvQt9QBspbLrq4DBuGnnUUZ1bQsm-HZvyE@mail.gmail.com>
	<6353CA579307224BAFDE9495906E691604BC7BE3@ca-ops-mail>
Message-ID: <f06240801c8495b6bf43a@[66.80.62.44]>

Anyone can, of course, keep whatever version(s) of the code that they 
wish.  However, we will continue to support the current version only.


>since they are of public domain.

A slight correction in terminology here: This code is "open source"; 
not "public domain".
-- 

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

From kamildobk at poczta.onet.pl  Fri Jun 25 06:51:47 2010
From: kamildobk at poczta.onet.pl (Kamil Dobkowski)
Date: Fri, 25 Jun 2010 15:51:47 +0200
Subject: [Live-devel] RTP over TCP problem in the latest version of library
Message-ID: <571A528A40AD457BBA79D47769258BCC@KamilPC>

Hello,

I have a few problems. I downloaded the latest version of LiveMedia library 2010.06.22 and RTPoverTCP streaming ( RTSPClient ) suddenly stopped working. In the previous version I tested - 2010.06.11 everything was working ok. PLAY command is invoked correctly by RTSPClient but no frames are received ( I've tried MPEG4, H264, MJPEG ). When I've restored RTPInterface.cpp and GroupSocketHelper.cpp/hh from the previous version TCP is workig again. Anyone noticed this problem ? 

Wireshark log shows that RTSPClient sends some commands my cameras don't recognize, RTCP packets probably, and they return RTSP/1.0 RTSP 505 Version not supported in response, but it is exactly how it worked in the previous version - and there was no problem. Is there a simple way to turn off RTCP in RTCPClient ?

By the way, is TCP using some blocking calls ? I've noticed that video stream often stops for a fraction of second on the first camera, but only when the second camera is receiving RTPoverTCP stream.

And the last issue not related to TCP. Many network cameras announce their SDP session with c=IN IP 0.0.0.0 ( they have no separated SDP description  for multicast sessions ) . Is there a way to enforce multicast on such connections ? It worked in the previous versions, but now it doesn't. I think it was usable feauture, so maybe there is a chance to add it to the latest version ...

Thanks in advance,
Kamil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100625/d670a728/attachment.html>

From finlayson at live555.com  Fri Jun 25 07:39:56 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 25 Jun 2010 07:39:56 -0700
Subject: [Live-devel] RTP over TCP problem in the latest version of
 library
In-Reply-To: <571A528A40AD457BBA79D47769258BCC@KamilPC>
References: <571A528A40AD457BBA79D47769258BCC@KamilPC>
Message-ID: <f06240800c84a68ed82c5@[66.80.62.44]>

>I have a few problems. I downloaded the latest version of LiveMedia 
>library 2010.06.22 and RTPoverTCP streaming ( RTSPClient ) suddenly 
>stopped working. In the previous version I tested - 2010.06.11 
>everything was working ok.

Please send us the (publically-accessible) "rtsp://" URL of a server 
that illustrates this problem.  (Recent changes to the RTP-over-TCP 
implementation actually *fixed* some bugs, so it's a bit surprising 
to hear that bugs might have been introduced here.)


>Wireshark log shows that RTSPClient sends some commands my cameras 
>don't recognize, RTCP packets probably, and they return RTSP/1.0 
>RTSP 505 Version not supported in response, but it is exactly how it 
>worked in the previous version - and there was no problem. Is there 
>a simple way to turn off RTCP in RTCPClient ?

No.  RTCP is a mandatory part of the RTP/RTCP standard.  If your 
server (camera) is not recognizing incoming RTCP packets, then it's 
not standards-compliant.  (If, however, your server is returning a 
RTSP error response each time it receives such a packet, then it's 
conceivable that this might be confusing the current RTSPClient 
implementation, in which case we'll take a look at this.  But again, 
please send us the (publically-accessible) "rtsp://" URL of a server 
that illustrates this problem.)


>  By the way, is TCP using some blocking calls ?

Not anymore!  This was fixed in the recent reimplementation of "RTSPClient".


>And the last issue not related to TCP. Many network cameras announce 
>their SDP session with c=IN IP 0.0.0.0 ( they have no separated SDP 
>description  for multicast sessions ) . Is there a way to enforce 
>multicast on such connections ? It worked in the previous versions, 
>but now it doesn't. I think it was usable feauture, so maybe there 
>is a chance to add it to the latest version ...

Are you referring to the "forceMulticastOnUnspecified" Boolean flag 
in "RTSPClient:: setupMediaSubsession()"?  Do you set this flag to 
True in your client application?

I deliberately disabled this functionality in the latest "RTSPClient" 
implementation, because I wanted to see if anyone still used it and 
wanted it.  If it is still being used, then I'll re-enable it in the 
next release of the software.
-- 

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/20100625/5c7482a9/attachment.html>

From stephane.saragaglia at robosoft.fr  Fri Jun 25 07:43:47 2010
From: stephane.saragaglia at robosoft.fr (=?ISO-8859-15?Q?St=E9phane_SARAGAGLIA?=)
Date: Fri, 25 Jun 2010 16:43:47 +0200
Subject: [Live-devel] RTP/H264 low latency streaming + source,	change
In-Reply-To: <mailman.1413.1276556454.852.live-devel@lists.live555.com>
References: <mailman.1413.1276556454.852.live-devel@lists.live555.com>
Message-ID: <4C24C0A3.6060807@robosoft.fr>

Le 15/06/2010 01:00, live-devel-request at ns.live555.com a ?crit :
>> I am using Live555 libraries to stream H264 video provided by a
>> >frame grabber, via RTP (not RTSP).
>> >I use VLC and VLC activeX as a RTP/H264 client.
>> >
>> >Sometimes, I need to change the camera used by the framegrabber, so
>> >I close the RTP sink, the framer, the source, and I open them again
>> >with the new video. Doing that, (even with the same video
>> >parameters), the client often hang (but not every time), and
>> >sometimes go on playing again but with a big delay.
>> >How can I prevent the client from freezing the video or display the
>> >video with delay ? Sending some missing frames ? Special trick to
>> >warn client ?
>> >My main objective is LOW latency, some image skips are not a problem.
> I suspect that your problem is caused by the fact that each sending
> camera (server) necessarily uses a different RTP timestamp base, and
> so when you switch to receiving from a new camera, the received
> data's presentation time will briefly be inaccurate, until you
> receive a new RTCP "SR" packet from the new source.  (I'm assuming
> that your servers send RTCP as well as RTP; because you're using our
> software, that should be the case.)
>
> One way to reduce this problem is to increase the average RTCP
> sending frequency, which you can do by increasing the "totSessionBW"
> parameter that you pass to "RTCPInstance::createNew()".  (This
> parameter is intended to represent the stream's bitrate in kbps.  It
> is used - by the RTCP code - to figure out how often to send RTCP
> packets.)

Oups...
I have not set up a RTCP flow. Just RTP.
The fact is that in my case the streaming client cannot reach the 
streaming server (simplex communication). So I guessed RTCP should not 
be used.

Thank-you for your advice, I am going to try playing with RTCP (even in 
simplex session) and timestamps.

Regards

From finlayson at live555.com  Fri Jun 25 08:05:20 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Fri, 25 Jun 2010 08:05:20 -0700
Subject: [Live-devel] RTP/H264 low latency streaming + source,	change
In-Reply-To: <4C24C0A3.6060807@robosoft.fr>
References: <mailman.1413.1276556454.852.live-devel@lists.live555.com>
	<4C24C0A3.6060807@robosoft.fr>
Message-ID: <f06240801c84a75f18fcb@[66.80.62.44]>

>>I suspect that your problem is caused by the fact that each sending
>>camera (server) necessarily uses a different RTP timestamp base, and
>>so when you switch to receiving from a new camera, the received
>>data's presentation time will briefly be inaccurate, until you
>>receive a new RTCP "SR" packet from the new source.  (I'm assuming
>>that your servers send RTCP as well as RTP; because you're using our
>>software, that should be the case.)
>>
>>One way to reduce this problem is to increase the average RTCP
>>sending frequency, which you can do by increasing the "totSessionBW"
>>parameter that you pass to "RTCPInstance::createNew()".  (This
>>parameter is intended to represent the stream's bitrate in kbps.  It
>>is used - by the RTCP code - to figure out how often to send RTCP
>>packets.)
>
>Oups...
>I have not set up a RTCP flow. Just RTP.
>The fact is that in my case the streaming client cannot reach the 
>streaming server (simplex communication). So I guessed RTCP should 
>not be used.
>
>Thank-you for your advice, I am going to try playing with RTCP (even 
>in simplex session) and timestamps.

Please, everyone - stop trying to 'second guess' the RTP/RTCP 
standard.  RTCP is *not* optional.
-- 

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

From Randy.Roberts at flir.com  Fri Jun 25 16:40:58 2010
From: Randy.Roberts at flir.com (Roberts, Randy)
Date: Fri, 25 Jun 2010 16:40:58 -0700
Subject: [Live-devel] DelayQueueEntry NULL
Message-ID: <9FF07362A2BFD446B95FC028D0B7B4D005596E38@coral.sba.flir.net>

Hi Ross,

 

Any ideas why I'd be coming across a NULL delay queue entry?

I've added to code in RED below, and I'm seeing this NULL..which causes
a SegFault without the code...

 

void DelayQueue::synchronize() {

  // First, figure out how much time has elapsed since the last sync:

  EventTime timeNow = TimeNow();

  if (timeNow < fLastSyncTime) {

    // The system clock has apparently gone back in time; reset our sync
time and return:

    fLastSyncTime  = timeNow;

    return;

  }

  DelayInterval timeSinceLastSync = timeNow - fLastSyncTime;

  fLastSyncTime = timeNow;

 

  // Then, adjust the delay queue for any entries whose time is up:

  DelayQueueEntry* curEntry = head();

  while (curEntry && timeSinceLastSync >= curEntry->fDeltaTimeRemaining)
{

    timeSinceLastSync -= curEntry->fDeltaTimeRemaining;

    curEntry->fDeltaTimeRemaining = DELAY_ZERO;

    curEntry = curEntry->fNext;

  }

  if (curEntry)

        curEntry->fDeltaTimeRemaining -= timeSinceLastSync;

  else fprintf(stderr, "%s:: curEntry is NULL!!\n", __FUNCTION__);

}

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

From finlayson at live555.com  Sat Jun 26 00:04:21 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Sat, 26 Jun 2010 00:04:21 -0700
Subject: [Live-devel] DelayQueueEntry NULL
In-Reply-To: <9FF07362A2BFD446B95FC028D0B7B4D005596E38@coral.sba.flir.net>
References: <9FF07362A2BFD446B95FC028D0B7B4D005596E38@coral.sba.flir.net>
Message-ID: <f06240802c84b563a5f6a@[66.80.62.44]>

>Any ideas why I'd be coming across a NULL delay queue entry?
>I've added to code in RED below, and I'm seeing 
>this NULL..which causes a SegFault without the 
>code?

No, calling "head()" on a "DelayQueue" should 
never return NULL; I have no idea how this could 
be happening.

I assume you're not doing something silly like 
trying to access the library from more than one 
thread.  Is there anything unusual about your 
application (and, in particular, how it uses the 
event loop)?
-- 

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/20100626/864e0792/attachment.html>

From sebastien-devel at celeos.eu  Mon Jun 28 06:29:48 2010
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Mon, 28 Jun 2010 15:29:48 +0200
Subject: [Live-devel] mixed rtp payload
Message-ID: <1277731788.4c28a3cc0ecc8@imp.celeos.eu>



Hi,

I have a network camera which sends rtp packed with payload = 100 (H264).
But the camera also sends some information in rtp packets with a different
payload type.
I believe these packets are discarded by live555, but is there a way to get
these packet in my application ?

Regards,

Sebastien.


From finlayson at live555.com  Mon Jun 28 07:04:20 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 28 Jun 2010 07:04:20 -0700
Subject: [Live-devel] mixed rtp payload
In-Reply-To: <1277731788.4c28a3cc0ecc8@imp.celeos.eu>
References: <1277731788.4c28a3cc0ecc8@imp.celeos.eu>
Message-ID: <f06240801c84e5bf11453@[66.80.62.44]>

>I have a network camera which sends rtp packed with payload = 100 (H264).
>But the camera also sends some information in rtp packets with a different
>payload type.
>I believe these packets are discarded by live555, but is there a way to get
>these packet in my application ?

Sebastien,

Perhaps.  Does the camera give you a SDP description for the stream? 
(Does the camera support RTSP?  If so, please run "openRTSP" on it, 
and send us the (stderr) output.)
-- 

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

From sebastien-devel at celeos.eu  Mon Jun 28 07:15:10 2010
From: sebastien-devel at celeos.eu (=?iso-8859-1?b?U+liYXN0aWVu?= Escudier)
Date: Mon, 28 Jun 2010 16:15:10 +0200
Subject: [Live-devel] mixed rtp payload
In-Reply-To: <f06240801c84e5bf11453@[66.80.62.44]>
References: <1277731788.4c28a3cc0ecc8@imp.celeos.eu>
	<f06240801c84e5bf11453@[66.80.62.44]>
Message-ID: <1277734510.4c28ae6e252e5@imp.celeos.eu>

Quoting Ross Finlayson <finlayson at live555.com>:

> Sebastien,
>
> Perhaps.  Does the camera give you a SDP description for the stream?
> (Does the camera support RTSP?  If so, please run "openRTSP" on it,
> and send us the (stderr) output.)

Yes I think it does, I can see it in the sdp.
Here is the output :

Opening connection to 192.43.185.150, port 554...
...remote connection opened
Sending request: OPTIONS rtsp://admin:admin at 192.43.185.150/VideoInput/1/h264/1
RTSP/1.0
CSeq: 2
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.06.22)


Received 96 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 2
Server: SANYO RTSP Server
Public: DESCRIBE, SETUP, TEARDOWN, PLAY


Sending request: DESCRIBE rtsp://admin:admin at 192.43.185.150/VideoInput/1/h264/1
RTSP/1.0
CSeq: 3
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.06.22)
Accept: application/sdp


Received 100 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 401 Unauthorized
CSeq: 3
Server: SANYO RTSP Server
WWW-Authenticate: Basic realm="/"


Resending...
Sending request: DESCRIBE rtsp://admin:admin at 192.43.185.150/VideoInput/1/h264/1
RTSP/1.0
CSeq: 4
Authorization: Basic YWRtaW46YWRtaW4=
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.06.22)
Accept: application/sdp


Received 202 new bytes of response data.
Have received 202 total bytes of a DESCRIBE RTSP response; awaiting 676 bytes
more.
Received 676 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK
CSeq: 4
Server: SANYO RTSP Server
Content-Base: rtsp://admin:admin at 192.43.185.150/VideoInput/1/h264/1/
Content-Type: application/sdp
Content-Length: 676
Cache-Control: no-cache

v=0
o=- 14975361453390338159 14975361453391734024 IN IP4 192.43.185.150
s=Media Presentation
c=IN IP4 0.0.0.0
b=AS:1864
t=0 0
m=video 0 RTP/AVP 100
b=AS:1800
a=framerate:12.5
a=quality:8
a=control:trackID=0
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=640028; Reso=320:240; Scanning=0; TVSystem=pal;
CameraMode=standard; StreamID=0; BitRateMode=vbr; Gop=30; AspectRatio=4:3;
packetization-mode=1;
sprop-parameter-sets=Z2QAKK0AzlBQfsBEAABwgAAK/IOAAAATEtAAAC+vCIvfjAAAAwCYloAAAX14RF78CAAAAA==,aP48sA==;
m=data 0 RTP/AVP 111
a=rtpmap:111 octet-stream/1
a=fmtp:111 Mac=08007b885ad5; Model=VCC-HD2500P; TargetBitRate=900;
FirmVer=01030000; CameraSeries=2;


Opened URL "rtsp://admin:admin at 192.43.185.150/VideoInput/1/h264/1", returning a
SDP description:
v=0
o=- 14975361453390338159 14975361453391734024 IN IP4 192.43.185.150
s=Media Presentation
c=IN IP4 0.0.0.0
b=AS:1864
t=0 0
m=video 0 RTP/AVP 100
b=AS:1800
a=framerate:12.5
a=quality:8
a=control:trackID=0
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=640028; Reso=320:240; Scanning=0; TVSystem=pal;
CameraMode=standard; StreamID=0; BitRateMode=vbr; Gop=30; AspectRatio=4:3;
packetization-mode=1;
sprop-parameter-sets=Z2QAKK0AzlBQfsBEAABwgAAK/IOAAAATEtAAAC+vCIvfjAAAAwCYloAAAX14RF78CAAAAA==,aP48sA==;
m=data 0 RTP/AVP 111
a=rtpmap:111 octet-stream/1
a=fmtp:111 Mac=08007b885ad5; Model=VCC-HD2500P; TargetBitRate=900;
FirmVer=01030000; CameraSeries=2;


Created receiver for "video/H264" subsession (client ports 49268-49269)
Unable to create receiver for "data/OCTET-STREAM" subsession: RTP payload format
unknown or not supported
Sending request: SETUP
rtsp://admin:admin at 192.43.185.150/VideoInput/1/h264/1/trackID=0 RTSP/1.0
CSeq: 5
Authorization: Basic YWRtaW46YWRtaW4=
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.06.22)
Transport: RTP/AVP;unicast;client_port=49268-49269


Received 185 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK
CSeq: 5
Server: SANYO RTSP Server
Session: 00316988;timeout=60
Transport:
RTP/AVP;unicast;client_port=49268-49269;server_port=2052-2053;ssrc=0019e388;mode="PLAY"


Setup "video/H264" subsession (client ports 49268-49269)
Created output file: "video-H264-1"
Sending request: PLAY rtsp://admin:admin at 192.43.185.150/VideoInput/1/h264/1/
RTSP/1.0
CSeq: 6
Authorization: Basic YWRtaW46YWRtaW4=
User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.06.22)
Session: 00316988
Range: npt=0.000-


Received 140 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK
CSeq: 6
Server: SANYO RTSP Server
Session: 00316988
Range: npt=now-
RTP-Info: url=trackID=0;seq=1;rtptime=535442400


Started playing session
Receiving streamed data (signal with "kill -HUP 23008" or "kill -USR1 23008" to
terminate)...


From andy at j2kvideo.com  Mon Jun 28 08:57:28 2010
From: andy at j2kvideo.com (Andy Bell)
Date: Mon, 28 Jun 2010 17:57:28 +0200
Subject: [Live-devel] JPEG file over RTP
Message-ID: <AANLkTin-sMt-0t3qaWYt_bTIQP4c4rpsyslLE-bny8OI@mail.gmail.com>

Hi All,

I am wanting to stream a single JPEG file over RTP for test purposes, I load
the file and then create a video source to stream it to a client, in this
case VLC.  I am using the following code on each frame:

void TestJPEGVideoSource::doGetNextFrame()

{

fFrameSize = this->sosSize;

 if ( fFrameSize > fMaxSize )

{

printf( "Truncating frame!!\n" );

fNumTruncatedBytes = fFrameSize - fMaxSize;

fFrameSize = fMaxSize;

}

 memcpy( fTo, this->buffer + this->sosIndex, fFrameSize );

 if ( fPresentationTime.tv_sec == 0 && fPresentationTime.tv_usec == 0 )

{

gettimeofday( &fPresentationTime, NULL );

}

else

{

unsigned uSeconds = fPresentationTime.tv_usec + ( fTimePerFrame * 1000 );

fPresentationTime.tv_sec += uSeconds / 1000000;

fPresentationTime.tv_usec = uSeconds % 1000000;

}


 fDurationInMicroseconds = fTimePerFrame * 1000;

 nextTask() = envir().taskScheduler().scheduleDelayedTask( 0,
(TaskFunc*)FramedSource::afterGetting, this );

}

Where 'buffer' is the JPEG file, and sosIndex is the SOS marker index of the
file.  The problem is that when I come to decode the stream in VLC the image
is far blockier than the original.  Why is this?  What am I doing wrong?

Thanks in advance

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

From kamildobk at poczta.onet.pl  Mon Jun 28 12:52:41 2010
From: kamildobk at poczta.onet.pl (kamildobk at poczta.onet.pl)
Date: Mon, 28 Jun 2010 21:52:41 +0200
Subject: [Live-devel] mixed rtp payload
Message-ID: <Q6569332-d78e078a65951681876ccf60cb21b49a@pmq4.m5r2.onet.test.onet.pl>

>I have a network camera which sends rtp packed with payload = 100 (H264).
>But the camera also sends some information in rtp packets with a different
>payload type.
>I believe these packets are discarded by live555, but is there a way to get

>these packet in my application ?

Hi,

I used SetAuxReadHandler() for this purpose - but you get a raw packet, so

you'll have to parse all RTP headers too, not only payload ( which is good
in

general case, because  you can read RTP extension headers ).


Regarding sanyo., did you manage to receive H264 over TCP ( -t option in

OpenRTSP.exe ) ? It looks like there is something wrong with the current

TCP tunneling implementation. I've tested it with a few camera models

( not only sanyo ) and none worked for me ( while the previous versions

of the library were working ok ). 


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

From finlayson at live555.com  Mon Jun 28 15:15:00 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 28 Jun 2010 15:15:00 -0700
Subject: [Live-devel] mixed rtp payload
In-Reply-To: <Q6569332-d78e078a65951681876ccf60cb21b49a@pmq4.m5r2.onet.test.onet.pl>
References: <Q6569332-d78e078a65951681876ccf60cb21b49a@pmq4.m5r2.onet.test.onet.pl>
Message-ID: <f06240801c84ecd67f294@[66.80.62.44]>

>I used SetAuxReadHandler() for this purpose

No, don't use "setAuxilliaryReadHandler()".  That's a hack that 
should never have been in the code; it will be going away sometime.

Instead, to receive the data from (otherwise) unknown RTP payload 
formats, pass a non-negative "useSpecialRTPoffset" parameter to 
"MediaSubsession::initiate()".  In particular, if you want to receive 
all of the data (i.e., not including the RTP header), use a 
"useSpecialRTPoffset" value of 0.

Alternatively, if you're using "openRTSP" (as Sebastien is), you can 
get the same effect by adding the command-line option "-S 0" to 
"openRTSP".  (See <http://www.live555.com/openRTSP/#other-options>)


>Regarding sanyo., did you manage to receive H264 over TCP ( -t option in
>OpenRTSP.exe ) ? It looks like there is something wrong with the current
>TCP tunneling implementation. I've tested it with a few camera models
>( not only sanyo ) and none worked for me ( while the previous versions
>of the library were working ok ).

Please send us the (publically-accessible) "rtsp://" URL of a server 
that illustrates this problem.  (The RTP-over-TCP implementation in 
recent versions should have been *improved*, so I'm a bit suprised to 
hear reports of bugs here.)
-- 

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

From finlayson at live555.com  Mon Jun 28 15:17:43 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 28 Jun 2010 15:17:43 -0700
Subject: [Live-devel] mixed rtp payload
In-Reply-To: <1277734510.4c28ae6e252e5@imp.celeos.eu>
References: <1277731788.4c28a3cc0ecc8@imp.celeos.eu>
	<f06240801c84e5bf11453@[66.80.62.44]>
	<1277734510.4c28ae6e252e5@imp.celeos.eu>
Message-ID: <f06240802c84ecfb17bcc@[66.80.62.44]>

>m=data 0 RTP/AVP 111
>a=rtpmap:111 octet-stream/1
>a=fmtp:111 Mac=08007b885ad5; Model=VCC-HD2500P; TargetBitRate=900;
>FirmVer=01030000; CameraSeries=2;

Yes, this is something totally non-standard.  However, I think you 
can receive this data by adding the command-line option "-S 0" to 
"openRTSP".  (<http://www.live555.com/openRTSP/#other-options>)
-- 

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

From finlayson at live555.com  Mon Jun 28 22:28:56 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Mon, 28 Jun 2010 22:28:56 -0700
Subject: [Live-devel] JPEG file over RTP
In-Reply-To: <AANLkTin-sMt-0t3qaWYt_bTIQP4c4rpsyslLE-bny8OI@mail.gmail.com>
References: <AANLkTin-sMt-0t3qaWYt_bTIQP4c4rpsyslLE-bny8OI@mail.gmail.com>
Message-ID: <f06240802c84f28a25f4f@[66.80.62.44]>

>The problem is that when I come to decode the stream in VLC the 
>image is far blockier than the original.  Why is this?  What am I 
>doing wrong?

I don't know, in part because you're missing some details about your 
implementation.  In particular, you didn't say anything about your 
implementation of the following pure virtual functions defined for 
"JPEGVideoSource":
	virtual u_int8_t type() = 0;
	virtual u_int8_t qFactor() = 0;
	virtual u_int8_t width() = 0; // # pixels/8 (or 0 for 2048 pixels)
	virtual u_int8_t height() = 0; // # pixels/8 (or 0 for 2048 pixels)

In any case, though, I suggest that - if possible - you test your 
system first by receiving data into a file (by connecting a 
"JPEGVideoRTPSource" to a "FileSink"), and looking at the resulting 
data using a JPEG image viewer (rather than a media player like VLC). 
If your server implements RTSP, then this is easy: Just run 
"openRTSP" with the "-m" option.
-- 

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

From sebastien-devel at celeos.eu  Tue Jun 29 00:09:48 2010
From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier)
Date: Tue, 29 Jun 2010 09:09:48 +0200
Subject: [Live-devel] mixed rtp payload
In-Reply-To: <f06240802c84ecfb17bcc@[66.80.62.44]>
References: <1277731788.4c28a3cc0ecc8@imp.celeos.eu>
	<f06240801c84e5bf11453@[66.80.62.44]>
	<1277734510.4c28ae6e252e5@imp.celeos.eu>
	<f06240802c84ecfb17bcc@[66.80.62.44]>
Message-ID: <1277795388.7448.15.camel@sebastien-desktop>

On Mon, 2010-06-28 at 15:17 -0700, Ross Finlayson wrote:
> >m=data 0 RTP/AVP 111
> >a=rtpmap:111 octet-stream/1
> >a=fmtp:111 Mac=08007b885ad5; Model=VCC-HD2500P; TargetBitRate=900;
> >FirmVer=01030000; CameraSeries=2;
> 
> Yes, this is something totally non-standard.  However, I think you 
> can receive this data by adding the command-line option "-S 0" to 
> "openRTSP".  (<http://www.live555.com/openRTSP/#other-options>)

Thank you Ross.
I tried this, but it doesn't work.
I think the issue is because there are two streams but only one
a=control attribute in the sdp description.
The camera sends both video and data in the same stream, and this seems
to be non standard.
If I understood the RTSP rfc correctly, each session must have its own
control attribute.

Sebastien.

Kamil : I don't use TCP method but I tried the -t option and it works.



From finlayson at live555.com  Tue Jun 29 00:16:50 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 29 Jun 2010 00:16:50 -0700
Subject: [Live-devel] mixed rtp payload
In-Reply-To: <1277795388.7448.15.camel@sebastien-desktop>
References: <1277731788.4c28a3cc0ecc8@imp.celeos.eu>
	<f06240801c84e5bf11453@[66.80.62.44]>
	<1277734510.4c28ae6e252e5@imp.celeos.eu>
	<f06240802c84ecfb17bcc@[66.80.62.44]>
	<1277795388.7448.15.camel@sebastien-desktop>
Message-ID: <f06240801c84f4e4790c8@[66.80.62.44]>

>I tried this, but it doesn't work.
>I think the issue is because there are two streams but only one
>a=control attribute in the sdp description.
>The camera sends both video and data in the same stream, and this seems
>to be non standard.

Yes, it looks like you're out of luck.
-- 

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

From kamildobk at poczta.onet.pl  Tue Jun 29 00:25:31 2010
From: kamildobk at poczta.onet.pl (Kamil Dobkowski)
Date: Tue, 29 Jun 2010 09:25:31 +0200
Subject: [Live-devel] mixed rtp payload
In-Reply-To: <1277795388.7448.15.camel@sebastien-desktop>
Message-ID: <4E9B65BFB7354D0AA2FE80CB21C06BA2@KamilPC>

> Kamil : I don't use TCP method but I tried the -t option and it works.

This is strange. I tried it a few times and it didn't work. Of course OpenRTSP client connects correctly, invokes PLAY and shows messages that is sending/receiving some control packets - everything looks ok at first glance, but eventually nothing is written to the output file ( sometimes there is a few hundred bytes ). The same is with HTTP. 

Kamil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100629/46b9596a/attachment.html>

From finlayson at live555.com  Tue Jun 29 00:47:16 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 29 Jun 2010 00:47:16 -0700
Subject: [Live-devel] mixed rtp payload
In-Reply-To: <4E9B65BFB7354D0AA2FE80CB21C06BA2@KamilPC>
References: <4E9B65BFB7354D0AA2FE80CB21C06BA2@KamilPC>
Message-ID: <f06240802c84f55252cfe@[66.80.62.44]>

>  > Kamil : I don't use TCP method but I tried the -t option and it works.
>
>This is strange. I tried it a few times and it didn't work. Of 
>course OpenRTSP client connects correctly, invokes PLAY and shows 
>messages that is sending/receiving some control packets - everything 
>looks ok at first glance, but eventually nothing is written to the 
>output file ( sometimes there is a few hundred bytes ). 

For the third time: If anyone is experiencing problems with 
"openRTSP" receiving a stream using RTP-over-TCP, then please send us 
a (publically-accessible) "rtsp://" URL of a stream that illustrates 
the problem, so we can test it for ourselves.
-- 

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/20100629/a179e8db/attachment.html>

From sebastien-devel at celeos.eu  Tue Jun 29 00:52:55 2010
From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier)
Date: Tue, 29 Jun 2010 09:52:55 +0200
Subject: [Live-devel] mixed rtp payload
In-Reply-To: <4E9B65BFB7354D0AA2FE80CB21C06BA2@KamilPC>
References: <4E9B65BFB7354D0AA2FE80CB21C06BA2@KamilPC>
Message-ID: <1277797975.7448.18.camel@sebastien-desktop>

On Tue, 2010-06-29 at 09:25 +0200, Kamil Dobkowski wrote:

> This is strange. I tried it a few times and it didn't work. Of course
> OpenRTSP client connects correctly, invokes PLAY and shows messages
> that is sending/receiving some control packets - everything looks ok
> at first glance, but eventually nothing is written to the output file
> ( sometimes there is a few hundred bytes ). The same is with HTTP. 

actually you're right, nothing is written to the output file. I thought
it worked because the rtsp dialogue is ok, and tcp packets are well
transmitted (checked this with wireshark).

I tested with an old version of live555 and it's working, the output
file is not empty.

Sebastien.




From kamildobk at poczta.onet.pl  Tue Jun 29 02:00:45 2010
From: kamildobk at poczta.onet.pl (Kamil Dobkowski)
Date: Tue, 29 Jun 2010 11:00:45 +0200
Subject: [Live-devel] mixed rtp payload
In-Reply-To: <f06240801c84ecd67f294@[66.80.62.44]>
Message-ID: <DD05451B1E9141FC9F4E7EE9C3C1D9C0@KamilPC>

> Please send us the (publically-accessible) "rtsp://" URL of a server 
> that illustrates this problem.  (The RTP-over-TCP implementation in 
> recent versions should have been *improved*, so I'm a bit suprised to 
> hear reports of bugs here.)

Yes I know, I'll try, but it can take a few days.

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

From andy at j2kvideo.com  Tue Jun 29 03:37:11 2010
From: andy at j2kvideo.com (Andy Bell)
Date: Tue, 29 Jun 2010 12:37:11 +0200
Subject: [Live-devel] JPEG file over RTP
In-Reply-To: <f06240802c84f28a25f4f@66.80.62.44>
References: <AANLkTin-sMt-0t3qaWYt_bTIQP4c4rpsyslLE-bny8OI@mail.gmail.com>
	<f06240802c84f28a25f4f@66.80.62.44>
Message-ID: <AANLkTilQzsrK8jZsMvvIYtkml1_XxLMLZ7YpEFydmlx-@mail.gmail.com>

On Tue, Jun 29, 2010 at 7:28 AM, Ross Finlayson <finlayson at live555.com>wrote:

> The problem is that when I come to decode the stream in VLC the image is
>> far blockier than the original.  Why is this?  What am I doing wrong?
>>
>
> I don't know, in part because you're missing some details about your
> implementation.  In particular, you didn't say anything about your
> implementation of the following pure virtual functions defined for
> "JPEGVideoSource":
>        virtual u_int8_t type() = 0;
>        virtual u_int8_t qFactor() = 0;
>        virtual u_int8_t width() = 0; // # pixels/8 (or 0 for 2048 pixels)
>        virtual u_int8_t height() = 0; // # pixels/8 (or 0 for 2048 pixels)
>
> In any case, though, I suggest that - if possible - you test your system
> first by receiving data into a file (by connecting a "JPEGVideoRTPSource" to
> a "FileSink"), and looking at the resulting data using a JPEG image viewer
> (rather than a media player like VLC). If your server implements RTSP, then
> this is easy: Just run "openRTSP" with the "-m" option.
>

Hi Ross,

TestJPEGVideoSource* TestJPEGVideoSource::createNew(UsageEnvironment& env,
const char * fileName, unsigned int timePerFrame)

{

FILE * fid = fopen( fileName, "r" );

 if ( fid == NULL )

{

env.setResultErrMsg( "Failed to open input device file" );

return NULL;

}

 return new TestJPEGVideoSource( env, fid, timePerFrame );

}


TestJPEGVideoSource::TestJPEGVideoSource(UsageEnvironment& env, FILE* fid,
unsigned int timePerFrame)

: JPEGVideoSource(env), fFid(fid), fTimePerFrame(timePerFrame),
fNeedAFrame(False)

{

this->buffer = NULL;

fseek( fid, 0L, SEEK_END );

size_t sz = ftell( fFid );

fseek( fid, 0L, SEEK_SET );

 buffer = new unsigned char[ sz ];

fread( buffer, 1, sz, fid );

bool sof0 = false;

bool sos = false;

this->sosIndex = 0;

this->sosSize = 0;

 for ( int i = 0; i < (int)(sz - 8); ++i )

{

if ( buffer[i] == 0xFF && buffer[i+1] == 0xC0)

{

fLastHeight = (buffer[i+5]<<5)|(buffer[i+6]>>3);

fLastWidth = (buffer[i+7]<<5)|(buffer[i+8]>>3);

if ( sos && sof0 ) break;

}

else if ( buffer[i] == 0xFF && buffer[i+1] == 0xDA )

{

sosIndex = i + 2;

if ( sos && sof0 ) break;

}

 }

 if ( this->sosIndex > 0 )

this->sosSize = sz - this->sosIndex;

 printf( "Streaming image w=%d h=%d total_size=%d sos_size=%d\n", fLastWidth
* 8, fLastHeight * 8, (int)sz, this->sosSize );

fclose(fFid);

}


TestJPEGVideoSource::~TestJPEGVideoSource()

{

if ( this->buffer ) delete [] buffer;

}


void TestJPEGVideoSource::doGetNextFrame()

{

fFrameSize = this->sosSize;

 if ( fFrameSize > fMaxSize )

{

printf( "Truncating frame!!\n" );

fNumTruncatedBytes = fFrameSize - fMaxSize;

fFrameSize = fMaxSize;

}

 memcpy( fTo, this->buffer + this->sosIndex, fFrameSize );

 if ( fPresentationTime.tv_sec == 0 && fPresentationTime.tv_usec == 0 )

{

gettimeofday( &fPresentationTime, NULL );

}

else

{

unsigned uSeconds = fPresentationTime.tv_usec + ( fTimePerFrame * 1000 );

fPresentationTime.tv_sec += uSeconds / 1000000;

fPresentationTime.tv_usec = uSeconds % 1000000;

}


 fDurationInMicroseconds = fTimePerFrame * 1000;

 nextTask() = envir().taskScheduler().scheduleDelayedTask( 0,
(TaskFunc*)FramedSource::afterGetting, this );

}

u_int8_t TestJPEGVideoSource::type()

{

return 1;

}

u_int8_t TestJPEGVideoSource::qFactor()

{

return 65;

}

u_int8_t TestJPEGVideoSource::width()

{

return fLastWidth;

}

u_int8_t TestJPEGVideoSource::height()

{

return fLastHeight;

}

That's pretty much it.  I have downloaded an image from an RTSP source using
openRTSP saving each frame as a JPG file.  I am the using one these JPG
files to be used as a source for the above code.  I have then connected
using openRTSP to my server streaming back the above source.  I have
attached the 'input' image and the 'output' image of the process.

Thanks, Andy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100629/efd28719/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: input.jpg
Type: image/jpeg
Size: 15701 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100629/efd28719/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output.jpg
Type: image/jpeg
Size: 15713 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100629/efd28719/attachment-0003.jpg>

From jnoring at logitech.com  Tue Jun 29 11:33:15 2010
From: jnoring at logitech.com (Jeremy Noring)
Date: Tue, 29 Jun 2010 11:33:15 -0700
Subject: [Live-devel] How to contribute code?
In-Reply-To: <6353CA579307224BAFDE9495906E691604BC7BE3@ca-ops-mail>
References: <201006181210.31991.david.stegbauer@acision.com>
	<f06240803c84130359c83@66.80.62.44>
	<AANLkTinxmob3m8yR8CJmMid8uzgpzKW4bNTKASi7F8R1@mail.gmail.com>
	<f06240802c845d0de604c@66.80.62.44>
	<AANLkTinQiZPvQt9QBspbLrq4DBuGnnUUZ1bQsm-HZvyE@mail.gmail.com>
	<6353CA579307224BAFDE9495906E691604BC7BE3@ca-ops-mail>
Message-ID: <AANLkTikOKD-zRla_pmR6It54XPOu-1OflYRkq6nazva_@mail.gmail.com>

On Thu, Jun 24, 2010 at 9:00 AM, BONNEAU Guy <gbonneau at miranda.com> wrote:

>  Jeremy,
>
>
>
> Since you already manage an open source project would you be available to
> setup and manage an open source public repository for live555. We could
> commit the sources as Ross release them since they are of public domain. I
> could offer some help if you want. Ross would only need to setup an URL link
> in the FAQ section for those people that want an history browsing of the
> changes for whatever reason.
>

Assuming this is acceptable to Ross, yes, I'd be happy to.  I do respect
that this isn't my project, and my intention isn't to rock any boats.

Ross, would this be okay with you?  Of course, your policy of supporting
trunk would remain in place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100629/a7724ee0/attachment.html>

From finlayson at live555.com  Tue Jun 29 13:07:17 2010
From: finlayson at live555.com (Ross Finlayson)
Date: Tue, 29 Jun 2010 13:07:17 -0700
Subject: [Live-devel] How to contribute code?
In-Reply-To: <AANLkTikOKD-zRla_pmR6It54XPOu-1OflYRkq6nazva_@mail.gmail.com>
References: <201006181210.31991.david.stegbauer@acision.com>
	<f06240803c84130359c83@66.80.62.44>
	<AANLkTinxmob3m8yR8CJmMid8uzgpzKW4bNTKASi7F8R1@mail.gmail.com>
	<f06240802c845d0de604c@66.80.62.44>
	<AANLkTinQiZPvQt9QBspbLrq4DBuGnnUUZ1bQsm-HZvyE@mail.gmail.com>
	<6353CA579307224BAFDE9495906E691604BC7BE3@ca-ops-mail>
	<AANLkTikOKD-zRla_pmR6It54XPOu-1OflYRkq6nazva_@mail.gmail.com>
Message-ID: <f06240800c84ff9780a99@[66.80.62.44]>

When I say that I don't support old versions of the code, that also 
means that I don't provide any *links* to old versions of the code. 
So, while anyone is, of course, free to keep around any old versions 
of the code that they wish, I won't be providing or publicizing (on 
the "live555.com" web site or elsewhere) any links to these.

The reason is quite simple: When a new version of the code is 
released, it's usually to fix bugs.  I can't, with a clear 
conscience, endorse a copy of the code that I know is buggy.

However, there was recently a rare exception to this - a new version 
that did not fix bugs, but instead was a major reimplementation of 
existing functionality (the "RTSPClient" class).  Although this was 
intended to improve the code, it also introduced some new bugs (most 
of which now appear to have been fixed, although there remain some 
unverified reports of problems with RTP-over-TCP).

I gave serious thought to making an exception for that particular 
version, and releasing it as a separate, 'experimental' release, 
separate from the usual 'latest' release ("live555-latest.tar.gz"). 
In hindsight, perhaps I should have done that.  It would have allowed 
people to avoid encountering bugs in the new "RTSPClient" 
implementation, but it also would have meant that these bugs would 
not have been found as quickly (because few people would have ended 
up trying the 'experimental' release).  (Note that the new 
"RTSPClient" implementation has so far also exposed a bug in at least 
one other server (camera) implementation, as well as a bug in our own 
"openRTSP" application code - neither of which would not have been 
found nearly as quickly (if at all) had we not made people endure the 
temporary pain of dealing with this new implementation.)
-- 

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

From george.toma at fundp.ac.be  Wed Jun 30 01:20:39 2010
From: george.toma at fundp.ac.be (George Toma)
Date: Wed, 30 Jun 2010 10:20:39 +0200
Subject: [Live-devel]  RTCP RR handler
In-Reply-To: <4C2A09BA.3090002@info.fundp.ac.be>
References: <4C2A09BA.3090002@info.fundp.ac.be>
Message-ID: <4C2AFE57.4020706@fundp.ac.be>

Hello,

I want to implement an adaptive streaming algorithm in the livemedia 
server, based on the information sent in the RTCP reports and also in 
some additional RTCP APP reports. I studied a bit the livemedia code and 
I was thinking that the way to do this is to create a RRhandler which 
will be called every RTCP RR packet.
Is this a good way to do it or do you think there is a better one ? Any 
advice would be much appreciated.

Thank you,
George

-- 
George Toma, Researcher
---------------------------
Faculty of Computer Science
University of Namur (FUNDP)
http://www.fundp.ac.be/facultes/info/
Tel: +32 81 724 999        
--------------------------- 


From david.stegbauer at acision.com  Wed Jun 30 03:01:35 2010
From: david.stegbauer at acision.com (David Stegbauer)
Date: Wed, 30 Jun 2010 12:01:35 +0200
Subject: [Live-devel] [PATCH] use cmake for building
Message-ID: <201006301201.35974.david.stegbauer@acision.com>

Hi all,

attached please find CMakeLists.txt configuration file for live555. It works on 
Linux, it is not tested on anything else yet. I'd like to know if it is 
acceptable to use cmake - if yes, then I will extend it for other platforms.
It is not intended to replace original makefiles.

Please let me know what do you think about it.

How to use it:

Copy CMakeLists.txt file into directory where live sources are (the same which 
contains genMakefiles), referenced as <path-to-live-source-dir> below .

If you would like to build in the same directory as sources are, then type:
cd <path-to-live-source-dir>
cmake .
make

If you would like to build in other directory (so called "out of source 
build"), for example in /tmp/live , then type:
mkdir /tmp/live
cd /tmp/live
cmake <path-to-live-source-dir>
make

If you will use "out of source build", then your source directory stays 
intact, it could even be read-only. I use it this way because then source 
directory easily could be shared between several machines.

Best Regards
David Stegbauer


This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMakeLists.txt
Type: text/x-cmake
Size: 5862 bytes
Desc: CMakeLists.txt
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100630/06786ae8/attachment.bin>

From gbonneau at miranda.com  Wed Jun 30 05:27:30 2010
From: gbonneau at miranda.com (BONNEAU Guy)
Date: Wed, 30 Jun 2010 08:27:30 -0400
Subject: [Live-devel] How to contribute code?
In-Reply-To: <f06240800c84ff9780a99@[66.80.62.44]>
References: <201006181210.31991.david.stegbauer@acision.com><f06240803c84130359c83@66.80.62.44><AANLkTinxmob3m8yR8CJmMid8uzgpzKW4bNTKASi7F8R1@mail.gmail.com><f06240802c845d0de604c@66.80.62.44><AANLkTinQiZPvQt9QBspbLrq4DBuGnnUUZ1bQsm-HZvyE@mail.gmail.com><6353CA579307224BAFDE9495906E691604BC7BE3@ca-ops-mail><AANLkTikOKD-zRla_pmR6It54XPOu-1OflYRkq6nazva_@mail.gmail.com>
	<f06240800c84ff9780a99@[66.80.62.44]>
Message-ID: <6353CA579307224BAFDE9495906E691604C45606@ca-ops-mail>

Ross,

|
|When I say that I don't support old versions of the code, that also
|means that I don't provide any *links* to old versions of the code.
|So, while anyone is, of course, free to keep around any old versions
|of the code that they wish, I won't be providing or publicizing (on
|the "live555.com" web site or elsewhere) any links to these.
|
|The reason is quite simple: When a new version of the code is
|released, it's usually to fix bugs.  I can't, with a clear
|conscience, endorse a copy of the code that I know is buggy.

I agree with you and understand your point about supporting old release.
However this being said my point of view is a source repository is not
about supporting old release. It is about knowledge and information. And
for this purpose it can only benefit the whole community using the
live555 library. A few years ago I had to implement the full SMPTE
2022-1 specification to the live555 library. For this purpose I had to
dig deeper in the library. To gain knowledge about the how and why of
some part of the code I really missed an history insight from a source
control repository. 

For professional development when you jump into a code with no a priori
knowledge an history repository is a great professional tool. It can
spare you of many hours if not days of struggling into understanding the
code.

Remember you wrote the live555 history. It is in your brain. For this
reason it is quite understandable that you don't need an history
repository. You own it. You write the book. But I didn't and this is
also shared by many others people.

I hope you will reconsider your decision about providing an external
link to an history repository for the benefit of the community and
everyone working with the live555 library. 

|
|However, there was recently a rare exception to this - a new version
|that did not fix bugs, but instead was a major reimplementation of
|existing functionality (the "RTSPClient" class).  Although this was
|intended to improve the code, it also introduced some new bugs (most
|of which now appear to have been fixed, although there remain some
|unverified reports of problems with RTP-over-TCP).
|
|I gave serious thought to making an exception for that particular
|version, and releasing it as a separate, 'experimental' release,
|separate from the usual 'latest' release ("live555-latest.tar.gz").
|In hindsight, perhaps I should have done that.  It would have allowed
|people to avoid encountering bugs in the new "RTSPClient"
|implementation, but it also would have meant that these bugs would
|not have been found as quickly (because few people would have ended
|up trying the 'experimental' release).  (Note that the new
|"RTSPClient" implementation has so far also exposed a bug in at least
|one other server (camera) implementation, as well as a bug in our own
|"openRTSP" application code - neither of which would not have been
|found nearly as quickly (if at all) had we not made people endure the
|temporary pain of dealing with this new implementation.)
|--
|
|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 andy at j2kvideo.com  Wed Jun 30 11:10:10 2010
From: andy at j2kvideo.com (Andy Bell)
Date: Wed, 30 Jun 2010 20:10:10 +0200
Subject: [Live-devel] MJPEG woes
Message-ID: <AANLkTimzSF_cmnESnGmTb4QvGIHa4HPDOrE0s3ZM49Rz@mail.gmail.com>

Hi,

I have been trying to use Live555 to stream a JPEG file to OpenRTSP and
other Live555 based clients.

Depending on the source JPEG file I get varying results in quality.  When
streaming the JPEG file I am simply finding the SOS marker and copying this
to fTo, the code is below.  I am starting to think that I need to be
something else here as at the client side, for example OpenRTSP, isn't the
exact same image.

For example, if I connect to an IP camera, streaming MJPEG, with OpenRTSP I
can get an image saved as a JPEG using:

./openRTSP -m rtsp://....

I then use this same image with the code below and use openRTSP again to
stream the image and I get something far blockier.

Where am I going wrong?

Thanks in advance
Andy

TestJPEGVideoSource* TestJPEGVideoSource::createNew(UsageEnvironment& env,
const char * fileName, unsigned int timePerFrame)

{

FILE * fid = fopen( fileName, "r" );

 if ( fid == NULL )

{

env.setResultErrMsg( "Failed to open input device file" );

return NULL;

}

 return new TestJPEGVideoSource( env, fid, timePerFrame );

}


TestJPEGVideoSource::TestJPEGVideoSource(UsageEnvironment& env, FILE* fid,
unsigned int timePerFrame)

: JPEGVideoSource(env), fFid(fid), fTimePerFrame(timePerFrame),
fNeedAFrame(False)

{

this->buffer = NULL;

fseek( fid, 0L, SEEK_END );

size_t sz = ftell( fFid );

fseek( fid, 0L, SEEK_SET );

 buffer = new unsigned char[ sz ];

fread( buffer, 1, sz, fid );

bool sof0 = false;

bool sos = false;

this->sosIndex = 0;

this->sosSize = 0;

 for ( int i = 0; i < (int)(sz - 8); ++i )

{

if ( buffer[i] == 0xFF && buffer[i+1] == 0xC0)

{

fLastHeight = (buffer[i+5]<<5)|(buffer[i+6]>>3);

fLastWidth = (buffer[i+7]<<5)|(buffer[i+8]>>3);

if ( sos && sof0 ) break;

}

else if ( buffer[i] == 0xFF && buffer[i+1] == 0xDA )

{

sosIndex = i + 2;

if ( sos && sof0 ) break;

}

 }

 if ( this->sosIndex > 0 )

this->sosSize = sz - this->sosIndex;

 printf( "Streaming image w=%d h=%d total_size=%d sos_size=%d\n", fLastWidth
* 8, fLastHeight * 8, (int)sz, this->sosSize );

fclose(fFid);

}


TestJPEGVideoSource::~TestJPEGVideoSource()

{

if ( this->buffer ) delete [] buffer;

}


void TestJPEGVideoSource::doGetNextFrame()

{

fFrameSize = this->sosSize;

 if ( fFrameSize > fMaxSize )

{

printf( "Truncating frame!!\n" );

fNumTruncatedBytes = fFrameSize - fMaxSize;

fFrameSize = fMaxSize;

}

 memcpy( fTo, this->buffer + this->sosIndex, fFrameSize );

 if ( fPresentationTime.tv_sec == 0 && fPresentationTime.tv_usec == 0 )

{

gettimeofday( &fPresentationTime, NULL );

}

else

{

unsigned uSeconds = fPresentationTime.tv_usec + ( fTimePerFrame * 1000 );

fPresentationTime.tv_sec += uSeconds / 1000000;

fPresentationTime.tv_usec = uSeconds % 1000000;

}


fDurationInMicroseconds = fTimePerFrame * 1000;

 nextTask() = envir().taskScheduler().scheduleDelayedTask( 0,
(TaskFunc*)FramedSource::afterGetting, this );

}

u_int8_t TestJPEGVideoSource::type()

{

return 1;

}

u_int8_t TestJPEGVideoSource::qFactor()

{

return 65;

}

u_int8_t TestJPEGVideoSource::width()

{

return fLastWidth;

}

u_int8_t TestJPEGVideoSource::height()

{

return fLastHeight;

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