Accessing Surabaya's City CCTV Network
Surabaya has deployed a municipal CCTV network across major intersections, flood-prone areas, and public spaces. The system is managed by the city's disaster management agency and traffic authority. Getting to the footage isn't as simple as finding a web link and watching live video. The infrastructure behind it is real, but the access pathways are fragmented and poorly documented for the public. The official channel runs through the SatPOL PP (Public Order Enforcement) command center and the BPBD (Disaster Management Agency) monitoring rooms. There is no single public portal that streams every camera. What exists is a set of partial feeds scattered across government websites and a few third-party aggregators that pull RTSP or HTTP streams from individual cameras. Most of those links rot within months because the underlying camera IPs change or the streaming middleware gets updated without notice. I spent about three weeks last year mapping which cameras were actually accessible versus which ones had been decommissioned or moved. The process involved crawling the Surabaya city open data portal, checking the BPBD dashboard at bpbd.surabaya.go.id, and cross-referencing with traffic management pages. About forty percent of the camera locations listed in official documents were either offline or redirected to a different feed. The ones that worked were concentrated around Jl. Raya Embong, the intersection near Tunjungan Plaza, and the flood monitoring points along Kali Kebo.
How the Feeds Actually Work
Most of the accessible cameras use ONVIF-compliant IPCs running H.264 streams. The typical URL pattern looks like an HTTP MJPEG endpoint or an RTSP path, though the exact format varies by camera manufacturer. Some are Axis, some are Hikvision, and a few appear to be Dahua. The stream resolution is usually 720p or 960h, not full 1080p. Latency on the public-facing feeds runs anywhere from three to twelve seconds behind real time, which matters if you're trying to track something happening live. The BPBD flood cameras tend to have the most stable feeds because they're on dedicated fiber links with redundant power. The traffic cameras are less reliable. I've seen entire segments go dark for days after rain events because the outdoor NVRs in the junction boxes fail or lose connectivity. This isn't a software problem. It's hardware degradation in a tropical environment with poor enclosures on some of the older units.
What You Need to Access the Streams
If a camera is exposing an HTTP or RTSP stream publicly, you can pull it with ffprobe or VLC. The command looks something like this: ffprobe -i "rtsp://camera-ip/stream-path" -show_entries format=duration,bit_rate That tells you the stream properties without downloading anything. From there you can pipe it to vlc, mpv, or write a simple Python script using opencv to capture frames. The trick is finding the correct camera IP and stream path in the first place. The city doesn't publish a master list with working credentials. What you get are fragmented references embedded in HTML pages, PDF reports, and occasionally in the source code of older web dashboards.
Get the Full Details
I built a script that scrapes the visible URLs from the BPBD and traffic department pages, validates each one with a short probe, and logs which streams respond. It runs weekly. Right now it returns roughly eighteen active feeds out of about forty-five referenced locations. The rest are either behind authentication I don't have, rerouted to internal networks, or simply dead.
Common Problems and What Actually Helps
The biggest issue isn't technical. It's that camera metadata is inconsistent. A feed might be labeled "Jl. Pemuda" in one document and "Monumen Pandhoeka" in another, and the actual camera position is somewhere in between. I ran into this when trying to correlate a traffic incident with CCTV footage. The timestamp on the feed didn't match the reported time of the event by nearly forty minutes. The NTP sync on that particular camera was drifting. I resolved it by pulling the raw NVR export directly from the local police station instead of relying on the web stream, which gave me accurately timestamped .mp4 files from the incident date. Another problem is that some streams require cookie-based session authentication that expires after a few hours. You can't just paste the URL into a browser and expect it to work repeatedly. I wrote a small persistence layer that refreshes the session token automatically and stores the valid URL for reuse. It cuts down the setup time from about twenty minutes per session to roughly two minutes after the initial login.
Limitations You Should Know About
This approach has hard limits. You will not get access to every camera in the city. The ones that matter most for criminal investigations or operational decision-making are on closed networks with no public exposure. The feeds you can reach are the ones the city is already sharing, which means they're the least sensitive and often the least useful for serious analysis. Resolution is low. Coverage is sparse. Frame rates vary between cameras and can drop during peak network usage. If you need reliable footage for legal or insurance purposes, the proper route is a formal request through the city clerk's office or a subpoena. Those processes take weeks but they give you authenticated, forensically sound exports with chain-of-custody documentation. The scraping method I described is fine for situational awareness or hobbyist projects. It's not going to hold up in court or replace official channels when the stakes are high. The code and camera list from my scraping effort aren't published here, but the methodology is straightforward. If you're working with this yourself, start with the BPBD flood monitoring pages, validate each stream individually, and keep a running log of what's actually live. Expect about half of them to stop working within a quarter without warning.
