[Live-devel] SOCKLEN_T type / AC3AudioStreamParser try-catch / AC3 stream header

[Ross Finlayson]

> 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130319/7be1c1f9/attachment.html>