Hi Bruce, I think you're describing some kind of codec container. Which is great for higher bitrate links. With a 4800 bps unreliable link (radio), any container would likely dig right into the data/control capacity, or force us to sacrifice some FEC bits.
What I could do, is provide container formats for higher capacity links (maybe even supporting time division on 9600+ links) if no-one else is handling general documentation. This isn't really something that is part of this document though. For sure maybe a general standard document could be produced. Again, if no-one else is working on any such thing. Also, maybe we could pre-define FEC/Interleaves for various bitrate codec/link combinations (with/without containers). Might be an idea? Without a container, everything fits in just nicely into the 4800 GMSK mode. I just think it'd be overkill and lost us data/control capacity. For now, I'll modularize the VHF/UHF draft. We can then expand upon interleave/FEC possibilities. As well as introduce container formats afterwards. Best regards, Petrer. On 19 April 2012 00:56, Bruce Perens <[email protected]> wrote: > On 04/18/2012 04:18 PM, Peter wrote: >> >> I understand why this is good. The issue I can see is that the FEC/Payload >> would likely be different depending on codec bitrate and target bitrate. > > Codec bitrate should be part of whatever field identifies the codec. If you > get voice messages at different rates over some high-speed transport, you > should be able to decode them all. > > Yes, please do more layers as you describe. Given the interest in linked > repeaters, etc., we can expect to have a lot done to the transport other > than our usual VHF/UHF link. > > Thanks > > Bruce > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
