[Live-devel] openRTSP, how to capture ONVIF metadata stream content?

[p]

Hello,

This may just be me missing something small / being stupid, but..:

when I connect to an RTSP camera stream like so:

openRTSP rtsp://USER:PASSWORD@192.168.1.20:5554/live/ch1

part of the output I see is:

--
Received 170 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK
CSeq: 6
Transport: 
RTP/AVP;unicast;client_port=39458-39459;server_port=20002-20003;ssrc=44ADCF73
Session: F4A7DBD1AE95170FF8D9DC8DA7E3FE;timeout=60


Setup "application/VND.ONVIF.METADATA" subsession (client ports 39458-39459)
Created output file: "video-H264-1"
Created output file: "application-VND.ONVIF.METADATA-2"
--


After that, the video file fills up ok, but the "metadata" file remains empty.

What could be a reason for this?
(I'd like to capture only the metadata)

Thanks in any case,
best,

Patrick
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] what to do about error 104 (Connection reset by peer)?

[p]

Hi,

I modified testRTSPClient to only process ONVIF metadata from a "smart" camera.

In DummySink::afterGettingFrame there's a line:

if (strcmp(fSubsession.mediumName(), "application") == 0) {
...

after which it processes the metadata.

This runs for a short while, after which recvfrom in 
GroupsockHelper::readSocket returns error 104.
(and the program hangs, or rather, does not receive any more data)

Am I missing something, should I maybe do something with the incoming video 
data?

Or should I contact the camera people about this error?

I can post more debug output if needed.

Thanks in advance,

Patrick


___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Video from ip camera by private protocol.

[p . gavrya]

Hi !I'm just starting to understand the library, help with advice.I get data from the IP CCTV camera on a private video protocol. Data from the camera comes in fragments in real time.In the SDK camera, I register a callback function in which I process the data. After processing this data in the buffer, I get a video stream in the x264 format.How can I transfer this stream via RTSP now?
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] openRTSP, how to capture ONVIF metadata stream content?

[P. Min]

> You could check this for sure by running ?testRTSPClient? (rather than 
> ?openRTSP?), because ?testRTSPClient? outputs a line for every RTP packet 
> that it receives.

Thanks, that's useful: indeed only seeing video/H264 packets arrive.

Do you know of a public test camera that produces a metadata stream so I can 
confirm it does work for a different setup?


Patrick

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] openRTSP, how to capture ONVIF metada stream content?

[P. Min]

With some help of the camera's technical people I was able to switch on the 
ONVIF metadata stream :-)

I added a parameter to openRTSP such that only the metadata is saved
(for those who want to dig in the source and do the same: set 'singleMedium' to 
"application")

thanks again,

Patrick


   --

   Message: 1
   Date: Fri, 1 Nov 2019 10:32:18 +0100
   From: "P. Min" 
   To: live-de...@us.live555.com
   Subject: Re: [Live-devel] openRTSP, how to capture ONVIF metada stream 
content?
   Message-ID: <201911010932.xa19wigc024...@pmcp.nl>


   > You could check this for sure by running ?testRTSPClient? (rather than 
?openRTSP?), because ?testRTSPClient? outputs a line for every RTP packet that 
it receives.

   Thanks, that's useful: indeed only seeing video/H264 packets arrive.

   Do you know of a public test camera that produces a metadata stream so I can 
confirm it does work for a different setup?


   Patrick



   --

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] what to do about error 104 (Connection reset by peer)?

[P. Min]

   
>   > This runs for a short while, after which recvfrom in 
> GroupsockHelper::readSocket returns error 104.
>
>   What does that error number mean on your system?  (In other words, what 
> does it show for error number 104 when you run ?man errno??)

"Connection reset by peer"

(perror() shows this as well)

>   > (and the program hangs, or rather, does not receive any more data)
>
>   Does the same thing happen when you run (the unmodified) ?openRTSP? 
> application  on this stream?

It seems to run a bit longer, then the same thing happens.


Some output from near the error (some of which is my debug output):

--

FileSink::addData
--
http://www.onvif.org/ver10/schema"; 
xmlns:ns6="http://docs.oasis-open.org/wsn/b-2"; 
xmlns:tns1="http://www.onvif.org/ver10/topics"; 
xmlns:tnsitx="http://www.itxsecurity.com/onvif/event0/topics";>http://docs.oasis-open.org/wsn/t-1/TopicExpression/Concrete";>tnsitx:ITX/Metadata
--
schedule(0.372382->1574713791.871601)
schedule(0.95->1574713791.982991)
schedule(0.442492->1574713792.425568)
sending REPORT
sending RTCP packet
 81c90007 37f03886 7a24cdf2 00ff 00017468 8172 b839ef5c 00065b89 
81ca0004 37f03886 0107656d 6f686177 6b00
schedule(4.665670->1574713797.091455)
recvfrom error: : Connection reset by peer
RTSPClient::handleResponseBytes(-1)
  exiting because of error
sending REPORT
sending RTCP packet
 80c90001 37f03886 81ca0004 37f03886 0107656d 6f686177 6b00
schedule(5.035523->1574713802.127137)
sending REPORT
sending RTCP packet
 80c90001 37f03886 81ca0004 37f03886 0107656d 6f686177 6b00
schedule(4.322214->1574713806.449528)
sending REPORT
sending RTCP packet
 80c90001 37f03886 81ca0004 37f03886 0107656d 6f686177 6b00

--

I'll test some with different RTSP clients now.

Thanks again for the quick response :)

Patrick

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] what to do about error 104 (Connection reset by peer)?

[P. Min]

Another follow-up: it looks like the source stream is flaky.

Other clients (like ffmpeg, and yellow.js running under node) also stop after a 
while.

It would be great if there was a way to somehow reconnect to the stream when 
this happens
(I suppose I could just restart the program)

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Memory Leak while exiting from doEventLoop

[Soumya P N]

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

thanks in advance,,
Soumya.



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments contained in it.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Memory Leak while exiting from doEventLoop

[Soumya P N]

Hi Ross,

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

Thanks,
Soumya

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ross Finlayson
Sent: Wednesday, October 08, 2008 7:47 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Memory Leak while exiting from doEventLoop



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

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


Ross Finlayson
Live Networks, Inc. (LIVE555.COM)


___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel


The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments contained in it.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Unable to stream RTSP using Live555 proxy server

[Kiran P. Thakkar]

Hello Ross,


I and Saurabh are working on same project.

** **

We tried analyzing into what is happening by using the testRTSPClient as
suggested by you and here is the verbose dump of the testRTSPClient:

** **

Opening connection to 10.17.1.111, port 8554...

...remote connection opened

Sending request: DESCRIBE rtsp://10.17.1.111:8554/proxyStream RTSP/1.0

CSeq: 2

User-Agent:
D:\KiranThakkar\VMS\live555-latest-windows\live\testProgs\TestProgra

ms___Win32_Debug\TestPrograms.exe (LIVE555 Streaming Media v2012.06.26)

Accept: application/sdp

** **

** **

Received 101 new bytes of response data.

Received a complete DESCRIBE response:

RTSP/1.0 404 File Not Found, Or In Incorrect Format

CSeq: 2

Date: Thu, Jul 05 2012 09:23:54 GMT

** **

** **

[URL:"rtsp://10.17.1.111:8554/proxyStream"]: Failed to get a SDP
description: 40

4 File Not Found, Or In Incorrect Format

[URL:"rtsp://10.17.1.111:8554/proxyStream"]: Closing the stream.

Press any key to continue

** **

It seems that the live555 proxy server is unable to provide a response to
the DESCRIBE request sent from the client (testRTSPClient). What could be
the reason for this. I am hereby attaching the corresponding live555 proxy
server verbose dump as well for reference.

** **

LIVE555 Proxy Server

(LIVE555 Streaming Media library version 2012.06.26)

** **

Opening connection to 10.17.10.67, port 554...

RTSP stream, proxying the stream "rtsp://10.17.10.67/ch0_unicast_firststream
"

Play this stream using the URL "rtsp://10.17.1.111:8554/proxyStream"


** **

(We use port 80 for optional RTSP-over-HTTP tunneling.)

...remote connection opened

Sending request: DESCRIBE rtsp://10.17.10.67/ch0_unicast_firststream
 RTSP/1.0

CSeq: 2

User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)

Accept: application/sdp

** **

** **

Received 718 new bytes of response data.

Received a complete DESCRIBE response:

RTSP/1.0 200 OK

CSeq: 2

Date: Thu, Jul 05 2012 09:19:08 GMT

Content-Base: rtsp://10.17.10.67/ch0_unicast_firststream/

Content-Type: application/sdp

Content-Length: 542

** **

v=0

o=- 1341403933373938 1 IN IP4 10.17.10.67

s=Session of first stream

i=First Codec Stream

t=0 0

a=tool:LIVE555 Streaming Media v2007.08.03

a=type:broadcast

a=control:*

a=range:npt=0-

a=x-qt-text-nam:Session of first stream

a=x-qt-text-inf:First Codec Stream

m=video 0 RTP/AVP 96

c=IN IP4 0.0.0.0

a=rtpmap:96 H264/9

a=fmtp:96
packetization-mode=1;profile-level-id=428028;sprop-parameter-sets=Z0KA

KNoC0EkQ,aM48gA==

a=control:track1

m=metadata 0 RTP/AVP 97

c=IN IP4 0.0.0.0

a=rtpmap:97 METADATA/64000

a=control:track2

** **

ProxyServerMediaSession["rtsp://10.17.10.67/ch0_unicast_firststream/"]
added new

 "ProxyServerMediaSubsession" for RTP/video/H264 track

ProxyServerMediaSession["rtsp://10.17.10.67/ch0_unicast_firststream/"]
added new

 "ProxyServerMediaSubsession" for RTP/metadata/METADATA track

Opening connection to 10.17.10.67, port 554...

...remote connection opened

Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/
 RTSP/1.0

CSeq: 3

User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)

** **

** **

Received 122 new bytes of response data.

Received a complete OPTIONS response:

RTSP/1.0 200 OK

CSeq: 3

Date: Thu, Jul 05 2012 09:20:09 GMT

Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

** **

** **

ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 0)

Initiated: ProxyServerMediaSubsession["H264"]

ProxyServerMediaSubsession["H264"]::createNewRTPSink()

ProxyServerMediaSubsession["H264"]::closeStreamSource()

ProxyServerMediaSubsession["METADATA"]::createNewStreamSource(session id 0)*
***

Initiated: ProxyServerMediaSubsession["METADATA"]

Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/
 RTSP/1.0

CSeq: 4

User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)

** **

** **

Received 122 new bytes of response data.

Received a complete OPTIONS response:

RTSP/1.0 200 OK

CSeq: 4

Date: Thu, Jul 05 2012 09:20:42 GMT

Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

** **

** **

Opening connection to 10.17.10.67, port 554...

...remote connection opened

Sending request: OPTIONS rtsp://10.17.10.67/ch0_unicast_firststream/
 RTSP/1.0

CSeq: 5

User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)

** **

** **

Received 122 new bytes of response data.

Received a complete OPTIONS response:

RTSP/1.0 200 OK

CSeq: 5

Date: Thu, Jul 05 2012 09:21:29 GMT

Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN,

Re: [Live-devel] Unable to stream RTSP using Live555 proxy server

[Kiran P. Thakkar]

Dear Ross,

Thanks for your response. I have dump debug info which you have suggested.
Please find log below.

 LOG
INFO-START**
*LIVE555 Proxy Server*
*(LIVE555 Streaming Media library version 2012.06.26)*
*
*
*Opening connection to 10.17.10.56, port 554...*
*RTSP stream, proxying the stream "rtsp://
10.17.10.56/ch0_unicast_firststream"*
*Play this stream using the URL "rtsp://10.17.1.111:8554/proxyStream
"*
*
*
*(We use port 80 for optional RTSP-over-HTTP tunneling.)*
*...remote connection opened*
*Sending request: DESCRIBE rtsp://10.17.10.56/ch0_unicast_firststreamRTSP/1.0
*
*CSeq: 2*
*User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)*
*Accept: application/sdp*
*
*
*
*
*Received 716 new bytes of response data.*
*Received a complete DESCRIBE response:*
*RTSP/1.0 200 OK*
*CSeq: 2*
*Date: Fri, Jul 06 2012 11:05:59 GMT*
*Content-Base: rtsp://10.17.10.56/ch0_unicast_firststream/*
*Content-Type: application/sdp*
*Content-Length: 540*
*
*
*v=0*
*o=- 134131742256 1 IN IP4 10.17.10.56*
*s=Session of first stream*
*i=First Codec Stream*
*t=0 0*
*a=tool:LIVE555 Streaming Media v2007.08.03*
*a=type:broadcast*
*a=control:**
*a=range:npt=0-*
*a=x-qt-text-nam:Session of first stream*
*a=x-qt-text-inf:First Codec Stream*
*m=video 0 RTP/AVP 96*
*c=IN IP4 0.0.0.0*
*a=rtpmap:96 MP4V-ES/9*
*a=fmtp:96
profile-level-id=5;config=01B00501B5090100012000847A98*
*28A02240A31F*
*a=control:track1*
*m=metadata 0 RTP/AVP 97*
*c=IN IP4 0.0.0.0*
*a=rtpmap:97 METADATA/64000*
*a=control:track2*
*
*
*ProxyServerMediaSession["rtsp://10.17.10.56/ch0_unicast_firststream/"]
added new*
* "ProxyServerMediaSubsession" for RTP/video/MP4V-ES track*
*ProxyServerMediaSession["rtsp://10.17.10.56/ch0_unicast_firststream/"]
added new*
* "ProxyServerMediaSubsession" for RTP/metadata/METADATA track*
*Sending request: OPTIONS rtsp://10.17.10.56/ch0_unicast_firststream/RTSP/1.0
*
*CSeq: 3*
*User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)*
*
*
*
*
*Received 122 new bytes of response data.*
*Received a complete OPTIONS response:*
*RTSP/1.0 200 OK*
*CSeq: 3*
*Date: Fri, Jul 06 2012 11:06:33 GMT*
*Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE*
*
*
*
*
*accept()ed connection from 10.17.1.111*
*Liveness indication from client at 10.17.1.111*
*Liveness indication from client at 10.17.1.111*
*RTSPClientSession[02060068]::handleRequestBytes() read 161 new
bytes:DESCRIBE rt*
*sp://10.17.1.111:8554/proxyStream RTSP/1.0*
*CSeq: 2*
*User-Agent: testRTSPClient.exe (LIVE555 Streaming Media v2012.05.11)*
*Accept: application/sdp*
*
*
*
*
*parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE",
urlPreSuffix "*
*", urlSuffix "proxyStream", CSeq "2", Content-Length 0, with 0 bytes
following t*
*he message.*
*ProxyServerMediaSubsession["MP4V-ES"]::createNewStreamSource(session id 0)*
*Initiated: ProxyServerMediaSubsession["MP4V-ES"]*
*ProxyServerMediaSubsession["MP4V-ES"]::createNewRTPSink()*
*ProxyServerMediaSubsession["MP4V-ES"]::closeStreamSource()*
*ProxyServerMediaSubsession["METADATA"]::createNewStreamSource(session id 0)
*
*Initiated: ProxyServerMediaSubsession["METADATA"]*
*sending response: RTSP/1.0 404 File Not Found, Or In Incorrect Format*
*CSeq: 2*
*Date: Fri, Jul 06 2012 05:38:16 GMT*
*
*
*Liveness indication from client at 10.17.1.111*
*RTSPClientSession[02060068]::handleRequestBytes() read 0 new bytes (of
1); t*
*erminating connection!*
*Sending request: OPTIONS rtsp://10.17.10.56/ch0_unicast_firststream/RTSP/1.0
*
*CSeq: 4*
*User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)*
*
*
*
*
*Received 122 new bytes of response data.*
*Received a complete OPTIONS response:*
*RTSP/1.0 200 OK*
*CSeq: 4*
*Date: Fri, Jul 06 2012 11:07:10 GMT*
*Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE*
*
*
*
*
*Opening connection to 10.17.10.56, port 554...*
*...remote connection opened*
*Sending request: OPTIONS rtsp://10.17.10.56/ch0_unicast_firststream/RTSP/1.0
*
*CSeq: 5*
*User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.06.26)*
*
*
*
*
*Received 122 new bytes of response data.*
*Received a complete OPTIONS response:*
*RTSP/1.0 200 OK*
*CSeq: 5*
*Date: Fri, Jul 06 2012 11:08:09 GMT*
*Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE*

***LOG INFO
END**

I have verified Debug info from RTSPServer.cpp is effected It is keep
printing for  other working camera( It prints *Liveness indication from
client at 10.17.1.111..)*

In current log  also once its prints* **Liveness indication from client at
10.17.1.111.*
*
*
and  in testRTSPClient is giving following log which is similar
to previously
*
*
*
**LOG*

Re: [Live-devel] Unable to stream RTSP using Live555 proxy server

[Kiran P. Thakkar]

Dear Ross,

Thanks for your quick support.  It is working now.

It also comes to us notice that same type,same setting  different camera
has different metadata.

Regards
Kiran

On Fri, Jul 6, 2012 at 6:48 PM, Ross Finlayson wrote:

> OK, I figured out the problem - it was caused by the nonstandard
> 'metadata' track in the back-end stream.  Because this track is
> non-standard, we can't proxy it, but that should not have prevetnted the
> other, standard 'video' track from being proxied.
>
> I've now installed a new version "2012.07.06" of the "LIVE555 Streaming
> Media" software that should fix this problem.  Now, your front-end client
> should be able to receive the 'video' track OK.
>
> Thanks for bringing this issue to our attention.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> ___
> live-devel mailing list
> live-devel@lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Changing maxPacketSize value for H264VideoRTPSink

[Maxim P. DEMENTIEV]

Hello,

Currently I'm working on improving an RTSP/RTCP/RTP server based on Live
library which transmits the live H264 stream in HD resolution.

Trying to lower the CPU consumption by the server (the hot-spot was
MultiFramedRTPSink::sendNext callback), I increased the maxPacketSize
value (by calling setPacketSizes() in the subsession's
createNewRTPSink() before return). It has solved the problem but I worry
about the consequences.

So, I've got some questions:

1. What is the safe range for maxPacketSize regarding to the modern
RTSP/RTP clients and the local networks?

2. Can you give some advice about the net load/bandwidth balancing and
the size of the RTP packet in the context of Live library?

3. Are there other ways to reduce the CPU consumption by the
Fragmenter/Sink?

Thanks in advance!

Regards,
Max

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Changing maxPacketSize value for H264VideoRTPSink

[Maxim P. DEMENTIEV]

Thanks for your quick and informative reply!

Yes, the LAN - it's exactly my case.
I see that the new version of the library is delivered.
I'm going to use it and to send back my results of a performance testing.

Regards,
Max

On 07/23/2015 09:39 PM, Ross Finlayson wrote:
> Increasing the maximum packet size (up to some value < 2^16 bytes) can
> be a good idea if you’re planning to stream only over a LAN.  If,
> however, you’re planning to stream beyond a single LAN, then you
> should be aware that some routers (and/or firewalls) may limit the
> size of network packets that they can forward.  In that case your
> (larger) packets might not get forwarded at all.
>
> As you noted, increasing the packet size reduces the number of network
> packet sends that get done, and thus improves performance (though
> probably mostly due to to reduced OS overhead, not reduced overhead in
> the LIVE555 code).
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
> ___
> live-devel mailing list
> live-devel@lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Changing maxPacketSize value for H264VideoRTPSink

[Maxim P. DEMENTIEV]

I've added ability to optionally change the packet size with the help of
an environment variable, the executable is always the same.
(The technical details comes after the stat.)

Unfortunately, my application is quite complex, multi-threaded, contains
many layers (video4linux, DSP h264 encoder, ...) and at the moment I
cannot refine the statistics results by leaving only Live part of
application. But the results show big user space numbers (regarding to
the system time) for the default maxPacketSize value.

Here are results (using time utility from BusyBox; tries are separated
by slash in each row):

Default (1456, see MultiFramedRTPSink ctor):

User time (seconds):
43.08 / 46.08 / 33.89 / 46.28 / 53.94
System time (seconds):
47.82 / 28.30 / 43.79 / 24.22 / 23.69
Percent of CPU this job got:
71% / 58% / 61% / 55% / 61%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 7.84s / 2m 7.60s / 2m 6.85s / 2m 7.01s / 2m 6.30s

PACKET_SIZE=2048:

User time (seconds):
29.05 / 18.41 / 47.89 / 11.57 / 17.63
System time (seconds):
37.08 / 47.18 / 24.31 / 55.67 / 36.48
Percent of CPU this job got:
52% / 51% / 56% / 52% / 42%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 7.13s / 2m 7.67s / 2m 7.23s / 2m 7.22s / 2m 6.94s

PACKET_SIZE=4096:

User time (seconds):
25.21 / 18.73 / 23.99 / 6.71 / 21.29
System time (seconds):
32.76 / 20.99 / 26.58 / 37.43 / 23.52
Percent of CPU this job got:
45% / 31% / 39% / 34% / 35%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 6.96s / 2m 7.34s / 2m 7.22s / 2m 6.54s / 2m 7.93s

PACKET_SIZE=8192:

User time (seconds):
14.95 / 24.76 / 17.58 / 27.76 / 5.37
System time (seconds):
26.12 / 17.87 / 23.20 / 13.47 / 36.20
Percent of CPU this job got:
32% / 33% / 32% / 32% / 32%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 7.14s / 2m 6.98s / 2m 6.95s / 2m 6.70s / 2m 7.34s

PACKET_SIZE=12288:

User time (seconds):
4.10 / 5.41 / 5.56 / 15.13 / 9.53
System time (seconds):
6.90 / 34.60 / 34.42 / 15.99 / 15.95
Percent of CPU this job got:
8% / 31% / 31% / 23% / 20%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 6.94s / 2m 7.21s / 2m 6.50s / 2m 9.88s / 2m 6.83s

PACKET_SIZE=16384:

User time (seconds):
5.29 / 4.94 / 9.72 / 11.84 / 5.67
System time (seconds):
8.22 / 7.20 / 9.44 / 11.58 / 5.76
Percent of CPU this job got:
10% / 9% / 14% / 18% / 9%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 7.15s / 2m 7.14s / 2m 8.81s / 2m 6.59s / 2m 6.95s

PACKET_SIZE=20480:

User time (seconds):
24.05 / 22.31 / 33.34
System time (seconds):
14.58 / 19.66 / 5.85
Percent of CPU this job got:
30% / 32% / 30%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 6.69s / 2m 10.02s / 2m 6.83s

PACKET_SIZE=32768:

User time (seconds):
13.09 / 3.91 / 19.72 / 5.83 / 15.28
System time (seconds):
25.89 / 23.16 / 16.80 / 7.74 / 25.00
Percent of CPU this job got:
30% / 21% / 28% / 10% / 31%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 7.51s / 2m 7.72s / 2m 6.64s / 2m 6.66s / 2m 6.64s

Thech details:

Stream: H264 25fps 1920x1080, ~250 bytes/sec

root@target:~ uname -a
Linux cvms-cam 2.6.32.24-davinci1-00205-gbc35ad4-dirty #3 PREEMPT Tue
Jun 23 10:31:35 CEST 2015 armv5tejl GNU/Linux

root@target:~ cat /proc/cpuinfo
Processor: ARM926EJ-S rev 5 (v5l)
BogoMIPS: 215.44
Features: swp half thumb fastmult edsp java
CPU implementer: 0x41
CPU architecture: 5TEJ
CPU variant: 0x0
CPU part: 0x926
CPU revision: 5

root@target:~ /usr/bin/time --help
BusyBox v1.22.0 (2015-05-19 11:47:11 CEST) multi-call binary.

Cross-compiler GCC on the host: arm-none-linux-gnueabi-gcc (Sourcery G++
Lite 2009q3-67) 4.4.1

Parameters of the compilation:
arm-none-linux-gnueabi-g++ -c -Iinclude -I../UsageEnvironment/include
-I../groupsock/include -I. -Os -DSOCKLEN_T=socklen_t
-D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64
-DALLOW_RTSP_SERVER_PORT_REUSE -march=armv5te -mtune=arm926ej-s
-fdata-sections -ffunction-sections -fPIC -DPIC -Wall -DBSD=1 Media.cpp

Best regards,
Max


On 07/23/2015 09:39 PM, Ross Finlayson wrote:
> Increasing the maximum packet size (up to some value < 2^16 bytes) can
> be a good idea if you’re planning to stream only over a LAN.  If,
> however, you’re planning to stream beyond a single LAN, then you
> should be aware that some routers (and/or firewalls) may limit the
> size of network packets that they can forward.  In that case your
> (larger) packets might not get forwarded at all.
>
> As you noted, increasing the packet size reduces the number of network
> packet sends that get done, and thus improves performance (though
> probably mostly due to to reduced OS overhead, not reduced overhead in
> the LIVE555 code).
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
> ___
> live-devel mailing

[Live-devel] RTPSink for a PCM audio subsession

[Maxim P. DEMENTIEV]

Hello,

We need to broadcast the PCM (S16LE/16000) audio as a separate channel
with our RTSP-server.

I've found this letter for the AAC format:

http://lists.live555.com/pipermail/live-devel/2014-January/017980.html

What is a preferred RTPSink class that I should use for this audio
format in our OnDemandServerMediaSubsession?

Thank you!

Best regards,
Max

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] RTPSink for a PCM audio subsession

[Maxim P. DEMENTIEV]

Thank you very much, it has worked out.

[rtsp @ 0x7f35f8c0] SDP:aq=0KB vq=0KB sq=0B f=0/0  
v=0
o=- 137163047 1 IN IP4 0.0.0.0
s=Live session, streamed by LIVE555
i=live?token=1080p_noaudio
t=0 0
a=tool:LIVE555 Streaming Media v2015.07.23
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:Live session, streamed by LIVE555
a=x-qt-text-inf:live?token=1080p_noaudio
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:0
a=rtpmap:96 H264/9
a=fmtp:96
packetization-mode=1;profile-level-id=640028;sprop-parameter-sets=Z2QAKK2EBUViuKxUdCAqKxXFYqOhAVFYrisVHQgKisVxWKjoQFRWK4rFR0ICorFcVio6ECSFITk8nyfk/k/J8nm5s00IEkKQnJ5Pk/J/J+T5PNzZprQDwBE/Kg==,aO48sA==
a=control:track1
m=audio 0 RTP/AVP 97
c=IN IP4 0.0.0.0
b=AS:0
a=rtpmap:97 L16/16000
a=control:track2

Input #0, rtsp, from 'rtsp://192.168.55.2:554/live?token=1080p_noaudio':
  Metadata:
title   : Live session, streamed by LIVE555
comment : live?token=1080p_noaudio
  Duration: N/A, start: 0.002375, bitrate: N/A
Stream #0:0: Video: h264 (High), yuv420p, 1920x1080 (1920x1088), 25
tbr, 90k tbn, 180k tbc
Stream #0:1: Audio: pcm_s16be, 16000 Hz, 1 channels, s16, 256 kb/s

And yes, I've used htons() on the PCM buffer, thanks again.

Best regards,
Max

On 07/29/2015 11:05 PM, Ross Finlayson wrote:
>> We need to broadcast the PCM (S16LE/16000) audio as a separate channel
>> with our RTSP-server.
> […]
>> What is a preferred RTPSink class that I should use for this audio
>> format in our OnDemandServerMediaSubsession?
>
> You should use a “SimpleRTPSink” - specifically:
> SimpleRTPSink::createNew(envir(), rtpGroupsock,
> rtpPayloadTypeIfDynamic, 16000,
> "audio", “L16", numChannels);
> where “numChannels” is 1 for mono, and 2 for stereo.
>
> Note, however, that because your input source is in ‘little-endian’
> form (I presume that’s what the “LE” stands for), you will need to
> byte-swap it before you feed it into your “SimpleRTPSink” (because the
> IETF standard RTP payload format for the “audio/L16” type specifies
> that the data be packed into RTP packets in big-endian form.
>
> Therefore, your implementation of the “createNewStreamSource()”
> virtual function should feed the input source into a new
> “EndianSwap16” filter object (and return a pointer to that filter object).
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
> ___
> live-devel mailing list
> live-devel@lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] RTSP response status codes: 403 Forbidden

[Maxim P. DEMENTIEV]

Hi,

Sometimes, under some condition I need to reply to the client of my RTSP
server - "403 Forbidden".
As a temporary solution, I can override (and I do) "Boolean
RTSPServer::specialClientAccessCheck(...)" but it gives me "401
Unauthorized" which is not exactly the case, see this link for details :

   
https://en.wikipedia.org/wiki/HTTP_403#Difference_from_status_.22401_Unauthorized.22

So, what is a right solution for this problem ?
Thank you in advance!

With regards,
Max

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] RTSP response status codes: 403 Forbidden

[Maxim P. DEMENTIEV]

Thank you very much, Ross!

I think it is possible to do a patch which will not break the old
behaviour and let other replies.
(And I personally have no doubt that you know better than me how to do
it; just as a proposal...)

Say, in the header we add another virtual method with the string as a
return value:

  // if there is some problem,
  // returns the status code in the form "4XX Message text",
  // otherwise NULL
  virtual const char * specialClientAccessCheck_ext(int clientSocket,
struct sockaddr_in& clientAddr,
   char const* urlSuffix);

Then to change the old method usage:

Boolean RTSPServer::RTSPClientConnection
::authenticationOK(char const* cmdName, char const* urlSuffix, char
const* fullRequestStr) {

  if (const char * resp =
fOurServer.specialClientAccessCheck_ext(fClientInputSocket, fClientAddr,
urlSuffix)) {
setRTSPResponse(resp);
return False;
  }

And to implement the new virtual method without breaking old behaviour:

const char * RTSPServer
::specialClientAccessCheck_ext(int /*clientSocket*/, struct sockaddr_in&
/*clientAddr*/, char const* /*urlSuffix*/) {
  // default implementation
  return specialClientAccessCheck(clientSocket, clientAddr, urlSuffix) ?
NULL : "401 Unauthorized";
}

Of course, if we want a more general behaviour, we need to add some mime
fields for a response.
In this case, the return value of the new method must be more complicated.

Regards,
Max

On 12/08/2015 08:45 AM, Ross Finlayson wrote:
> Our server code currently has no mechanism for specifying an ‘authentication 
> failed’ response other than “401 Unauthorized”.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> ___
> live-devel mailing list
> live-devel@lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] RTSP response status codes: 403 Forbidden

[Maxim P. DEMENTIEV]

Just in case...
This is the resulting patch which is working for us.
LGPL.

With respect,
Max

On 12/08/2015 10:21 AM, Ross Finlayson wrote:
> Thanks for the suggestion, but right now I’m not planning on making such a 
> change to the supplied server code, because this functionality is unlikely to 
> be used very much.
>
> So for now you should just modify your own copy of the code, subject - as 
> always - to the LGPL:
>   http://live555.com/liveMedia/faq.html#copyright-and-license
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> ___
> live-devel mailing list
> live-devel@lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

http://lists.live555.com/pipermail/live-devel/2015-December/019794.html

[Live-devel] RTSP response status codes: 403 Forbidden
Maxim P. DEMENTIEV maxim.dementiev at nexvision.fr
Tue Dec 8 00:50:08 PST 2015

Index: live/liveMedia/RTSPServer.cpp
===
--- live.orig/liveMedia/RTSPServer.cpp
+++ live/liveMedia/RTSPServer.cpp
@@ -211,6 +211,12 @@ Boolean RTSPServer
   return True;
 }
 
+const char * RTSPServer
+::specialClientAccessCheck_ext(int clientSocket, struct sockaddr_in& clientAddr, char const* urlSuffix) {
+  // default implementation
+  return specialClientAccessCheck(clientSocket, clientAddr, urlSuffix) ? NULL : "401 Unauthorized";
+}
+
 RTSPServer::RTSPServer(UsageEnvironment& env,
 		   int ourSocket, Port ourPort,
 		   UserAuthenticationDatabase* authDatabase,
@@ -917,8 +923,8 @@ static Boolean parseAuthorizationHeader(
 Boolean RTSPServer::RTSPClientConnection
 ::authenticationOK(char const* cmdName, char const* urlSuffix, char const* fullRequestStr) {
 
-  if (!fOurServer.specialClientAccessCheck(fClientInputSocket, fClientAddr, urlSuffix)) {
-setRTSPResponse("401 Unauthorized");
+  if (const char * resp = fOurServer.specialClientAccessCheck_ext(fClientInputSocket, fClientAddr, urlSuffix)) {
+setRTSPResponse(resp);
 return False;
   }
 
Index: live/liveMedia/include/RTSPServer.hh
===
--- live.orig/liveMedia/include/RTSPServer.hh
+++ live/liveMedia/include/RTSPServer.hh
@@ -136,6 +136,8 @@ protected:
   // a hook that allows subclassed servers to do server-specific access checking
   // on each client (e.g., based on client IP address), without using
   // digest authentication.
+  virtual const char * specialClientAccessCheck_ext(int clientSocket, struct sockaddr_in& clientAddr,
+	   char const* urlSuffix);
 
 private: // redefined virtual functions
   virtual Boolean isRTSPServer() const;
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] ServerMediaSession::numSubsessions() and fNumStreamStates in RTSPServer::RTSPClientSession::handleCmd_SETUP()

[Maxim P. DEMENTIEV]

Hi,

A cycle with ServerMediaSubsessionIterator is used in
RTSPServer::RTSPClientSession::handleCmd_SETUP() to calculate the value
of fNumStreamStates.

I wonder why ServerMediaSession::numSubsessions() isn't used for it?
Could they have different results?

Regards,
Max

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] ServerMediaSession::numSubsessions() and fNumStreamStates in RTSPServer::RTSPClientSession::handleCmd_SETUP()

[Maxim P. DEMENTIEV]

On 06/29/2016 11:29 PM, Ross Finlayson wrote:
> yes - if a new “ServerMediaSubsession” object happened to be added to the 
> “ServerMediaSession”
So, if a new subsession is added to the session, it should be done with
the help of ServerMediaSession::addSubsession(subsession) method which
increases the value of fSubsessionCounter, and
ServerMediaSession::numSubsessions() getter returns this value.

The question is more general, it is about a using the linear iteration
to count objects instead of a using the counter which is present in the
linked list container (ServerMediaSession), and not about the moment of
adding or removing objects to/from the container. (The invariant?)

Please, don't mind. It could be a little optimization, nothing more.

With respect,
Max

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] minor bug on windows implementation ofgettimeofday()

[I-McMahon, Andrew P]

A suggestion for this could be to intialise using time() to get UTC time, then 
use QueryPerformanceFrequency/QueryPerformanceCounter from then on, like this:

int gettimeofday(struct timeval* tp, int* /*tz*/) {
  static bool tickFrequencySet = false;
  static unsigned __int64 tickFrequency = 0;
  static unsigned __int64 timeOffset = 0;
  
  unsigned __int64 tickNow;
 
  if (tickFrequencySet == false) {
QueryPerformanceFrequency(reinterpret_cast(&tickFrequency));

time_t t;
time(&t);

QueryPerformanceCounter(reinterpret_cast(&tickNow));
tickNow /= tickFrequency;
timeOffset = t - tickNow;

tickFrequencySet = true;
  }
  
  QueryPerformanceCounter(reinterpret_cast(&tickNow));
  tp->tv_sec = static_cast((tickNow / tickFrequency) + timeOffset);
  tp->tv_usec = static_cast(((tickNow % tickFrequency) * 100L) / 
tickFrequency);

  return 0;
}

(better implementations of this are probably available ;))

Andy M

-Original Message-
From: Sébastien Escudier [mailto:sebastien-de...@celeos.eu] 
Sent: 2009-04-02 07:58
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] minor bug on windows implementation ofgettimeofday()

Quoting Ross Finlayson :

> Unfortunately I'm not an expert on Windoze-specific API stuff.

You may have a look at vlc times functions :

http://git.videolan.org/gitweb.cgi?p=vlc.git;a=blob;f=src/misc/mtime.c;h=0dbb4df578308b38e6e3ff9487b0e9143f11853b;hb=HEAD

or for a direct access to the file :

http://git.videolan.org/gitweb.cgi?p=vlc.git;a=blob_plain;f=src/misc/mtime.c;hb=HEAD

If you need a high precision clock, with a random epoch, look at mdate.
If you need a constant epoch look at gettimeofday

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Regarding the build

[Erlandsson, Claes P (CERLANDS)]

Example with a x64 OS:

VS2010:
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\

VS2008:
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\

I btw use the short path (that you can see with dir /X) to avoid issue with
space:
c:\PROGRA~2\MICROS~2.0\VC


/C


From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of dushyanth
Sent: Tuesday, July 03, 2012 10:04 AM
To: live-de...@ns.live555.com
Subject: Re: [Live-devel] Regarding the build

In the instructions to build and run the libraries for windows, the second
point says
"If the 'tools' directory on your Windows machine is something other than
"c:\Program Files\DevStudio\Vc", change the "TOOLS32 =" line in the file
"win32config" " where can i expect to find this directory. Is it the tools
folder in my visual studio package? Thanks.


-- 
Dushyanth Subramanya
University of Pennsylvania
Class of 2012
School of Engineering & Applied Science
MSE, MCIT
www.seas.upenn.edu/~dushs


smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] RTSP - Absolute Time

[Erlandsson, Claes P (CERLANDS)]

After doing some testing with openRTSP and looking through the code it appears 
like "Absolute Time" is currently not supported for RTSP streams. I.e. I can't 
specify a specific time that the stream should seek to, e.g. Range: 
clock=20120629T07.00Z, all according to paragraph 3.7 at 
http://www.ietf.org/rfc/rfc2326.txt.

I see some remarks for "clock" (and "smtpe") in the code at 
RTSPCommon->parseRangeParam() which sort of confirms that this is still to be 
done.

I'm curious if there is a reason that absolute time has been left out, i.e. are 
there problems implementing it, or is it just that people for some reason 
haven't been showing any interest in it?

I find the seek functionality to be an essential part of RTSP, but it's kind of 
hard to implement anything with just the npt-time (Normal Play Time) to use. 
For most uses, like Video Management Systems that uses a circular buffer, the 
start is a moving target, i.e. seeking to 50 minutes might not take you to the 
same place in 10 minutes as it does now.

Do you know of any reliable workarounds?

Thanks!


/Claes


___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Recording time available?

[Erlandsson, Claes P (CERLANDS)]

Is there a way to get the recording timestamp for stored content?

When looking at the presentation time that is received with each frame I see
that it is matching the current time of the server, but when playing back an
archived stream I'm interested in when it was recorded. Can that be found
somewhere?


/Claes


smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Recording time available?

[Erlandsson, Claes P (CERLANDS)]

I find your question confusing, because it wasn't really clear how it 
relates to our software.  Could you please clarify your question, explaining in 
particular how you are using our software?  (Remember that our software can be 
used to build RTSP clients, RTSP servers, RTSP proxy servers, and other things.)

I've built a RTSP client using your library, so my question is related to what 
information that is passed from the server to the client. When I stream an 
archive file (i.e. non-live) from a RTSP-server ("Cisco Video Surveillance 
Media Server" in this case) it would great to be able to get a timestamp 
indicating when it was recorded. For live streams such a field would of course 
be the current server time. Is there any other timestamp available at all 
besides presentation time?
I have been trying to research if such a timestamp field is part of the 
RTSP-protocol or not, but I haven't found anything, so that is one reason I ask 
before spending too much time looking into the code. Since it's kind of 
essential information, at least for surveillance, I would hope it's part of the 
specification. I know it's possible to get this information with the Cisco 
bundled software, but it can of course be some third party added feature.

/Claes
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Design choice

[Erlandsson, Claes P (CERLANDS)]

When implementing liveMedia using multiple streams in one process I see two
choices:

 1. Each stream is kept totally separate. I.e. each stream have their own
TaskScheduler, UsageEnvironment, eventLoopWatchVariable and each
doEventLoop() is running in a separate thread.

 2. The rtspClient's share the same TaskScheduler, UsageEnvironment,
eventLoopWatchVariable and there is one doEventLoop() running (as in the
testRTSPClient project). 


I've current implemented design 1, while I see option 2 being the intended
choice. The reason for picking 1 is the added "security" of keeping each
stream entirely independent, i.e. if an exception occurs for any reason only
one stream should be affected.

As I'm fairly new to the liveMedia library I however wanted to see if anyone
has an opinion on this. The overhead doesn't appear to be an issue even with
10+ streams. Could there be any possible drawbacks with option 1 that I have
overseen?


/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Cleanup problems when passing non-valid URL?

[Erlandsson, Claes P (CERLANDS)]

I'm writing a playback client based on the testRTSPClient example. For each
new stream to connect to, I setup a new environment, i.e. create new
UsageEnvironment, StreamClientState etc.

Everything works great and I can start and stop streams multiple times
without seeing any issues. There is one exception, and it's when I try to
connect to a totally messed up URL, e.g. "rtsp://cw".

The stream then appears to correctly "shut down" when ending up in
continueAfterDESCRIBE(), but whatever stream I try connect to after that
will end up in a fatal crash. As long as I send in valid URL's it doesn't
crash, i.e. it behaves correctly even if there is no stream available. It is
only when I send in non-valid URL's something bad happens. 

Example of stream connections; everything works fine until after
rtsp://cw:

rtsp://192.168.1.103/live/MyWorkingCamera1
rtsp://192.168.1.103/live/NoStreamHere1
rtsp://192.168.1.103/live/MyWorkingCamera2
rtsp://192.168.1.103/live/MyWorkingCamera1
rtsp://192.168.1.103/live/NoStreamHere2
rtsp://192.168.1.103/live/MyWorkingCamera2
rtsp://cw
-> Whatever URL I try to connect to after this will trigger a fatal error


I've tried to debug this a lot, but am kind of stuck. A solution is of
course to validate the URL before passing it, but now I'm kind of curious
what the issue is. I haven't been able narrow it down, but it appears to
usually occur when a new RTSPClient is created, i.e. on
OurRTSPClient::createNew().

Has anyone else experienced this?


/Claes


smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] RTSP - Absolute Time

[Erlandsson, Claes P (CERLANDS)]

FYI, the latest version (2012.08.20) of the "LIVE555 Streaming Media" code
adds optional RTSP server and RTSP client support for streams that are
indexed by 'absolute' time - i.e., using strings of the form
"MMDDTHHMMSSZ" or "MMDDTHHMMSS.Z".

 

Ross Finlayson



 

Ross, Thank you very much for getting this implemented!

 

 

I've been playing around with it a bit today, and will continue to test.

I'm using Cisco Video Surveillance Media Server, and liveMedia for the
client. I've experienced some issues today that I haven't really seen
before, but I'm fairly sure liveMedia is not to blame. Still thought I could
mention it in case someone else is playing around with absolute seeking too.

 

- Seeking using absolute time takes 5-15s.

 

- The absolute timestamp I ask for doesn't match what I receive, Many hours
off, but at least it's consistent.

 

The functionality works ok when using the Cisco Active X control, but I get
the exact same issue when sending RTSP commands manually via a telnet client
(which is expected, just confirming liveMedia doesn't introduce anything).

 

At one time the Cisco server suddenly refused to accept new connections
(from any computer); something I've never seen before. Worked ok after a
reboot.

 

Will investigate more and maybe create new archive files on the server...
Thanks again!

 

 

/Claes

 



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] RTSP - Absolute Time

[Erlandsson, Claes P (CERLANDS)]

 

- The absolute timestamp I ask for doesn't match what I receive, Many hours
off, but at least it's consistent.

 

For what it's worth, this sounds like it could potentially be a time zone
issue.  I've run into issues in the past where some of the routines I used
interpreted my UTC timestamp as a timestamp in the local time zone (or vice
versa), thus adding or subtracting a fixed number of hours.

 

Note that according to the RTSP specification (RFC 2326, section 3.7)
'absolute' time - in both RTSP requests and RTSP responses - must be
expressed as a UTC time - i.e., using a string of the form
"MMDDTHHMMSSZ" or "MMDDTHHMMSS.Z".  (Note the "Z" at the end.)

 

 

 

Thanks to everyone for your response.

A new day and another restart of the server and everything appears to work
fine.

 

I think I might have messed up the UTC conversion yesterday, as I did it
manually, but it was also confusing as it was not always whole hours off,
which potentially could have been due to incomplete archives (for unknown
reasons). Well, today it appears to work fine and even the delay is gone. No
idea what that was about, but it must have been something on the server.
I've re-created a few of the archives and will continue to test more.
Thanks!

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Re-connection handling

[Erlandsson, Claes P (CERLANDS)]

Best possible uptime is essential for the RTSP client I'm implementing. I've
therefore looked into how to best handle reconnection if the stream for any
reason is disconnected. I noticed fairly quickly that liveMedia is taking
care of that really good and there is no reason for me to try to implement
any general disconnect handling, as I can't possible reconnect any faster
than liveMedia already does.

 

There is one case where it doesn't work though, and I'm not sure how to
handle it. This is if I do a seek while the stream is disconnected, then it
never reconnects. In some cases I play a 10s loop where a timer do a seek
every 10s and jumps back (using absolute seeking). Those streams never
reconnect after a disconnection.

 

 

I see a few alternatives:

 

1. I continuously try to reconnect myself, but I don't want to mess up
liveMedia's reconnection handling, so not sure how to detect when I should
handle a disconnect myself.

 

2. Make sure I don't issue a seek, or any PLAY-command (i.e. call
sendPlayCommand()) when the stream is down. Is there a status flag I can
check somewhere to determine this?

 

3. Look at the reconnect-handling in liveMedia. No idea what could be done
to make sure the re-connect functionality isn't disrupted, but maybe buffer
the PLAY-commands until they can be performed, or just discard them. 

 

 

Any comments would be appreciated. Can anyone confirm that my theories are
correct, i.e. that a stream doesn't reconnect if a PLAY-command is issued
while the stream is down?

 

 

/Claes

 



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Re-connection handling

[Erlandsson, Claes P (CERLANDS)]

There is one case where it doesn't work though, and I'm not sure how to
handle it. This is if I do a seek while the stream is disconnected, then it
never reconnects. In some cases I play a 10s loop where a timer do a seek
every 10s and jumps back (using absolute seeking). Those streams never
reconnect after a disconnection.

 

 

OK, so unless you can tell me a reliable way to reproduce this problem
(perhaps using "openRTSP), then you'll need to figure out yourself why the
LIVE555 library's connection reestablishment code is not working in this
case (and then I'll try to fix it).  Remember, You Have Complete Source
Code.

 

The place to look in the code is near the start of
"RTSPClient::sendRequest()" (line 535 of "liveMedia/RTSPClient.cpp").  When
you do your 'seek' (really "PLAY") operation (that's failing), then is
"fInputSocketNum" <0?  If so, then what value does "openConnection()"
return.

 

If, however, "fInputSocketNum" is >= 0 (in practice, it will be >0), then we
will (eventually) call "send()" (at line 787) to transmit the command.  Is
this "send()" call succeeding, or not?

 

 

I don't believe there is a loop functionality in openRTSP, so I can't think
of a way to recreate it there.

 

In simple words, what I do is:

1. Play a non-live stream.

2. Pull the plug on the server side (shouldn't matter if client side
though), and put it back.

3. Do one, or many, seek (PLAY-command using absolute time) on the stream
while not connected.

4. When connection works again, the stream will not continue, while other
streams will.

 

I will do some testing and look up the lines you're referring to. Will get
back when I've some answers for you.

 





I see a few alternatives:

 

No, there's only one 'alternative': Figure out why the LIVE55 code is
(apparently) failing in this case, so I can fix the problem.  Trying instead
to work around this problem yourself might help you in the short term, but
wouldn't help anyone else.

 

I of course totally agree on that. Guess I considered that it potentially
could be a known issue that was hard to fix.

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Possible bug (and fix)?

[Erlandsson, Claes P (CERLANDS)]

Thanks for the report.  I have now installed a new version (2012.09.07) that 
should fix the problem (with receiving RTP-over-TCP on Windows).

Thanks a lot!


(FYI: The bug got accidentally introduced back in version 2012.07.24, when we 
added a fix to better handle the disconnection of the remote end of TCP 
sockets.  Unfortunately, however, that fix broke a separate, earlier workaround 
for a bug in Windows - so the Windows bug ended up accidentally reemerging.  
The latest version of the software should fix both.  But this situation 
illustrates, yet again, that Windows is rapidly becoming more trouble than it's 
worth.  I hope those of you who - for whatever reason - have chosen to develop 
only for Windows have an exit strategy in mind :-)

In many cases, at least on the client side, Windows is the only viable option. 
I definitely wouldn't mind if >50% were using a Linux flavor as desktop OS, but 
today that's not the case.
I just want to say that I'm, and I'm sure many with me, are thankful as long as 
you support Windows.

/Claes

___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Proper function calls from other threads (was: RE: All client termination)

[Erlandsson, Claes P (CERLANDS)]

Right now Live555 loop run in separate thread. The clean up function can be
called from the another thread

 

No!  You cannot safely do this!  Read the FAQ (that you were asked to do
before posting to this mailing list)!

 

Apart from "triggerEvent()" (see below), all calls to LIVE555 code *must* be
done within the LIVE555 thread - e.g., from a LIVE555 event handler.

 

For an illustration of how to shutdown (and reclaim) a "RTSPClient" object -
and all of the objects that it uses - see the function "shutdownStream()" in
"testProgs/testRTSPClient.cpp".

 

Now, you may wish to signal this shutdown/reclaim mechanism from an external
thread - i.e., from a thread other than one that's running the LIVE555 event
loop, for example, a GUI.  To do this, use the "event trigger" mechanism
(see the FAQ and "UsageEnvironment/include/UsageEnvironment.hh").  Note that
the "triggerEvent()" function is the *only* LIVE555 function that can be
called from an external thread.

 

 

This is a mistake I first made, even after reading the FAQ. I somehow didn't
think about that I was calling shutdown and issue PLAY-commands (seek) from
my own thread (since it usually works fine). Looking at the example code I
however thought it was safe to schedule tasks. After reading your response
above I'd like to verify that what I do is correct.

 

My question is... I'm not calling triggerEvent() directly, but instead
scheduling tasks using the taskScheduler. The code example below is called
from an external thread. Is that ok, and the proper way to do it?

 

 

void StopStream(OurRTSPClient *rtspClient)

{

 if (rtspClient)

 {

   UsageEnvironment& env = rtspClient->envir();

 
env.taskScheduler().scheduleDelayedTask(TASK_FUNCTION_CALL_DELAY_MS,
(TaskFunc*)StopStreamTask, rtspClient);

 }

}

 

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Proper function calls from other threads (was: RE: All client termination)

[Erlandsson, Claes P (CERLANDS)]

The code example below is called from an external thread. Is that ok

 

No - absolutely not!!!   What you're trying to do - call
"TaskScheduler::scheduleDelayedTask()" from an external thread - is
extremely wrong! 

 

Look folks, how many times do I have to say this: A LIVE555 application runs
as a single-thread of control (using an event loop, rather than threads, to
provide concurrency).  If you want to communicate with a LIVE555 application
from an external thread (i.e., from a thread other than the one that runs
the LIVE555 event loop), then there are only two proper ways to do this:

1/ By setting a global variable, or

2/ Using an 'event trigger' - i.e., by calling
"TaskScheduler::triggerEvent()".  Note that "triggerEvent()" is the
***only*** LIVE555 function that you may call from an external thread.

 

This is all explained in the FAQ that you were all asked to read before
posting to this mailing list!!!

 

In your case, you would do something like the following:

1/ Within the LIVE555 thread (e.g., somewhere after you've created
"rtspClient"), call

EventTriggerId myStopStreamEvent =
env.taskScheduler().createEventTrigger(StopStream);

2/ Later, from an external thread, you can call:

env.taskScheduler().triggerEvent(myStopStreamEvent, rtspClient);

and this will cause your "StopStream()" function to be called (with
"rtspClient" as parameter) from the event loop - i.e., as a handled event.

(Note: For this to work, "env", "myStopStreamEvent" and "rtspClient" need to
be global variables, so that they are visible to the external thread.  Note,
though, that they are never *modified* by the external thread, only read by
it.)

 

 

Thanks a lot for taking the time to (again) clarify things.

 

One last question on this, as I'm in the middle of reorganizing the code. 

Shouldn't it be safe to create the rtspClient object in another thread?

I can't really see a problem with that as it only appears to assign
variables. Since I was so wrong before, I want to verify though ;-)

 

Besides just being curious and want to find out, it would also simplify
things in the application I'm working on. The application creates clients
dynamically and starts up without any active clients. Having to create the
rtspClient objects using triggers would introduce additional callbacks and
making passing arguments a bit more complex.

 

This is now the "main startup code":

 

void InitStreamEngine()

{

 TaskScheduler* scheduler = BasicTaskScheduler::createNew();

 usageEnvironment = BasicUsageEnvironment::createNew(*scheduler);

 

 myStartStreamEvent =
usageEnvironment->taskScheduler().createEventTrigger((TaskFunc*)StartStreamE
vent);

 myStopStreamEvent =
usageEnvironment->taskScheduler().createEventTrigger((TaskFunc*)StopStreamEv
ent);

 mySeekAbsoluteEvent =
usageEnvironment->taskScheduler().createEventTrigger((TaskFunc*)SeekAbsolute
Event);

 

 usageEnvironment->taskScheduler().doEventLoop(&eventLoopWatchVariable);

}

 

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Proper function calls from other threads (was: RE: All client termination)

[Erlandsson, Claes P (CERLANDS)]

One last question on this, as I'm in the middle of reorganizing the code.

Shouldn't it be safe to create the rtspClient object in another thread?

 

Once again, NO!  "RTSPClient" objects - like all subclasses of class
"Medium" - update shared data structures (stored within the
"UsageEnvironment" object) when they are constructed.  A single
"UsageEnvironment" object MUST NOT be accessed from multiple threads (except
that the "triggerEvent()" member function may be called from a
non-LIVE555-event-loop thread).

 

 

 

Got it. I'm happy that I asked...

 

For a class that's created outside of liveMedia, it still seem safe to store
temporary variables even though they can be accessed via the rtspClient
object. I'm thinking of StreamClientState (as used in the testRTSPClient
example). It is only part of OurRTSPClient, not RTSPClient. If I add a
variable there that I know is only accessed in two places, it appears
perfectly safe even if it will be written to from one thread and read from
another.

 

 

I can't think of any problems passing arguments that way. If anyone see any
possible issue, please enlighten me what could potentially go wrong.

 

In the example below, SeekAbsolute() will execute on a second thread,
assigning scs.seekToAbsolutePosition, while SeekAbsoluteEvent() will be
executed on the liveMedia thread reading the value.

 

void SeekAbsolute(OurRTSPClient *rtspClient, char *seekTo)

{

 if (rtspClient)

 {

   // Pass on the argument.

   StreamClientState& scs = ((OurRTSPClient*)rtspClient)->scs;

   strcpy_s(scs.seekToAbsolutePosition,
sizeof(scs.seekToAbsolutePosition), seekTo);

 

   UsageEnvironment& env = rtspClient->envir();

   env.taskScheduler().triggerEvent(mySeekAbsoluteEvent,
rtspClient);

 }

}

 

 

void SeekAbsoluteEvent(OurRTSPClient *rtspClient)

{

 StreamClientState& scs = ((OurRTSPClient*)rtspClient)->scs;

 rtspClient->sendPlayCommand(*scs.session, continueAfterPLAY,
*scs.seekToAbsolutePosition);

}

 

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Re-connection handling

[Erlandsson, Claes P (CERLANDS)]

There is one case where it doesn't work though, and I'm not sure how to
handle it. This is if I do a seek while the stream is disconnected, then it
never reconnects. In some cases I play a 10s loop where a timer do a seek
every 10s and jumps back (using absolute seeking). Those streams never
reconnect after a disconnection.

 

 

OK, so unless you can tell me a reliable way to reproduce this problem
(perhaps using "openRTSP), then you'll need to figure out yourself why the
LIVE555 library's connection reestablishment code is not working in this
case (and then I'll try to fix it).  Remember, You Have Complete Source
Code.

 

The place to look in the code is near the start of
"RTSPClient::sendRequest()" (line 535 of "liveMedia/RTSPClient.cpp").  When
you do your 'seek' (really "PLAY") operation (that's failing), then is
"fInputSocketNum" <0?  If so, then what value does "openConnection()"
return.

 

If, however, "fInputSocketNum" is >= 0 (in practice, it will be >0), then we
will (eventually) call "send()" (at line 787) to transmit the command.  Is
this "send()" call succeeding, or not?

 





 

I've finally come around to try to dig deeper into this reconnect issue.
First, I'd like to point out that I've updated to the latest liveMedia code
(2012.09.13) and I've redesigned my program to only access/create liveMedia
objects/functions within a function triggered by triggerEvent().

 

I put some debug messages in RTSPClient::sendRequest(), but it doesn't seem
to end up there when I do the seek. I do get an exception at random
locations. Sometimes it happens without me doing anything, i.e. directly
when the connection has been re-established, other times the exception
occurs after I try to do something to the RTSP stream, e.g. stop or seek.

 

Below is an example of the call stack for an exception:

...

msvcr90d.dll!_free_base(void * pBlock=0x61d4d496)

msvcr90d.dll!_unlock(int locknum=4)

msvcr90d.dll!operator delete(void * pUserData=0x06a2acf0)

msvcr90d.dll!operator delete(void * pUserData=0x06a2acf0)

msvcr90d.dll!_free_base(void * pBlock=0x05051718)

msvcr90d.dll!strerror(int errnum=111825400)

RtspVideo.dll!BasicUsageEnvironment0::setResultErrMsg()

RtspVideo.dll!readsocket()

RtspVideo.dll!RTSPClient::incomingDataHandler()

RtspVideo.dll!BasicTaskScheduler::SingleStep()

RtspVideo.dll!BasicTaskScheduler0::doEventLoop()

...

here is another one:

...

msvcr90d.dll!malloc(unsigned int size=21)

msvcr90d.dll!operator new(unsigned int size=21)

RtspVideo.dll!BasicTaskScheduler::SingleStep()

RtspVideo.dll!BasicTaskScheduler0::doEventLoop()

...

 

Please let me know what I can do to help. I'll continue to look in to this.

 

 

Again, what I do is:

1. Play an archive (i.e. non-live) stream.

2. Unplug Ethernet cable.

3. Do a seek while disconnected.

4. Plug in Ethernet cable.

 

I get an exception every time, but as mentioned above, it appears slightly
different and the call stack usually looks different each time.

 

 

/Claes

 



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Re-connection handling

[Erlandsson, Claes P (CERLANDS)]

This is the first time you've mentioned an exception.  (Previously, you said
just that the stream failed to reconnect afterwards.)

 

I've attached a modified version of our "testRTSPClient.cpp" demo
application.  It starts playing the specified stream - as usual - but then,
after 60 seconds, sends another "PLAY" command (to seek by 'absolute time').
Please build and run this version of "testRTSPClient", unplugging your
Ethernet cable after the initial "PLAY" command.  See if an exception occurs
after 60 seconds (when the second "PLAY" command (seeking) is sent).

 

If you get an exception in this (modified) "testRTSPClient" application,
then let us know; this indicates a bug in the LIVE555 code.  If, however,
you don't get an exception in this application, then it suggests that the
problem occurs only in *your* application, in which case you're going to
have to figure this out for yourself.

 

 

 

There is no problem with the liveMedia code, i.e. the testRTSPClient you
provided worked fine when I did my disconnect testing.

 

Thanks to this I found the issue. When doing the seek I had the response
handler set to continueAfterPLAY instead of NULL. Since the resultCode after
the disconnect was -10057 that triggered a call to shutdownStream(). As I
after that used the rtspClient pointer it obviously led to the random
exceptions I experienced.

 

Your support is very much appreciated. Sorry for bothering you with this
issue.

 

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Client connection timeout

[Erlandsson, Claes P (CERLANDS)]

When connecting to a server that doesn't respond, or is just slow, the
timeout appears to be around 25s, i.e. the time before the response handler
is called.

Is there a way to decrease this time?

 

 

Why? Well, in the project I'm working on there are lots of changing cameras
that are on a 10s cycle, so there is no need to try for more than 10s. While
I assume it should be ok to call shutdown() while the client is still trying
(and stop the event loop etc), it would be beneficial to be able to wait for
the response handler to return.

 

I've seen some lingering connections in rare cases, which most likely is due
to my code, but it would nonetheless be nicer to always wait for the
response handler. These yet unexplained lingering connections happens for
maybe 1 stream out of 2.

 

When looking in the code the only somewhat related variable or function I
see is the sessionTimeoutParameter which doesn't seem to have anything with
the connection timeout to do.

 

 

Two testRTSPClient examples below. In the first I just connect to an
arbitrary URL where there is no server that responds, and it takes about 25s
before the response handler is called. In the second example our Cisco VSM
is bogged down and it takes 30s for it to respond.

 

 

e:\projects\live\Release>testRTSPClient.exe rtsp://ibm.com/moo

!!!  fInputSocketNum -1

Opening connection to 129.42.38.1, port 554...

!!!  connectResult 0

...Connection to server failed: Unknown error

[URL:"rtsp://ibm.com/moo"]: Failed to get a SDP description: Connection to
server failed: Unknown error

[URL:"rtsp://ibm.com/moo"]: Closing the stream.

 

 

e:\projects\live\Release>testRTSPClient.exe rtsp://192.168.1.103/live/TVF-16

!!!  fInputSocketNum -1

Opening connection to 192.168.1.103, port 554...

!!!  connectResult 0

...remote connection opened

!!!  fInputSocketNum 124

Sending request: DESCRIBE rtsp://192.168.1.103/live/TVF-16 RTSP/1.0

CSeq: 2

User-Agent: testRTSPClient.exe (LIVE555 Streaming Media v2012.09.13)

Accept: application/sdp

 

 

Received 61 new bytes of response data.

Received a complete DESCRIBE response:

RTSP/1.0 500 Server Error (Unable to open proxy)

CSeq: 2

 

 

[URL:"rtsp://192.168.1.103/live/TVF-16"]: Failed to get a SDP description:
500 Server Error (Unable to open proxy)

[URL:"rtsp://192.168.1.103/live/TVF-16"]: Closing the stream.

 

 

/Claes

 



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Properly shutting down stream after TEARDOWN

[Erlandsson, Claes P (CERLANDS)]

Lately I've seen some random exceptions when streams are being shut down. I
believe these were introduced when I changed the code so it waits for a
TEARDOWN response. This was btw done as Cisco mentioned their server
requires that.

I'm probably doing something wrong, as it appears the error happens in, or
are related to, the TEARDOWN response handler.

With the shutdownStream() function in testRTSPClient as a model I basically
added a response handler to the sendTeardownCommand() and added an
additional cleanup function that should take care of the final cleanup and
properly close the rtspClient.

- Can't I assume the rtspClient is valid after TEARDOWN?

- If not, how should I then properly execute Medium::close(rtspClient)?

- In cleanUpStream() I delete all event triggers. This needs to be done,
right, or is it somehow that's taken care of automatically?

 

The exception has never occurred while stepping through the code, but the
exception appears to occur right after sendTeardownCommand() has been
called.

Sample code below. Is that the proper way to clean up?

 

void continueAfterTEARDOWN(RTSPClient* rtspClient, int resultCode, char*
resultString)

{

 if (resultCode != 0)

 {

   UsageEnvironment& env = rtspClient->envir();

  env << *rtspClient << "TEARDOWN result code: " << resultCode <<
".\n";

 }

 

 cleanUpStream(rtspClient);

}

 

void shutdownStream(RTSPClient* rtspClient, int exitCode)

{

 UsageEnvironment& env = rtspClient->envir();

 StreamClientState& scs = ((OurRTSPClient*)rtspClient)->scs; 

 

 // First, check whether any subsessions have still to be closed:

 if (scs.session != NULL)

 { 

   Boolean someSubsessionsWereActive = False;

   MediaSubsessionIterator iter(*scs.session);

   MediaSubsession* subsession;

 

   while ((subsession = iter.next()) != NULL)

   {

if (subsession->sink != NULL)

{

 Medium::close(subsession->sink);

 subsession->sink = NULL;

 

 if (subsession->rtcpInstance() != NULL)

 {

   // in case the server sends a RTCP "BYE" while
handling "TEARDOWN"

   subsession->rtcpInstance()->setByeHandler(NULL,
NULL);

 }

 

 someSubsessionsWereActive = True;

}

   }

 

   if (someSubsessionsWereActive)

   {

// Send a RTSP "TEARDOWN" command, to tell the server to
shutdown the stream.

// We now want to handle the response.

rtspClient->sendTeardownCommand(*scs.session,
continueAfterTEARDOWN);

   }

   else

   {

cleanUpStream(rtspClient);

   }

 }

 else

 {

   cleanUpStream(rtspClient);

 }

}

 

// Aka shutdownStream part 2. We do the final cleanup in a separate function
as we

// want to wait until we receive the TEARDOWN response.

void cleanUpStream(RTSPClient* rtspClient)

{

 UsageEnvironment& env = rtspClient->envir();

 

 
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStart
StreamEvent);

 
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStopS
treamEvent);

 
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->mySeekA
bsoluteEvent);

 

 env << *rtspClient << "Closing the stream.\n";

 Medium::close(rtspClient);

 // Note that this will also cause this stream's "StreamClientState"
structure to get reclaimed.

}

 

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Possible to disable use of RTCP?

[Erlandsson, Claes P (CERLANDS)]

Cisco has confirmed a bug in their VSM-server (v6.3.2) when using RTSP. To
get around the bug we've been told to "disabling the use of RTCP when they
setup the playback sessions. This is done by only specifying one client port
(the RTP port) on the SETUP request. As the sessions are only kept up for 10
seconds, then RTCP is not required. RTCP is only required if the session is
going to be longer than 5 minutes."

 

The 10s sessions referred to in the quote is the cycle interval our client
uses to switch cameras, i.e. streams are continuously connected and shut
down. I haven't found a way to tell liveMedia to not use RTCP, or to change
the way the SETUP request is sent. Is it possible?

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] TEARDOWN issue when using response handler

[Erlandsson, Claes P (CERLANDS)]

I'm using the liveMedia (2012.11.05) connecting to a Cisco VSM (version
6.3.2-47d). The server, as I've mentioned in a previous post, requires the
client to wait for the TEARDOWN-response, otherwise the server logs will be
filled with errors and things will eventually go bad. This can arguably be
considered an issue with the server, but it should anyhow be possible to
work around.

 

The issue on the client side is that whenever using a TEARDOWN response
handler it crashes once in a while. I want to point out that I've has the
issue when using sendTeardownCommand() without a response handler. Our
client cycles through streams frequently and I'd say I see the problem about
1 time out of 7000. That means about once every other hour when cycling
through 10 cameras every 10s. 

 

After sending TEARDOWN the response handler is never called, but instead an
exception is thrown. I haven't been able to catch the exception in the
liveMedia DLL, but I instead get an AccessViolationException in the C# code
that uses it. Logging shows that the exception happens at the exact same
place every time, which is right after calling sendTeardownCommand(), but it
never reaches the response handler.

 

Please see sample code below.

 

The code can't really be simpler, and I've no idea why it occurs.

Have I missed something obvious? Anyone experienced anything similar?

 

 

 

void shutdownStream(RTSPClient* rtspClient, int exitCode)

{

// Code omitted, as shutdownStream() is identical to the testRTSPClient
example

// beside having moved Medium::close(rtspClient) to a separate function and
adding

// the TEARDOWN response handler

...

if (someSubsessionsWereActive)

rtspClient->sendTeardownCommand(*scs.session,
continueAfterTEARDOWN);

   else

cleanUpStream(rtspClient);

 }

 else

 {

   cleanUpStream(rtspClient);

 }

}

 

 

void continueAfterTEARDOWN(RTSPClient* rtspClient, int resultCode, char*
resultString)

{

 cleanUpStream(rtspClient);

}

 

 

void cleanUpStream(RTSPClient* rtspClient)

{

 UsageEnvironment& env = rtspClient->envir();

 
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStart
StreamEvent);

 
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStopS
treamEvent);

 
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->mySeekA
bsoluteEvent);

 

 env << *rtspClient << "Closing the stream.\n";

 Medium::close(rtspClient);

}

 

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] TEARDOWN issue when using response handler

[Erlandsson, Claes P (CERLANDS)]

Yes, I only call shutdownStream() from my StopStreamEvent, which is
triggered by triggerEvent(), and from other "internal" functions, similar to
the testRTSPClient example.

If that was the case though, I imagine it would be more random, and also
happen when not using a response handler. A few months back I did the
mistake of not using triggerEvent() and I sure experiences random crashes,
but this looks different.

/Claes


-Original Message-
From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of Matt Schuckmann
Sent: Thursday, November 08, 2012 12:45 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] TEARDOWN issue when using response handler

Are you sure you're calling sendTeardownCommand() from the liveMedia 
thread?
Typically I've seen random crashes like this when calling a liveMedia 
method from the wrong thread, usually inadvertently.

Matt S.

On Thursday, November 08, 2012 10:26:16 AM, Erlandsson, Claes P 
(CERLANDS) wrote:
> I'm using the liveMedia (2012.11.05) connecting to a Cisco VSM
> (version 6.3.2-47d). The server, as I've mentioned in a previous post,
> requires the client to wait for the TEARDOWN-response, otherwise the
> server logs will be filled with errors and things will eventually go
> bad. This can arguably be considered an issue with the server, but it
> should anyhow be possible to work around.
>
> The issue on the client side is that whenever using a TEARDOWN
> response handler it crashes once in a while. I want to point out that
> I've has the issue when using sendTeardownCommand() without a response
> handler. Our client cycles through streams frequently and I'd say I
> see the problem about 1 time out of 7000. That means about once every
> other hour when cycling through 10 cameras every 10s.
>
> After sending TEARDOWN the response handler is never called, but
> instead an exception is thrown. I haven't been able to catch the
> exception in the liveMedia DLL, but I instead get an
> AccessViolationException in the C# code that uses it. Logging shows
> that the exception happens at the exact same place every time, which
> is right after calling sendTeardownCommand(), but it never reaches the
> response handler.
>
> Please see sample code below.
>
> The code can't really be simpler, and I've no idea why it occurs.
>
> Have I missed something obvious? Anyone experienced anything similar?
>
> voidshutdownStream(RTSPClient* rtspClient, int exitCode)
>
> {
>
> // Code omitted, as shutdownStream() is identical to the
> testRTSPClient example
>
> // beside having moved Medium::close(rtspClient) to a separate
> function and adding
>
> // the TEARDOWN response handler
>
> ...
>
> if(someSubsessionsWereActive)
>
> rtspClient->sendTeardownCommand(*scs.session, continueAfterTEARDOWN);
>
> else
>
> cleanUpStream(rtspClient);
>
>  }
>
> else
>
>  {
>
>cleanUpStream(rtspClient);
>
>  }
>
> }
>
> voidcontinueAfterTEARDOWN(RTSPClient* rtspClient, int resultCode,
> char* resultString)
>
> {
>
>  cleanUpStream(rtspClient);
>
> }
>
> voidcleanUpStream(RTSPClient* rtspClient)
>
> {
>
>  UsageEnvironment& env = rtspClient->envir();
>
>
>
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStart
StreamEvent);
>
>
>
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->myStopS
treamEvent);
>
>
>
env.taskScheduler().deleteEventTrigger(((OurRTSPClient*)rtspClient)->mySeekA
bsoluteEvent);
>
>  env << *rtspClient << "Closing the stream.\n";
>
>  Medium::close(rtspClient);
>
> }
>
> /Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Windows make-files broken

[Erlandsson, Claes P (CERLANDS)]

 

When downloading and building the latest version (2012-01-04) on Windows I
ran into problems.

 

I get a fatal error for all projects. Example for liveMedia:

liveMedia.mak(54) : fatal error U1036: syntax error : too many names to left
of '='

Stop.

 

 

I noticed Makefile.tail has changed recently and it seems like the Windows
compiler (VS2008 & 2010 at least) doesn't like these lines (only PREFIX for
testProgs & mediaServer):

PREFIX ?= /usr/local

LIBDIR ?= $(PREFIX)/lib

 

 

When commenting out those lines it compiles just fine. This is of course
just a hack to make it compile. Not sure how to properly include the
recently added makefile install section on Windows.

 

 

/Claes

 



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Unhandled exception during TEARDOWN

[Erlandsson, Claes P (CERLANDS)]

I experience an issue with TEARDOWN that I can't resolve.

I've attached an example (testRTSPClientCycleStreams.cpp) that for me
results in an Unhandled exception after a while; it usually happens after 10
minutes to an hour. The example is the testRTSPClient example with some
modifications to cycle between two streams every 10s.

Summary of the changes:
- Added 10s delayed task in continueAfterPLAY() that calls
streamTimerHandler().
- streamTimerHandler() shuts down the running client and starts a new one.
Here are two hardcoded URL's that it switches between. Will most likely work
as well using one stream; just easier to spot different streams in the
output with two.
- Broken up the last part of shutdownStream() and put it in cleanUpStream().
The sendTeardownCommand() function now uses the continueAfterTEARDOWN
response handler. Using the response handler appears to be what is causing
the exception. Never seen the exception when passing NULL.
- Added cleanUpStream() that just performs the last cleanup.


If you have the time to compile and test, it should be enough to change the
URL's on line 391.

The exception appears to occur deep inside the event loop in standard
libraries and I haven't been able to make anything out of it. Would be great
if someone can confirm it happens for them or have any input on how to fix
it.
Also, of course, if you see any issues with the code, please let me know.
I run on a Windows client and have tested with Cisco VSM6 & VSM7 servers.


/Claes
/**
This library is free software; you can redistribute it and/or modify it under
the terms of the GNU Lesser General Public License as published by the
Free Software Foundation; either version 2.1 of the License, or (at your
option) any later version. (See .)

This library is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License for
more details.

You should have received a copy of the GNU Lesser General Public License
along with this library; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301  USA
**/
// Copyright (c) 1996-2013, Live Networks, Inc.  All rights reserved
// A demo application, showing how to create and run a RTSP client (that can 
potentially receive multiple streams concurrently).
//
// NOTE: This code - although it builds a running application - is intended 
only to illustrate how to develop your own RTSP
// client application.  For a full-featured RTSP client application - with much 
more functionality, and many options - see
// "openRTSP": http://www.live555.com/openRTSP/

#include "liveMedia.hh"
#include "BasicUsageEnvironment.hh"

// Forward function definitions:

// RTSP 'response handlers':
void continueAfterDESCRIBE(RTSPClient* rtspClient, int resultCode, char* 
resultString);
void continueAfterSETUP(RTSPClient* rtspClient, int resultCode, char* 
resultString);
void continueAfterPLAY(RTSPClient* rtspClient, int resultCode, char* 
resultString);
void continueAfterTEARDOWN(RTSPClient* rtspClient, int resultCode, char* 
resultString);

// Other event handler functions:
void subsessionAfterPlaying(void* clientData); // called when a stream's 
subsession (e.g., audio or video substream) ends
void subsessionByeHandler(void* clientData); // called when a RTCP "BYE" is 
received for a subsession
void streamTimerHandler(void* clientData);
  // called at the end of a stream's expected duration (if the stream has not 
already signaled its end using a RTCP "BYE")

// The main streaming routine (for each "rtsp://" URL):
void openURL(UsageEnvironment& env, char const* progName, char const* rtspURL);

// Used to iterate through each stream's 'subsessions', setting up each one:
void setupNextSubsession(RTSPClient* rtspClient);

// Used to shut down and close a stream (including its "RTSPClient" object):
void shutdownStream(RTSPClient* rtspClient, int exitCode = 1);
void cleanUpStream(RTSPClient* rtspClient);

// A function that outputs a string that identifies each stream (for debugging 
output).  Modify this if you wish:
UsageEnvironment& operator<<(UsageEnvironment& env, const RTSPClient& 
rtspClient) {
  return env << "[URL:\"" << rtspClient.url() << "\"]: ";
}

// A function that outputs a string that identifies each subsession (for 
debugging output).  Modify this if you wish:
UsageEnvironment& operator<<(UsageEnvironment& env, const MediaSubsession& 
subsession) {
  return env << subsession.mediumName() << "/" << subsession.codecName();
}

void usage(UsageEnvironment& env, char const* progName) {
  env << "Usage: " << progName << "  ... \n";
  env << "\t(where each  is a \"rtsp://\" URL)\n";
}

char eventLoopWatchVariable = 0;
bool streamSwitch = false; // Simple flag to switch between streams.

int main(int argc, char** argv) {
  // Begin by setting up our

Re: [Live-devel] Unhandled exception during TEARDOWN

[Erlandsson, Claes P (CERLANDS)]

I ran your modified application for several hours (on FreeBSD, under GDB),
and also on Linux using "valgrind", but unfortunately was unable to find any
problem.

 

I suspect that whatever bug is causing this is something that (for some
reason) is causing an exception only in your environment.  I'm still
interested in learning the cause, of course (especially if it is - as it
appears to be - a bug in our code), but it looks like you're probably going
to have to track this down yourself.

 

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

 

 

Thanks a lot for taking the time to test it.

 

I'm not really sure how to proceed, but I guess I can try to locate a Linux
client to compile and run the test on. It can of course be the Cisco server
that does something that somehow triggers the issue to occur in the client.
Cisco VSM7 should however be a complete rewrite from VSM6 and since the
behavior in this case is exactly the same it would surprise me a bit, but
any "oddities" can of course be carried over to a new version, rewrite or
not. I've however never seen anything strange in the logs indicating this.

 

As already mentioned, the issue always happens after calling
sendTeardownCommand() (with a response handler). When looking at the
callstack after the unhandled exception I often see slightly different
locations, where the last reference point is to some system DLL, e.g. ntdll
or msvcr90d.dll. The last RTSP client function call in the callstack is
often BasicTaskScheduler::SingleStep(). Would it be of any help to keep
track of and pass on the callstacks (or any other info)?

 

As expected, the debug output (from the previously attached test program)
always ends with the line "Opening connection to 192.168.1.103, port 554..."
after a TEARDOWN request has been sent. I've attached an output example; not
sure if it might be of any help. It can be seen that the TEARDOWN response
often comes after the new stream has been started, but I assume that is ok. 

 

 

/Claes

 



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Unhandled exception during TEARDOWN

[Erlandsson, Claes P (CERLANDS)]

Included the attachment I was mentioning below... It shows the last minute
or so of the output from the modified testRTSPClient.

 

/Claes

 

 

 

Thanks a lot for taking the time to test it.

 

I'm not really sure how to proceed, but I guess I can try to locate a Linux
client to compile and run the test on. It can of course be the Cisco server
that does something that somehow triggers the issue to occur in the client.
Cisco VSM7 should however be a complete rewrite from VSM6 and since the
behavior in this case is exactly the same it would surprise me a bit, but
any "oddities" can of course be carried over to a new version, rewrite or
not. I've however never seen anything strange in the logs indicating this.

 

As already mentioned, the issue always happens after calling
sendTeardownCommand() (with a response handler). When looking at the
callstack after the unhandled exception I often see slightly different
locations, where the last reference point is to some system DLL, e.g. ntdll
or msvcr90d.dll. The last RTSP client function call in the callstack is
often BasicTaskScheduler::SingleStep(). Would it be of any help to keep
track of and pass on the callstacks (or any other info)?

 

As expected, the debug output (from the previously attached test program)
always ends with the line "Opening connection to 192.168.1.103, port 554..."
after a TEARDOWN request has been sent. I've attached an output example; not
sure if it might be of any help. It can be seen that the TEARDOWN response
often comes after the new stream has been started, but I assume that is ok. 

 

 

/Claes

 

[URL:"rtsp://192.168.1.103/live/TVF-01/"]: Initiated the "video/JPEG" 
subsession (client ports 51842-51843)
Sending request: SETUP rtsp://192.168.1.103/live/TVF-01 RTSP/1.0
CSeq: 3
User-Agent: Test (LIVE555 Streaming Media v2013.01.04)
Transport: RTP/AVP;unicast;client_port=51842-51843


Received 162 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK
CSeq: 3
Session: 725498257;timeout=300
Transport: 
RTP/AVP;unicast;client_port=51842-51843;server_port=54142-54143;mode="PLAY";ssrc=23450494


[URL:"rtsp://192.168.1.103/live/TVF-01/"]: Set up the "video/JPEG" subsession 
(client ports 51842-51843)
[URL:"rtsp://192.168.1.103/live/TVF-01/"]: Created a data sink for the 
"video/JPEG" subsession
Sending request: PLAY rtsp://192.168.1.103/live/TVF-01/ RTSP/1.0
CSeq: 4
User-Agent: Test (LIVE555 Streaming Media v2013.01.04)
Session: 725498257
Range: npt=0.000-


Received 126 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK
CSeq: 4
Session: 725498257
RTP-Info: url=rtsp://192.168.1.103/live/TVF-01;seqno=28099
Range: npt=0.00-


[URL:"rtsp://192.168.1.103/live/TVF-01/"]: Started playing session...
Sending request: TEARDOWN rtsp://192.168.1.103/live/TVF-01/ RTSP/1.0
CSeq: 5
User-Agent: Test (LIVE555 Streaming Media v2013.01.04)
Session: 725498257


Opening connection to 192.168.1.103, port 554...
...remote connection opened
Sending request: DESCRIBE rtsp://192.168.1.103/live/TVF-16 RTSP/1.0
CSeq: 2
User-Agent: Test (LIVE555 Streaming Media v2013.01.04)
Accept: application/sdp


Received 485 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK
CSeq: 2
Content-Base: rtsp://192.168.1.103/live/TVF-16/
Content-Type: application/sdp
Content-Length: 356

v=0
o=- 15319195471205593595 15319195471205593625 IN IP4 192.168.1.101
s=Cisco Live Media Streaming Session
e=NONE
c=IN IP4 0.0.0.0
b=AS:3000
t=0 0
a=control:*
a=range:npt=now-
m=video 0 RTP/AVP 26
a=rtpmap:26 JPEG/9
a=fmtp:26 width=704;height=480;4CIF=1
a=framerate:15.00
a=range:npt=now-
a=control:rtsp://192.168.1.103/live/TVF-16



[URL:"rtsp://192.168.1.103/live/TVF-16/"]: Got a SDP description:
v=0
o=- 15319195471205593595 15319195471205593625 IN IP4 192.168.1.101
s=Cisco Live Media Streaming Session
e=NONE
c=IN IP4 0.0.0.0
b=AS:3000
t=0 0
a=control:*
a=range:npt=now-
m=video 0 RTP/AVP 26
a=rtpmap:26 JPEG/9
a=fmtp:26 width=704;height=480;4CIF=1
a=framerate:15.00
a=range:npt=now-
a=control:rtsp://192.168.1.103/live/TVF-16



[URL:"rtsp://192.168.1.103/live/TVF-16/"]: Initiated the "video/JPEG" 
subsession (client ports 51844-51845)
Sending request: SETUP rtsp://192.168.1.103/live/TVF-16 RTSP/1.0
CSeq: 3
User-Agent: Test (LIVE555 Streaming Media v2013.01.04)
Transport: RTP/AVP;unicast;client_port=51844-51845


Received 48 new bytes of response data.
Received a complete TEARDOWN response:
RTSP/1.0 200 OK
CSeq: 5
Session: 725498257


[URL:"rtsp://192.168.1.103/live/TVF-01/"]: Closing the stream.
Received 162 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK
CSeq: 3
Session: 725498258;timeout=300
Transport: 
RTP/AVP;unicast;client_port=51844-51845;server_port=57970-57971;mode="PLAY";ssrc=23454322


[URL:"rtsp://192.168.1.103/live/TVF-16/"]: Set up the "video/JPEG" subsession 
(client ports 51844-51845)
[URL:"rtsp://192.168.1.103/live/TVF-16/"]: Created a data sink for the 
"vid

[Live-devel] Windows build, some projects failing

[Erlandsson, Claes P (CERLANDS)]

fyi: While downloading and compiling the latest (live.2013.01.15.tar) code I
noticed testProgs, mediaServer and proxyServer still fails on Windows, i.e.
Makefile.tail contains ?= which nmake doesn't like:

PREFIX ?= /usr/local

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Unhandled exception during TEARDOWN

[Erlandsson, Claes P (CERLANDS)]

The crashes are very consistent. Not the frequency, but the location. When
they occur, 602 is always the last message printed. I've attached an output
example. Judging by the callstack it almost looks to me like the printf
would be the cause, but the same thing happens if I remove the debug output,
i.e. 602, and 601 etc.

 

This however makes no sense at all. What is causing the sudden app crash? I
see no explanation at all in the code.

 

I suspect that a 'memory smash' - i.e., a write through a bad pointer
(caused by a bug in the code) - is to blame.  If that happens, then a
pointer somewhere else might be getting corrupted, which could lead to an
error like this that occurs in an unexpected place in the code.

 

I suggest that you run a 'memory debugger' on your application.  See

http://en.wikipedia.org/wiki/Memory_debugger

 

Some tools that I've seen recommended are

- "Dr. Memory":  http://code.google.com/p/drmemory/

- "OllyDbg":http://ollydbg.de/

 

Thanks. Never heard of those two, but will look into.





I would also suspect threads going havoc, but as liveMedia is
single-threaded that shouldn't be the case.

 

Correct - provided, of course, that your *application* uses only a single
thread (that calls LIVE555 code).

 

Well, "our app" uses multiple threads outside the liveMedia library, but
I've lately only been testing with the modified testRTSPClient that I
attached.





It definitely seems like the server matters. How can that be?

 

Perhaps it's because the different servers (streams) use different codecs
(and thus our RTSP client code uses different classes to receive/process the
incoming packets)?

 

I see (from the SDP descriptions returned in response to "DESCRIBE") that
the stream(s) that are causing your crash are using motion JPEG.  What about
the "Axis 243q" streams (the ones that you think do not cause the crash)?
What codec do they use?  (Please post a SDP description from those streams.)

 

That makes sense. I was planning on setting up some Cisco VMS streams using
mpeg4, but wasn't sure how/if that affected the client. The Axis 243q always
outputs mpeg4 while using rtsp. I've attached output from Axis 243q
mpeg4-streams which includes the SDP. Now when you point it out it seems
fairly safe to say jpeg is the source of the issue.

 

btw. I know you discourage mjpeg, and I can agree on that, but there are
legacy reasons for us still using it and bandwidth isn't an issue in our
case.

 

Thanks!

 

/Claes

 

 

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

 

e:\projects\live\Release>testRTSPClient.exe 
rtsp://192.168.1.102/mpeg4/media.amp rtsp://192.168.1.110/mpeg4/media.amp
100 0Entering RTSPClient::connectToServer()
Opening connection to 192.168.1.102, port 554...
1 2 3 4 124 a1a3a0 554 10035 5 101 103 10 11 20 21 22 23 24 26 ...remote 
connection opened
27 28 Sending request: DESCRIBE rtsp://192.168.1.102/mpeg4/media.amp RTSP/1.0
CSeq: 2
User-Agent: Test (LIVE555 Streaming Media v2013.01.15)
Accept: application/sdp


 400  401  402  403 29 200 201 Received 837 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK
CSeq: 2
Content-Base: rtsp://192.168.1.102:554/mpeg4/media.amp/
Content-Type: application/sdp
Content-Length: 700

v=0
o=- 719747360261394 719747360261404 IN IP4 192.168.1.102
s=Media Presentation
e=NONE
c=IN IP4 0.0.0.0
b=AS:8000
t=0 0
a=control:*
a=range:npt=now-
a=mpeg4-iod: 
"data:application/mpeg4-iod;base64,AoDUAE8BAf/1AQOAbwABQFBkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCx
UjBCR3dVZkF4Y0F5U1FBWlFRTklCRUVrK0FBZWhJQUFIb1NBQVlCQkE9PQQNAQUABAYJAQAAAzoAAkA2ZGF0YTphcHBsaWNhdGl
bi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTWVFTSVVFVUZQd0E9BBICDQAAAgAABQMAAEAGCQEAAA=="
m=video 0 RTP/AVP 96
b=AS:8000
a=framerate:30.0
a=control:trackID=1
a=rtpmap:96 MP4V-ES/9
a=fmtp:96 profile-level-id=245; 
config=01B0F501B5090100012008D49D88032516043C14440F
a=mpeg4-esid:201

[URL:"rtsp://192.168.1.102:554/mpeg4/media.amp/"]: Got a SDP description:
v=0
o=- 719747360261394 719747360261404 IN IP4 192.168.1.102
s=Media Presentation
e=NONE
c=IN IP4 0.0.0.0
b=AS:8000
t=0 0
a=control:*
a=range:npt=now-
a=mpeg4-iod: 
"data:application/mpeg4-iod;base64,AoDUAE8BAf/1AQOAbwABQFBkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCx
UjBCR3dVZkF4Y0F5U1FBWlFRTklCRUVrK0FBZWhJQUFIb1NBQVlCQkE9PQQNAQUABAYJAQAAAzoAAkA2ZGF0YTphcHBsaWNhdGl
bi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTWVFTSVVFVUZQd0E9BBICDQAAAgAABQMAAEAGCQEAAA=="
m=video 0 RTP/AVP 96
b=AS:8000
a=framerate:30.0
a=control:trackID=1
a=rtpmap:96 MP4V-ES/9
a=fmtp:96 profile-level-id=245; 
config=01B0F501B5090100012008D49D88032516043C14440F
a=mpeg4-esid:201

[URL:"rtsp://192.168.1.102:554/mpeg4/media.amp/"]: Init

[Live-devel] Connection failure - socket error 10057

[Erlandsson, Claes P (CERLANDS)]

Once in a while, about 1 out of maybe 3000 connections, I notice a
connection failure. The client runs on Windows.

 

The DESCRIBE response handler receives resultCode -10057 and resultString
"Unknown error". I first suspected the server was to blame by not
responding, but when I look at socket error 10057 the description says
"Socket is not connected." (WSAENOTCONN), which sounds like a client issue.
I btw don't know why it says -10057, but assume it is socket error 10057.

 

Does this happen to anyone else?

Anyone have more insight in why/when this socket error occur?

 

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Confirm absolute time playing position on startup

[Erlandsson, Claes P (CERLANDS)]

In the following examples I'm writing about streams that are (in the code)
referred to as indexed by 'absolute' time. For video storage and security I
believe they're often referred to as archive streams.

 

 

Seeking while already streaming 

When doing a "seek" while the stream is playing, i.e. calling
rtspClient->sendPlayCommand() with a new position to jump to, you will in
the response handler be able to verify the actual position you end up
playing.

scs.session->absStartTime()  could e.g. be 20130318T180327Z.

 

It's a great way to verify that you got what you asked for. This is of
course very useful as video hiccups are not uncommon.

 

 

Start new stream at specific position

When starting a new stream, also by calling rtspClient->sendPlayCommand()
with an absolute position, the behavior appears to be different;
scs.session->absStartTime() then instead returns the timestamp of the
beginning of the stream. That information could be useful, but I'd say the
expected information is to be consistent with how it works when jumping in
the stream while it's already playing.

Is this intended, or is it somehow server dependent?

 

 

btw. scs.session->absEndTime()  contains the timestamp for the end of the
stream in both cases. 

 

 

Is there a way to confirm what position is currently playing when starting
up a stream?

 

Is there a way to ask for the timestamp that's currently being played at any
given time?

 

 

/Claes

 



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Confirm absolute time playing position on startup

[Erlandsson, Claes P (CERLANDS)]

Is this intended, or is it somehow server dependent?

 

I don't know.  Please show the complete RTSP protocol exchange for each
case, so I can try to figure out what's happening.

 





I've attached the protocol exchange for the following example:

 

1. Start up an archive stream without any timestamp.

PLAY rtsp://192.168.1.103/archive/TVF-01a/ RTSP/1.0

 

2. Seek in that stream.

Range: clock=20130322T20.000Z-

 

3. And then, after teardown, start up the same stream with the same
seek-time.

PLAY rtsp://192.168.1.103/archive/TVF-01a/ RTSP/1.0

Range: clock=20130322T20.000Z-

 

 

 

The response to #2:

Range: clock=20130322T20Z-20130322T204538Z

 

The PLAY- response to #3:

Range: clock=20130320T203757Z-20130322T204804Z

 

 

So, if I interpret this correctly it's the Cisco server that is
inconsistent.

I don't see any specific examples of this in the RFC2326, but appears like
an error to me. Please comment.

 

 

/Claes

Opening connection to 192.168.1.103, port 554...
...remote connection opened
Sending request: DESCRIBE rtsp://192.168.1.103/archive/TVF-01a RTSP/1.0

CSeq: 2

User-Agent: Arinc RTSP DLL (LIVE555 Streaming Media v2013.03.07)

Accept: application/sdp




Received 512 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK

CSeq: 2

Content-Base: rtsp://192.168.1.103/archive/TVF-01a/

Content-Type: application/sdp

Content-Length: 379



v=0

o=- 15345806154308539295 15345806154308539295 IN IP4 192.168.1.101

s=Cisco Media Streaming Session

e=NONE

c=IN IP4 192.168.1.101

b=AS:512

t=0 0

a=control:*

a=range:clock=20130320T203757.046Z-

m=video 0 RTP/AVP 26

a=rtpmap:26 JPEG/9

a=fmtp:26 width=704;height=480;4CIF=1

a=framerate:15.07

a=range:npt=0.0-

a=control:rtsp://192.168.1.103/archive/TVF-01a






Sending request: SETUP rtsp://192.168.1.103/archive/TVF-01a RTSP/1.0

CSeq: 3

User-Agent: Arinc RTSP DLL (LIVE555 Streaming Media v2013.03.07)

Transport: RTP/AVP;unicast;client_port=57048-57049




Received 163 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK

CSeq: 3

Session: 1341378127;timeout=300

Transport: 
RTP/AVP;unicast;client_port=57048-57049;server_port=43474-43475;mode="PLAY";ssrc=23439826




Sending request: PLAY rtsp://192.168.1.103/archive/TVF-01a/ RTSP/1.0

CSeq: 4

User-Agent: Arinc RTSP DLL (LIVE555 Streaming Media v2013.03.07)

Session: 1341378127

Range: clock=-




Received 161 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK

CSeq: 4

Session: 1341378127

RTP-Info: url=rtsp://192.168.1.103/archive/TVF-01a;seqno=64052

Range: clock=20130320T203757Z-20130322T204524Z




Sending request: PLAY rtsp://192.168.1.103/archive/TVF-01a/ RTSP/1.0

CSeq: 5

User-Agent: Arinc RTSP DLL (LIVE555 Streaming Media v2013.03.07)

Session: 1341378127

Range: clock=20130322T20.000Z-




Received 160 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK

CSeq: 5

Session: 1341378127

RTP-Info: url=rtsp://192.168.1.103/archive/TVF-01a;seqno=3575

Range: clock=20130322T20Z-20130322T204538Z




Sending request: TEARDOWN rtsp://192.168.1.103/archive/TVF-01a/ RTSP/1.0

CSeq: 6

User-Agent: Arinc RTSP DLL (LIVE555 Streaming Media v2013.03.07)

Session: 1341378127




Received 49 new bytes of response data.
Received a complete TEARDOWN response:
RTSP/1.0 200 OK

CSeq: 6

Session: 1341378127




Opening connection to 192.168.1.103, port 554...
...remote connection opened
Sending request: DESCRIBE rtsp://192.168.1.103/archive/TVF-01a RTSP/1.0

CSeq: 2

User-Agent: Arinc RTSP DLL (LIVE555 Streaming Media v2013.03.07)

Accept: application/sdp




Received 512 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK

CSeq: 2

Content-Base: rtsp://192.168.1.103/archive/TVF-01a/

Content-Type: application/sdp

Content-Length: 379



v=0

o=- 15345806840033074925 15345806840033074925 IN IP4 192.168.1.101

s=Cisco Media Streaming Session

e=NONE

c=IN IP4 192.168.1.101

b=AS:512

t=0 0

a=control:*

a=range:clock=20130320T203757.046Z-

m=video 0 RTP/AVP 26

a=rtpmap:26 JPEG/9

a=fmtp:26 width=704;height=480;4CIF=1

a=framerate:15.07

a=range:npt=0.0-

a=control:rtsp://192.168.1.103/archive/TVF-01a






Sending request: SETUP rtsp://192.168.1.103/archive/TVF-01a RTSP/1.0

CSeq: 3

User-Agent: Arinc RTSP DLL (LIVE555 Streaming Media v2013.03.07)

Transport: RTP/AVP;unicast;client_port=57054-57055




Received 163 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK

CSeq: 3

Session: 1341378343;timeout=300

Transport: 
RTP/AVP;unicast;client_port=57054-57055;server_port=51424-51425;mode="PLAY";ssrc=23447776




Sending request: PLAY rtsp://192.168.1.103/archive/TVF-01a/ RTSP/1.0

CSeq: 4

User-Agent: Arinc RTSP DLL (LIVE555 Streaming Media v2013.03.07)

Session: 1341378343

Range: clock=20130322T20.000Z-




Received 161 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 O

[Live-devel] Trick-play - Reverse

[Erlandsson, Claes P (CERLANDS)]

Can someone confirm if reverse play works fine?

 

Whenever I supply a negative scale value to the Play-function it always
plays forward. The speed is correct, but I've never been able to play in
reverse.

 

It might be some RTSP fluke with the Cisco VSM server we're using, but
wanted to verify if reverse works fine for others.

 

 

 

Also, kind of related to trick-play... Is it possible to do frame-stepping
in RTSP?

 

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Trick-play - Reverse

[Erlandsson, Claes P (CERLANDS)]

Whenever I supply a negative scale value to the Play-function it always
plays forward. The speed is correct, but I've never been able to play in
reverse.

 

Don't forget to also specify a non-zero 'start time', so that the server
knows where to start reverse-play from.

 

 

Thanks, I do that. I should probably also have mentioned that the streams
are all indexed by absolute time.

 

absoluteStartPosition below can e.g. be "20130420T040645.774Z". -10 in the
example gives the exact same result as if I use 10.

rtspClient->sendPlayCommand(*scs.session, continueAfterPLAY,
scs.absoluteStartPosition, "", -10.0);

 

 

The main reason I didn't blame Cisco's VSM server right away is because
reverse play works in Cisco's player that comes with the server (which
however doesn't use RTSP).

 

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Segmentation fault after TEARDOWN

[Erlandsson, Claes P (CERLANDS)]

I unfortunately don't have much more info, but I believe I also experience
this issue.

 

Last week I upgraded from 2013.03.07 to 2013.04.23 and we suddenly started
to experience program crashes (liveMedia used within a DLL in Windows client
streaming mjpeg). I didn't suspect the liveMedia update at first, since we
also had made some other changes, but when I saw your message I reverted
back to 2013.03.07 and now everything seems to work as before.

 

/Claes

 

 

From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of
serge.gron...@miranda.com
Sent: Monday, April 29, 2013 2:14 PM
To: LIVE555 Streaming Media - development & use
Cc: live-devel-boun...@ns.live555.com
Subject: Re: [Live-devel] Segmentation fault after TEARDOWN

 

Hi guys,

I got the exact same crash today while testing RTSP over TCP, I can see that
the root cause seems to come from file RTPInterface.cpp in
SocketDescriptor::tcpReadHandler() (line 406).  There is a while loop that
was not there before and it finally crash in Groupsock while looping this
code.  I don't have time now to give more info but I can provider a better
call stack later if needed.

Serge




Inactive hide details for Conchi Abasolo ---2013-04-29 10:04:46---Hello,
I've update to the last version of the live555 libraryConchi Abasolo
---2013-04-29 10:04:46---Hello, I've update to the last version of the
live555 library (2013.04.23) and 've

From: Conchi Abasolo 
To: live-de...@ns.live555.com, 
Date: 2013-04-29 10:04
Subject: [Live-devel] Segmentation fault after TEARDOWN
Sent by: live-devel-boun...@ns.live555.com

  _  




Hello,

I've update to the last version of the live555 library (2013.04.23) and 've
experiencing a problem that doesn't appear in previous versions. After a
TEARDOWN sent by the client, the software crashes with a segmentation fault.

I've reproduced the problem with the live555ProxyServer (I send attached the
application log).You can see that after a TEARDOWN sent by the client, the
proxy server tries to execute the
"ProxyServerMediaSubsession["H264"]::closeStreamSource()", and then the
segmentation fault occurs.
I don't know whats happening, but with the 2013.04.01 version doesn't
happen.
It seems that any change in the last version causes this issue
I would be grateful if someone could help me with this


Conchi Abasolo Pérez
C/Santiago Grisolía nº 2, of. 203
Edif. PCM, Parque Tecnológico de Madrid
28760 Tres Cantos, Madrid
[attachment "live555ProxyServer.txt" deleted by Serge
Grondin/MontrealMIR/BeldenCDT]
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

DISCLAIMER: Privileged and/or Confidential information may be contained in
this message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you should
destroy the message and kindly notify the sender by reply e-mail. It is
understood that opinions or conclusions that do not relate to the official
business of the company are neither given nor endorsed by the company. Thank
You. 

<>

smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Best way to get video width and height?

[Erlandsson, Claes P (CERLANDS)]

 

I receive a mjpeg stream from a Cisco server. In the SDP I see this line:

 

a=fmtp:26 width=704;height=480;4CIF=1

 

When looking at fVideoWidth & fVideoHeight in MediaSubsession they are
always 0 and it looks like they're only populated if "a=x-dimensions:%d,%d"
is found in the SDP.

 

 

Is there another reliable way to grab the video resolution or would you need
to "manually" parse the SDP line above?

 

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Rare 2s "delay" when viewing live streams

[Erlandsson, Claes P (CERLANDS)]

We stream lots of live MJPEG streams using a pretty simple client that is
based on the testRTSPClient example. In very rare cases we see a delay/lag
that I can't explain.

 

When it happens it is like the live video is delayed 2s. If I at the time
start the same stream in VLC and specify a cache of 2000ms the videos play
in sync.

 

The thing is that we don't buffer anything, and the fact that any other
instance of our program, or any other player, shows the video live tells me
it's not the server. The instance where the delay can be seen will continue
to do show the delay for all following streams (using the same live555 event
loop), i.e. if I switch to another stream the delay is still there. It
should be noted that the video plays smooth (no visible frame dropping),
just that there is a consistent 2s lag. As mentioned, this is very rare and
I've only seen it twice in the last four months, so it's not something that
I can recreate.

 

 

I didn't think live555 really buffer anything, but when trying to look for
any explanation at all to this "magic delay" I stumbled upon some old posts
that mention a buffer used for sorting RTP packages that are received out of
order. It also mentions that setPacketReorderingThresholdTime() can be
called to minimize this time. I believe we have quite a bit of packet loss
and I will try to check this out, but since we can't reproduce the issue
it's like a ghost hunt and it would be great to get some feedback on this.

 

 

- Is there any possibility that a "delay" (>1s) can somehow be introduced in
live555 (e.g. during heavy packet loss)?

 

- Has anyone else experienced any delayed live streams like this?

 

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Rare 2s "delay" when viewing live streams

[Erlandsson, Claes P (CERLANDS)]

Thanks for the confirmation Ross.

 

We do use UDP, i.e. the default, which makes this lag so very strange. I can
clearly see all frames being received on the first UDP-port (when viewing
ports in use with e.g. TCPView).

 

This 2s lag has been observed three times in total over the last four
months, on different workstations. However, each test-workstation cycles
through a lot of streams, each typically making around 100,000 connections a
day, so it's a very rare occurrence. The fact that it continues to happen
once it started, i.e. for every subsequent connection using the same event
loop/video pane is even more confusing.

 

/Claes

 

Of course our code doesn't buffer anything for 2 seconds.  (The 'packet
reordering' queue delays incoming packets for at most the 'packet reordering
threshold' - which is, by default, only 100 ms - and only if packet loss
occurs.)

 

The delay is obviously caused by the TCP implementation - i.e., in the OSs
of your server and client.  This is not a bug; this is simply TCP's way of
ensuring reliable data delivery, in the face of high data rates and lossy
networks.  To overcome this, either send less, or stream via UDP instead of
TCP. (You should stream RTP-over-TCP *only* if there's a firewall - between
the server and client - that blocks UDP packets.)

 

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] Seeing small handle leak when repeatedly starting and stopping event loop

[Erlandsson, Claes P (CERLANDS)]

When I start and stop the liveMedia event loop I see a small handle leak in
my Windows test client. When looking in Process Explorer I can see the
amount of file handles with the name "\Device\Afd" growing.

 

I don't have to stream anything for it to occur, i.e. I just start the event
loop and then bring it down by setting the flag to 1. It is very possible
it's due to some needed cleanup I'm missing.

 

After leaving doEventLoop I delete my trigger(s), call env->reclaim() and
delete the TaskScheduler.

Is there anything else that should be done?

 

 

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Seeing small handle leak when repeatedly starting and stopping event loop

[Erlandsson, Claes P (CERLANDS)]

To verify if the handle leak I've noticed is in my code or in liveMedia I
wrote a really simple program that just start and stops the event loop. I
took the latest testRTSPClient.cpp and just replaced main() with a loop that
initiates a thread which starts the event loop - StartEventLoop(). The main
thread sleeps for 2s and then sets eventLoopWatchVariable making the thread
exit. No streams are started, it's just the event loop going up and down.

 

Code attached (testLiveMediaUpDown.cpp). I compile it using VC++; threading
probably needs to be adjusted if using other compiler/OS.

 

If I run this and monitor handles used I can see that the handles are
incremented by one each time the event loop runs. This can e.g. be done
using SysInternal's "Process Explorer" (handle column not on by default).
Looking at the handle type I can also see it's the "\Device\Afd" handles
that are increasing. I believe "Afd" stands for Auxiliary Function Driver
and that it's related to sockets, but "Afd" is new to me as I've have never
come across it before.

 

 

Any idea where that handle leak originates? Could it be Windows specific?

 

 

/Claes

 

From: Erlandsson, Claes P (CERLANDS) 
Sent: Friday, July 19, 2013 11:20 AM
To: 'live-devel@lists.live555.com'
Subject: Seeing small handle leak when repeatedly starting and stopping
event loop

 

When I start and stop the liveMedia event loop I see a small handle leak in
my Windows test client. When looking in Process Explorer I can see the
amount of file handles with the name "\Device\Afd" growing.

 

I don't have to stream anything for it to occur, i.e. I just start the event
loop and then bring it down by setting the flag to 1. It is very possible
it's due to some needed cleanup I'm missing.

 

After leaving doEventLoop I delete my trigger(s), call env->reclaim() and
delete the TaskScheduler.

Is there anything else that should be done?

 

 

/Claes

/**
This library is free software; you can redistribute it and/or modify it under
the terms of the GNU Lesser General Public License as published by the
Free Software Foundation; either version 2.1 of the License, or (at your
option) any later version. (See <http://www.gnu.org/copyleft/lesser.html>.)

This library is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License for
more details.

You should have received a copy of the GNU Lesser General Public License
along with this library; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301  USA
**/
// Copyright (c) 1996-2013, Live Networks, Inc.  All rights reserved
// A demo application, showing how to create and run a RTSP client (that can 
potentially receive multiple streams concurrently).
//
// NOTE: This code - although it builds a running application - is intended 
only to illustrate how to develop your own RTSP
// client application.  For a full-featured RTSP client application - with much 
more functionality, and many options - see
// "openRTSP": http://www.live555.com/openRTSP/

#include "liveMedia.hh"
#include "BasicUsageEnvironment.hh"

#include 
#include 
using namespace std;

// Forward function definitions:

// RTSP 'response handlers':
void continueAfterDESCRIBE(RTSPClient* rtspClient, int resultCode, char* 
resultString);
void continueAfterSETUP(RTSPClient* rtspClient, int resultCode, char* 
resultString);
void continueAfterPLAY(RTSPClient* rtspClient, int resultCode, char* 
resultString);

// Other event handler functions:
void subsessionAfterPlaying(void* clientData); // called when a stream's 
subsession (e.g., audio or video substream) ends
void subsessionByeHandler(void* clientData); // called when a RTCP "BYE" is 
received for a subsession
void streamTimerHandler(void* clientData);
  // called at the end of a stream's expected duration (if the stream has not 
already signaled its end using a RTCP "BYE")

// The main streaming routine (for each "rtsp://" URL):
void openURL(UsageEnvironment& env, char const* progName, char const* rtspURL);

// Used to iterate through each stream's 'subsessions', setting up each one:
void setupNextSubsession(RTSPClient* rtspClient);

// Used to shut down and close a stream (including its "RTSPClient" object):
void shutdownStream(RTSPClient* rtspClient, int exitCode = 1);

// A function that outputs a string that identifies each stream (for debugging 
output).  Modify this if you wish:
UsageEnvironment& operator<<(UsageEnvironment& env, const RTSPClient& 
rtspClient) {
  return env << "[URL:\"" << rtspClient

Re: [Live-devel] Problem with RTSP streaming of HD Camera with Live555Proxyserver

[Erlandsson, Claes P (CERLANDS)]

>I try to increase "OutPacketBuffer::maxSize" to 10 or 20 but the
>problem it's the same.


How big are your frames? I typically see larger frames than that from high
resolution cameras and have the buffer set to 50 or 100.

/Claes



smime.p7s
Description: S/MIME cryptographic signature
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Live-devel] GroupsockHelper for Android

[Chase, Brian P [US] (MS)]

Good day,

In the GroupsockHelper.cpp file there are couple of preprocessor conditional 
blocks that populate a struct differently depending on whether the platform is 
Android or anything else. With the latest version of Android's Native 
Development Kit (NDK), version 17, the headers included define that struct the 
same way as the other platforms, thus breaking the code in those preprocessor 
blocks.

Therefore, I propose to that the "#ifdef __ANDROID__" lines be replace with 
"#if ANDROID_NDK_OLD" and such as the following block added amidst the other 
'#include's:

#ifdef __ANDROID_NDK__
#include 
#define ANDROID_OLD_NDK __NDK_MAJOR__ < 17
#endif

I hope these changes will be useful. I have attached a patch file and resulting 
source file for clarity. Have a blessed day.

Regards,
-Brian P. Chase




GroupsockHelper_cpp.patch
Description: GroupsockHelper_cpp.patch
/**
This library is free software; you can redistribute it and/or modify it under
the terms of the GNU Lesser General Public License as published by the
Free Software Foundation; either version 3 of the License, or (at your
option) any later version. (See <http://www.gnu.org/copyleft/lesser.html>.)

This library is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License for
more details.

You should have received a copy of the GNU Lesser General Public License
along with this library; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301  USA
**/
// "mTunnel" multicast access service
// Copyright (c) 1996-2018 Live Networks, Inc.  All rights reserved.
// Helper routines to implement 'group sockets'
// Implementation

#include "GroupsockHelper.hh"

#if (defined(__WIN32__) || defined(_WIN32)) && !defined(__MINGW32__)
#include 
extern "C" int initializeWinsockIfNecessary();
#else
#include 
#include 
#include 
#if !defined(_WIN32)
#include 
#ifdef __ANDROID_NDK__
#include 
#define ANDROID_OLD_NDK __NDK_MAJOR__ < 17
#endif
#endif
#include 
#define initializeWinsockIfNecessary() 1
#endif
#if defined(__WIN32__) || defined(_WIN32) || defined(_QNX4)
#else
#include 
#define USE_SIGNALS 1
#endif
#include 

// By default, use INADDR_ANY for the sending and receiving interfaces:
netAddressBits SendingInterfaceAddr = INADDR_ANY;
netAddressBits ReceivingInterfaceAddr = INADDR_ANY;

static void socketErr(UsageEnvironment& env, char const* errorMsg) {
  env.setResultErrMsg(errorMsg);
}

NoReuse::NoReuse(UsageEnvironment& env)
  : fEnv(env) {
  groupsockPriv(fEnv)->reuseFlag = 0;
}

NoReuse::~NoReuse() {
  groupsockPriv(fEnv)->reuseFlag = 1;
  reclaimGroupsockPriv(fEnv);
}


_groupsockPriv* groupsockPriv(UsageEnvironment& env) {
  if (env.groupsockPriv == NULL) { // We need to create it
_groupsockPriv* result = new _groupsockPriv;
result->socketTable = NULL;
result->reuseFlag = 1; // default value => allow reuse of socket numbers
env.groupsockPriv = result;
  }
  return (_groupsockPriv*)(env.groupsockPriv);
}

void reclaimGroupsockPriv(UsageEnvironment& env) {
  _groupsockPriv* priv = (_groupsockPriv*)(env.groupsockPriv);
  if (priv->socketTable == NULL && priv->reuseFlag == 1/*default value*/) {
// We can delete the structure (to save space); it will get created again, 
if needed:
delete priv;
env.groupsockPriv = NULL;
  }
}

static int createSocket(int type) {
  // Call "socket()" to create a (IPv4) socket of the specified type.
  // But also set it to have the 'close on exec' property (if we can)
  int sock;

#ifdef SOCK_CLOEXEC
  sock = socket(AF_INET, type|SOCK_CLOEXEC, 0);
  if (sock != -1 || errno != EINVAL) return sock;
  // An "errno" of EINVAL likely means that the system wasn't happy with the 
SOCK_CLOEXEC; fall through and try again without it:
#endif

  sock = socket(AF_INET, type, 0);
#ifdef FD_CLOEXEC
  if (sock != -1) fcntl(sock, F_SETFD, FD_CLOEXEC);
#endif
  return sock;
}

int setupDatagramSocket(UsageEnvironment& env, Port port) {
  if (!initializeWinsockIfNecessary()) {
socketErr(env, "Failed to initialize 'winsock': ");
return -1;
  }

  int newSocket = createSocket(SOCK_DGRAM);
  if (newSocket < 0) {
socketErr(env, "unable to create datagram socket: ");
return newSocket;
  }

  int reuseFlag = groupsockPriv(env)->reuseFlag;
  reclaimGroupsockPriv(env);
  if (setsockopt(newSocket, SOL_SOCKET, SO_REUSEADDR,
 (const char*)&reuseFlag, sizeof reuseFlag) < 0) {
socketErr(env, "setsockopt(SO_REUSEADDR) error: ");
closeSocket(newSocket);
return -1;
  }

#if defined(__WIN32__) || defined(_WIN32)
  // Windoze doesn't pro