OK, I figured out the problem - and it's bad news. Our proxying code currently
cannot handle the proxying of JPEG video (or, incidentally, AMR audio) streams.
The basic problem with proxying MJPEG is that the output of the "RTPSource"
object is a complete JPEG frame, which is not the data form
MJPEG streaming is tolerable if you're in a high-bandwidth environment with
very little packet loss. It's when people try to use it outside such
environments that they run into trouble.
And 'ONVIF' is an industry consortium (that we do not belong to) - not a
standards organizations. The relev
Hi Ross,
just as a side note (and because this is not the first time you are saying
this), your last sentence about that nobody should be streaming MJPEG in 2013
is wrong. Well, despite my e-mail address, I am not a casual hobbyist :), but
since there is a little to none protection in mail li
> No change :(
>
> After recompiling with OutPacketBuffer::maxSize = 20; at the start of
> main(), I get this:
Are your JPEG frames less than 20 bytes in size? If so, then I can't
explain your problem. Sorry.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
__
No change :(
After recompiling with OutPacketBuffer::maxSize = 20; at the start of
main(), I get this:
$ live555ProxyServer -V rtsp://192.168.0.221/live2.sdp
LIVE555 Proxy Server
(LIVE555 Streaming Media library version 2013.03.23)
Opening connection to 192.168.0.221, port 554...
RTSP stre
