DEV Community: 宛涵

A practical workflow for debugging flaky RTSP camera streams

宛涵 — Thu, 02 Jul 2026 06:04:24 +0000

When an RTSP camera works 95% of the time and falls apart at the worst possible moment, you usually don't have a network problem — you have a session problem. Here is the checklist I run before I touch the camera config or the VMS.

1. Confirm the session actually opens

The first thing to check is whether DESCRIBE returns a valid SDP. If the server replies with a 401 before SDP, your credential realm is wrong; if it returns SDP with m=video 0, the server is advertising a track it cannot actually serve. Don't proceed until DESCRIBE returns something usable.

2. Read the SDP like a packet, not a string

Two things matter most:

The rtpmap and fmtp lines tell you exactly what the encoder is sending. If the camera says H.264 High@L4.1 but your decoder caps at Baseline, you will get a green wall, not an error.
The a=rtcp and a=control attributes decide whether RTCP feedback and per-track SETUP will actually work. If a=control is missing or duplicated, SETUP will hang forever even though DESCRIBE looked fine.

3. Watch the timing, not just the bytes

RTP streams fail in two flavors: late packets and missing sequence numbers. With tcpdump and Wireshark I look at the inter-packet delta first — a 30 fps stream should sit near 33 ms, not 100 ms — and then at gaps in the sequence number. A consistent 33 ms with periodic sequence gaps usually means the camera is dropping at the encoder, not on the wire.

4. Inspect the interleaved binary

For RTSP-over-TCP (the RTP/AVP/TCP;interleaved= case), the failure mode is different. The interleaved channel can stop interleaving, and then your "RTSP" connection is silently just TCP. Open the TCP stream, count the $ framing bytes, and confirm the server is still emitting interleaved RTP and not just keepalive.

5. Decide what you actually need to repair

Most of the time the diagnosis above points to one of three fixes: tweak the encoder profile, change the transport from UDP to TCP (or vice versa), or move the camera off a congested switch port. Sometimes the answer is that the recording you already have is fine but needs clean re-muxing.

If you want a faster loop on steps 2–4, RTSP Inspector is a local desktop tool I built that walks you through the same checklist with the actual SDP, RTP timing, and interleaved framing laid out next to each other. Disclosure: I am the author.

Stop learning whole songs first: a local audio practice workflow for guitar and bass

宛涵 — Sat, 27 Jun 2026 01:55:17 +0000

Stop learning whole songs first: a local audio practice workflow for guitar and bass

Most players do not get stuck because the next song is too hard.

They get stuck because they keep trying to learn the whole recording at once: intro, verse, chorus, fill, solo, tone, timing, and memory all in the same practice pass. That feels productive for the first fifteen minutes, then it turns into scrolling tabs, restarting the track, and guessing where the problem actually is.

A better workflow is smaller and more mechanical.

1. Pick one phrase, not one song

Choose the smallest part that still feels musical:

a two-bar riff
one chord change
one bass fill
the first half of a lead phrase
the transition into the chorus

If you cannot hum it, count it, or tap the rhythm, it is too large for the first pass.

The goal is not to "finish the song" today. The goal is to make one section boring.

2. Slow it down before you touch the instrument

Slow practice only works if the loop is short enough.

A useful starting point:

50-60% speed for a new phrase
no pitch change if you are playing in the original key
a loop that starts slightly before the mistake and ends slightly after it
five clean repetitions before raising the tempo

Do not raise speed because you are bored. Raise speed when the timing survives boredom.

3. Separate sound, timing, and location

For guitar and bass, three different things often get confused:

what the phrase sounds like
where the notes live on the fretboard
how the rhythm sits against the track

If you try to solve all three at once, you usually memorize a hand shape without understanding the phrase.

For guitar, name the key center and the chord tones under the phrase. Even basic intervals help: root, third, fifth, flat seventh. That turns a lick into something reusable.

For bass, listen for the relationship to the kick and the chord movement before worrying about every ghost note. The low end often sounds busier than it is because the mix hides the attack.

4. Use tabs as a draft, not the source of truth

Tabs are useful when they get you unstuck. They are dangerous when they replace listening.

A good tab workflow:

listen first
make a rough position guess
check a tab or chart only where needed
correct the fingering against the audio
write down the version that actually works under your hand

For bass especially, the best chart is often not the prettiest one. It is the one you can play in time with the recording.

5. Keep the file local when possible

For practice, local tools have a few boring but important advantages:

no upload wait
no subscription just to slow down a song
no private lesson or rehearsal audio leaving your machine
repeatable projects you can reopen tomorrow

That matters more than flashy features if you practice every day.

Disclosure: I build local music practice tools for this kind of workflow.

Session Craft is for slowing, looping, pitch shifting, chord timelines, and stem-focused practice from local audio: https://hannes-software.com/session-craft/
Fretboard Lab is for mapping chord tones, voicings, keys, and fretboard positions: https://hannes-software.com/fretboard-lab/
LowEnd Forge is for bass-first transcription: isolate the low end, draft four-string tab, edit it, and export a usable chart: https://hannes-software.com/lowend-forge/

The Community Free versions are enough to start. Do not pay for practice software until the workflow actually sticks.

The short version

Practice smaller sections than your ego wants.

Slow the recording down.

Loop until the mistake becomes boring.

Learn why the notes work, not only where your fingers go.

Then move to the next phrase.

Bass transcription workflow: isolate the low end before drafting tab

宛涵 — Sat, 27 Jun 2026 01:53:56 +0000

Bass transcription workflow: isolate the low end before drafting tab

Most "MP3 to bass tab" tools fail for the same reason: they treat the bass as a generic instrument and try to recognise every note in the mix at once. The result is a chart full of guesses that look like a bass line and play nothing like one.

A usable bass transcription workflow does three things in this order:

Pull the bass role away from the rest of the mix.
Trace the low-register line, not every pitched sound.
Draft the chart against the waveform, so the bassist can correct decisions instead of fighting the tool.

This post walks through the steps in detail, with the failure modes that show up when each step is skipped.

Why full-mix transcription is the wrong first step

A bass part lives between roughly 40 Hz and 1 kHz:

E1 (low E string)        ~41 Hz
A1                       ~55 Hz
D2                       ~73 Hz
G2                       ~98 Hz
upper harmonic focus    ~200-1000 Hz

A bass part sits behind kick and rhythm guitar, and often shares pitch classes with the piano's left hand. When a transcription engine runs across the whole mix:

kick transients register as low notes and pollute the note stream
the bass guitar's body resonance is mistaken for sustained pitches
pitch confidence drops every time the bass and another instrument share a note

The output looks complete. It is not playable. A bassist who prints it and brings it to rehearsal finds the rhythm is roughly right, the pitch classes are often wrong, and every "decision" the tool made is invisible.

The fix is to narrow the source first.

Step 1: isolate the bass role, not the bass frequency

Bass isolation is not a single EQ move. Useful results come from a chain that mirrors how a bassist listens to a recording:

start with a mid/side or center-channel pull so the bass-heavy centre content is reduced in the side image
apply a high-pass above the bass register on the side image only, to kill vocals and guitars that pan wide
run a low-pass around 1 kHz on the result so harmonics above the bass role drop out
de-bleed the kick by sidechaining the bass to the kick, or by spectral subtraction if the bleed is consistent

The point is to keep the bass register but to remove the instruments that share it. If you only low-pass filter, you still have kick, rhythm guitar low end, and piano left hand polluting the line.

A useful test: play the isolated signal alongside the original. You should hear the bass line move, with kick and guitar mostly gone, and the rest of the mix reduced but not silent.

Step 2: trace the low-register line, not every note

Once the source is clean, the transcription step needs to constrain the search to four strings and the bass register. Generic polyphonic transcription tries to label every pitched event, including harmonics that the bass plays briefly between notes. On a bass part, those are noise, not melody.

A bass-focused trace should:

constrain the search to four strings at standard or alternate tuning
prefer the lowest plausible note in any window where two pitches overlap
track position changes across the neck, so a note on the A string at the 7th fret is recognised as E, not as D on the E string
ignore sub-harmonic artefacts that come from the body resonance

This is the difference between a "tab that looks like bass" and a tab a bassist can play. If the chart shows two adjacent frets on the same string where the audio clearly walks, the trace followed the wrong string. If the chart shows notes that are physically impossible (B on the low B string followed by G on the D string at the same moment), the trace ignored position.

Step 3: draft against the waveform, not against the spectrogram

A spectrogram is useful for picking out attack points. It is misleading for rhythm, because the strongest frequency on a bass note is often the fundamental, which arrives a few milliseconds after the attack.

The reliable reference for a bass part is the waveform, with a vertical guide at each beat. The transcription should align note onsets to waveform peaks, not to spectrogram contours. When the chart shows a note that lands on a beat but the waveform peak is on the off-beat, the chart is wrong and the tool should let the bassist drag the note rather than offering another auto-fix.

This is also where most auto-transcription tools lose trust. The user hears that something is off, cannot tell what, and starts over. A workflow that lets the bassist nudge individual notes against the waveform is faster and produces a chart that survives a second listen.

Failure modes you can recognise early

Once you know the failure modes, you can hear them in the chart.

Every note is right but the rhythm is loose. The trace followed the pitch class but not the attack. Re-align the onsets to waveform peaks.

Notes that should be on the same string jump to a higher string. The position tracker lost the neck. Lower the search window or add a position hint at the start of the section.

A long note shows up as multiple short notes. The note tracker split on amplitude variation. Smooth the tracking window or merge notes within a phrase.

Ghost notes disappear. Ghost notes are quiet and short. If the threshold is set for full-volume notes, ghost notes never enter the chart. Lower the threshold for unrecognised windows and add them back manually.

The chart plays in time but sounds wrong. The pitch classes are close, the rhythm is close, but it is not the bass line. This usually means the source was not isolated well enough and the trace is following another instrument. Go back to step 1.

What to keep in the workflow

A bass transcription workflow is not "run the auto-tab, clean up later". It is:

Isolate the bass role, with the test of "play it next to the original".
Trace the low-register line, constrained to four strings and the bass register.
Draft against the waveform, so attacks line up with peaks.
Edit the chart manually, with ghost notes, slides, and position changes the trace did not catch.
Export a chart the player can take to the room.

Each step is a chance to correct what the previous one guessed. Skipping any of them produces a chart that looks right and plays wrong, which is the main complaint people have with auto-tab tools.

If you want a bass-first transcription workbench that runs the workflow above, LowEnd Forge is the local-first desktop tool I built for this. It isolates the bass role, drafts four-string tab, lets you correct notes against the waveform, and exports MIDI, MusicXML, and PDF. Community Free is free to evaluate; Professional is a one-time $19 licence, not a subscription.

LowEnd Forge: https://hannes-software.com/lowend-forge

Dental practice management without the monthly cloud bill

宛涵 — Fri, 26 Jun 2026 01:52:26 +0000

Are you running a small dental clinic and tired of paying $200–$500/month for cloud practice management software that breaks whenever the internet goes down?

You are not alone. Every week on dental forums, someone asks: "Is there a dental software that does not require a subscription?" or "Our internet has been spotty — can we still run the front desk?"

The short answer is yes. Desktop dental software still exists, and for a small clinic (1–5 chairs), it often works better than cloud-first suites.

What a local clinic actually needs

The daily workflow in a small dental practice is surprisingly consistent:

Schedule appointments on a calendar
Register new patients with medical history
Record treatment notes per visit
Chart procedures on a tooth diagram (FDI or universal)
Generate invoices and record payments
Print or email receipts
Back up at the end of the day

None of these require a live internet connection. They require a reliable database, a clear interface, and PDF export for when you do need to share records.

Why some clinics switch back from cloud

The cloud practice management pitch sounds great on paper: access from anywhere, automatic updates, no IT maintenance. But the reality for small clinics includes:

Internet dependency. When the ISP goes down (and it will), the front desk cannot check in patients, the dentist cannot pull yesterday's treatment notes, and billing stops.

Pricing creep. The $99/month starter tier quietly becomes $200+, then $350+, with features you never asked for bundled in.

Data migration lock-in. Exporting years of patient records from a cloud system is often a paid professional service, not a built-in button.

Training churn. Every major UI update forces retraining. Desktop software that stays stable saves hours per staff member.

What to look for

If you are evaluating practice management software for a small clinic, here is a pragmatic checklist:

Offline-first. Can you open the schedule and patient records without internet?
Local backups. Can you copy the database to a USB drive or network folder at the end of the day?
One-time purchase. Is there a buy-once option, or is every feature behind a recurring paywall?
PDF export. Can you share treatment records, invoices, and referrals without the recipient needing the same software?
GDPR / data control. Do you know where your patient data lives, or is it mixed into a multi-tenant cloud database?

A practical alternative

I built Dental Ark because the small clinic workflow should not require a monthly SaaS subscription and a permanent internet connection. It is a local-first desktop application that runs on Windows and Linux, stores patient data on your own machine, and exports everything to PDF. There is a free community edition and a $119 professional license — one payment, not a subscription.

The software handles appointments, patient records, treatment notes, FDI tooth charting, billing, follow-ups, PDF export, and manual backups. No internet required. No cloud dependency. No data leaving your clinic.

If you are currently evaluating alternatives to Cloud 9, Curve, Dentrix, or Open Dental, or if you just want a fallback system for days when the cloud is down, the Dental Ark page has screenshots, a detailed feature list, and the community download link.

This is not a sponsored post. I am the developer, and I build local-first desktop tools because I believe small clinics should own their data and control their software costs.

USBPcap and usbmon debugging: what to collect before blaming firmware

宛涵 — Tue, 23 Jun 2026 07:16:50 +0000

USB bugs are easy to describe badly.

The device is not detected.
The HID report is wrong.
The endpoint stalls.
It works on one machine but not another.
The firmware team says the host is wrong.
The host team says the firmware is wrong.

The fastest way out is to collect evidence at the USB transfer level.

On Windows, that often means USBPcap. On Linux, that often means usbmon. The capture alone is only the beginning; the useful work is turning that capture into a readable explanation.

Start with the failure mode

Before capturing, write down the exact failure.

Examples:

Device never enumerates
Configuration is selected but interface does not start
HID input report length is unexpected
Bulk IN endpoint stops responding
CDC device opens but no data arrives
Mass Storage command times out
UVC camera exposes descriptors but preview fails

Different failures require different evidence.

Capture enumeration first

If the device is not recognized correctly, capture from plug-in through configuration.

Look for:

reset
device descriptor request
configuration descriptor request
string descriptor requests
set address
set configuration
interface and endpoint descriptors
class-specific descriptors

Enumeration bugs often hide in descriptors, not payload data.

Read descriptors like a contract

Descriptors tell the host what the device claims to be.

Check:

bDeviceClass / bInterfaceClass
idVendor / idProduct
bcdUSB
configuration count
interface count
endpoint address and direction
endpoint transfer type
wMaxPacketSize
polling interval
HID report descriptor
CDC class descriptors
UVC class descriptors

If the descriptor contract is wrong, the host may behave correctly while the product still fails.

Separate control, interrupt, bulk, and isochronous traffic

Not every transfer means the same thing.

Control transfers often explain setup and class requests.

Interrupt transfers often matter for HID devices.

Bulk transfers often matter for CDC, storage, vendor protocols, and firmware update flows.

Isochronous transfers often matter for cameras, audio, and real-time media.

A readable timeline should keep these categories visible.

Check setup packets before payloads

For control transfers, inspect the setup packet:

bmRequestType
bRequest
wValue
wIndex
wLength

A single wrong wIndex or request direction can explain a failure that looks like a payload problem.

Compare good vs bad hosts

If the device works on one machine and fails on another, capture both.

Compare:

descriptor requests
selected configuration
class driver behavior
endpoint polling interval
transfer sizes
timeout patterns
stall/clear-feature sequences

Do not assume the host with the failure is the only interesting one. The working host is your baseline.

Avoid overclaiming from software captures

USBPcap and usbmon are software-side evidence. They are very useful, but they are not a replacement for a hardware analyzer when the question is electrical timing, signal integrity, low-level bus errors, or power behavior.

Use software captures for:

enumeration logic
descriptors
class requests
transfer sequence
payload inspection
host/device protocol behavior

Use hardware tools when you need electrical truth.

What to send to firmware or support

A useful USB debugging handoff should include:

OS and kernel/build version
Device VID/PID
Firmware version
Capture source: USBPcap or usbmon
Failure mode
Enumeration summary
Descriptor notes
Endpoint involved
Transfer timeline
Relevant setup packets
Payload examples if safe
What changed between good and bad runs

That is much better than “USB does not work”.

Where Bus Scope fits

You can capture USB evidence with USBPcap, usbmon, Wireshark, and scripts. The hard part is making the session readable enough for firmware, hardware, and support teams to discuss the same evidence.

I build Bus Scope for that workflow. It is a local desktop USB diagnostics workbench for inspecting USBPcap or usbmon evidence, descriptors, endpoints, HID reports, payloads, sessions, filters, and exportable support notes.

It is not a professional hardware analyzer replacement for electrical timing or signal integrity. It is for daily software-side USB debugging and handoff.

Disclosure: I build Bus Scope.

Quick checklist

[ ] Define the exact failure mode
[ ] Capture from plug-in if enumeration matters
[ ] Save descriptors
[ ] Inspect setup packets
[ ] Separate transfer types
[ ] Compare good and bad hosts
[ ] Document OS, firmware, VID/PID
[ ] Export a readable handoff

How to prepare a PCAP for vendor support without leaking the whole capture

宛涵 — Tue, 23 Jun 2026 07:02:13 +0000

Packet captures are useful because they are specific. They are risky for the same reason.

A raw PCAP can contain:

internal IP addresses
hostnames
credentials or tokens in cleartext protocols
cookies
DNS queries
customer traffic unrelated to the bug
proprietary endpoints
timing information
enough context to reveal network architecture

Before sending a capture to a vendor, support team, customer, or public issue, treat it like evidence that needs minimization.

The goal is not to make the file pretty. The goal is to preserve the packets needed to reproduce or explain the issue while removing everything that does not belong in the handoff.

Start with the question

Do not edit a PCAP until you know what the receiver needs to answer.

Examples:

Why does TLS negotiation fail after ServerHello?
Why does this device retransmit every request?
Why does the API return 400 only for this payload?
Why does the camera stream freeze after PLAY?
Why does DNS resolve differently on this subnet?

That question tells you which packets matter.

Keep a read-only original

Always preserve the original capture.

Recommended structure:

case-1234/
  original/
    customer-capture-raw.pcapng
  working/
    filtered-draft.pcapng
  handoff/
    vendor-handoff-v1.pcapng
    notes.md

Never overwrite the original file. If a later question appears, you may need to rebuild the handoff from the untouched source.

Reduce the time window

The easiest safe reduction is time.

If the failure happens between 10:42:13 and 10:42:18, the vendor probably does not need a 45-minute capture.

Keep:

a small lead-in before the failure
the failure itself
enough aftermath to show retries, resets, or recovery

Remove unrelated browsing, background sync, update checks, and other noise.

Filter by conversation, not just protocol

Protocol filters are often too broad.

Instead of “all HTTP” or “all DNS”, narrow to:

client IP
server IP
port
stream/conversation
device MAC
transaction ID
request path if visible

A narrow conversation makes review faster and reduces accidental disclosure.

Redact identifiers deliberately

Common fields to inspect before sharing:

IP addresses
MAC addresses
Hostnames
DNS queries
HTTP headers
URLs and query strings
Cookies
Authorization headers
Email addresses
Usernames
Device serial numbers
Payload strings

Redaction should be intentional. Replacing every IP with nonsense can destroy routing evidence. Leaving every internal hostname can leak environment details.

A good rule:

preserve structure needed for diagnosis
remove identities not needed for diagnosis
document what changed

Repair checksums when rewriting

If you modify packet bytes, addresses, or headers, checksums may no longer match.

Some tools ignore bad checksums. Some analysis tools and test harnesses do not.

After editing, check:

IP header checksum
TCP checksum
UDP checksum
transport length fields
capture file format validity

If the file is meant for replay, testing, or regression fixtures, checksum correctness matters more.

Add a short handoff note

Do not send a PCAP alone.

Include a note like:

Case: login request fails after TLS renegotiation
Original capture retained internally: yes
Shared file time window: 10:42:10-10:42:22 UTC
Included hosts: client 10.0.0.15, api.example.internal
Redactions: client IP anonymized, hostname shortened, cookies removed
Checksums repaired: yes
Expected symptom: server closes connection after packet 184
Question for vendor: is this close_notify behavior expected?

That note prevents the receiver from reverse-engineering your intent.

Validate the final file

Before sending:

[ ] Opens in Wireshark/tshark
[ ] Contains the failure
[ ] Does not contain unrelated traffic
[ ] Redactions are documented
[ ] Checksums are valid if needed
[ ] File size is reasonable
[ ] Receiver knows what question to answer

Where PCAP Surgery fits

You can do parts of this with Wireshark, editcap, text notes, and scripts. The problem is that safe support handoff is a workflow, not one command.

I build PCAP Surgery for that workflow: review, trim, redact, repair checksums, and export focused PCAP/PCAPNG files from a local desktop workbench.

It is not a live packet sniffer, IDS, VPN, or traffic generator. It is for preparing packet evidence that can be safely handed to another person.

Disclosure: I build PCAP Surgery.

Minimal handoff checklist

[ ] Define the support question
[ ] Preserve the original capture
[ ] Trim the time window
[ ] Keep only relevant conversations
[ ] Redact sensitive identifiers
[ ] Repair checksums if rewriting
[ ] Export a focused PCAP/PCAPNG
[ ] Send a short note with the file

RTSP black screen troubleshooting: what to check when VLC works but your VMS does not

宛涵 — Tue, 23 Jun 2026 07:01:48 +0000

An IP camera stream failure is rarely just “RTSP does not work”. The useful question is more specific:

Did RTSP authentication succeed?
Did DESCRIBE return the SDP you expected?
Did SETUP choose TCP interleaved or UDP RTP?
Is media arriving after PLAY?
Are RTP sequence numbers continuous?
Does the codec profile match what the client can decode?
Is ONVIF handing the VMS a different URI than the one you tested in VLC?

When a camera plays in VLC but not in an NVR/VMS, the failure is usually in the gap between “the stream exists” and “this client can negotiate, receive, and decode it reliably”.

Start with the exact URI

Do not compare two different tests.

Write down the full RTSP URL used by each client:

rtsp://user:pass@camera.local:554/path

Check for differences in:

profile path
channel number
stream subtype
query parameters
username/password encoding
transport settings
ONVIF-generated URI vs manually copied URI

Many cameras expose multiple profiles. VLC may be opening the main stream while the VMS is using a substream, or vice versa.

Check the RTSP control flow

A normal session usually looks like this:

OPTIONS
DESCRIBE
SETUP video
SETUP audio (optional)
PLAY
TEARDOWN

Useful failure patterns:

401 loop

Authentication is not being accepted. Check digest/basic auth, clock drift on some devices, special characters in passwords, and whether the VMS encodes credentials differently.

DESCRIBE succeeds, SETUP fails

The client can read metadata but cannot negotiate media transport. Check UDP/TCP mode, client ports, firewall/NAT, and multicast settings.

PLAY succeeds, black screen

The control session succeeded, but media or decoding failed. Now inspect RTP and codec details.

Read the SDP instead of guessing

The DESCRIBE response should return SDP similar to:

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=control:trackID=1
a=fmtp:96 packetization-mode=1; profile-level-id=...

Check:

codec: H.264, H.265, MJPEG
payload type
control attribute
SPS/PPS availability for H.264
profile-level-id compatibility
audio track that may confuse weaker clients

A stream can be valid but still use a profile or packetization mode the receiving system handles poorly.

Verify RTP actually arrives

If RTSP SETUP selected UDP, confirm that RTP packets arrive on the negotiated ports.

Symptoms of blocked media:

RTSP commands return 200 OK
PLAY succeeds
no RTP packets arrive
no RTCP receiver reports
client shows black screen or timeout

This often means firewall, NAT, VLAN, routing, or client port negotiation is the real issue.

If TCP interleaved works but UDP does not, you have a transport path problem, not necessarily a camera problem.

Inspect RTP continuity

When packets arrive but playback freezes or breaks, look for:

sequence gaps
timestamp jumps
marker bit behavior
payload type changes
RTCP sender reports
jitter patterns

A few packet losses may be tolerable. Repeated gaps around keyframes can make a stream look like a decode failure.

ONVIF handoff can hide the real URI

Many VMS products discover cameras through ONVIF, then request stream URIs from the device.

That URI may not match the one you tested manually.

Compare:

ONVIF profile token
returned media URI
transport protocol requested by ONVIF client
main/sub stream selection
authentication behavior after handoff

If VLC uses a hand-written URI and the VMS uses an ONVIF URI, you have not tested the same thing yet.

What to hand to support

A useful report should include:

Camera model / firmware
Client name and version
RTSP URL path (without password)
Transport mode: TCP or UDP
RTSP request/response summary
SDP video/audio details
RTP arrival status
Packet loss or sequence gap notes
Codec profile notes
Exact failure symptom

That is much more actionable than “camera does not play”.

Where RTSP Inspector fits

You can do parts of this manually with VLC logs, Wireshark, ONVIF tools, and packet captures. The hard part is turning those pieces into a compact handoff that a camera vendor, installer, or VMS support team can understand.

I build RTSP Inspector for that workflow. It is a local desktop tool for RTSP, RTP, RTCP, SDP, ONVIF handoff, packet loss, and codec-readiness diagnostics. It is not a VMS, NVR, surveillance recorder, or media player; it is meant to explain why a stream does or does not work.

A practical workflow is:

Reproduce the failure with the same URI the client uses.
Capture RTSP control messages and SDP.
Confirm transport mode and media arrival.
Inspect RTP/RTCP evidence.
Export a report for support handoff.

Disclosure: I build RTSP Inspector.

Quick checklist

[ ] Same RTSP URI in both clients
[ ] Authentication result known
[ ] DESCRIBE response saved
[ ] SDP codec/profile inspected
[ ] SETUP transport mode known
[ ] RTP arrival confirmed
[ ] RTP sequence gaps checked
[ ] ONVIF media URI compared
[ ] Report prepared for support