You wired an IP camera into the plant network, typed its RTSP URL into the video widget on a 15-inch HMI panel, and the panel answered with a "Resource Error" and no picture. The same URL plays in the desktop RTSP test tool you keep for exactly this purpose. Those two facts together are the diagnosis: addressing, transport and authentication all work, and the panel's decoder is rejecting the payload it receives. This guide walks the fault in the order that pays off — probe the stream, set a codec the panel can decode, transcode or convert only when you must, budget the bandwidth, then close the fault out so it stays closed.
Why does the panel show a resource error when the stream plays on a PC?
Because the panel's decoder cannot handle what the camera is sending. On most panels that means anything other than H.264 baseline profile, so H.265 or H.264 high profile fails. Your desktop test tool ships with a full codec set. A resource error is the player saying it ran out of decoder, not out of network. A reach failure announces itself as a timeout or a "could not connect" message; here the panel opened a session, read the stream description, and rejected the media inside it.
Consumer IP cameras default to H.265 or to H.264 in a high profile because it roughly halves storage on the recorder. Desktop tools bundle decoders for all of that. Panel firmware usually does not: the decode path on an HMI covers H.264 baseline, sometimes Main, and little else. The H.264 profiles exist precisely so a decoder can declare a subset of the standard and refuse the rest.
Work the causes in this order:
- Codec or profile above the panel's decoder — H.265, or H.264 Main/High where only Baseline is implemented.
- Pixel format — full-range
yuvj420por 10-bit colour from the camera, which some hardware decoders refuse. - An audio track the panel tries to decode before it starts video.
- UDP transport mangled on the path — least likely when the same URL plays on the desk.
The panel end of this job has pitfalls of its own, and the wiring under it matters too; for the network side see 5GBASE-T camera interface: bandwidth, cables and distance. A PC can fail the same way, as in a viewer that shows no video because GStreamer plugins are missing — the common thread is always the player, not the wire.
How do you check which codec the RTSP stream is sending?
Run ffprobe with the stream fields selected against the RTSP URL. Read the codec_name, profile, level and pix_fmt lines: a camera set to H.265 prints codec_name=hevc, and an H.264 stream prints codec_name=h264 with profile=High or profile=Baseline. The URL below is an example; substitute your camera's:
ffprobe -v error -rtsp_transport tcp -select_streams v:0 -show_entries stream=codec_name,profile,level,pix_fmt,width,height -of default=noprint_wrappers=1 rtsp://192.168.1.40:554/stream1
A panel-unfriendly camera answers like this:
codec_name=h264
profile=High
level=42
pix_fmt=yuvj420p
Read it as: H.264, but High profile at level 4.2 (ffprobe prints level multiplied by 10) in full-range colour. Any one of those three can stop a panel decoder. The panel-friendly result reads codec_name=h264, profile=Baseline, pix_fmt=yuv420p, and a level at or under the panel's stated maximum. Without ffprobe, open the URL in a desktop player's codec-information view, which lists the same fields for the live stream.
Which codec and profile should a panel stream use?
H.264 baseline profile, 8-bit yuv420p, level 4.0 or lower, with the audio track disabled — that combination decodes on essentially every panel player and web client you will meet. Baseline also drops B-frames, which is part of why it plays everywhere: every frame stands alone in the decode order, so simple hardware handles it.
| What the camera sends | Typical panel support | Decision |
|---|---|---|
| H.264 Baseline, yuv420p, level 4.0 or lower, no audio | Near-universal | Make this the default panel feed |
| H.264 Main or High | Common on native players, rare in browser widgets | Test once; force Baseline if in doubt |
| H.265 / HEVC | Needs decode silicon or a licence most panels lack | Transcode before the panel |
| MJPEG | Decodes almost everywhere | Short drops only; see the bandwidth cost below |
If the camera offers a colour-range setting, choose limited range over full range. And when the panel's specification names a maximum, believe it: 1080p at any frame rate needs level 4.0, while 720p at 30 fps fits level 3.1. A panel capped at level 3.1 plays the 720p sub-stream and never the 1080p main stream.
How do you re-encode the stream when the camera cannot change it?
Run ffmpeg on any always-on host to pull the camera's stream over TCP and republish an H.264 baseline copy on a local RTSP URL. The panel plays the clean URL and everything else keeps the original. Publish into a local RTSP server such as mediamtx, which listens on port 8554:
ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.40:554/stream1 -c:v libx264 -profile:v baseline -level 4.0 -preset veryfast -tune zerolatency -pix_fmt yuv420p -b:v 2M -maxrate 3M -bufsize 6M -an -f rtsp rtsp://127.0.0.1:8554/panel
Each flag earns its place: -profile:v baseline and -level 4.0 set the pair the panel decodes; -pix_fmt yuv420p converts full-range camera output to what hardware expects; -an drops the audio track; -b:v 2M matches the budget in the next section. With zerolatency the transcode adds well under a second, so an operator view stays live. A GStreamer pipeline does the same job if that is already in your stack.
Why does the panel still fail once the codec matches?
Three things survive a codec fix: an audio track the player cannot decode, a UDP transport the panel's network path mangles, and a stream resolution or level above what the panel's decoder was built for — check them in that order.
Audio first. Disable the track in the camera for panel viewing, or keep -an in the transcode. The one exception is a browser-based client that negotiates an audio channel: if it errors on a video-only stream, add a silent AAC track at the transcoder rather than forwarding the camera's G.711.
Transport second. Force RTSP over TCP interleaved — the panel's stream settings usually expose the option, and -rtsp_transport tcp does it for the probe and the transcode. UDP works until a busy switch drops one RTP packet in a group of frames; the failure pattern is covered in streaming camera video over UDP without broken frames.
Resolution third. If the panel's decode ceiling is not written down anywhere, use the 720p sub-stream; a panel that cannot name its ceiling will not decode 1080p reliably. Take a panel firmware update once — decode support widens over time — then retest before adding a transcoder. And if one screen has to work today, MJPEG plays on nearly everything: the MJPEG viewer showing no video faults are about pointing the player at the real stream URL, not about decoding.
What bitrate should you budget for the stream?
Plan 0.05 to 0.1 bit per pixel for H.264 — about 2.2 Mbit/s at 1080p and 15 fps. Keep total camera traffic on the panel's switch port below a quarter of the link so bursts do not drop frames. The per-pixel figure is a planning rule, not a law: surveillance-grade content sits near the bottom of the range, detailed inspection content near the top.
Worked example, a 1080p panel feed at 15 fps:
- 1920 × 1080 = 2,073,600 pixels per frame
- 2,073,600 × 15 fps = 31,104,000 pixels per second
- 31,104,000 × 0.07 bit per pixel = 2,177,280 bit/s ≈ 2.2 Mbit/s
- Recorder pulling the main stream at 4 Mbit/s on the same 100 Mbit/s port: (2.2 + 4.0) / 100 = 6.2 % of the link
Set the camera's encoder cap at 3 Mbit/s for the panel stream and its keyframe interval to one second; both keep the panel's decode buffer happy and the latency low. For contrast, MJPEG at the same size runs near 150 kB per frame, which is 150 kB × 15 fps × 8 = 18,000 kbit/s ≈ 18 Mbit/s — that is why it stays a fallback.
When should you convert RTSP to HLS for the panel?
When the panel's video widget is a browser view with no native RTSP client at all, convert to HLS on the host and point the widget at the .m3u8 URL. Native panel players should stay on RTSP, because HLS adds roughly three segment durations of latency.
ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.40:554/stream1 -c:v libx264 -profile:v baseline -level 4.0 -pix_fmt yuv420p -an -f hls -hls_time 1 -hls_list_size 6 -hls_flags delete_segments /var/www/stream/index.m3u8
With 1-second segments the widget sits about 3 seconds behind live; 2-second segments double that. Serve the segment directory over HTTP and the widget needs nothing else. Two write-ups walk this end in depth: RTSP to HLS conversion on a web HMI and RTSP and live feed set-up on a web HMI video widget. If the same camera also feeds recorded evidence files, choosing a codec for grayscale machine vision video files is the companion decision.
What hardware should carry the video to the panel?
Give the camera and any transcode host a wired gigabit path with PoE on dedicated switch ports. The panel then plays from a wired neighbour, and the only variable left in the chain is the encoder you already control. The camera end can be any of the area scan cameras with a GigE interface, the network end rides the PoE cards stocked with the frame grabbers, and the camera drop is one of the shielded camera cables.
Power the camera and the transcode host from one PoE switch.
- Interface
- GigE
- Ports
- 2 ports
The MV-GE2002P is a dual-port PoE NIC, and LS-CBL-0199 is a 3 m GigE camera cable with screw locks. Give the camera one port and the transcode host the other.
For an inspection-grade feed, two GigE options cover the common cases:
| Specification | MV-CU020-90GC | MV-CS200-10GC |
|---|---|---|
| Sensor type | CMOS, global shutter | CMOS, rolling shutter |
| Sensor model | GMAX4002 | Sony® IMX183 |
| Pixel size | 4 μm × 4 μm | 2.4 μm × 2.4 μm |
| Sensor size | 1/1.7" | 1" |
| Resolution | 2048 × 1200 | 5472 × 3648 |
| Max. frame rate | 49 fps @ 2048 × 1200 Bayer GB 8 | 5.9 fps @ 5472 × 3648 |
| Dynamic range | 66.9 dB | 65.5 dB |
| SNR | 40.8 dB | 41.5 dB |
| Gain | 0 dB to 11.1 dB | 0 dB to 24 dB |
| Exposure time | 4 μs to 10 sec | 46 μs to 2.5 sec |
| Exposure mode | Off/Once/Continuous exposure mode | Off/Once/Continuous exposure auto, supports Timed and Trigger Width exposure mode, and Rolling and Global Reset sensor shutter mode |
| Pixel format | Bayer GB 8/10/10Packed/12/12Packed | Mono 8/10/12, Bayer GB 8/10/10p/12/12p, YUV422Packed, YUV422_YUYV_Packed, RGB 8, BGR 8 |
| Price | $309.00 | $739.00 |
All 2 share: Binning Supports 1 × 1, 2 × 2, 4 × 4; Lens mount C-mount; Humidity 20% RH to 95% RH (no condensation); Compatibility GigE Vision V2.0, GenICam; Certification CE, RoHS, KC; Mono/color Color. Values as printed in each product's data sheet; open a part for its drawing and full specifications.
The MV-CU020-90GC is a 2.5 MP GigE camera with a global shutter and a C-mount, so the encoder decision moves into your software where you control the profile. The MV-CS200-10GC is the 20 MP option when an operator has to read detail on the same screen. Build the camera end in the system configurator if you want the card, cable and camera matched in one pass.
How do you verify the fix and keep it fixed?
Re-run ffprobe against the URL the panel uses and confirm codec_name=h264, profile=Baseline, level at or under 40 and pix_fmt=yuv420p. When the panel plays that URL for an hour without a dropped frame, the fault is closed.
- Probe the exact URL the panel plays — the sub-stream, not the main stream, if that is what you configured.
- Soak-test one hour on the panel, including the plant's busy minutes.
- Export the camera's configuration and record the working profile, level, pixel format and audio state in the panel project.
- Re-run the probe after every camera firmware update; updates reset encoder defaults, which is how this fault returns months later.
- Leave the transcoder running even after the camera is fixed, so the URL the panel plays never changes.
Decisions in one place:
- Camera exposes H.264 settings: force Baseline,
yuv420p, level 4.0 for 1080p or 3.1 for 720p, audio off, panel on the sub-stream. - Camera locked to H.265: transcode with ffmpeg and point the panel at the republished URL.
- Panel widget is a browser view: HLS with 1-second segments.
- Codec matches but the panel still errors: audio off, then force TCP, then drop to 720p.
- Nothing sticks: MJPEG for that one drop, and read the panel's decode specification properly.
If the fault survives all five paths, bring the ffprobe output and the panel's supported-codec list to our contact page and we will pick the path with you. More streaming and player faults are collected on the systems topic page.
Questions
How is a resource error different from a connection timeout?
A timeout means no media arrived — wrong URL, blocked port 554, or a subnet the camera cannot reach — and the player gives up after several seconds of silence. A resource error means media arrived and the decode step failed: the session opened, the stream description was read, and the payload was refused. Treat timeouts as network faults and resource errors as codec faults.
Can you read the refused format from the panel instead of probing on a PC?
Sometimes. A few RTSP widgets name the rejected codec in a diagnostics or event log, and that log is worth one look before any rewiring. Most panels print only the generic error text, so the practical instrument is a desktop probe: ffprobe on the URL, or the codec-information view of a desktop player, which lists profile and level for the same stream.
Should the panel stream carry audio?
Not by default. Turn the audio track off in the camera for panel viewing; many industrial players have no audio decoder and stall before the first frame. Browser-based clients that negotiate an audio channel are the single case where you instead add a silent AAC track at the transcoder rather than forwarding the camera's G.711.
How much bandwidth does a 720p panel stream need?
1280 × 720 is 921,600 pixels per frame; at 10 fps and 0.07 bit per pixel that is 921,600 × 10 × 0.07 ≈ 645,000 bit/s, call it 0.7 Mbit/s. A 100 Mbit/s plant link carries that alongside control traffic without noticing, which is why a 720p sub-stream makes a good default panel feed.
Is MJPEG a safe fallback when H.264 will not play?
Yes, and nearly every player decodes it because each frame is an independent JPEG with no inter-frame dependencies. The cost is bandwidth: at 1080p and typical quality expect on the order of 15-20 Mbit/s at 15 fps, roughly ten times the H.264 figure. Use it for one or two short drops, not for a plant-wide rollout.
Will a camera firmware update break the working stream?
It can. Updates sometimes reset encoder defaults back to H.265 or a high H.264 profile, which is the classic way this fault returns months after a clean fix. Export the camera configuration once the stream works, re-run the ffprobe check after every update, and keep the transcoder in place so the URL the panel plays never changes.