>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).
Yes it is indeed not RTP, I've conformed this with the server side
developer.
Will try with BasicUDPSource.
Thanks,
pushkar
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ross Finlayson
Sent: Wednesday, March 19, 2008 9:49 PM
To: LIVE555 Streaming Media
When you stream audio over live-555's RTSP plugin on mplayer, what decides
the
audio data to be big endian vs little endian? 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. B
>I'm trying to play a MPEGTS stream (sending both audio video on same
>port), by creating a SimpleRTPSource.
>I figured out that SimpleRTPSource was the right choice by looking at
>the Boolean MediaSubsession::initiate(int useSpecialRTPoffset) function.
>
>However, MultiFramedRTPSource::networkRead
I'm trying to play a MPEGTS stream (sending both audio video on same
port), by creating a SimpleRTPSource.
I figured out that SimpleRTPSource was the right choice by looking at
the Boolean MediaSubsession::initiate(int useSpecialRTPoffset) function.
However, MultiFramedRTPSource::networkReadHandle
Hey Marco,
Did you make any progress diagnosing this problem ?
--
Glen Gray
[EMAIL PROTECTED]
On 18 Mar 2008, at 09:09, Marco Amadori wrote:
> Il Monday 17 March 2008 23:11:52 Ross Finlayson ha scritto:
>>> So it seems to be a strange threading or concurrency problem
>>
>> Unlikely, because t
To remove yourself from the mailing list, use the web page whose
address appears at the bottom of every mailing list message
(including this one).
Requests to leave a mailing list should *never* be sent to the
mailing list itself.
___
live-devel maili
Hello,
On Mon, Mar 17, 2008 at 11:19 PM, Ross Finlayson <[EMAIL PROTECTED]> wrote:
> Yes (although I'm not sure how "SPTS" differs from "TS" (Transport
> Stream)). See
SPTS is a single program transport stream.
It is a subset of a (MP)TS. I suspect a SPTS often lacks the high
level tables to
Please remove me, thanks
Neel Pahlajani
Partner Relations
Advanced Home Technologies of North America
347 Fifth Avenue
Suite 500
New York, NY 10016
212.400.3030 (office)
631.806.7003 (mobile)
212.447.9300 (fax)
[EMAIL PROTECTED]
___
Hi,
Qfactor will not be available in JFIF header, it is input to JPEG
encoder. If you are aware of JPEG encoder block in your system, find a
way to transfer the qfactor value to MJPEG RTP streamer out block.
And type 0 - YUV422 & 1 = YUV420 (refer RFC2345)
mean while wrote:
hello,
I'm us
hello,
I'm using livemedia to stream mjpeg, and I don't know how to get the
qFactor value. Could you please tell me how to calculate the qFactor? Can I
found it from the jpeg content? And another question, the rtp type field
should be 1 if the jpeg is yuv422 format, and 0 if yuv420, is this rig
On Tue, 2008-03-18 at 19:07 -0700, Ross Finlayson wrote:
> >Sorry if I wasn't clear...
> >
> >Symbolic links would work if I could get the client to request
> >"rtsp://server/video.ts", but it is requesting
> >"rtsp://server/dirA/dirB/dirC/video.ts" and I don't have any way to
> >change what it req
Am 19.03.2008 um 14:22 schrieb Ross Finlayson:
>> I am working on a StreamParser subclass and am wondering how the end-
>> of-file is supposed to be handled.
>
> This is specified by the parameters "onInputCloseFunc" and
> "onInputCloseClientData" that are passed to the "StreamParser"
> construct
>I am working on a StreamParser subclass and am wondering how the end-
>of-file is supposed to be handled.
This is specified by the parameters "onInputCloseFunc" and
"onInputCloseClientData" that are passed to the "StreamParser"
constructor (in the code for the subclass's constructor). Usually
Hello,
I am working on a StreamParser subclass and am wondering how the end-
of-file is supposed to be handled. If reading data until a delimiter
such as 0x01 appears, the test4Bytes() may bail out via
ensureValidBytes(4) when reaching the end of file, exiting the RTSP
server. In the MP
15 matches
Mail list logo
