[Live-devel] live 555 rtsp library for mplayer

[Ratin]

From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com>
Date: Wed, 19 Mar 2008 23:18:49 -0700
Subject: Re: [Live-devel] live 555 rtsp library for mplayer
>>When you stream audio over live-555's RTSP plugin  on mplayer, what
>>decides the
>>audio data to be big endian vs little endian?

>16-bit PCM audio data - when streamed using RTP using an
>IETF-standard RTP payload format - is *always* in Big Endian order
>(called "Network Byte Order" in the RFCs).  That's the standard[*].
I am developing the server for an embedded device, I was hoping I could
avoid that but alas!
It sucks that mplayer code actually support a whole slew of combinations
(any of the
types specified in file ad_pcm.c, function static int init(sh_audio_t
*sh_audio). The code
checks sh_audio->format  to  match a data format, in order for data to be 16
bit, little endian
it has to be one of these formats: 'sowt' (0x74776F73) , 0x0, 0x1, 0xfffe .
If I could soecify a string for that would falll into one of these cases, I
wouldve been
in good shape.

>>I am developing a server and I am
>>specifying the format as 97 (dynamic format) with rtpmap being : 96
L16/8000
>>for single channel, 16 bit/sample, 8 khz sample rate audio. But
>>mplayer somehow
>>thinks audio data is in  big endian format and attaches a BE -> LE
>>conversion filter

>It is correct; your server is not.  If your server's PCM data is
>originally in Little Endian order, then you need to insert a LE->BE
>filter in your server.  If you are using our libraries to build your
>server, then this involves just inserting a "EndianSwap16" filter
>object in front of your "SimpleRTPSink".  (If you are streaming from
>WAV audio files, then you could just use the
>"WAVAudioFileServerMediaSubsession" class, which does this for you.
>Note also our "LIVE555 Media Server", which can stream ".wav" audio
>files.)

I am not using live555 libraries because of the light weight requirement of
this project, so I need to come up with an optimized version of the byte
swaper. I wonder if there would be a way to read the data backwards from
the A/D that we use for audio.

>[*] The reason for this is that IETF protocol standards began in an
>era when most computers on the Internet were Big Endian computers
>like Sun workstations (which originally used the Motorola 68xxx
>architecture).  Back then, computers that used the (Little Endian)
>Intel 8086 architecture were (generally speaking) too underpowered to
>be used as Internet nodes.  If we had known back then that the x86
>architecture would come to dominate the industry, then perhaps things
>would have been done differently....

The standards definitely lack today's computing and multimedia needs.
I was looking at the rfc for media specification - the fourcc and character
based  stream identification all sleems like a joke to me ..they need new
revisions like many other rfc's.

Ratin

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080320/c97056c6/attachment.html