vlc 2.07, audio 500ms ahead of video, VLC 1.x ok

[nobody.loopback]

I use VLC for MacOSX (10.6) to transcode a DVB stream to X.264 baseline + mp4 audio latm. With VLC 1.X (1.1.10) the parameter "audio-sync" works perfect. Audio is always correct.
With VLC 2.0.7, the audio is always ahead of the video. I tried to add "--audio-desync=-500" but this has no effect.

example transcode string:

Code: Select all

--sout '#duplicate{dst="transcode{vcodec=h264,vb=450,fps=24,width=480,height=320,venc=x264{profile=baseline,keyint=24},acodec=mp4a,ab=64,channels=1,audio-sync,samplerate=44100}",select="es=511,es=515"}:rtp{mp4a-latm,dst=127.0.0.1,port-audio=20006,port-video=20008,ttl=127,sdp=file:///Library/QuickTimeStreaming/Movies/something.sdp}'

While I am currently happy with VLC1.x, I observed that that VLC2 will use less CPU on my machine and give a slightly better video quality, so if I would be able to fix the audio problem, that would be great.

The values of transcode string regarding the keyint values are rather a result of experiments then real knowledge, however it currently works very reliable, also the reference client (blackberry OS V5) is not able to accept a different x264 profile then baseline, and no other codec then mp4/aac, and, not more then 30fps.

There is also a problem that with VLC v2, I wont get a picture on the client, it only starts buffering (with vlc v1, the picture starts immediately). Display works with VLC as a client, but it takes more then 30seconds until the picture appears.

Any Idea on this ?
Thanks.

[nobody.loopback]

Followup: With vlc 2.0.7 I observed, that I sometimes have audio in the stream which comes from a previous transcoding session.

I guess, this relates to the built in timeshift ?
So, I added "--input-timeshift-granularity=0", however, the timeshift buffer is still 1MB, if I add "--input-timeshift-granularity=-1" then the buffer is 50MB. Is there a way to completely disable timeshift for transoding ?