[Red5] R: R: unequal delay on audio and video

[Daniele Bettella]

Cancel the previous message, I forgot to enable the interleaving of packets...
Apparently I still need to understand how to correlate the stream timebase and the audio frame duration...

Da: red5-bounces at osflash.org [mailto:red5-bounces at osflash.org] Per conto di Daniele Bettella
Inviato: martedì 24 novembre 2009 17.58
A: red5 at osflash.org
Oggetto: [Red5] R: unequal delay on audio and video


Ok, I was able to calculate my timestamps based on the code in the mp3 header; it all works fine for the first minutes, but after a while I begin to notice a little delay on audio. I think this could be because the frame duration is calculated as

576 / (getSampleRate() * 0.001)

Inevitably this is not an integer, but the set dts requires one.

So whatever I do (and based on the stream timebase, which is 1/90000) I'll need to transform a double into a long and hence introduce error...

And my audio will not be in sync.



I suppose there's a solution to this, but what is it?



Daniele


Da: red5-bounces at osflash.org [mailto:red5-bounces at osflash.org] Per conto di Andy Shaules
Inviato: lunedì 23 novembre 2009 17.14
A: red5 at osflash.org
Oggetto: Re: [Red5] unequal delay on audio and video

You should base your timestamps on the mp3 frame durations, not guesses.

Look at the MP3Header class in the red5.io.mp3 package. Use the class to determine each duration.
----- Original Message -----
From: Daniele Bettella<mailto:daniele.bettella at newvision.it>
To: red5 at osflash.org<mailto:red5 at osflash.org>
Sent: Monday, November 23, 2009 3:05 AM
Subject: [Red5] unequal delay on audio and video

I'm using Xuggle to publish an H264/mp3 live stream on red5. Audio and video are already encoded when they get to xuggle, so I do no transcoding, I just pass the packets on to red5.
Now, if I stream video only I have a small delay, around 0.3 secs, I don't know where it comes from, but it's either in xuggle/red5 or the player (which has a buffer of zero, btw). I could live with this delay (well, sort of), problem is, when I stream audio too this has a delay of little less than one second, resulting in audio and video not in sync.
So came the idea to force interleaving of packets (that is, using container.writePacket(packet, true)). This meant adjusting dsts by hand, since my packets had no timestamps to start with. This brought two problems:


1)      I know how to adjust timestamps on video packets (since I have one frame per packet), but I had to guess on audio packets;

2)      My best guess resulted in audio and video in sync (at least for the first minutes), but with a delay of one second which grew when insufficient bandwidths came out (streaming locally). Which is no good at all.

What I'd really like would be to minimize and balance the delays when non interleaving packets in xuggle, because that's the way I have had the best results.

Also to note: if I stream video only at 15fps instead of 30fps the delay grows from .3 to .8 seconds (which, as a side effect, make audio and video in sync if I add it).

I'd really love to figure out where these delays come out from.
Thanks in advance.

Daniele

P.S.
I'm sending this on osflash for now, since my membership on the official group is pending
________________________________
_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20091124/b78415b1/attachment-0001.html>