Audio / Video sync issue - audio leads by a few seconds while video is delayed.

[Jinn_Koriech]

I have a live stream coming in that is transcoded in VLC/1.1.7. At this point if I view the stream directly from VLC with a player over RTSP such as QuickTime or VLC the audio & video are in perfect sync and never skew. These streams are transcoded to 30fps with something along the lines of the following VLC transcode profile:

#transcode{thread=4,vb=512,fps=30,width=360,height=202,vcodec=h264,venc=x264{cqm=flat,level=30,keyint=90,bframes=0,ref=2,me=umh,weightp=0,subq=6,no-8x8dct,trellis=0,no-interlaced,no-mbtree,no-weightb,vbv-bufsize=8192},audio-sync=1,acodec=mp4a,ab=64}:rtp{dst=127.0.0.1,port=39335,port-video=39336,port-audio=39334,sdp=file:///usr/local/WowzaMediaServer/content/app/stream.sdp}

When the stream is viewed via Wowza a variable skew of between 3 to 5 seconds is introduced. I have tried WMS 2.2.3, 2.2.3patch3, 2.2.2, 2.1.0. All show the same behaviour.

When compared to the good direct stream side by side the stream via WMS has audio at almost exactly the same time while the video is is lagging behind.

I suspect this may be related to the frame rates on the source stream. I believe the original source upstream is 1080i@59.94fps. This is transcoded to 1080p@29.97fps for us, which is what we feed to VLC:

Stream #0.1[0x45]: Video: mpeg2video, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 17000 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc

When I transcode to 30fps the audio is always skewed by 3 to 5 seconds. If I transcode to 60fps there is no audio-video skew about a third of the time. Unfortunately 60fps is just too much for both the transcoder and flash to handle.

I have a feeling it’s related to the tbr, tbn, tbc values, but haven’t been able to find much information on these.

I found references on the forum to debug AAC timecode issues and found there is no difference as defined in that thread, so as I understand it there should be no drift.

I have tried adjustments to systemclock. The rtptimecode option results in very choppy sound. systemclock seems to give the best result, but still not perfect.

I have tried with and without flushInterval=25 as defined here.

I have tried sortPackets=true as defined here.

I’ve tried forcing an --audio-desync in VLC to compensate, but the skew appears to be variable when it comes out of WMS, even though it never skews when played directly from VLC.

At this point I’m now at a complete loss on how to proceed further with this issue.

[Charlie_Good]

I am not sure how to help. This is some type of encoding issue. You might try a different encoder. Try baseline profile. Looks like you are not encoding B-frames which is good.

Charlie

[Jinn_Koriech]

Ok. Problem is solved, though the exact reason is still unclear unfortunately.

Initially we were compiling, on Ubuntu 10.04.2, our own vanilla version of the latest VLC (1.1.7 at time of writing) with manually pulled down and compiled latest dependencies needed for our case. I also tried various versions and dependencies without any luck.

In the end I created an LXC instance of gentoo on the same box and built the latest version of VLC, again v1.1.7, with the necessary dependencies for our setup. This compile of VLC works without the a/v skew, sending over the network to the exact same WMS-2.2.3 instance. All the command lines for the transcode remain identical.