Re: [Live-devel] OPTIONS vs GET_PARAMETER for keep alive with proxy server

2014-03-04 Thread Craig Matsuura
It appears the GET_PARAMETER will accept the Session header as a OPTIONS does not care. So if for some reason the camera server closes the session what is the indicator to the client? If the GET_PARAMETER is sent with a Session I assume the camera server should respond with a 454 and not reply

Re: [Live-devel] OPTIONS vs GET_PARAMETER for keep alive with proxy server

2014-03-04 Thread Ross Finlayson
I'm not sure I understand your question. If the 'liveness' command from the proxy server (*either* "OPTIONS" or "GET_PARAMETER") fails - either because the TCP connection fails, or because the back-end server responded with a response code other than 200 - then the proxy server will assume that

[Live-devel] OPTIONS vs GET_PARAMETER for keep alive with proxy server

2014-03-04 Thread Craig Matsuura
I'm still consider myself a newbie with RTSP, but had a question I hope someone can help me with. I have a general question about a camera session and keeping it alive. The rtsp proxy uses OPTIONS by default and optionally can use GET_PARAMETER. If a camera closes a session due to some bug ho

Re: [Live-devel] TS thrashing

2014-03-04 Thread Ross Finlayson
> So is there a way to have more buffering going on so at each fwrite call > writes more than 188 bytes at a time to /dev/my_device ?? Yes, one solution would be to insert another pipe - between your modified "testH264VideoToTransportStream" code, and your output device. I.e., modify your cod

Re: [Live-devel] testRTSPClient - can't find a port not in use

2014-03-04 Thread Ross Finlayson
> Thanks for the help. I was able to use setClientPortNum() inside > setupNextSubsession() to specify which port for it to use so it didn’t > auto-search. Oddly enough, any even port between 65408 – 65518 seems to > work. That was just the range I tested, it probably works outside of that as

[Live-devel] TS thrashing

2014-03-04 Thread Umar Qureshey
Hello, I have modified the testH264VideoToTransportStream.cpp program by simply replacing inputFileName to "stdin" and outputFileName to "/dev/my_device". /dev/my_device is a Linux device driver that transports the TS data to the streaming hardware. Then I run the following command line: ./op

Re: [Live-devel] testRTSPClient - can't find a port not in use

2014-03-04 Thread Rob Coker
Ross, Thanks for the help. I was able to use setClientPortNum() inside setupNextSubsession() to specify which port for it to use so it didn't auto-search. Oddly enough, any even port between 65408 - 65518 seems to work. That was just the range I tested, it probably works outside of that as w