Re: Panasonic Camera Streaming MJPEG Video with G.726 Audio
Posted: 19 Feb 2010 01:37
The raw audio data that openRTSP captures and stores can be converted into a playable wav file with a few utilities on a Linux machine, but it takes a bit of effort. Some of the same information is posted on a few other forums but it deserves to be here too so that those who are trying to find a way to get the audio stream data from a Panasonic IP cam won't have to go hunting for it. Maybe it will also give the VLC developers some ideas about how to consume and transcode the audio in spite of the sketchy support in openRTSP.
First, the raw audio data is apparently not encoded by the camera in a way that is expected by the generally available codecs, so someone wrote a command line utility called decode-g72x that does an initial conversion into a format that can be consumed more easily. The source code for that is at http://www.ps-auxw.de/g72x++.tar.bz2 You have to do the usual download, unpack, read the build instructions, compile, and put the binary somewhere you can execute.
Next, the output from decode-g72x has to be fed into the linux sox command to output a wav format audio file.
The entire piped set of commands goes as follows:
cat <infile> | decode-g72x -64 -l -R | sox -r 8000 -w -c 1 -s -t raw - -t wav <outfile>.wav
decode-g72x parameters
* -64 specifies to Process G.726 32kbps (4-bit) input data
* -l specifies to Generate 16-bit linear PCM data
* -R specifies that G.726 samples are right packed (Note: this seems to be the key non-standard encoding issue)
sox parameters:
* -c 1 specifies 1 audio channel
* -w specifies 16bit "word" samples
* -s specifies "signed linear" data
* -t raw specifies raw input data, no header
* - is a place-holder for streamed input
* -t wav specifies the output file format.
Note that <infile> must be just the raw audio data. By default, openRTSP, when run on the command line, will output a separate file for each stream. If the -4 switch is used, the video and audio from the Panasonic camera will be muxed into an MP4 file, so the audio would need to be demuxed into a separate file. That turns out to be somewhat tricky since most tools like ffmpeg refuse to do anything with the audio atom in the MP4 file that has a format-type / fourcc of "????". Since I already had quite a few captures stored that way, I ended up writing my own QT atom parser to extract the audio chunks from the MP4 into another file that could be used with decode-g72x. So, I'd recommend starting with openRTSP capturing streams to separate files. Then convert the audio. Then use something like ffmpeg to mux the audio and video together into a file playable in VLC.
Note: Sometimes VLC manages to play audio directly from the camera, but it is very choppy and seems to die after a minute or two. It's a hassle to pipe the audio through these other utilities, but I was happy to at least find a way to convert the raw audio into something usable. Hope this helps or inspires. I'd still rather have a nice point, click, and play, re-stream, or record solution.
First, the raw audio data is apparently not encoded by the camera in a way that is expected by the generally available codecs, so someone wrote a command line utility called decode-g72x that does an initial conversion into a format that can be consumed more easily. The source code for that is at http://www.ps-auxw.de/g72x++.tar.bz2 You have to do the usual download, unpack, read the build instructions, compile, and put the binary somewhere you can execute.
Next, the output from decode-g72x has to be fed into the linux sox command to output a wav format audio file.
The entire piped set of commands goes as follows:
cat <infile> | decode-g72x -64 -l -R | sox -r 8000 -w -c 1 -s -t raw - -t wav <outfile>.wav
decode-g72x parameters
* -64 specifies to Process G.726 32kbps (4-bit) input data
* -l specifies to Generate 16-bit linear PCM data
* -R specifies that G.726 samples are right packed (Note: this seems to be the key non-standard encoding issue)
sox parameters:
* -c 1 specifies 1 audio channel
* -w specifies 16bit "word" samples
* -s specifies "signed linear" data
* -t raw specifies raw input data, no header
* - is a place-holder for streamed input
* -t wav specifies the output file format.
Note that <infile> must be just the raw audio data. By default, openRTSP, when run on the command line, will output a separate file for each stream. If the -4 switch is used, the video and audio from the Panasonic camera will be muxed into an MP4 file, so the audio would need to be demuxed into a separate file. That turns out to be somewhat tricky since most tools like ffmpeg refuse to do anything with the audio atom in the MP4 file that has a format-type / fourcc of "????". Since I already had quite a few captures stored that way, I ended up writing my own QT atom parser to extract the audio chunks from the MP4 into another file that could be used with decode-g72x. So, I'd recommend starting with openRTSP capturing streams to separate files. Then convert the audio. Then use something like ffmpeg to mux the audio and video together into a file playable in VLC.
Note: Sometimes VLC manages to play audio directly from the camera, but it is very choppy and seems to die after a minute or two. It's a hassle to pipe the audio through these other utilities, but I was happy to at least find a way to convert the raw audio into something usable. Hope this helps or inspires. I'd still rather have a nice point, click, and play, re-stream, or record solution.
