Most camcorders capture audio at 48 kHz, so there’s a natural tendency to produce your streaming files at that sample rate. There’s just one problem; it can cause loss of audio/video synch during playback on the Flash Player.
Andy Stevenson of the University of Manchester reported this in an interesting thread on the Linked In Streaming Media Professionals group last week. Andy commented that he experienced loss of synchronization on some live video that he was producing (Andy’s explanation is pasted below). Long story short, Andy reported that by changing the audio sample rate from 48 kHz to 44.1 kHz, he fixed the problem. This is so, he concluded, because Flash resamples all audio to 44.1 kHz during playback, and on CPU challenged computers, this translation can cause loss of synch.
A little research confirmed Andy’s conclusion. Here’s a blurb from Robert Reinhardt’s Video with Adobe Flash CS4 Professional Studio Techniques.
- Sampling rate: This property determines how many audio samples are recorded per second, expressed in kilohertz (kHz). The higher the value, the more faithfully the original sound is reproduced. The common sampling rates for Web video are 11.025 kHz (or 11 kHz), 22.050 kHz (or 22 kHz), and 44.100 kHz (or 44.1 kHz). Audio CD recordings use a 44.1 kHz sampling rate, and some digital video formats record at 48 kHz. The sound quality you hear from FM radio broadcasts is roughly 22 kHZ, whereas 11 kHz is equivalent to telephone sound quality. Flash Player resamples all sound sources to 44.1 kHz during playback. For high-quality audio, I recommend always using 44.1 kHz. Use 22 kHz or 11 kHz sampling rates only if you need to encode low bit rate audio for slow connection speeds.
Here are the options from the Adobe Flash Live Media Encoder – you will notice that 48 kHz isn’t available. If you check Adobe Media Encoder for either FLV or F4V output, you’ll see the same thing. The problem is, 48 kHz is available on lots of other encoding tools.
Bottom line is that you should never output at 48 kHz for files destined for Flash Playback. You should check all of your Flash presets to make sure that you’re not producing at this sample rate.
Here’s his first post.
At first I was experiencing some definite audio syncing issues, firstly with a time lag of approximately 1/4 to 1/2 second lag. I have also noticed some slippage, so when the stream starts after several hours later (3-4), there was a similar delay. Depending on whether I maximise and restore the player I also noticed a lag on restore. The confusing aspect regarding this is that the problems I experience happens with different parameters. Sometime it can happen with one change, other times it has with a different change. I have also noticed some clicking, which while it is not loud, it is noticable. It reminds me of some crumpling paper quietly.
We have just purchased two VBrick encoders, which I have configured to encode at one bit-rate, which will deliver the stream to Wowza 1.7.0. We have also purchased 2.2.4, but I will not be able to upgrade before our graduation ceremonies on 11th July
Source Input -> HD/3G-SDI
Video Format -> 1080i/50
Video Aspect Ratio -> 16:9
Resolution -> 656×368
Target Bit Rate (bit/sec) -> 750kb/s
Target Frame Rate (frames/sec) 50
IDR Frame Interval (sec) -> 4 (default setting)
Rate Control Setting -> 3 (default setting)
AAC-HE -> Enabled
L+R Bit Rate (bits/sec) -> 64k
Sample Frequency -> 44.1KHz
I originally had configured the sample frequency to 48KHz. I have recently read the that Flash converts it to 44.1KHz, which causes a delay in the audio. To test this I have re-configured it to encode at 44.1KHz. The stream has been running for approximately 20 minutes, or so now and have not noticed any syncing issues, however I need to test for longer than 20 minutes.
Here’s his second.
I think I have solved my audio syncing issues. I have only realised today that Flash doesn’t support the TV standard audio sample frequency of 48Khz, which is seems a bit poor to me, but there you go. Anyway as mentioned in an earlier post, I originally configured the encoder to have a sample frequency of 48khz. Somewhere in the chain – either Wowza, or the Flash player, it was converted down to 44.1khz. This obviously took a little time, which seems to account for the lag. I was concentrating all my efforts into other aspects of the stream, so missed this.
I have re-configured the encoder with a sample frequency of 44.1khz and been testing for a little over a couple of hours now. All seems fine, but I am paranoid, so will be testing for a few days yet.