unequal delay on audio and video

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

unequal delay on audio and video

Daniele Bettella

I’m using Xuggle 3.3 to publish an H264/mp3 live stream on red5 0.9rc2. 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

 

Reply | Threaded
Open this post in threaded view
|

R: unequal delay on audio and video

Daniele Bettella

I need to make a correction. I just made a test: the delay on audio is not created by xuggle/red5, but by the encoder!

I’ll have to look into the problem a bit more.

 

Da: Daniele Bettella [mailto:[hidden email]]
Inviato: lunedì 23 novembre 2009 12.19
A: [hidden email]
Oggetto: [Red5] unequal delay on audio and video

 

I’m using Xuggle 3.3 to publish an H264/mp3 live stream on red5 0.9rc2. 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