I have written a lot of ONVIF stuff, and have done pretty similar stuff with WireShark and Cocoa Packet Analyzer.
Video is still surprisingly proprietary, even after all this time.
I got the ONVIF stuff sorted, but the challenges I deal with, these days, is providing the video in a realtime streaming format that can be interpreted by as many clients as possible (especially Apple). RT[S]P doesn’t really cut it.
There is even a nice sample application that you can try out without having to write any code.
https://github.com/Kurento/kurento-tutorial-java/tree/master...
As you probably know, Apple is not just badly supported in the surveillance industry, it is actively hated.
As I was working on the ONVIF stuff, I encountered this quite often. As soon as people found out I was working on Apple stuff, the relationship would go belly-up.
I ended up not bothering to renew my ONVIF membership, because it didn’t really buy me anything.
I created a “breadboard” streaming server for ffmpeg[0], but I’ve put my ONVIF stuff aside for a while, as I work on Bluetooth projects.
I ended up reverse engineering a bunch of the hikvision protocol for the bits that I could not do with ONVIF.
I think that one of the reasons that its uptake has been slow, is because manufacturers like to keep everything "in-house," and aren't too happy to allow devices they don't make to access their equipment.
I understand that. I really do. I worked for a manufacturer like that for ages. All kinds of hell can break loose, when you move from proprietary to open. It's not a simple transition.
The people that do like it, though, are the integrators. They are the ones that buy cameras in lots of a thousand, so there is definitely a case to be made in its favor.
(I developed pyGridware, which was based on SOAP and WSDL. It took hundreds of lines of code just to build Echo Hello World.
[0] https://github.com/priore/SOAPEngine
[1] https://github.com/RiftValleySoftware/RVS_ONVIF/blob/master/...
I had used Wowza to take multiple rtsp streams (from cctv cameras) and properly stream to multiple clients (Flash h.264 player and iOS streaming).
That's not-so-simple. The VLAN folks have written some excellent SDKs for their VLCKit engine, but it is quite "heavy." I've also messed around with ffmpeg, but that's not much lighter, and doesn't easily work on iOS.
Another consideration for iOS is battery use. Video tends to be a bit "piggy," when it comes to power usage.
I am sort of waiting to see who comes out of the scrum. Video is just too damn important to be allowed to remain the rather chaotic mess it's in now.
Now its someone elses problem transcoding the data into millions of formats for every device under the sun...