HDMI Encoder Setup: From Login to a Working Stream
Follow it once and you are live. Every step includes how to confirm it worked, so you are not debugging at the end.
- Before you start: three things to have ready
- Step 1: log in to the web interface
- Step 2: network settings (where most people get stuck)
- Step 3: encoding parameters with recommended values
- Step 4: choosing protocols and outputs
- Step 5: main and sub streams
- Step 6: OSD text and image overlay
- Step 7: verify layer by layer
Before you start: three things to have ready
- A network cable and a PC: configure over a direct connection first, away from site network variables.
- Source and monitor: confirm the camera or player is producing a stable output.
- Platform details: publish URL, port, application name and stream key. All four are required.
Step 1: log in to the web interface
The unit ships with a default IP, commonly on the 192.168.0.x subnet. To reach it, your PC must sit on the same subnet — the same idea as configuring a router.
- Set the PC's network adapter to a manual IP on the same subnet as the device, with a different host address and the same mask.
- Browse to the device IP to open the management interface.
Confirm this step: the login page loads and the device responds (verify with ping). If it will not open, check whether the PC is still on DHCP — with a direct connection there is no DHCP server, so a manual address is mandatory.
Step 2: network settings (where most people get stuck)
Connection type is usually wired or wireless (the latter only if the model supports it). Three things go wrong most often:
- Changing the IP and forgetting it: with power applied, hold the reset button to restore factory defaults (duration varies by model, commonly 10–15 seconds). A reset clears all configuration.
- Losing the device after enabling DHCP: the encoder's address is then assigned by the switch, so check the switch's lease table or ask the manufacturer for an IP discovery tool. If you cannot find it, reset to the default address.
- No DNS configured: required when publishing to a domain name, and DNS differs by ISP. DNS failure looks like "network is fine but nothing goes out" — easy to miss.
Confirm this step: the device can ping its gateway and an external address — not just your PC. If you publish to a domain, ping that domain too to confirm resolution.
Step 3: encoding parameters with recommended values
| Parameter | Meaning | Recommendation |
|---|---|---|
| Codec | H.264 or H.265 | H.264 for RTMP (best compatibility); H.265 when bandwidth is tight or for archive recording |
| Profile | baseline / main / high | main for H.264; main profile for H.265 |
| Rate control | CBR constant / VBR variable | CBR when uplink is limited and predictable usage matters; VBR when quality comes first and headroom exists |
| Frame rate | Typically 5–60 fps | Match the input; for interlaced sources such as 1080i50 use 25 fps |
| Keyframe interval (GOP) | Quality-related | Default unless you have a reason; one keyframe every 1–2 seconds is common for live |
| Output size | Auto matches the input | Set below input resolution to save bandwidth |
| Video bitrate | Drives quality and bandwidth | Set to 60–70% of measured upstream capacity |
CBR or VBR: CBR holds bitrate steady, so bandwidth use is predictable — right for constrained uplinks. VBR spends more bits on complex scenes and fewer on simple ones, giving steadier quality but a higher peak. If unsure, start with CBR, then compare VBR once it is stable.
Most encoders apply these changes without a reboot, so you can tune while watching the picture.
Step 4: choosing protocols and outputs
| Protocol | Purpose | How to use it |
|---|---|---|
| RTSP | Pull a live stream on the LAN (VLC, players, NVR) | Enable it and set the port; open rtsp://device-ip/path in VLC |
| HTTP | Simple LAN playback | Commonly open http://device-ip/main in a player |
| Multicast (UDP/RTP) | One source to many screens on a LAN, lowest bandwidth | Set group address and port; receivers open udp://@group:port |
| RTMP | Publish to a platform or server | Enter server address, port, application name and stream key |
| ONVIF | Surveillance integration | Enable when connecting to an NVR or VMS |
LAN versus public: for viewing on the LAN use RTSP, HTTP or multicast. For outside audiences publish RTMP to a platform. On a poor link, replace RTMP with SRT.
Step 5: main and sub streams
Most encoders output a main stream plus a sub stream, each with independent resolution, bitrate and destination. Typical uses:
- Main stream high quality for recording or local display; sub stream low bitrate for mobile or remote viewing.
- One stream to platform A, one to platform B (different stream keys).
- Disable the sub stream when unused to free device resources.
Key point: the sub stream needs its own stream key, distinct from the main stream. Reusing the same key makes the two conflict.
Step 6: OSD text and image overlay
OSD overlays logos, captions or timestamps. Common settings:
- Text: X/Y coordinates, font size, transparency, text colour, background colour and the content itself.
- Image: on/off, coordinates, transparency, and upload (mind the format and size limits in your model's documentation).
- Some models support several text entries and images at once.
Confirm this step: check OSD on the actual output picture, not just a preview thumbnail — coordinates are calculated against output resolution, so changing resolution moves everything.
Step 7: verify layer by layer
- Local: open the RTSP or HTTP URL in VLC and confirm picture and audio. If this fails, nothing later matters.
- Network: ping the gateway, an external address, and the publish domain (to validate DNS).
- Publishing: after entering the four RTMP values, confirm on the platform that the stream arrives, and check that the interrupt counter on the status page is rising normally.
- Quality: run real content for 20–30 minutes, watching motion and text edges, then decide whether to adjust bitrate.
The three most common failures: (1) H.265 selected while publishing RTMP — many platforms cannot handle it and show black video; (2) DNS not filled in; (3) bitrate above the real available uplink. Verify in the four steps above and you will locate it on the first pass.
Products mentioned
Designed and manufactured in-house · OEM/ODM · 3-year warranty
ZY-EH1401 4K Live Streaming Encoder
H.265 / H.264 / MJPEG with an onboard display to check bitrate and publish status directly on the device.
Single-camera liveZY-EH1301 4K Encoder
Independent main and sub streams: one local, one to the platform — ideal for step-by-step verification.
Main + subZY-DH931 Decoder
Receiving-side companion that restores the network stream to HDMI, verifying the far end of the chain.
Receive sideFAQ
Why will the web interface not open when my PC is connected directly?
With a direct connection there is no DHCP server, so the PC must be given a manual IP on the same subnet as the encoder (same mask). After changing it, ping the device to confirm reachability, then reload the page.
Should I choose CBR or VBR?
CBR keeps bitrate fixed so bandwidth use is predictable — best when uplink is constrained or must be controlled. VBR gives steadier quality with a higher peak. If unsure, start with CBR and compare VBR quality once stable.
RTMP publishes but the platform shows no picture — why?
Check three things: whether the codec is H.264 (H.265 is rejected by many platforms and shows as black video or audio only), whether DNS is configured, and whether the application name and stream key match what the platform assigned.
Can main and sub streams publish to two platforms?
Yes. Each stream has independent resolution, bitrate and destination. Just make sure the sub stream uses a different stream key from the main stream, otherwise they conflict.
Related reading
Not sure whether to pick H.264 or H.265? Send us the scenario
30-day free trial | 24/7 technical support | 3-year warranty
Get a recommendation 400-056-8185