> On Nov 8, 2023, at 12:49 PM, Eric Eastman <eric.east...@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/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
