The packet for the theora and vorbis  have much closer granules time when using icecast2. When ezstream/icecast2 is used for a live stream the granules are far off. Packet 1392 of audio could sync with packet 234 of the video.

Since I e-mailed the mailinglist last, I tried something different.

I'm taking one second of audio and using the last time stamp of the packet of  that one second interval as the current audio time. Theora is one frame per. packet so, that's easy. Then doing what I said concerning taking the difference be tween the first and the curent packet and using that value as the clock. So, every time I get a new packet from the Ogg stream I say:

audio_time = audio_time - first_audio_time 

The first timestamp after the media headers is greater than zero, I check for this in the code and compensate if it's not the case.

giving me the difference which will initially start at zero and increase. The same being done for the video.Then syncing the two by keeping the video and audio timestamps as close as possible before presenting them to the media device.

This seems to work well, but the ezstream/icecast2 stream is so slow that the buffering in my software causes the audio and video to stagger a lot. It's strange to me that the icecast2 stream alone without using ezstream is very fast and causes no buffering problem in my software.

Does anyone have any idea way ezstream would be so much slower than using icecast2 alone? I'm on ly using a cat <filename> in the ezstream config file.

I really appreciate the help.

Thanks