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

Saverio ABC s.decarpentieri at abcimpianti.com
Mon May 12 08:37:45 PDT 2014


Dear Ross,

Thanks for your response, i analyzed the problem better.

First of all I update today live555 and now we use ProxyRTSPClient 
(LIVE555 Streaming Media v2014.05.08) that it's the last version.
In my Encoder we only can set Encode, Resolution, Frame-rate(FPS), 
I-Frame interval and bit-rate, and now it's set to:
Encode: h264
Resolution: 1,3M (1280*960)
Frame-rate(FPS): 15 (max value)
I-Frame interval: 15 (min value)
bit-rate: 2048 Kb/s or 1024 Kb/s

To send smaller NAL units i reduce I-Frame interval to 15 but i don't 
want reduce Resolution! How can reduce NAL unit without change 
resolution and FPS

I also try to increase "OutPacketBuffer::maxSize" in 
"proxyServer/live555ProxyServer.cpp" to 2000000 and more but the problem 
it's the same.

Finally I find this behaviour:

I start my software that use live555ProxyServer  and run code 
"live555ProxyServer -V -p 9002 -R 
rtsp://admin:369000@192.168.100.20:554/cam/realmonitor?channel=1&subtype=0"

now we have the same situation:

                                                               --> [RTSP client1]
         [back-end RTSP/RTP stream] --> [LIVE555 Proxy Server] --> [RTSP client2]
                                                               ...
                                                               --> [RTSP clientN]

If I use only one RTSP client all it's fine: the video HD streaming 
result fine and not corrupt but, as soon as, i start another RTSP client 
(es. vlc) the video HD streaming result corrupt as in attached picture, WHY?
I'am in local network (LAN) so we can't have network problem!

Thanks so much for your support.

Best Regards,

Ing. Saverio De Carpentieri
ABC Impianti S.r.l.

Il 12/05/2014 16:42, Ross Finlayson ha scritto:
>> How can I resolve this problem?
>
> The best solution is to not send such large NAL units.  Reconfigure 
> your encoder to break up 'key frames' into multiple (therefore much 
> smaller) 'slice' NAL units.
>
> It's important to understand that each outgoing NAL unit - if it is 
> larger than the RTP/UDP packet size (about 1500 bytes on most 
> networks) - will be broken up into multiple outgoing RTP packets, and 
> the receiver - both the proxy server and the final receiving client(s) 
> - must receive *all* of these packets in order to be able to 
> reconstruct the frame.  In other words, if even one of these packets 
> is lost, then the receiver will lose the *entire* NAL unit.  That's 
> why the NAL units - generated by your encoder - should be as small as 
> is reasonable.
>
>
> Alternatively (though not as good, for the reason noted above), you 
> can increase the buffer size ("OutPacketBuffer::maxSize") that the 
> "LIVE555 Proxy Server" uses.  I.e., change line 59 of 
> "proxyServer/live555ProxyServer.cpp".
>
>> I try to increase "OutPacketBuffer::maxSize" to 100000 or 200000 but 
>> the problem it's the same.
>>
>
> I'm not sure why; if you make this buffer size large enough, it should 
> work (provided, of course, you don't lose any network packets, as 
> noted above).
>
> You should also make sure that you're using an up-to-date version of 
> the "LIVE555 Streaming Media" code; see
> http://www.live555.com/liveMedia/faq.html#latest-version
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140512/21359161/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bad streaming.png
Type: image/png
Size: 353418 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140512/21359161/attachment-0001.png>


More information about the live-devel mailing list