Hi Ross Thanks for your past help with this.
I now have a trivial but awkward C++ compilation error: PCMSource.cpp: In destructor âvirtual PCMSource::~PCMSource()â: PCMSource.cpp:192: error: invalid conversion from âintâ to âMedium*â PCMSource.cpp:192: error: initializing argument 1 of âstatic void Medium::close(Medium*)â I want to close the socket but have a name conflict with Medium::close(). The old library functions are not in name spaces and I can't figure out how, or find the technique on the web, to use the standard file descriptor/socket close() function rather than the Media::close() method. Is there a simple solution? Martin From: live-devel-boun...@ns.live555.com [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson Sent: 04 May 2012 21:19 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] raw PCM from TCP socket to RTP Martin, First, because you're delivering PCM audio, where the frames are very small, you shouldn't need to modify "OutPacketBuffer::maxSize". (That variable needs to be increased only when you are transmitting media with exceptionally large frames (larger than the default value of 60000 bytes). Because that's not the case for you, I don't recommend changing this value - at least not until you fix your other problems.) I have written PCMSource.cpp, based on DeviceSource.cpp, in which createNew() creates a socket and connects to the remote endpoint, and doGetNextFrame() does the recv() and then calls deliverFrame() to do the memmove(fTo, receivedData). PCMStreamServerMediaSubsession.cpp is based on WAVAudioFileServerMediaSubsession.cpp but the createNewStreamSource() can hardcode the bits/sample, sampling frequency and number of channels information that would normally come from the .wav file header. These new files compile on CentOS 5. Adding an extra section to testOnDemandRTSPServer.cpp to create a stream name allows me to enter the url and reproduce the speech from the original mp3 podcast I'm using to test this with VLC from a Win 7 workstation. Nice; the raw samples are being converted to a recognisable RTP stream. Unfortunately, I am only getting the first second of a minute's worth of audio data. I suggest that you begin by ensuring that your "PCMSource" class is delivering 'correct' data to its downstream object. To do this, I suggest that - rather than starting with a RTSP server (which is a complex application) - you begin by writing an application that feeds a "PCMSource" into a "FileSink". I.e., write a simple application that - creates a "FileSink" - creates a "PCMSource" - calls "FileSink" -> startPlaying("PCMSource", ...) - calls "doEventLoop();" to enter the LIVE555 event loop. Once you've done this, you should be able to look at the output file to figure out whether or not your "PCMSource" is delivering correct data. (Perhaps also add a WAV header to the beginning of the file, and try playing it.) If your "PCMSource" seems to be delivering correct data, then you should next make sure that it's the right size. Because your "PCMSource" will be delivering into a "RTPSink" (subclass) - i.e., packing the data into outgoing RTP packets - you should make sure that "fFrameSize" is large enough for each delivery. Don't just deliver one audio sample at a time. Instead, deliver as much data as you can, up to the limit of "fMaxSize". 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
