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 between 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 only using a cat <filename> in the ezstream config
file.
I really appreciate the help.
Thanks
----- Original Message ----
From: Conrad Parker <conrad at metadecks.org>
To: Jim Smith <jimjim197 at yahoo.com>
Cc: theora-dev at xiph.org
Sent: Sunday, June 22, 2008 7:48:17 PM
Subject: Re: [theora-dev] syncing a live stream
2008/6/23 Jim Smith <jimjim197 at yahoo.com>:> Hi,
>
> When I sync the a/v with just an icecast2 stream I'm starting at the
> beginning of the stream so it's simpler. But, when I read the stream
from
> icecast2/ezstream I get the stream after the beginning and the a/v timing
on
> the packets need to be handled differently. Does anyone know what approach
I
> should take to sync the live stream? There has to be some generic
high-level
> logic for an OGG stream.
In what way is the a/v timing incorrect in your current
implementation? Can you give an example of the timestamps in the
resulting Ogg stream?
Conrad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/theora-dev/attachments/20080624/df0228df/attachment.htm