[Live-devel] openRTSP woes

Shawn Van Every vanevery at walking-productions.com
Wed May 20 06:42:24 PDT 2009


Thanks Ross.

The audio/video are in sync when viewing the actual stream in  
QuickTime (haven't tried VLC).  Interestingly enough, we are doing  
another process which converts the RTSP stream to RTMP (Flash) and we  
see a consistent half second sync issue after that process.  The  
interesting part is that this isn't the same behavior that we see with  
the openRTSP recordings.

I hear you regarding capturing to MP4/MOV files. Do you think that  
capturing to raw files and then putting them together using another  
process would yield better results?

-s

> Message: 8
> Date: Tue, 19 May 2009 15:52:31 -0700
> From: Ross Finlayson <finlayson at live555.com>
> Subject: Re: [Live-devel] openRTSP woes
> To: LIVE555 Streaming Media - development & use
> 	<live-devel at ns.live555.com>
> Message-ID: <f06240804c638e2a78d51@[66.80.62.44]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
>> The second issue that we have run into is with audio/video sync.
>> Right now, at the beginning of many of the recorded files, we are
>> seeing very fast video with normal speed audio which I think is the
>> culprit.  This lasts for less than a second.  (Using the -y flag
>> seems to help but it throws away audio data making our audio very
>> bad)  Is it possible this occurs until the first keyframe is seen?
>>
>> We are encoding at full resolution and full framerate from these  
>> cams:
>>
>> openRTSP -q -f 30 -w 1280 -h 720 -t -Q -b 2000000
>> rtsp://10.10.10.10/axis-media/media.amp?videocodec=h264&resolution=1280x720&audio=1&duration=0&fps=30&videobitrate=10000&videomaxbitrate=10000&videobitratepriority=framerate&videokeyframeinterval=2&compression=10&color=1&clock=0&date=0&text=0
>
>
> First, you should make sure that you are seeing properly synced audio
> and video when you play the stream directly, using (e.g.) VLC.  If
> (for whatever reason) you're not getting A/V sync when you play the
> stream directly, then you will never be able to get A/V sync when you
> record the data into a file.
>
> Second, it's important to realize that the ".mov" (or ".mp4") file
> format is badly designed, and is poorly suited for recording live
> input streams (like these).  One basic problem with the file format
> is that it records audio/video data using sample/frame *durations*,
> rather than timestamps (or presentation times).  This makes it very
> difficult to keep audio/video data in sync, if the input data is
> synchronized using presentation times, as is the case for incoming
> RTP/RTCP data.  Because of this, the current implementation of
> writing ".mov" or ".mp4" files is - and will likely always remain -
> an unreliable hack.
>
> If you want to have any chance of A/V sync working when writing
> ".mov" or ".mp4" files, then you *must* use the "-y" option.  This
> may lose a small amount of initial data (until RTCP synchronization
> begins), but that's unavoidable.
>
> If you really want to look at the appropriate code for this, then the
> class to look at is "QuickTimeFileSync".
> -- 
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/


More information about the live-devel mailing list