[vlc-devel] Re: lip sych problem

[serkan bozkurt]

Hi Victor,

I have cancelled the RTCP part of the liveMedia and
now it seems that lip synch. problem is okey.
Doesn't this show that the RTCP SR's report are bad?
Because if they are okey than synch should be okey.
As far as I know RTCP packets are used for inter media
synch also.


Again I have a few questions:)))

For example think a RTP MP3(128 kbps) streamer(the
most simple one).
Each RTP packet has 20 ms data. So timestamp is 160
for each RTP packet.
We can say that for each 20 ms one RTP packet must be
sent.
But when the network speed slows down(jitter happens)
then what the RTP sender must do?
Sent it in a less periodics from 20ms?
(I think for a some time this period must be less then
the 20ms.
and this value is directly depend on the network
speed. In fact I am a bit mixed on this subject)

Please write your ideas about this subject.

--- Viktor Kompaneyets <vato at wnet.ua> wrote:

> serkan bozkurt wrote:
> 
> > Thanks for your replay Viktor,
> > 
> > I have some questions ,
> > 
> > First; you are saying that network jitter may
> cause
> > lip synch problem.
> > Jitter means the timestamp frequency difference
> > between 2 adjacent
> > rtp packets in the receiver side.
> 
> Should add here - RTP streams are actually 2 (at
> least) different streams
> with different payloads, that are not syncronised
> well (look at live555
> mailing list). I.e - system will "sync on average
> bitrate", not on each
> video packet. It means, that LiveMedia free library
> do not contain
> mechanisms to make A/V sync/resync. Try to add 2
> seconds delay  in stream -
> and all will be OK.   I've made so, trying to
> connect VLC to
> DarvinStreamingServer.
> 
> > if network goes down then timestamp difference
> between
> > adjacent rtp packets will be bigger than the
> previous
> > one.
> > This may cause starvation on the receiver side
> buffers
> > because datas are late!
> > But after network is okey from the RTCP SR
> > timestamps(they are sent periodically), lip synch
> must
> > be ok isn't it?
> 
> No. RTP streams with different payloads have
> different sync rate. The
> streams may contain real timecode, but (IMHO) the
> timecode is replaced with
> "timestamps" to avoid complexity, that causes
> different timestamps for
> different RTP substreams. 
> 
> 
> > 
> > Second problem:Why bid rtp packets may result in
> > buffer starvation
> > on the reiver side can you please explain.
> 
> Large packets are sended in parts (fragments). In
> some situations these
> fragments can reach receiver side with jitter, that
> can break packet
> assemble. This packet will be dropped. Most common
> reccomendation - reduce
> packet size to MTU munus 50-60 bytes, to avoid
> packet fragmentation. Or
> check, (in GigEthernet environment) if your network
> cleanly support
> Jumbo-frames.
> 
> > 
> > Third one :
> > For the time being live55.com is inactive but I
> know 2
> > days ago it was okey.
> > Do you have any idea about this.
> 
> No idea :(
> -- 
> Viktor Kompaneyets
> Wnet project manager
> 
> -- 
> This is the vlc-devel mailing-list, see
> http://www.videolan.org/vlc/
> To unsubscribe, please read
> http://developers.videolan.org/lists.html
> 
> 



		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free. 
http://music.yahoo.com/unlimited/

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html