[Live-devel] **EXTERNAL**Re: Adding UDP Video to an Audio RTSP URL coming from an AXIS encoder in the same stream doesn't work

[Ross Finlayson]

> On Nov 8, 2023, at 12:49 PM, Eric Eastman <Eric.Eastman at AITEngineering.com> wrote:
> 
> I was able to update to the latest live555. Here is the output from openRTSP and the audio file output. Every player I use says it's corrupted and doesn't understand the compression.

Hold on.  You said before that if your “ServerMediaSession” contained only the “ServerMediaSubsession” for audio, but not the “ServerMediaSubsession” for video, then your media player (RTSP client) was able to play the audio OK.  Is that still the case?

If that’s the case, then it’s unlikely that “every player [you] use” is now (for the combined audio+video session) telling you that "it's corrupted and doesn't understand the compression”.  Instead, it’s more likely that the problem is something about your *combination* of the audio and video streams, not the audio stream (or the video stream) per se.

My guess is that the problem is that your audio and video streams have wildly different presentation times, which would come about if your audio and video sources have clocks that are badly out of sync.

So, my suggestion is to make sure that:
	1/ Your Axis encoder (that contains the server that’s generating the back-end audio stream),
and
	2/ The computer for your RTSP server
have clocks that are roughly ‘in sync’ - i.e., generate similar ‘wall clock’ times (the times that you’d get by calling “gettimeofday()”)


> I also tested with the -4 option and piped it to a test.mp4. The test.mp4 has video but no audio.

OK, but the audio (PCM u-law) is still valid (PCM u-law), because the following still produces a playable audio file:
	ffmpeg -f mulaw -ar 8000 -ac 1 -i audio-PCMU-2 test.wav

(In any case, we’re now approaching the limit for how much support I can continue to give to your project ‘for free’ on this mailing list…)


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/