>> I plan do make same extensions to live proxy, just one switch
>> to avoid OPTIONS before first client connects to proxy
FYI, the problem with doing this would be that - if there is a long delay
before the first client connects to the proxy - the connection to the back-end
server might end up
Thanks Ross,
I have an email out to the camera provider and told them to get on the list.
Sounds like you work with alot of camera manufactures. This particular camera
is a Vivotek, anyone from there company on this list?
Thanks,
Craig
On 11/03/2013 03:05 PM, Ross Finlayson wrote:
Craig was
Craig was running an up-to-date version of the code.
The problem is definitely with his 'back-end' server; it should not be
returning a "400 Bad Request" error in response to a perfectly good request.
This server (network camera) needs to be fixed (perhaps a firmware upgrade is
available?).
Yes...that was added in 2013.10.16 version.
In my case this took care of the problem with streams timing out.
Bob
On Sun, Nov 3, 2013 at 2:20 PM, Craig Matsuura wrote:
> Hi Bob,
>
> I was looking at some post you had and wondering if my issues is related.
>
> http://lists.live555.com/piperma
Hi Bob,
I was looking at some post you had and wondering if my issues is related.
http://lists.live555.com/pipermail/live-devel/2013-October/017538.html
So if I read correctly the OPTION command, needs an additional Session field to
keep your axis camera
alive? Was this code in the 20131025 so
Hi Ross,
That is what I suspect as well, however I was trying to recover from such an
error as it would be nice to be more robust and not fail because of a firmware
issue with the camera. I am in the process of having the manufacture look into
the issue, however this can be a slow process. I
I have read the readme, but thanks for the suggestion,. I have had success
with several as well, but I have one particular camera with this issue. I was
hoping there was a good way to handle this from the live555 side. Sometimes
camera manufactures are slow to respond.
Thanks,
Craig
On 11/0
Be sure to read changelog.txt for recent updates/changes to ProxyServer
implementation. I have been testing ProxyServer with numerous streams /
client connections with success.
Bob
On Sun, Nov 3, 2013 at 2:10 AM, Craig Matsuura wrote:
> I have a question in regards to the live555proxyServer. I
> Sending request: SETUP rtsp://172.16.10.109/live.sdp/trackID=1 RTSP/1.0
> CSeq: 4
> User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2013.10.25)
> Transport: RTP/AVP;unicast;client_port=60278-60279
>
>
> Received 37 new bytes of response data.
> Received a complete SETUP response:
> RTSP/1
Ok, so I did a quick run of the liveProxyServer. See 400 Bad Request below,
this is when I connect my RTSPClient to rtsp://172.16.10.100/proxyStream (The
client was gstreamer playbin2)
root@custom:~# live555ProxyServer -V rtsp://172.16.10.109/live.s
dp
LIVE555 Proxy Server
(LIVE555 Stre
Please post an example of the diagnostic output from the *unmodified* proxy
server, when run with the back-end server that causes you a problem. I.e., run
the server with the "-V" command-line option.
(And, as always, make sure you're using the most up-to-date version of the
code.)
Ross Finla
I have a question in regards to the live555proxyServer. I have been
playing with the server and have implemented one for our use for our
project. It works great when connecting to all proxied rtsp streams,
however if I wait about 10-15 seconds and than connect a client I always
get a 400 Bad
12 matches
Mail list logo
