Skip to main content

Tech

NDI Analysis log

NDI Analysis log

by Andrey Zikov - Number of replies: 5
Hi there!

I have a trubles with an NDI stream in OBS+DistroAV (freezy, little stops).  Seems in NDI Monitor they are not, or they are much more less and faster.

So I get to read data from NDI feed and first, the log says that camera is type="NDI". I read that this mean it is FULL NDI, but mine camera is NDI|HX3, for HX feed there should be NDI|HX, but what should be if it HX3?

And is some one who can read the Analysis csv file and make any idea? For me it looks like the feed from camera is not correctly. What you think?

Link to CSV -> https://drive.google.com/file/d/1hmkFMfGUbi_c1_X0Thg6AV8Okjj7yk-0

Best regards,
Andrey.
In reply to Andrey Zikov

Re: NDI Analysis log

by Kane Peterson -
type="NDI" displays what kind of discovery is being used to find this source. All High Bandwidth (Full), HX2 and HX3 devices will appear as type="NDI" since they all use the same mechanism.

The only devices that appear as type="NDI|HX" will be old HX1 devices, which use different discovery mechanisms.

As for the report, you performed the CSV detailed export, what you should perform is the standard analysis, I direct the output to a file to match sure all data is captured.  The standard report will give send/receive times.

NDIAnalysis.exe /source:"My Source (Channel 1)" /time:120 > d:\filename/txt
In reply to Kane Peterson

Re: NDI Analysis log

by Andrey Zikov -
Thanks for a reply!
I attached a new TXT log file, what you can say?


In reply to Andrey Zikov

Re: NDI Analysis log

by Elias Puurunen -
So there's a couple things going on.

1. NDI + OBS is not the best. OBS tries to be smart about frame scheduling. By default it tries to use the timestamp as the "timecode" for the frame, which can be inconsistent (that's the time the frame was sent to the source's encoder). Switching to source timecode tells OBS to use the source's timecode field as the timestamp for the OBS video frame. I'd start there.
2. If the latency mode is set to normal, DistroAV requests frames in BGRA format, which incurs a conversion penalty. I've personally had too many sources being decoded and had stalls in that part of the pipeline. Use low/lowest to force DistroAV to provide YUV frames without any conversion.
3. I see instances where the video's max recv time is beyond the nyquist limit (16.67 + 8.3msec). That could cause stutters.

Can you provide more details about the type of device you're using? i.e. is it a camera, converter, etc.
In reply to Elias Puurunen

Re: NDI Analysis log

by Andrey Zikov -
Thanks for a reply!

1. I was try a vMix and there was much more better, but also when the scene is more active have a little freezes!
Those freezes almost can't see in NDI Monitor.
2. Tonight I'll try with those settings, thanks!
3. I was try without a local network, just patch cord (2m) from camera to PC, also was tried a several machines - Intel and AMD, so this trouble is not in machine.

This is an AVKANS camera from Amazon, as they say - a brand for online store only. I have limited budged, so goes with them.
In reply to Andrey Zikov

Re: NDI Analysis log

by Andrey Zikov -
UPDATE:
Downloaded the KMS software and after that I was try to research what happen if I change an ENCODE LEVEL at the source (camera) to MEDIUM and press SAVE ... and what you think? Freezes goes away in vMix, switching back to the HIGH and again there is no freezes until the camera goes powered off, when power it up I should again change those settings and again no freezes. Don't know what happen inside, but after those manipulations the dTime(ms) is more stable, please see attached LOG files, also uploaded CSV to GD.

[LINK] to CSV

p.s. Not yet tried the feed in OBS+plugin, just in trial vMix.