[openbeos] Re: Solution to MediaKit sync issue resolved
- From: "David McPaul" <dmcpaul@xxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 30 Jun 2004 20:18:33 +1000 EST
> "Solaja, Zenja" <solaja@xxxxxxxxxx> wrote:
> > It seems that the issue is with decoding a BMediaTrack, and its
> > method
> > DecodedFormat(). When you perform a SeekToTime(bigtime_t), it
> > misjumps by a
> > factor of 1024/1000. Also, the DecodReadFrame or ReadChunk()
> > members
> > of
> > BMediaTrack will as a consequence read 1024/1000 bytes when passing
> > it to
> > BSoundPlayer. To resolve audio sync issues, all you need to do is
> > manually
> > adjust bigtime_t when seeking by:
> >
> > time *= 1000/1024;
> > SeekToTime(time);
>
> How can you know that the current media file has sync issues?
> I've several files that play perfectly with the BeOS Media Player;
> adapting the seek time for them doesn't sound like a good idea. Also,
> you don't seek everytime, and the streams can get asynchronous by
> viewing them only.
Are they short or long media clips? I am pretty sure you will not
notice any sync issues over a short clip. Longer durations clips is
usually where the problems are noticed.
The issue is where does the problem occur. If SOME decoders are using
1024 and OTHER decoders use 1000 then we cannot globally adjust (unless
we can detect which decoders do what).
BUT if the issue is at the media framework level then we can globally
adjust I guess for the R5 code. Since this sort of issue would be
fixed in the Haiku media kit.
However, the test case that I have here, shows media sync issues using
the same decoder.
I have 2 AVI encodes using the RAW audio decoder The video is PAL 25
fps
One is encoded at 16bit 48 kHz
the other at 16bit 44.1 kHz
The first plays fine but the second one gets out of sync very quickly.
So same decoder but different audio frame rates.
Also it is not seeking that causes the issue. if I use the slider to
seek I can correct the issue but over time the audio will drift.
I am trying to remember a discussion about how certain audio framerates
don't match video framerates so you get drift over time but I am not
sure that is the case here. I think the issue here is that the 48.1
kHz is being converted to another frequency and there is a error
somewhere in that.
I guess what I am trying to say is that I don't see SeekToTime being
used here and it is the same decoder so both should show the sync
issue.
Cheers
David
--
... If forced to travel on an airplane, try and get in the cabin with
the Captain, so you can keep an eye on him and nudge him if he falls
asleep or point out any mountains looming up ahead ...
-- Mike Harding, "The Armchair Anarchist's Almanac"
Other related posts:
