On Wed, Sep 9, 2009 at 5:50 PM, Ross Finlayson <finlay...@live555.com>wrote:
> I believe this because VLC is incorrectly reporting the # of bits per
>> sample as 16, and that's the only inheritance hierarchy I can see that
>> clearly communicates such a value. Is that correct?
>>
>
> What RTP payload format are you delivering to the client? u-law ("PCMU")?
> "L8"? Or "L16"? Only the last is 16-bits-per-sample. Once again, look
> closely at the "WAVAudioFileServerMediaSubsession" code for a model.
>
>
Here's how I implemented the subsession methods:
RTPSink * LiveG711MediaSubsession::createNewRTPSink(Groupsock
*rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource
*inputSource)
{
char const* mimeType = "PCMU";
unsigned char payloadFormatCode = 0;
int sampleFrequency = 8000;
unsigned int numChannels = 1;
return SimpleRTPSink::createNew(envir(), rtpGroupsock,
payloadFormatCode, sampleFrequency,
"audio", mimeType, numChannels);
}
FramedSource * LiveG711MediaSubsession::createNewStreamSource(unsigned
int clientSessionId, unsigned int &estBitrate)
{
// For G711, our bitrate is always going to be 64kbps
estBitrate = 64;
return LiveG711AudioStreamFramer::createNew(envir(), NULL,
m_mediaSource );
}
The "LiveG711AudioStreamFramer is also something I wrote, and
"m_mediaSource" is the thing that supplies my audio. For the values I
supply to SimpleRTPSink, I basically copied what
WAVAudioFileServerMediaSubsession was delivering for PCMU audio (8000 hz, 1
channel, etc.).
Still not sure what problem I'm having--I see VLC is receiving the audio
stream, but it's dropping all of the data claiming the "PTS is out of
range." Going to check and see what the SDP exchange looks like with
openRTSP. Thanks again for all your help.
>
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
