I just built and ran live555 and the proxyRtsptest app on my raspberry PI and
I didn't have to change a thing.
________________________________
From: [email protected] [[email protected]] on
behalf of Ross Finlayson [[email protected]]
Sent: Tuesday, March 19, 2013 12:30 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] SOCKLEN_T type / AC3AudioStreamParser try-catch / AC3
stream header
I compiled and ran live555 on Raspberry Pi but I changed the type of SOCKLEN_T
For the bazillionth time: Please DO NOT change the supplied code! (I want to
make it as easy as possible for you to comply with the LGPL :-)
Int works fine on windows but it’s unsigned int on the PI.
Does your development environment for the 'Raspberry Pi' (Linux, right?) not
already define "socklen_t"?? If it does, then you should be able to use the
existing "config.linux" configuration file. But even if it doesn't, there's a
very easy way to make this change, without having to modify the supplied code:
Create a "config.linux-for-raspberry-pi" configuration file (perhaps just by
copying "config.linux"), and, in the 'COMPILE_OPTS' line, set
-DSOCKLEN_T="unsigned int"
(I'm not sure about the quoting there; you might need to use single quotes
instead?)
(If you find that you need to create a separate "config.linux-for-raspberry-pi"
configuration file, then please share it on the mailing list, so I can include
it in future software releases.)
I noticed a try/catch block in liveMedia\AC3AudioStreamFramer.cpp is this
intentional?
Of course it's intentional; I wouldn't write that code for no reason :-)
Since my compiler stumbled over try/catch (exceptions turned off)
Sorry, but that won't work. To compile our code, your C++ compiler needs to
understand C++ language exceptions. (I wish this weren't true, but we use C++
exceptions for stream parsing; getting rid of them would be difficult.)
I came across (liveMedia/AC3AudioStreamFramer.cpp)
// We expect an AC3 audio header (first 2 bytes == 0x0B77) at the start:
while (1) {
unsigned next4Bytes = test4Bytes();
if (next4Bytes>>16 == 0x0B77) break;
skipBytes(1);
saveParserState();
}
AC3 streams are WORD oriented and both endianness’ are possible.
Are you saying that both orders are possible *in the stream*?? I don't think
that's true. The AC-3 specification says, I think, that all values are sent in
'big endian' order (i.e., high-order byte first). Our "test4Bytes()" code
reads the next 4 bytes - one at a time - from the stream, always returning a
'big endian' result (regardless of the byte order of the host computer). So
the code of ours that you quoted is correct, I believe.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
This message and any attachments contain confidential and proprietary
information, and may contain privileged information, belonging to one or more
affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is
waived by this transmission. Unauthorized use, copying or disclosure of such
information is prohibited and may be unlawful. If you receive this message in
error, please delete it from your system, destroy any printouts or copies of
it, and notify the sender immediately by e-mail or phone.
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
