<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Dan,<br>
<br>
Lip sync?? jeje.. good one.. ;)<br>
<br>
Let's start with the bad news there is no audio/video sync mechanism in
asterisk (as we comment in a previous mail), the good news are that if
you have two synced media streams input in asterisk, the two media
streams outputs are going to be synced.<br>
<br>
So let's go for the source, app_mp4. As Emmanuel says in another mail,
the hint track marks the timing for the rtp packets to be sent, so if
the source i synced, app_mp4 will play it synced.<br>
The bad news is that mp4 files are prepared for streaming, not for been
transmitted on a fixed rate channel and played on a live, non-buffered
player. So, what's the problem?<br>
First, app_h324m does nothing with the sync, it just receives the
packets from asterisk, extract the media and send it to the h324m
library, so far so good.<br>
<br>
The h324m library has a small jitter buffer, and it does not start
sending until it has a minimum of data on it (3 packets if I remember
correctly), so it introduces a small delay. Why? because if audio data
is not sent with an almost perfect timing the mobile phone will suffer
an audio under run and the audio will be crappy. But 3 packets are
60ms, so not much to worry.<br>
When the jitter has enough data it starts sending audio at a fixed
rate, and audio data will have preference over video, so the audio will
be constantly played, no variable delays introduced.<br>
<br>
Video is another issue, the biggest problem are the encoders. Most of
them, ffmpeg at least, are not constant bitrate encoders. So they will
produce a very big IFrame followed by small PFrames. What's the problem
with that? The ISDN can't send faster, so a variable delay will be
introduced on video depending on the size of the frame.<br>
<br>
What happens then? Did you remember that we said that audio and video
were RECEIVED synced on the app_h324m application? So when you sent the
audio and video frame to the h324m library they are still synced, and
even the h324m library starts sending it almost synced. But the amr
arrives much more faster than the video, that depending on the size
could take almost a second to be sent depending on the video bitrate.<br>
<br>
What do mobile phones do? Usually a best effort approach, as soon as
they receive audio, they play it. As soon as they receive the a video
frame they decode and display it. That is the reason why sometimes a
video plays faster than it should be for a while (several frames have
been enqueued, been the latest very small, and they are received by the
mobile phone almost at the same time).<br>
<br>
What can be done? not much, buffering will introduce an unacceptable
delay in a person to person communication, so the only good solution is
to be ale to have a CBR h263 encoder that outputs always the same
amount of data for each frame. That way a fixed delay will be
introduced in video and by adjusting the jitter the synchronization we
could be almost perfect.<br>
<br>
Best regards!<br>
Sergio<br>
<br>
Dan Julius escribi&oacute;:
<blockquote
 cite="mid:131b8bd40811111255l7556faben1240b4c8e5b7ea31@mail.gmail.com"
 type="cite">
  <div dir="ltr">
  <div>Hi,</div>
  <div>&nbsp;</div>
  <div>Is there a good reference to better understand how audio/video
synchronization is handled in h324m?</div>
  <div>&nbsp;</div>
  <div>I'm using mp4_play to play a file I created following the mp4
mini tutorial. I combined an h263 track with a g711 track,</div>
  <div>I've noticed that by modifying the bitrate of the video channel
I can get different results, but all of them have lip-sync issues.</div>
  <div>&nbsp;</div>
  <div>where is the av sync supposed to be handled, in the mp4 file, by
libh324m, or the 3g handset?</div>
  <div>&nbsp;</div>
  <div>Thanks for the advice,</div>
  <div>Dan</div>
  <div>&nbsp;</div>
  </div>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
--Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>--

asterisk-video mailing list
To UNSUBSCRIBE or update options visit:
   <a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-video">http://lists.digium.com/mailman/listinfo/asterisk-video</a></pre>
</blockquote>
<br>
</body>
</html>