Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DeckLink synchronized mode not working #362

Open
MartinPulec opened this issue Nov 21, 2023 · 9 comments
Open

DeckLink synchronized mode not working #362

MartinPulec opened this issue Nov 21, 2023 · 9 comments

Comments

@MartinPulec
Copy link
Collaborator

Hey everyone, I'm finally back in the office and can do some testing on this with a professional lip sync analyzer.

I tired all of the above and was not able to get a stable test setup with either continuous or release. The option --param incompatible does not exist, or at least I am putting it in the wrong spot, which I don't think I am.

Just as fyi using UG on a local network or the same machine has somewhere between 80-110ms of drift in the audio. I was told broadcast industry standard is within one frame, sometime accepting two frames of miss-match.

Here is what I am testing:

./UltraGrid-continuous-x86_64.AppImage -t decklink:4 -c libavcodec:encoder=libx264:bitrate=8000k -s embedded --audio-codec=MP3:sample_rate=48000:bitrate=128k --audio-capture-format channels=2 192.168.99.123 -P 10000

and

./UltraGrid-continuous-x86_64.AppImage -d decklink:sync:device=0 -r embedded 192.168.99.123 -P 10000

When running sync option I get flooded with overflow messages and occasional missing frame messages.

Surprisingly when running without the sync option it works "as UG should" but as of the last release and continious build, now I am seeing random decoding errors:

[lavc h264 @ 0x7f339413c0c0] corrupted macroblock 69 24 (total_coeff=-1)
[lavc h264 @ 0x7f339413c0c0] error while decoding MB 69 24
[lavc h264 @ 0x7f339413c0c0] negative number of zero coeffs at 86 35
[lavc h264 @ 0x7f339413c0c0] error while decoding MB 86 34

Suggestions?

Originally posted by @TheSashmo in #326 (comment)

@MartinPulec
Copy link
Collaborator Author

The option --param incompatible does not exist

correct

When running sync option I get flooded with overflow messages and occasional missing frame messages.

Could you provide a minimal non-working example? If you start with the following, does it work?

uv -t testcard -s embedded -d decklink:sync -r embedded -c lavc:enc=libx264 -A Opus

Please note, that I've replaced MP3 with Opus – there is some strange behavior, I'll open a separate issue if I find out more. Anyways, Opus is better, anyways.

When you find the problematic case, what if you set sync parameters, I don't know, something like -d decklink:sync=10,20?

[lavc h264 @ 0x7f339413c0c0] corrupted macroblock 69 24 (total_coeff=-1)
[lavc h264 @ 0x7f339413c0c0] error while decoding MB 69 24
[lavc h264 @ 0x7f339413c0c0] negative number of zero coeffs at 86 35
[lavc h264 @ 0x7f339413c0c0] error while decoding MB 86 34

I don't think it is anything special but network loss – what loss does UG report?

@alatteri
Copy link

I've tested decklink:sync, using the iOS app CatchinSync, and found it to be quite accurate, much lower drift than 80-110ms. I don't know if there is a broadcast industry standard of variance, but at 24fps, that would only be about 41ms for a single frame.

I recently discovered this sync testing app, https://synqr.app , have yet to use with it but it looks to be much more advanced than CatchinSync.

It does feel like decklink:sync requires more CPU resources on the receiver, so I guess make sure you have an adequately powerful platform. Also, can't hurt to use this parameter to get HW decoding if available. --param use-hw-accel

@alatteri
Copy link

Also, make sure you are using latest build.

@TheSashmo
Copy link

Thanks guys, I am going to start on two fresh systems and see the results.

I tried to use that synqr.app and it fails during calibration and I honestly don't think its the best way to do it.

I didn't notice the extra CPU but I will be sure to keep an eye on it.

@2pages
Copy link

2pages commented Nov 26, 2023

Thanks guys, I am going to start on two fresh systems and see the results.

I tried to use that synqr.app and it fails during calibration and I honestly don't think its the best way to do it.

I didn't notice the extra CPU but I will be sure to keep an eye on it.

Hi TheSashmo,

Benjamin from SynQR here.

sorry to hear that you are having troubles calibrating synqr.app. If you can spare a minute it would be great if you could send a detailed bug report through the support form on the website.
Thanks a lot

@TheSashmo
Copy link

Hi TheSashmo,

Benjamin from SynQR here.

sorry to hear that you are having troubles calibrating synqr.app. If you can spare a minute it would be great if you could
end a detailed bug report through the support form on the website.
Thanks a lot

Sure I would be happy to do that.

@2pages
Copy link

2pages commented Nov 27, 2023

Haha.
Yeah would be great if you could end the bug report. But for now I’d be happy if you could send it.
Cheers, Benjamin

@TheSashmo
Copy link

The main issue is that the app will not calibrate correctly. I was able to calibrate once. But when I went back to do it again, it was stuck trying to load your animation image to show the process of it. Send me a link to the bug page and I will upload the whole list of what I found.

@2pages
Copy link

2pages commented Nov 27, 2023

Send the list via the form at synqr.app/support or as an email to [email protected]
Thank you.

MartinPulec added a commit that referenced this issue Nov 29, 2023
using audio codec with relatively long delay may cause underflows, eg.:
```
uv -t testcard:mode=Hi59 -s embedded -d decklink:sync=4 -r embedded \
  -c libavcodec:encoder=libx264 -A mp3:bitrate=64b
```

refers to GH-362
MartinPulec added a commit that referenced this issue Nov 29, 2023
using audio codec with relatively long delay may cause underflows, eg.:
```
uv -t testcard:mode=Hi59 -s embedded -d decklink:sync=4 -r embedded \
  -c libavcodec:encoder=libx264 -A mp3:bitrate=64k
```

refers to GH-362
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants