
Video file playback audio beginning to go out of sync as program progresses
We have recently noticed that in a particular program that over time (a few hours), playing back media files (h.264 5000mbps encoded mp4s), slowly starts to lose audio sync (audio lags behind he video picture). Sometimes I can almost hear the moment when things shift, like a slight audio artifact-ing (glitch occurs). The only way to seemingly fix this is restart Wirecast.
Windows 10
CPU i5-7600K
Ram 32gb
GTX 1070
Wirecast 14.3.4
System CPU: 25%
App CPU: 23%
Encoding streaming at 720p, 3500kbps (however, I can replicate this without even streaming, in which case the CPU load is down by about 15% on average).
I noticed that when I am building our my program, the process of building shots/adding media etc.. sends wirecast into a completely fubared state for actual live. I can never not "restart" prior to starting a show.
Our clients are starting to become unsatisfied with these little bugs that start to show up when we are producing events. Its becoming painful not being able to explain where we "screwed" up when we aren't changing anything in our process (and really havn't for at least a year). Is this the computer? or the media? what am I missing, its driving me nuts lol. Again this is JUST when playing back video media. Sync issues with live sources we can always adjust for in software or hardware.
-
Sorry to hear that.
How was the mp4 created?
I assume you're hearing this monitoring Wirecast and not just the stream but please confirm that.
Would you be able to link to a file we can test?
At what rate is the drift? For example how far out is it at "x" minutes? We may need this if we test your file.
Do you have the wherewithal to convert one of the MP4 files to Apple ProRes to see if the sync drift still occurs? If that fixes it, it might indicate an issue with how Wirecast handles the source codec.
Cody Ferreira said:
I noticed that when I am building our my program, the process of building shots/adding media etc.. sends wirecast into a completely fubared state for actual live. I can never not "restart" prior to starting a show.We'd need repeatable steps and what the actual failure is?
-
Hey CraigS thanks for the response.
The files were created by Vimeo's transcoder (we downloaded them from the 720p rendition). Unfortunately I cannot send a sample as the content is something that is not public facing (its for paid users etc..).
The drift appears to happen at random and random amounts. There is no catchup. Its as if the demuxer in wirecast literally starts to take a dump and never corrects it self. As I move from video to video, nothing ever resets, nothing ever gets better...eventually only gets worse (until I restart wirecast).The drift can be seen both in the program viewer (live program, the right window), and can also be seen in the encoded live stream as its going out (what I see, the end users see).
I can certainly change the fils to a ProRes format and try things out and see how it runs.
The repeatable steps are something along these lines:
1. Play a 1 minute video (on loop) for 5 minutes or more
2. Play a different 2 minute video until it ends
3. Play another 1 minute video until it ends
4. Play a more long form video (10 to 60 minutes), until it ends
5. repeat from steps 2 through 4.
Anything else you can advise while I look into a prores encoded test against this flow?
-
Thanks for the above info.
Cody Ferreira said:
I can certainly change the fils to a ProRes format and try things out and see how it runs.Please do. That's an important test.
-
Cody Ferreira said:
Unfortunately I cannot send a sample as the content is something that is not public facingWe won't disclose the contents. You can use our forum private message system and link to a secure file transfer system such as Dropbox, etc. We could download a random file but if we can't reproduce it that would impact resolving/fixing.
Investigation issue WIRE-20142 -
Cody Ferreira said:
all of a suddenat the point of switching a shot or somewhere in the middle of playback.
It's possible that there's some background or drive activity that interrupts playback. -
It appears to happen in the middle of playback, it could be something where it also happens when switching the shot, but its impossible to tell because the shots when switching dont have audio vs. video to really tell if thats when it happens. I know for sure I have seen in just happen while playing back, again to reference my original message... i can sometimes even hear an audio "glitch/artifact" occur and it throws things out of sync a few frames.
Also Im doubtful of background activity, because we run it on a system that doesn't have anything running application wise except for wirecast and windows 10. So if it is a background activity it would mean wirecast is super sensitive and essentially broken to something with windows 10. As we are running it without any applications that do not require actual user initiated function (like a dropbox, adobe cloud, slack etc.. etc..) -
Cody Ferreira said:
A new user account? Like a windows user?Yes. That will determine if there's an odd account-based issue.
-
Cody Ferreira said:
I actually was having a hard time replicating the issue easily as i had to run about 3 hours of video before I saw it.I can't help but think this is a system-related issue since we have no other reports like this.
Cody Ferreira said:
The ProRes doesn't seem to really do much of anything different other than bloat the crap out of the small file.ProRes shouldn't drift so it really does seem like an odd system problem. Again no other reports like this.
Cody Ferreira said:
I was able to get wirecast to go out of sync by some brute forceThat seems like an extreme circumstance.
Cody Ferreira said:
I was encoding a video file in Adobe Media encoder and decided to also push a video to program in wirecast (was not streaming or recording). I could see the lad and hear some skips in the audio (while the system CPU remained VERY low). Obviously I would never do this while actually broadcasting but I was just trying to get things to not behave.It sounds like Wirecast would behave under normal use.
Cody Ferreira said:
I have yet to fiddle with the beta as I haven't had time.Please do as the file playback has likely improved. The developers are waiting for this to move forward.
-
Cody Ferreira said:
I did test another user account, I didn't see the issue when I was testing another user; but then again I wasn't able to run a 3+ hour test.That may well mean a user account-specific issue. The test should match the circumstances. It may well indicate some background task-specific to the user account interfering.
-
Yea the hardest part of reproducing the issue is trying to find a free entire day to replicate the whole broadcast. I need something like at least 3 or 4 hours to even get to the point where I was seeing failures. Its the struggle buss to get there. As I was saying earlier, I could even get the system to a failure point successfully prior to that stretch of time on the normal user account. Also I have no background tasks running beyond whats native to windows and whatever resources are needed to run wirecast. Given the state of the machine, its build, time using wirecast (for years and years) its really hard to point the issue at the machine unless its something SO tiny that wirecast just has a bug with that "tiny tiny little task".
One thing I realized, as it didn't occur to me until just now, is that we were running a rendezvous instance. We only had two users connected and were only being used in the program for about an hour of the 8 hour productions. Im wondering how much of an effect Rendezvous could be factoring. For example, we do run the live program playback for the rendezvous users and it does tax the system an additional 10-15% CPU (which seems really strange). Again never going above 30%-35% when "playing media and running rendezvous". I will do some more testing as I find the time later this week to see whats going on, will also try to test the beta.Is there a way to install the beta in parallel to the current stable version?
-
Cody Ferreira said:
I need something like at least 3 or 4 hours to even get to the point where I was seeing failures.I can understand. Yet if it were a file playback issue it would likely be easier to reproduce. I don't doubt there are other users doing longer programs but so far no reports of a similar issue though so it's hard to find the cause. If it's your personal time perhaps setting up a playlist and letting it run can duplicate the issue.
Cody Ferreira said:
we were running a rendezvous instance. We only had two users connected and were only being used in the program for about an hour of the 8 hour productions. Im wondering how much of an effect Rendezvous could be factoring.I'm not sure if that would impact file playback. I could understand if Rendezvous itself were going out of sync if there were an issue with the server or a peer to peer connection.
Cody Ferreira said:
have no background tasks running beyond whats native to windowsIt could certainly be something native to Windows but again we'd probably hear from other users if it were common.
Cody Ferreira said:
Is there a way to install the beta in parallel to the current stable version?Not on Windows, unfortunately (it's easy to do on Mac).
-
I have finally made time to run the beta and the issue i am running into is audio and video still at random, drifting out of sync. However in the beta, the playback of the "live program" is out of sync, but the actual stream encoding (as I am seeing it playing back in a video player like vimeo) is in sync. Really frustrating.....after production this week I am going to completely re-install windows and wipe everything.