[Live-devel] A Sneak Preview: WebRTC streaming (to web browsers, without plugins) using LIVE555

[Aaron Clauson]

The WebRTC integration is a great looking feature.

I appreciate it's a rather cheeky request but is there any timeframe on
when the WebRTC and specifically the ICE checks will be released into the
LIVE555 RTP stack?

Regards,
Aaron

[Ross Finlayson]

Post by Aaron Clauson
The WebRTC integration is a great looking feature.
I appreciate it's a rather cheeky request but is there any timeframe on when the WebRTC and specifically the ICE checks will be released into the LIVE555 RTP stack?

There’s a lot more testing to be done, and I haven’t yet decided which pieces of this will be made open source and when.

(If anyone can make a business case for expediting the release of some parts of this, then feel free to contact me (by separate email).)


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

[Marco (Xanatos Marine)]

*Ing. Marco A. Pérez López*

Software Development

Xanatos Marine Ltd.

#370 18 Gostick Place

North Vancouver, B.C., V7M 3G3

Phone: [phone]

www.xanatosmarine.com <http://www.xanatosmarine.com/>

This electronic transmission (including any and all attachments) is
intended solely for the use of the individual or entity to which it is
addressed and may contain information that is privileged and/or
confidential. If you are not the intended recipient of this electronic
transmission, you are hereby notified that any disclosure, copying, or
distribution, or the taking of any action in reliance upon the contents
of this electronic transmission, is strictly prohibited, and you are
further requested to purge this electronic transmission and all copies
thereof from your computer system.



I am building an application where several clients should be able to
watch a video stream from a CCTV IP camera.
I think that the best solution bandwidth-wise is to have a single
computer in the network connect to the rtsp stream from the camera, and
then broadcast this stream via UDP (to some address like
255.255.255.255) so all other computers in the network only need to
"tap" that UDP port to get the video stream.

I implemented this with VLC and it works, but... as the network gets
more load from several devices, the VLC instances start falling behind
the real time stream from the camera. With one Full HD camera and four
standard cameras in the network, VLC (the "source" or re-streaming
instance mainly) falls behind at an astonishing rate and after some 10
minutes the output stream is like 5 minutes behind real time!

Looking for an alternative to VLC, I have tried to use LIVE555 to
replace VLC in its "server" end but I haven't found an example or a
discussion on how to implement UDP broadcast with it. Is this possible?
Where should I look? Are there any examples? Will using LIVE555 solve
the growing latency problem or is it inherent to the way RTSP/RTP work?

Thanks,
Marco

[Ross Finlayson]

I am building an application where several clients should be able to watch a video stream from a CCTV IP camera.
I think that the best solution bandwidth-wise is to have a single computer in the network connect to the rtsp stream from the camera, and then broadcast this stream via UDP (to some address like 255.255.255.255) so all other computers in the network only need to "tap" that UDP port to get the video stream.

First, you shouldn’t be sending to the ‘broadcast’ address 255.255.255.255, because that will cause the packets to get received (and then discarded, if inappropriate) by all computers on your LAN. Instead, you should be using an IP multicast address - which will cause the packets to get delivered only to the computer(s) that have subscribed to that address, and also (with appropriate routing) allows for the possibility of the packets being forwarded beyond a single LAN.

And, of course, you should be using the standard RTP protocol (over UDP), rather than raw UDP.

We have several demo applications - in the “testProgs” directory - that will stream (from a video file) via IP multicast. You didn’t say what video codec you are using, but if you’re using H.264 (the most commonly-used video codec these days), then you can use our “testH264VideoStreamer” application.

Then, once you have demonstrated multicast streaming from a file (using an appropriate “test*Streamer” demo application), then see here
http://live555.com/liveMedia/faq.html#liveInput <http://live555.com/liveMedia/faq.html#liveInput>
for tips on how to adapt this to stream from a live video source.

I implemented this with VLC and it works, but... as the network gets more load from several devices, the VLC instances start falling behind the real time stream from the camera. With one Full HD camera and four standard cameras in the network, VLC (the "source" or re-streaming instance mainly) falls behind at an astonishing rate and after some 10 minutes the output stream is like 5 minutes behind real time!

We can’t help you with VLC problems (because VLC is not our problem), but I wonder if perhaps you’re running into network capacity problems. Note that if any of your cameras are streaming over WiFi, then broadcast (or multicast) over WiFi is notoriously slow.


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

[Marco (Xanatos Marine)]

Thank you so much for your prompt answer Ross,

I exposed my problems with VLC to explain why I am looking for an
alternative; I was not looking here for help with VLC... sorry if I
didn't explain myself clearly.

The main reason I originally chose to use UDP broadcast instead of
multicast was that I have a network recorder that can be setup to record
all the activity in an specific UDP port, and then replay it at will. I
was not sure that it could record multicast transmissions so I decided
to go the safe way (as always delivery time was too short) and after I
had something working and the client happy, I would have time to test
better technologies and optimizations.

Yes, the cameras use H.264. I started dealing with digital cameras and
digital video barely two months ago so please excuse my utter lack of
knowledge in video technologies. Some questions that may seem obvious
but I don't know the answers:

- My idea is to reduce as much as possible the bandwidth usage in the
network, so probably the ideal scenario would be to program the camera
to multicast its stream and have the clients connect directly to that
one... am I right?

- If the camera or video server is not programmable for multicasting, is
it at all possible to open a single connection to the camera from one
client and then direct my clients to "tap" on the RTP video stream to
that single client without creating a duplicate UDP video stream for each?

- I had modified the proxyServer application to rebroadcast the camera
streams but that was not very useful since still each client had to open
an RTSP connection to the specific IP address of my server, so I guess
that also created duplicated streams in the network. I will follow your
advise to try and multicast with the "testH264VideoStreamer" app and see
how it goes. I think I can use the "input" part of proxyServer and
combine it with textH264VideoStreamer to be able to re-stream a live
stream via multicast, am I right?

Thanks again,
Marco.

*Ing. Marco A. Pérez López*

Software Development

Xanatos Marine Ltd.

#370 18 Gostick Place

North Vancouver, B.C., V7M 3G3

Phone: [phone]

www.xanatosmarine.com <http://www.xanatosmarine.com/>

This electronic transmission (including any and all attachments) is
intended solely for the use of the individual or entity to which it is
addressed and may contain information that is privileged and/or
confidential. If you are not the intended recipient of this electronic
transmission, you are hereby notified that any disclosure, copying, or
distribution, or the taking of any action in reliance upon the contents
of this electronic transmission, is strictly prohibited, and you are
further requested to purge this electronic transmission and all copies
thereof from your computer system.

Post by Ross Finlayson

Post by Marco (Xanatos Marine)
I am building an application where several clients should be able to
watch a video stream from a CCTV IP camera.
I think that the best solution bandwidth-wise is to have a single
computer in the network connect to the rtsp stream from the camera,
and then broadcast this stream via UDP (to some address like
255.255.255.255) so all other computers in the network only need to
"tap" that UDP port to get the video stream.

First, you shouldn’t be sending to the ‘broadcast’ address
255.255.255.255, because that will cause the packets to get received
(and then discarded, if inappropriate) by all computers on your LAN.
Instead, you should be using an IP multicast address - which will
cause the packets to get delivered only to the computer(s) that have
subscribed to that address, and also (with appropriate routing) allows
for the possibility of the packets being forwarded beyond a single LAN.
And, of course, you should be using the standard RTP protocol (over
UDP), rather than raw UDP.
We have several demo applications - in the “testProgs” directory -
that will stream (from a video file) via IP multicast. You didn’t say
what video codec you are using, but if you’re using H.264 (the most
commonly-used video codec these days), then you can use our
“testH264VideoStreamer” application.
Then, once you have demonstrated multicast streaming from a file
(using an appropriate “test*Streamer” demo application), then see here
http://live555.com/liveMedia/faq.html#liveInput
for tips on how to adapt this to stream from a live video source.

Post by Marco (Xanatos Marine)
I implemented this with VLC and it works, but... as the network gets
more load from several devices, the VLC instances start falling
behind the real time stream from the camera. With one Full HD camera
and four standard cameras in the network, VLC (the "source" or
re-streaming instance mainly) falls behind at an astonishing rate and
after some 10 minutes the output stream is like 5 minutes behind real
time!

We can’t help you with VLC problems (because VLC is not our problem),
but I wonder if perhaps you’re running into network capacity problems.
Note that if any of your cameras are streaming over WiFi, then
broadcast (or multicast) over WiFi is notoriously slow.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
http://lists.live555.com/mailman/listinfo/live-devel

[Ross Finlayson]

- My idea is to reduce as much as possible the bandwidth usage in the network, so probably the ideal scenario would be to program the camera to multicast its stream and have the clients connect directly to that one... am I right?

Yes - provided, of course, that the clients are all on the same LAN (or else IP multicast routing is enabled between your server and client network(s)).

- If the camera or video server is not programmable for multicasting, is it at all possible to open a single connection to the camera from one client and then direct my clients to "tap" on the RTP video stream to that single client without creating a duplicate UDP video stream for each?

Sorry, I don’t understand this question. (However, you might (or might not) find our “testRelay” demo application useful; see “testProgs/testRelay.cpp”.)

- I had modified the proxyServer application to rebroadcast the camera streams but that was not very useful since still each client had to open an RTSP connection to the specific IP address of my server, so I guess that also created duplicated streams in the network. I will follow your advise to try and multicast with the "testH264VideoStreamer" app and see how it goes. I think I can use the "input" part of proxyServer and combine it with textH264VideoStreamer to be able to re-stream a live stream via multicast, am I right?

No, because the proxy server code works by creating multiple unicast connections - one for each front-end client. It does not work for multicast front-end clients.

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

[Marco (Xanatos Marine)]

Thanks Ross,

I modified "testH264VideoStream" by replacing

ServerMediaSession* sms
= ServerMediaSession::createNew(*env, "testStream", inputFileName,
"Session streamed by \"testH264VideoStreamer\"",
True /*SSM*/);

with
ServerMediaSession* sms
= ProxyServerMediaSession::createNew(*env, rtspServer,
"rtsp://<ip address>/axis-media/media.amp?camera=1", "testStream");

and commented out the call to "play" before enter the event loop of
taskScheduler. It works and re-streams the live feed from the camera!
but I find the following issues: when I open a VLC instance in the same
computer to receive the multicast stream, it takes about 15 seconds to
start replaying the stream, and it shows artifacts in the video that are
not in the original image, which I can monitor with a direct connection
to the camera: Note in the next image how the last digit of the seconds,
in the bottom center, looks totally garbled. Same, using the seconds as
guide, sometimes it shows "older" frames where the time is actually
previous to frames that have already been displayed. Some times whole
areas of the image go gray and then slowly starts recovering its correct
appearance (second image).

If I connect a client directly to the camera feed instead of my modified
"testH264VideoStream", the image appears normal, so it doesn't seem to
be a network bandwidth problem, although it looks like it.

What can be happening? Is there a way to correct these problems?





Thanks,
Marco

*Ing. Marco A. Pérez López*

Software Development

Xanatos Marine Ltd.

#370 18 Gostick Place

North Vancouver, B.C., V7M 3G3

Phone: [phone]

www.xanatosmarine.com <http://www.xanatosmarine.com/>

This electronic transmission (including any and all attachments) is
intended solely for the use of the individual or entity to which it is
addressed and may contain information that is privileged and/or
confidential. If you are not the intended recipient of this electronic
transmission, you are hereby notified that any disclosure, copying, or
distribution, or the taking of any action in reliance upon the contents
of this electronic transmission, is strictly prohibited, and you are
further requested to purge this electronic transmission and all copies
thereof from your computer system.

[Ross Finlayson]

Post by Marco (Xanatos Marine)
Thanks Ross,
I modified "testH264VideoStream" by replacing
ServerMediaSession* sms
= ServerMediaSession::createNew(*env, "testStream", inputFileName,
"Session streamed by \"testH264VideoStreamer\"",
True /*SSM*/);
with
ServerMediaSession* sms
= ProxyServerMediaSession::createNew(*env, rtspServer,
"rtsp://<ip address>/axis-media/media.amp?camera=1", "testStream”);

That has *exactly* the same effect as just running the “LIVE555 Proxy Server”! In other words, all clients that connect to the RTSP server will get their own, unicast copy of the stream. That’s what the “ProxyServerMediaSession” object does.

Note that if you have N front-end clients to this proxy server, then there will be N+1 total streams on the network: the original ‘back-end’ stream from the camera, plus the N front-end stream copies. Thus, even if you have just one ‘front-end’ client, you will have two copies of the stream on the network. You’re probably running into network capacity issues (unless you’re also seeing error messages about “dropped” or “truncated” data).

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

[Marco (Xanatos Marine)]

Post by Ross Finlayson

Post by Marco (Xanatos Marine)
ServerMediaSession* sms
= ServerMediaSession::createNew(*env, "testStream",
inputFileName,
"Session streamed by \"testH264VideoStreamer\"",
True /*SSM*/);
with
ServerMediaSession* sms
= ProxyServerMediaSession::createNew(*env, rtspServer,
"rtsp://<ip address>/axis-media/media.amp?camera=1",
"testStream”);

That has *exactly* the same effect as just running the “LIVE555 Proxy
Server”! In other words, all clients that connect to the RTSP server
will get their own, unicast copy of the stream. That’s what the
“ProxyServerMediaSession” object does.

Oh and I thought I had solved the problem! What should I do then?
replace "inputFileName" with the input stream URL in the
"ServerMediaSession" constructor?

I'm running in Windows btw. The cameras can be inside or outside the
LAN, so yes, in those cases where the camera is inside the LAN and we
use this program, there will be two copies of the stream in the network.
When the camera is in an external IP, I want this program to connect to
it via unicast and then distribute the stream to the clients in the
network via multicast. Sometimes you cannot control all the routers in
between to guarantee there will be multicasting availability all the way
from the camera to the clients.

Sorry to bother you so much, and thanks,
Marco

*Ing. Marco A. Pérez López*

Software Development

Xanatos Marine Ltd.

#370 18 Gostick Place

North Vancouver, B.C., V7M 3G3

Phone: [phone]

www.xanatosmarine.com <http://www.xanatosmarine.com/>

This electronic transmission (including any and all attachments) is
intended solely for the use of the individual or entity to which it is
addressed and may contain information that is privileged and/or
confidential. If you are not the intended recipient of this electronic
transmission, you are hereby notified that any disclosure, copying, or
distribution, or the taking of any action in reliance upon the contents
of this electronic transmission, is strictly prohibited, and you are
further requested to purge this electronic transmission and all copies
thereof from your computer system.

[Ross Finlayson]

The cameras can be inside or outside the LAN, so yes, in those cases where the camera is inside the LAN and we use this program, there will be two copies of the stream in the network. When the camera is in an external IP, I want this program to connect to it via unicast and then distribute the stream to the clients in the network via multicast. Sometimes you cannot control all the routers in between to guarantee there will be multicasting availability all the way from the camera to the clients.

If you want to relay a unicast RTSP/RTP stream into a multicast RTSP/RTP stream, then something like the following should work:

1/ Modify “testH264VideoStreamer.cpp” to change the “inputFileName” variable from "test.264” to “stdin”. Recompile “testH264VideoStreamer”.
2/ Then you can run “openRTSP -v” to receive the unicast RTSP/RTP stream, and then ‘pipe’ the resulting H.264 video stream into your modified “testH264VideoStreamer”. I.e., run - from the command line (sorry, this works for a Unix command line; I don’t know if it’ll work in Windows):
openRTSP -v 'rtsp://<ip address>/axis-media/media.amp?camera=1’ | your-modified-testH264VideoStreamer

(Unfortunately this is as much help as I can give you here ‘for free’ on this mailing list. If your company is interested in having me consult further on your project, then please have your management let me know (via separate email).)

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