headers
Doug Porter | 1 Jun 2010 19:52

RTSP over HTTP patch

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
 <at>  <at>  -664,6 +664,11  <at>  <at> 
       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
Permalink | Reply | 2 comments |
headers
Doug Porter | 2 Jun 2010 00:21

Re: New, improved "RTSPClient" interface now available

Ross Finlayson <finlayson@...> 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
Permalink | Reply | 6 comments |
headers
Ross Finlayson | 2 Jun 2010 09:10
Favicon

Re: New, improved "RTSPClient" interface now available

>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/
Permalink | Reply | 4 comments |
headers
Ross Finlayson | 2 Jun 2010 09:19
Favicon

Re: RTSP over HTTP patch

>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/
Permalink | Reply | 0 comments |
headers
Miguel Angel Arcos | 2 Jun 2010 09:28

FPS limit

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

_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 4 comments |
headers
Doug Porter | 2 Jun 2010 18:21

Re: New, improved "RTSPClient" interface now available

Ross Finlayson <finlayson@...> 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
Permalink | Reply | 2 comments |
headers
Ross Finlayson | 3 Jun 2010 04:36
Favicon

Re: FPS limit

>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/
Permalink | Reply | 2 comments |
headers
Melms, Kenneth | 3 Jun 2010 18:13

MPEG2TransportStreamIndexer still fails on some files

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-USCIjHQIazI/1aL3O+LjVg@public.gmane.org/public/live555%5Fwont%5Findex.zip

 

Thanks in advance,

 

Ken Melms

 

_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 4 comments |
headers
Ross Finlayson | 3 Jun 2010 19:17
Favicon

Re: 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-USCIjHQIazI/1aL3O+LjVg@public.gmane.org/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/
_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 2 comments |
headers
Melms, Kenneth | 3 Jun 2010 20:34

Re: MPEG2TransportStreamIndexer still fails on some files

xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

Re: [Live-devel] MPEG2TransportStreamIndexer still fails o

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-m22LxytlYjp4ccXRSk2lxg@public.gmane.org [mailto:live-devel-bounces-m22LxytlYjp4ccXRSk2lxg@public.gmane.org] 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-USCIjHQIazI/1aL3O+LjVg@public.gmane.org/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.

_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply | 0 comments |

Gmane