Sorry for the constant posts--I solved it. Again, timestamping bug. I
changed my code to use the gettimeofday() defined in GroupsockHelper.hh, and
everything works, so...pretty clear the problem is in our timestamping class
(portable timestamping code == royal PITA).
Thanks for all your help, Ro
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;
On Wed, Sep 9, 2009 at 5:50 PM, Ross Finlayson 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 del
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 t
On Wed, Sep 9, 2009 at 3:17 PM, Ross Finlayson wrote:
> testOnDemandRTSPServer uses WAVAudioFileServerMediaSubsession, which has an
>> option to convert to ulaw--this class is sort of like what I want (?),
>> although it reads from a file instead of a live source (hence the "seek" and
>> "scale" m
testOnDemandRTSPServer uses WAVAudioFileServerMediaSubsession, which
has an option to convert to ulaw--this class is sort of like what I
want (?), although it reads from a file instead of a live source
(hence the "seek" and "scale" methods that are irrelevant to a live
source) and my ulaw sourc
I want to expose a live G711 stream (specifically, PCMU) through an
on-demand RTSP server; my application receives a pre-encoded stream (single
channel, 8000 samples/sec, etc.). I reviewed a bunch of the samples that
come with Live555 (and wis-streamer) and they were good references, but I
want to
