-
Notifications
You must be signed in to change notification settings - Fork 53
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
Comments
Could you provide a minimal non-working example? If you start with the following, does it work?
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?
I don't think it is anything special but network loss – what loss does UG report? |
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. |
Also, make sure you are using latest build. |
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. |
Sure I would be happy to do that. |
Haha. |
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. |
Send the list via the form at synqr.app/support or as an email to [email protected] |
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
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
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)
The text was updated successfully, but these errors were encountered: