<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<STYLE>.hmmessage P {
PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px
}
BODY.hmmessage {
FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>
<META content="MSHTML 6.00.2800.1555" name=GENERATOR></HEAD>
<BODY class=hmmessage bgColor=#ffffff>
<DIV><FONT face=Arial>Hi Thomas, Thomas and Ratmin.. :)</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Back to work form a long abroad weekend (nice
Belgium!)</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>As Ratmin has stated the Skew indication would help
to indicate the handset the delay between audio and video.</FONT></DIV>
<DIV><FONT face=Arial>It's usually used to correct fixed delays introduced by
internal jitter buffers and thinks alike. The problem that Thomas</FONT></DIV>
<DIV><FONT face=Arial>Z. is </FONT><FONT face=Arial>suffering seems to be
produced by using ffmpeg for video encoding (as Thomas without Z points
:)</FONT></DIV>
<DIV><FONT face=Arial>The problem is the following, ffmpeg is a great VBR
(variable bit rate) encoder, but I've not been able to behave like a
</FONT></DIV>
<DIV><FONT face=Arial>CBR (constant bit rate) encoder. The problem is that it's
prepared for movies, not for streaming, and defenitevilly not</FONT></DIV>
<DIV><FONT face=Arial>at this low bitrates.</FONT></DIV>
<DIV><FONT face=Arial>The inner loop of the encoder always tries to encode ALL
macroblocks in a frame, so in I frames and at a very low</FONT></DIV>
<DIV><FONT face=Arial>bitrate it simply just can't get a small amount of data
for that frame and when it's enqued into h324m it takes more</FONT></DIV>
<DIV><FONT face=Arial>than one frame time to send (sometimes even more than a
second), the following frames are small and sent after</FONT></DIV>
<DIV><FONT face=Arial>that until the queue is empty, which causes a fast-forward
effect on some handsets. As you can imagine adjustime</FONT></DIV>
<DIV><FONT face=Arial>audio to that scenary is jus impossible (even with the
Skew Indication the result would be horrible!!)</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>The good solution: use a CBR encoder :)</FONT></DIV>
<DIV><FONT face=Arial>The not so good solution: drop packets when the queue is
filled, but you'll end up dropping all the frames between</FONT></DIV>
<DIV><FONT face=Arial>each I frame.. but in that case it would be much
better to lower the video fps...</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>BR</FONT></DIV>
<DIV><FONT face=Arial>Sergio</FONT></DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=keytwho@hotmail.com href="mailto:keytwho@hotmail.com">Ramtin Amin</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
title=asterisk-video@lists.digium.com
href="mailto:asterisk-video@lists.digium.com">Development discussion of video
media support in Asterisk</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, September 24, 2007 2:01
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [Asterisk-video] MP4Play
async Audio / Video</DIV>
<DIV><BR></DIV><BR><BR><BR>RTSP has timestamp... so you can usually know how
to sync the audio/video<BR>But the problem would be more that we'll need to
add a Skew Indication concept inside asterisk's core so it could make the
message go throught the different channel/application, as it is currently done
for VideoFastUpdatePicutre... Which means that currently, if a SIP channel
receives a VideoFastUpdatePicture, it is capable of resending it to an other
channel...<BR><BR> <BR>
<HR id=stopSpelling>
<BR>> Date: Mon, 24 Sep 2007 13:48:54 +0200<BR>> From:
mobilemail@gmx-topmail.de<BR>> To: asterisk-video@lists.digium.com<BR>>
Subject: Re: [Asterisk-video] MP4Play async Audio / Video<BR>> <BR>>
Hello Ramin,<BR>> hello Thomas.<BR>> <BR>> I think both ways are
possible. But I don't know if it easy to implement.<BR>> Sergio, what do
you think about it?<BR>> <BR>> Is this also a problem if we stream the
audi/video via rtsp?<BR>> <BR>> Regrads<BR>> Thomas<BR>> <BR>>
<BR>> Ramtin Amin schrieb:<BR>> > hello<BR>> > <BR>> >
The way I solved this problem was by sending a H223SkewIndication<BR>> >
message to the other terminal<BR>> > Acutally, You will have to ask
Sergio to add a H245 indication message<BR>> > of type
h223SkewIndication and when playing the video with mp4play, he<BR>> >
will have to see the difference of timing between Video and Audio and<BR>>
> then send this value to the remote terminal so the lip sync would
work...<BR>> > <BR>> > <BR>> > <BR>> > **<BR>>
><BR>> > *2.3 Multipoint Lip Synchronization*<BR>> ><BR>>
> In a multipoint VC, each terminal may transmit different<BR>>
><BR>> > //<BR>> ><BR>> > /H223SkewIndication /message
for associated video and<BR>> ><BR>> > audio channels in H.223
protocol. To enable lip<BR>> ><BR>> > synchronization at receiving
terminals, MCUs will<BR>> ><BR>> > transmit accurate
/H223SkewIndication /messages. MCUs<BR>> ><BR>> > may accomplish
this by adding delay to equalize the<BR>> ><BR>> > audio/video
skew for all transmitting terminals. When<BR>> ><BR>> > switching
between broadcasting terminals, H.223 may<BR>> ><BR>> > transmit a
new /H223SkewIndication /message reflecting the<BR>> ><BR>> >
audio/video skew of the current broadcaster.<BR>> > <BR>>
><BR>> > -- <BR>> > Ramtin Amin<BR>> ><BR>>
><BR>> ><BR>> > <BR>> >
------------------------------------------------------------------------<BR>>
><BR>> > > From: thomas.frieling@viif.de<BR>> > > To:
asterisk-video@lists.digium.com<BR>> > > Date: Mon, 24 Sep 2007
11:48:12 +0200<BR>> > > Subject: Re: [Asterisk-video] MP4Play async
Audio / Video<BR>> > ><BR>> > > Hi Thomas Z!<BR>> >
><BR>> > > I think this problem is due to the bitrate restriction
on 3G calls. The<BR>> > > audio stream is always sent immediately
while the video stream has to<BR>> > > use what is left of the
bandwidth. This is why videos become synchrous<BR>> > > again when
the video bitrate is pretty low for a while in the video...<BR>> >
><BR>> > > Take a look at this discussion:<BR>> >
><BR>> >
http://lists.digium.com/pipermail/asterisk-video/2007-September/001257.html<BR>>
> ><BR>> > > One solution is to reencode every video with a low
bitrate and use a<BR>> > > fixed bitrate encoder (ffmpeg is dynamic
bitrate for example). I had the<BR>> > > impression though that this
still doesn't always work, especially when<BR>> > > the UMTS
connection is not too good...<BR>> > ><BR>> > > My idea is
that we check each time before sending a keyframe if there is<BR>> >
> already a new keyframe in the queue. If this is the case, we jump to
the<BR>> > > most recent keyframe and just drop the data before
that.<BR>> > ><BR>> > > What do you think about this? How
hard to implement?<BR>> > ><BR>> > > Regards,<BR>> >
> Thomas F<BR>> > ><BR>> > ><BR>> > ><BR>>
> > Am Montag, den 24.09.2007, 11:15 +0200 schrieb Thomas Z.:<BR>>
> > > Hello,<BR>> > > ><BR>> > > > We have
the problem, that a converted mp4 file is asynchronous via 3g<BR>> >
> > network.<BR>> > > > If we play the file on a pc,
everything is synchron.<BR>> > > > We tried already to reduce the
quality and framerate of the video. But<BR>> > > > nothing
helps.<BR>> > > ><BR>> > > > Is it a problem with
mp4play or with the video?<BR>> > > ><BR>> > > > What
can we do to get the audio and video synchronized via 3g network?<BR>> >
> ><BR>> > > > Thank you,<BR>> > > > best
regards<BR>> > > > Thomas<BR>> > > ><BR>> > >
><BR>> > > ><BR>> > > >
_______________________________________________<BR>> > > >
--Bandwidth and Colocation Provided by http://www.api-digital.com--<BR>>
> > ><BR>> > > > asterisk-video mailing list<BR>> >
> > To UNSUBSCRIBE or update options visit:<BR>> > > >
http://lists.digium.com/mailman/listinfo/asterisk-video<BR>> > >
--<BR>> > > www.ViiF.de - your Mobile Video Community<BR>> >
><BR>> > >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>> > ><BR>>
> > Thomas Frieling - IT Development<BR>> > > ViiF Mobile Video
GmbH, Poststr. 21-22, 10178 Berlin<BR>> > > Cell: +49 (0) 173 63 62
62 3<BR>> > ><BR>> > > mailto:thomas@ViiF.de<BR>> >
><BR>> > > Sitz: Berlin, Amtgericht Berlin-Charlottenburg, HRB:
108350B<BR>> > ><BR>> > > Geschäftsführer: Daniel Höpfner,
Steffen Brünn<BR>> > ><BR>> > >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>> > ><BR>>
> > _______________________________________________<BR>> > >
--Bandwidth and Colocation Provided by http://www.api-digital.com--<BR>>
> ><BR>> > > asterisk-video mailing list<BR>> > > To
UNSUBSCRIBE or update options visit:<BR>> > >
http://lists.digium.com/mailman/listinfo/asterisk-video<BR>> ><BR>>
><BR>> >
------------------------------------------------------------------------<BR>>
> Besoin d'un e-mail ? Créez gratuitement un compte Windows Live
Hotmail<BR>> > et bénéficiez d'un filtre antivirus gratuit ! Windows
Live Hotmail<BR>> >
<http://www.windowslive.fr/hotmail/default.asp><BR>> >
------------------------------------------------------------------------<BR>>
><BR>> > _______________________________________________<BR>> >
--Bandwidth and Colocation Provided by http://www.api-digital.com--<BR>>
><BR>> > asterisk-video mailing list<BR>> > To UNSUBSCRIBE or
update options visit:<BR>> >
http://lists.digium.com/mailman/listinfo/asterisk-video<BR>> <BR>>
<BR>> _______________________________________________<BR>> --Bandwidth
and Colocation Provided by http://www.api-digital.com--<BR>> <BR>>
asterisk-video mailing list<BR>> To UNSUBSCRIBE or update options
visit:<BR>>
http://lists.digium.com/mailman/listinfo/asterisk-video<BR><BR><BR>
<HR>
Besoin d'un e-mail ? Créez gratuitement un compte Windows Live Hotmail, plus
sûr, plus simple et plus complet ! <A
href="http://www.windowslive.fr/hotmail/default.asp" target=_new>Windows Live
Hotmail</A>
<P>
<HR>
<P></P>_______________________________________________<BR>--Bandwidth and
Colocation Provided by http://www.api-digital.com--<BR><BR>asterisk-video
mailing list<BR>To UNSUBSCRIBE or update options visit:<BR>
http://lists.digium.com/mailman/listinfo/asterisk-video</BLOCKQUOTE></BODY></HTML>