Ran Shalit | 1 Jul 2012 14:56
Picon

SAP - session announcement protocol

Hello,

Is SAP - session announcement protocol supported in Live555 streaming media ?

Best Regards,

Ran
Ross Finlayson | 2 Jul 2012 05:31
Favicon

Re: SAP - session announcement protocol

Is SAP - session announcement protocol supported in Live555 streaming media ?

We have a demo application - "sapWatch" - that will read and display SAP announcements, but we don't have any direct support for creating and sending SAP announcements; you would need to program that yourself.


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

_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
jhseo | 2 Jul 2012 09:08
Picon
Gravatar

Question about proxyserver.

 

Hi.

 

Forward / Backward random seeking is supported in LIVE555 Proxy server?

 

In my case,,

Seeking bar is activated by modifying the “virtual float duration( ) const;

however, the command of client( “PAUSE” or “PLAY”) did not send to back-end LIVE555 Server.

To do this, what shall I modify in Proxy Server Source code?

 

Thanks for your interest.

_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Ross Finlayson | 2 Jul 2012 09:41
Favicon

Re: Question about proxyserver.

Forward / Backward random seeking is supported in LIVE555 Proxy server?

No, it's not - because the purpose of the "LIVE555 Proxy Server" is to share a single 'back-end' stream amongst possibly several concurrent 'front-end' streams.

If you want to seek within a RTSP stream, then don't proxy it.  Instead, access the stream directly.


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

_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Jesús Leganés | 2 Jul 2012 09:46

Re: Set ProxyServerMediaSession::fProxyRTSPClient as protected

> So if you want to detect/log every client connection (etc.) to the proxy
> server, then you would not modify (or subclass) the "Proxy*" code at all.
> Instead, you would subclass "RTSPServer" and
> "RTSPServer::RTSPClientSession", and reimplement the "handleCmd_SETUP()"
> (etc.) virtual functions.
>
Correctly, and i have this done already :-) At this moment i'm able to
detect and log this way connections between clients and the proxy, and
now i need to detect and log connections between the proxy and the
remote camera (the 'back-end' server as you say).

> But if your intention is instead to detect/log only connections from the
> proxy server to the 'back-end' server (which is only a subset of the number
> of connections from front-end clients to the proxy server), then:
>
Yes, exactly what i want to do :-)

> The fact is that reviewing the code it seems to me it's the correct
> aproach, just use a ProxyServerMediaSession child constructor that
> inits ProxyServerMediaSession::fProxyRTSPClient to my own
> ProxyRTSPClient child class
>
>
> Yes, but note that the existing "ProxyServerMediaSession" constructor
> already initializes the "fProxyRTSPClient" field (to a new "ProxyRTSPClient"
> object), so you'll need to delete this (using "Medium::close()") first,
> before assigning your new "ProxyRTSPClient" subclass object.
>
Oh, i didn't thought about it, thanks for the advice... :-)

> But hold on: At present, the "ProxyRTSPClient" class is defined only inside
> the "ProxyServerMediaSession.cpp" file, not in a header file, so you
> shouldn't even have the ability to access it, let alone subclass it.  So,
> are you sure that this is something that you really want to do??
>
Well, i don't know if there's a better (or at least a different) way
to do this, but if it's the only way to be able to detect and log the
connections from the proxy to the remote back-end server (the camera)
and you can't be able to suggest to me any other way to do it, then
yes, this and the redefination of RTSPClient::sendRequest() method in
a subclass is what i want to do :-) But i'm open to ideas, too... :-D

--

-- 
Jesús Leganés Combarro
Software developer at Vaelsys
Bruno Babic | 2 Jul 2012 10:34
Picon
Favicon

Is there something like WindowsUsageEnvironment?

Hi!

What would be the best way to get openRTSP client to run as a GUI tool 
under Windows?
Should I try to create something like WindowsUsageEnvironment to handle 
Windows message pool? Has anyone already did anything like that?

--
2b||!2b?
Naresh Sankapelly | 2 Jul 2012 11:32

Re: Is there something like WindowsUsageEnvironment?

You could use VLC. 

Thanks
Naresh
Ph. 8884199804

-----Original Message-----
From: live-devel-bounces@...
[mailto:live-devel-bounces@...] On Behalf Of Bruno Babic
Sent: Monday, July 02, 2012 2:05 PM
To: LIVE555 Streaming Media - development & use
Subject: [Live-devel] Is there something like WindowsUsageEnvironment?

Hi!

What would be the best way to get openRTSP client to run as a GUI tool under
Windows?
Should I try to create something like WindowsUsageEnvironment to handle
Windows message pool? Has anyone already did anything like that?

--
2b||!2b?
_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Chai, Zheng (Ajax | 2 Jul 2012 11:59
Favicon

About the H264 over RTP FA

Dear Live555 DEV,

First thank you give the guide line on how to let Live555 to take input from a live source (H264 pictures over
RTP) http://www.live555.com/liveMedia/faq.html#liveInput-unicast.
I followed this guideline and made it successfully to receive the H264/RTP Live Stream from a live source
(which sends Single NAL Unit Packet). However, I encountered one problem as following and need your help
and clarification.

The problem is: if I send H264 over RTP/UDP with Fragmentation Units (FUs-A)  then Live555 failed to parse
this live stream. I have to use FUs-A since Single NAL unit packet is less network efficient, and I will
seperate the source H264/RTP/UDP package into FUs-As and send them one by one to Live555. Please give some
suggestions on that how to make Live555 receive/parse FUs-A. Thanks a lot. It will be appreciated if you
can point me some existing codes examples on this.

BR

Ajax Chai
Ross Finlayson | 2 Jul 2012 16:47
Favicon

Re: About the H264 over RTP FA

I find your message confusing, because here you're talking about transmitting H.264 over RTP:

First thank you give the guide line on how to let Live555 to take input from a live source (H264 pictures over RTP) http://www.live555.com/liveMedia/faq.html#liveInput-unicast.

But here you're talking about *receiving* H.264 over RTP:
 
I followed this guideline and made it successfully to receive the H264/RTP Live Stream from a live source (which sends Single NAL Unit Packet).

And here you seem to be talking about both transmitting and receiving, but I'm not sure:

The problem is: if I send H264 over RTP/UDP with Fragmentation Units (FUs-A)  then Live555 failed to parse this live stream.


But anyway, the important thing to understand is that our software *automatically* handles the fragmentation (when transmitting) and defragmentation (when receiving) H.264 NAL units.  Your application software (which uses our software) *should not* deal with FU-A NAL units at all.

In particular:
- When transmitting H.264 over RTP, you should deliver your (unfragmented!) NAL units - one at a time - to a "H264VideoStreamDiscreteFramer", and then into a "H264VideoRTPSink".
- When receiving H.64 over RTP, you use a "H264VideoRTPSource".  Any fragmented NAL units in the RTP stream will automatically be defragmented before delivery.


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

_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Jesús Leganés | 2 Jul 2012 18:28

Re: Set ProxyServerMediaSession::fProxyRTSPClient as protected

>> Yes, but note that the existing "ProxyServerMediaSession" constructor
>> already initializes the "fProxyRTSPClient" field (to a new "ProxyRTSPClient"
>> object), so you'll need to delete this (using "Medium::close()") first,
>> before assigning your new "ProxyRTSPClient" subclass object.
>>
> Oh, i didn't thought about it, thanks for the advice... :-)
>
I have been talking with my boss and we got a better solution to this:
instead of set the constructor to protected, redefine it and close the
previous connection before create the new one, have this connection
created on a protected method so only is needed to be overloaded just
this method, so the connection is only done one time and also the
constructor gets untouched :-)

--

-- 
Jesús Leganés Combarro
Software developer at Vaelsys

Gmane