Constant decklink Audio buffer overflow

[TheSashmo]

I am using these settings for my encoding and decoding, and I am constantly getting decklink audio buffer overflow, I've tried OPUS and and MP3 the result is the same. Any suggestions?

/usr/bin/uv --audio-filter controlport_stats --capture-filter preview:path=/tmp/encode_thumbnail_65.socket:target_size=854x480 -t decklink:connection=sdi:device=0:codec=UYVY -c libavcodec:codec=H.264:encoder=libx264:bitrate=20000000:preset=veryfast:subsampling=420 -s embedded --audio-codec=MP3:sample_rate=48000:bitrate=128k --audio-capture-format channels=16 -f V:rs:: -f A:mult:3 -P 20492 172.18.20.5

/usr/bin/uv --audio-filter controlport_stats -d multiplier decklink:device=0:drift_fix#preview:path=/tmp/decode_thumbnail_65.socket:hq:rate_limit=2:target_size=854x480 -r embedded -P 20492 172.18.20.5

Using latest stable build.

Any suggestions?

[alatteri]

I think drift_fix is old terminology, and it is now synchronized, also try adding --param use-hw-accel,resampler=soxr to the receiver.

If the encoder or receiver CPU can't keep up, I believe the errors would be similar.

[TheSashmo]

So replace drift fix with synchronized ?

[TheSashmo]

But it says its using it by default:

[DeckLink display] Using SoxR resampler by default when DecKlink audio drift fixer is enabled.
[DeckLink display] Using device DeckLink Duo (1)
[DeckLink display] bmdDeckLinkConfigFieldFlickerRemoval set to: false
[DeckLink display] bmdDeckLinkConfigLowLatencyVideoOutput set to: true
[DeckLink display] bmdDeckLinkConfigOutput1080pAsPsF set to: false
[DeckLink display] Using audio output: embedeed

[mikekoetter]

I might be mistaken, but I don't think synchronized aka sync is a replacement for drift_fix as I don't think it does any resampling. I believe synchronized is a replacement for the deprecated low-latency mode.

Also I believe soxr is already the default resampler now

[alatteri]

drift_fix activates a time drift fix for the DeckLink cards with resampler (experimental)

synchronized[=m[,M]] use regular scheduled mode for synchrized output
		(m -  minimum scheduled frames /default 4/, M - max sched
		frames /default 6/), shortcut sync

it was my understanding that synchronized superceded drift_fix

or can they be combined for even more consistency?

[TheSashmo]

It seems that both options work.

[alatteri]

one at a time, or combined?

It seems that both options work.

[alatteri]

more context here:

#326 (comment)

[TheSashmo]

Yeah thanks I will look into this, I see that I in fact commented on that thread too complaining about how this would add 100ms of latency, which in the case I am using would be problematic for the setup I am using. Is this option to just keep things in time for audio and video for synchronous playback or can I ignore this option and just yse the audio delay option to be able to keep things sync'd up?

What very very funny is now I don't see the problem anymore. It seems to be gone. The only thing that has changed is a different source was given to me for the encode. Could there be something in the SDI VANC or timecode that is a problem but not being logged as an error in the encoder side, but causes the decoder side to have this problem?

Update: The source now connected a reference signal to their production (not to our encoders) and the issues seems to be gone. Do you think that I should be referencing the cards anyways?

[mikekoetter]

if you are still getting "buffer overflows" maybe try lowing your mtu.
I've seen a change from -m 1500 to -m 1440 make the difference in more complex networks.

[TheSashmo]

Well.... that does make sense if the audio and video were interleaved into one packet, but RTP/RTSP normally has audio on one packet and video on another. The audio packets are like 80 and video is 1430, so setting the MTU would only be setting the limit on video packets and not audio.

That being said, I don't have the problem anymore after the client added a sync to their setup. So I am still trying to find out why the problem was happening.

[alatteri]

maybe @MartinPulec could give us some input on the differences between using :drift_fix and:synchronized with Decklink, and if they are exclusive or there would be benefit in using both at the same time.

[TheSashmo]

And by the way when I try the synchronized mode, I loose audio on my decoding side.

[MartinPulec]

I didn't follow the whole discussion (yet?) so I'll just respond specifically to the question:

differences between using :drift_fix and:synchronized with Decklink

• drift_fix - a resampling buffer is used within DeckLink display module to compensate eventually drifting clocks between the sender and the receiver to mitigate overruns or underruns; no explicit synchronization with the video. But the audio delay is kept more or less consistent so assuming the same holds for video, A/V desync can be compensated with --audio-delay parameter
• synchronized - at the receiver, timestamped audio and video is re-synchronized (best effort) but not doing any compensation as above. Also audio/video source should be one device (eg. decklink). It may also require some tweaking - there is a arbitrary chosen a (video frame) range in which the "synchronization" is attempted, but it can be adjusted.

Those 2 options are totally incompatible, I believe - the audio resampler in first case drops timestamps - even if it wasn't, the number of samples won't fit the audio time frame*. I don't believe that it can be currently made work together. To use both features, it must have been perhaps done in one component.

* it's hard to explain in few lines - I'd need to go more into details if wanted

[alatteri]

Thanks for the info @MartinPulec . I've been using :synchronized since it became available, and haven't had complaints from our endpoints. Does seem like a single component that does both drift_fix & syncro would be ideal at some point?