[Live-devel] openRTSP, 30 seconds, Kill, teardown, network, interPacketGapMaxTime
Roberts, Alan
Alan.Roberts at e2v.com
Wed Apr 15 07:43:27 PDT 2009
Hi Ross
I appreciate that you'll probably just want to copy this onto the forum but...
I'm up against it. I'm struggling and just need to know if there's any light at the end of the tunnel in trying to get my system to work! I'm so close but there's a black hole between where I'm "at" and "finishing" my project!
I'm trying to connect my new Linux "streaming video recorder" embeded processor card's ethernet port to our existing camera (not allowed to change software on the camera) which has streaming video over ethernet coming out of it. My problem is that the ethernet port gets "strangled" inside the camera at the same time as the one-and-only control signal (record start/stop) gets de-asserted (record stop). The Linux card detects when this signal gets de-asserted and I issue a Kill -HUP <PID> to kill the current openRTSP session. This works brilliantly... but only provided I leave the system for more than 30 seconds before removing the power!
There is obviously some sort of "network outage handler thing" going on... I need to reduce the 30 seconds down to say 1 second... this will be fine as it's literally an ad-hoc point-to-point link that's about 12cm long. It takes 3 seconds of holding down the power button before power is actually removed so I've got a bit of slack time. If I remove the power before 30 seconds (after having tried to kill the openRTSP session) then the resulting file has duration 0 when I come to play it back with VLC. There's probably something that's not getting written to the mp4 file - it has roughly the correct physical size (Mbytes vs record time) but it just won't play. I suspect that the openRTSP hasn't actually been killed successfully. I'm going to write some test code to look into this but my gut feeling is that "something" is keeping openRTSP "on ice" (can't kill it) until either the network has "come back" or a 30 second timeout has "timed out".
I've seen a few postings recently that "sort of" relate to this... pulling out RJ45s, timeouts, re-connecting, blocking/non-blocking etc etc. The one that interests me is when you replied saying that you plan to revamp rtspClient to make it "non-blocking" some time in the future. I've no idea how to do it myself so am really interested in finding out when this may become available? It's my only hope at the moment unless you can point me in another direction?
I'm just using openRTSP and haven't tweaked any of your code... I effectively just call it from the command line.
"-D 2" doesn't seem to answer my problem even though, in principle, it sounded like "the" answer. Is it implemented?
I hope you can help me. Apart from this last hitch, I've really enjoyed this project. It would be great to finish it though!
Kind regards
Alan
____________________________________________________
Alan Roberts
Senior Engineer
ISIS Business Unit
Tel: 01245 493493 x3876
Email: alan.roberts at e2v.com
e2v, 106 Waterhouse Lane, Chelmsford, Essex. CM1 2QU
____________________________________________________
Sent by a member of the e2v group of companies. The parent company, e2v technologies plc, is registered in England and Wales. Company number; 04439718. Registered address; 106 Waterhouse Lane, Chelmsford, Essex, CM1 2QU, UK. This email and any attachments are confidential and meant solely for the use of the intended recipient. If you are not the intended recipient and have received this email in error, please notify us immediately by replying to the sender and then deleting this copy and the reply from your system without further disclosing, copying, distributing or using the e-mail or any attachment. Thank you for your cooperation.
______________________________________________________
________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20090415/ac633258/attachment.html>
More information about the live-devel
mailing list