[Live-devel] Sync problems streaming H.263+ and MPEG4

[Ross Finlayson]

>I'm trying to stream H.263+ and MPEG4 (with MP3) with the LIVE.COM 
>libraries. I want to receive the streams with MPlayer but i'm having 
>several A/V sync problems when viewing (video is ahead of audio).
>
>Although VLC plays these streams correctly, I've been looking into the 
>problem and right now I suspect it's not a problem of MPlayer.

No, I think that MPlayer may well be the problem - it often has problems 
handling A/V sync for RTP streams.  VLC, on the other hand, does A/V sync 
OK, which is one of the reasons why I recommend VLC over MPlayer.

>I've implemented FramedSources to give discrete H.263 frames and MPEG4 
>frames to the respective sinks. I'm feeding the output of my MPEG4 
>FramedSource to the MPEG4VideoStreamDiscreteFramer. If I feed it to the 
>MPEG4VideoStreamFramer, this class seems to calculate correct values for 
>the presentation stamps and I get good synk at the receiver, although this 
>class doesn't parse very well the frames I'm giving it.
>
>My way of calculating the presentation stamp for each frame (H.263+/MPEG4) 
>is based solely on the fps of the video stream. That is, 
>timeperframe=100000/fps. I based this on the code for the 
>ElphelJPEGVideoSource although I suspect that with H.263+/MPEG4 this is 
>not correct...

If you are feeding your video input source into 
"MPEG4VideoStreamDiscreteFramer", then the presentation time of each input 
frame should be the 'wall clock' time (i.e., computed using 
"gettimeofday()")  that the frame was captured.  (Don't try to adjust this 
for B-frames; "MPEG4VideoStreamDiscreteFramer" will do that for you 
automatically.)

If, however, you are feeding your video input source into 
"MPEG4VideoStreamFramer", then the presentation time of the input data 
(which, in this case, need not be discrete frames) doesn't matter.


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>