Panasonic SRT Gateway Workflows with Callaba
More live video workflow notes and product updates.
Panasonic camera fleet
Standardize the receiving side without pretending every Panasonic camera is the same
A Panasonic fleet can combine permanent PTZ positions, operator-led camcorders and different firmware generations. SRT is documented across selected models, but raster, frame rate, codec, control surface and available fields remain model-specific. The safe design is one operating standard in Callaba and one verified camera contract per source.
Place each model on the right production rail
Guide
UE150 · UE100
UE80 · UE50 · UE40
Guide
Guide
Guide
Guide
RTMPS guide
Keep control traffic and contribution media on separate checklists
Camera control
Prove PTZ movement, presets, tally and any controller integration. A reachable controller does not establish that SRT media is arriving.
Media contribution
Prove the SRT or verified RTMPS session, sustained bitrate, decoded picture, complete audio program and receiver-side reconnect. A healthy feed does not prove that PTZ control remains available.
Give both paths an owner. During an incident, the team should know whether the camera operator, venue network engineer or Callaba operator changes a setting. Avoid identifying sources only by UDP port: stable names such as Auditorium UE160 are easier to operate and safer to discuss.
Define one Callaba contract for each camera
For an SRT source
Record model, firmware, SRT role, reachable host, UDP port, Stream ID, passphrase policy, latency, codec, raster, frame rate and expected bitrate. Camera as Caller toward a Callaba Listener is a practical first cloud test when the venue permits outbound UDP.
For the HC-X20 RTMPS path
Keep the RTMPS source URL and credentials in the correct protected store. Receive that protocol as documented, then create an onward SRT route only after Callaba has decoded and accepted the feed.
Rehearse the whole fleet, not one representative camera
- Inventory every model, regional suffix, firmware, video-system frequency and selected IP format.
- Confirm local picture, camera audio, power and recording before enabling the contribution output.
- Create separately named Callaba inputs and open only the required network paths.
- Run every intended camera simultaneously. Watch aggregate uplink, switch and receiver load while moving PTZ cameras and following action with handheld units.
- Verify bitrate, RTT, packet loss, decoded motion, audio and sync for each input; make and play back a short Callaba recording.
- Interrupt one camera and one shared network path in separate tests. Record what reconnects automatically and what requires an operator.
Leave an operator-readable fleet record
Store a known-good profile for each camera without public credentials, and map every stable source name to its model, room, Callaba input and recovery owner. The record should tell the next operator what can be changed safely and which firmware-specific guide applies.
Use Callaba as the common operator view
Callaba can receive the approved feeds in AWS or on self-hosted Linux infrastructure, place them in browser Multiview, retain receiver-side telemetry, record selected sources and route them onward. This common view reduces operating variation without hiding the camera-specific facts that determine whether each path works.
Official Panasonic references
Start with Panasonic’s PTZ camera technology overview, the AW-UE160 specifications, and the current manual for every installed camera. Family-level support is not evidence that controls, output formats or firmware prerequisites are identical.
