A/V dropouts/sync when local recording w/ 7.6

I've been doing a weekly livestream for a couple months, streaming to a Wowza server on AWS while also archiving a local recording in ProRes

In each of the last two weeks, the archive .mov has a glitch where both audio and video frames are dropped around the same time, but not in exact sync and apparently not the same amount of time. The result is that the audio and video are out of sync from then on, and if I want to do anything with the video, I need to detach and retime the audio in Final Cut Pro (and live with the glaring dropout).

I'm attaching an H.264 encode of one such dropout (Vimeo password "optional"). It hits around 0:35 in the video. I also have this part of the original ProRes recording on Dropbox if that helps (I can send a link), along with my .wcst file. I also have the entire original ProRes recording, but at 65GB, I don't know how I'd get it to anyone, short of mailing an SD card.

This error happened after upgrading to Wirecast Studio 7.6 -- two dropouts in this week's recording, one in last week's -- and has not been a problem with previous versions of Wirecast. Since I have Time Machine, I'm inclined to downgrade to Wirecast 7.5 for next week's show, and see if the problem goes away.

Hardware is a late 2013 Mac Pro, 3.5 MHz 6-core Xeon E5, 16 GB RAM, recording to an SSD in a Thunderbolt 2 drive bay.

 

Thanks.

--Chris (@invalidname)

21replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Odd. Since you mention DropBox I'll just ask to make sure you're not recording directly to a DropBox folder are you?
    SSD on Thunderbolt 2 should be plenty fast to not have any throughput issues.
    Some Thunderbolt 2 controllers can be stressed. For example, Thunderbolt port 5, 6 and HDMI are all on the same controller (bus) and that can be an issue.

    See Apple KBase.

     

     

    Do you have anything else running besides the webcam and the browser?
    Do you have any programs running the background (virus checkers, etc.)?
    Try using using your SSD on Thunderbolt Port with nothing else on its Bus.

    Reply Like
  • Thanks for the reply, CraigS.

    • The drive bay is the only thing on Thunderbolt Bus 1 (it's on port 3, with port 1 empty). Actually, I did my first 6 or 7 episodes archiving to a spinning 4TB HDD, before realizing I had a spare 1TB SSD that would probably be a better choice for a media drive at run-time. So I did a few episodes on the SSD and they were fine too.
    • Of course I have stuff other than the browser and webcam running; that's the whole point of Wirecast. Why would Desktop Presenter exist if running any desktop apps would break the livestream? In the last episode, I was using Xcode for the first glitch, previous episode it glitched when I was in Parallels. Note, however, that I'd done nearly a dozen episodes livestreaming these same apps without the glitch.

    Like I said, I'm going to try to downgrade to Wirecast 7.5 for this week and see if that makes a difference. Also possible that Apple updated the ProRes codec and that's causing a problem, but it looks like Apple hasn't updated the Pro video codecs since last year, so I don't think that's it.

    Anyways, I'll check back here Saturday with the results of downgrading to 7.5 for Friday night's show.

    Reply Like
  • I guess the other thing to say is that the problem isn't dropping frames, per se. That's always happened when I suddenly put a lot of load on the system (launching big apps while broadcasting, for example). In a two-hour show, I'll regularly drop 50+ frames.

    The new problem is dropping frames in such a way that audio is out of sync with the video in the archived recording after one of these glitches. That didn't used to happen.

    Reply Like
  • Chris Adamson Please do post your results.
    Of course one can run multiple programs but depending on the system and the program, some may have greater impact.
    A software switcher has much more flexibility than a hardware switcher but there's a lot of variables that can stress the system. I even see differences screen capturing one browser vs another impacting the results.
    That the results aren't consistent could well mean there's a variable outside of Wirecast.

    Reply Like
  • Sorry I forgot to follow up here… I've been dealing with a family medical emergency for the last week.

     

    Anyways, last Friday I did my show with Wirecast 7.5 and I did not have any problem with the glitch that gets the audio and video out of sync. Everything was fine. This was with the same production techniques that caused the problems in my previous two 7.6-based episodes (ie, running the same apps while doing the broadcast, same bitrate and codecs for both RTMP and local archive, etc.)

     

    I'm not streaming tonight (see first paragraph) and I'm not sure when my next stream will be, but when I next do another stream, it'll still be with 7.5, and we'll see if I'm still avoiding the glitch.

    Reply Like
  • CraigS  I'm having the same problem as Chris. I'm only running Wirecast and a teleprompter app since my system is quite constrained in terms of ram, processor... in every respect really (system info below)

    The issue seems to occur when I switch to a 154Kb image overlay, so even for my system that shouldn't be a problem.

    OS X El Capitan 10.11.6

    Wirecast Studio 7 - Mac Version 7.6.0 

    Mac Pro early 2009 Processor: 2.66 GHz Quad-Core Intel Xeon

    RAM 6 GB 

    NVIDIA GeForce GT 120 512MB

    Canvas size: 720p

    Encoder:  Performance Preferences:

     

     

    Chris Adamson I wish you good luck with that medical emergency.

    Reply Like
  • Chris Adamson Perhaps you can setup a local test since it's a recording only issues. On Mac you can keep multiple versions of Wirecast (put them in folders in Applications folder). Using the exact same source (that's  MUST) run a test with 7.6 and then run a test with 7.5.

    Reply Like
  • Gabriel Arrache said:
    The issue seems to occur when I switch to a 154Kb image overlay, so even for my system that shouldn't be a problem.

     Since you have it tied to a specific source can you tell me more about the source, frame size and type (png, tiff, jpeg, etc) and how it was created if you know. Also include the complete makeup of the shot (overlay on separate Master Layer or shot with layers in it and what are the video sources).

    Also what is the CPU% at the time of occurrence and are you using an internal 7200rpm drive or SSD drive or maybe an external drive).

    Reply Like
  • CraigS 

    Sure!

    PNG

    Downloaded from wikimedia commons

    833 × 833

    Scaled in Wirecast to 30%

    The image has its own shot on top of another shot that has a Sony HDV camcorder connected via firewire (iLink) 

    Here is a screenshot: 

    Since my last post I conducted several tests and found out that the problem also occurs when switching to a shot that includes: a solid color square, and two other pngs.

    I'm not sure how but I have a sneaking suspicion that the problem has something to do with a video larger than my canvas to which I switch earlier in my show.

    Here are the specifics: 23 sec 1920 × 1080 .mov scaled to 22% 

    I know that should have been my first suspect, since my system specs leave no room to be untidy and I should resize that video. But the problem is not happening when I switch to that video, but later on, when switching to the pngs.

    Reply Like
  • Gabriel Arrache I'm wondering if it's scaling related. Just to confirm, you're scaling both the video and the PNG in the shot. Is the live video HDV? That may play a role as well.

    This presents us with a few variables. Is it possible to create something in which only the PNG is scaled and the video is 720?

    Reply Like
  • CraigS Yes the live video is HDV, I am scaling both in order to create a picture in picture layout, our show is a newscast.

    I can create that. What should be the 720 video should it be the live video or the 23 second .mov?

    Reply Like
  •  Gabriel Arrache Basically I want you to try something where only the PNG is scaled. You can transcode the video clip to ProRes at 720p before hand.
    Do you have a way to bring in HDMI or SDI source?
    HDV demands a lot of resources to decode, has noticeable latency and is actually 1440x1080 scaled to 1920x1080 so I'm wondering if that is part of the issue as well.
    I'd like to see if any single source or combination of sources are causing the issue.

    Reply Like
  • CraigS Good suggestion on keeping the separate versions of Wirecast around. I will try that and see if I can decisively isolate 7.6 versus 7.5 as the cause of the sync glitch. However, it may be a while, as the family medical emergency continues.

    Also, I would hesitate to jump to the conclusion that this is a "recording-only issue". It's certainly more convenient for isolating the bug if it is, and I'm going to do some record-straight-to-file sessions soon anyways. But given your earlier concern about other activity on the system, surely the H.264 encoding performed for the livestream is going to grab some CPU time and attention.

    Reply Like
  • CraigS said:
    Basically I want you to try something where only the PNG is scaled. You can transcode the video clip to ProRes at 720p before hand.

     Will try it and report.

    CraigS said:
    Do you have a way to bring in HDMI or SDI source?
    HDV demands a lot of resources to decode, has noticeable latency and is actually 1440x1080 scaled to 1920x1080 so I'm wondering if that is part of the issue as well.

    I have already ordered two BlackMagic Decklink Mini Recorder in order to use a Canon 7D DSLR via HDMI as a live input, and some other input later on. Also I have 8 gigs of additional RAM on the way and we are planning to upgrade our processor to 3.46 GHz  (i7 990x)

    Reply Like
  • Gabriel Arrache The Canon 7D may not send standard looking video out of HDMI unless Canon has changed the firmware. Some will use the Magic Lantern firmware hack but that voids the warranty of the camera.

    I'm not at all implying it's a recording only issue. I'm making suggested testing procedures and, given the issue, there's no reason to go live to document and test. Testing requires eliminating variables. There are three additional variables, the PNG, the recorded video used as source, the camera source. Each involve scaling. Each test should eliminate two of the three variables so that only one source is being scaled.

    Reply Like
  • CraigS I tried transcoding the video beforehand and it seemed to resolve the problem... until...

    Today I updated the project with some new jpgs (I made no use of the video I only switched images) and the problem returned. I restarted Wirecast, did several recordings using the same project and the same files and those turned up OK. 

    Anyway I would like to know what is causing the issue, I need to be sure that every recording is OK.

    In one of the "good" recordings I noticed some clicks in the audio right about the same spot where in the bad video the audio started to be out of sync. The clicks appear periodically in all of my videos. I use a Blue Snowball USB mic. I created a video for comparison: 

    Reply Like
  • Gabriel Arrache said:
    I tried transcoding the video beforehand and it seemed to resolve the problem... until...

    I'd rather not make assumptions. Transcoded to Apple Pro Res? Something Else? Frame Size?

    Gabriel Arrache said:
    Today I updated the project with some new jpgs (I made no use of the video I only switched images) and the problem returned.

     Please explain further. You just switched between JPEGs without video? Again I can't make assumptions. You must describe as if you wanted me to match exactly what you are doing.

    Gabriel Arrache said:
    In one of the "good" recordings I noticed some clicks in the audio right about the same spot where in the bad video the audio started to be out of sync. The clicks appear periodically in all of my videos. I use a Blue Snowball USB mic. I created a video for comparison: 

     Yes I can see the issues in your example. Since they included video, still, Snowball mic. I really need the specifics.

    For testing your video source should be 720 (ProRes if a recording), Canvas 720, Recording ProRes 720. Only the PNG or JPEGs scaled. I need to determine if scaling the graphics is the issue (and PNGs may behave differently than JPEGs). We have to eliminate all variables but one in order to determine the cause. That means either PNGs or JPEGs, don't alternate please.

    There most certainly is an issue but to determine the cause we have to eliminate all the variables but one. Since you indicated the possibility that the PNGs (now JPEGs?) are involved I'd like to focus on that.

    Reply Like
  • CraigS Hey Craig

    I think the issue had to do with CPU usage, the solution was to stop using the teleprompter app, CPU usage went down from aproximately 75% to 45%

    I have recorded about ten 2 minute videos and the issue seems to be gone so far.

    However the clicks remain, although they have become less frequent. 

    Reply Like
  • Gabriel Arrache Yes generally as you near 80% CPU use frames can be dropped or other similar issues can be experienced.

    You may try an experiment using the Snowball only and do an audio only recording with Wirecast to see if using the Mic by itself is the issue (vs the mic in combination with something else).

    Reply Like
  • OK, so I did another test stream with 7.6 and the sync glitch returned. Raw recording of the video is linked from Vimeo at the bottom of this post (password, again, is "optional").

    • Jump to 5:25 where we come up from bars, and I'm on camera. Audio syncs to video just fine.
    • Glitch hits somewhere around 19:00. Unfortunately, this occurs when the only thing on screen is some minimally-animated sprites, so the video hit is not as apparent. But if you start from 18:45, you'll hear me talking normally, then get a fragment of a sentence ("…the route too, but I could…"), and then picks up with in-game dialogue and my own next line ("I feel like I owe you guys an apology…").
    • As of this point, audio and video are now out of sync. It's totally obvious when I come back at 36:40 and the audio is about one second ahead of the video.

    Another thing to note is that there's nothing particularly interesting going on at the point where it glitches; I'm capturing my screen while running Parallels, which is exactly the same thing I'm doing for 10 minutes before the glitch and 15 minutes after.

    This is the same document as my last 7.5 stream that was glitch free, except for adding another file source that I played at the end of the stream. So far, I have a 100% correspondence of glitching with being on 7.6 instead of 7.5. Next stream I do will be 7.5, and of course I'll follow up if I ever see this problem with 7.5.

    Might be worth my testing 7.6 with a slate that counts frames, like Apple's bip-bop HLS sample stream ( https://devimages.apple.com.edgekey.net/iphone/samples/bipbop/bipbopall.m3u8 ), so we can get a more accurate understanding of exactly what gets dropped at glitch-time -- it seems like it's a separate hit to audio and video at slightly different times.

    Reply Like
  • Chris Adamson As a simple test. Please create a new document in 7.6 and use only a camera source with built in audio. Record using one of our Apple ProRes record to disk presets. I want to eliminate all variables and test under the simplest AV setup (one camera using its own mic).

    Wirecast records a variable frame rate so I'm not sure a timer slate will have meaningful result regarding his issue. The variable frame rate actually should avoid skipped frames and audio sync issues. So the simple camera plus camera mic recording test would expose any issue with skipped frames and sync offset that might occur at such point. Make sure CPU is well under 80% (it should be with just one camera source and ProRes recording). Make sure nothing else is running on the computer.

    If you have the issue in 7.6 do the same with a new document in 7.5 and test. This would then verify the only change is the Wirecast version and document native to it.

    Reply Like
login to reply
Like Follow
  • 3 mths agoLast active
  • 21Replies
  • 366Views
  • 3 Following