Hi List<br><br>Apart from Michael's review (which I'm currently working on) I wanted to make sure you<br>as a whole had a general overview of what's done, what's being done and what's completely missing
<br>from your QCELP decoder so here it goes.<br><br>Done<br>====<br>An independent implementation of the decoder (and I do mean independent. Its not in any way<br>based on the ref source but on the actual especification) that has reached decoding stage, ie: it
<br>works with the 3g2 samples I have, and all the ones at <a href="http://samples.mplayerhq.hu">samples.mplayerhq.hu</a>. mind you:<br><br>1.- Haven't triyed to decode anything but RATE_FULL streams, lower rates<br>seem not to be that common as computer 'files' but as actual comm streams so
<br>RATE_FULL has been my target. There is a lot of code to support the other rates<br>on your decoder but its untested and has some known flaws that need to be worked<br>around yet.<br><br>2.- Till now I have been unable to decode Qclp streams stored in mov files, In fact, I haven't
<br>even succeed at parsing them.<br><br>Being worked on<br>============<br>1.- Final adaptive postfiltering and gain control stage.<br>2.- Decode loop un-gluing/un-drafting, that is, make the decode loop at qcelp_decode_frame() do its
<br>work in a better way -- A right way.<br>3.- Complete IFQ (that is 'Insufficient Frame Quality') frame cicle, Keep in mind though<br>that from what I have come to understand, there is no point on doing this for _files_, it
<br>only makes sense when there is two way communication going between the decoder and the<br>encoder (as in a phone conversation), maybe this makes sense for streaming also and that's <br>why I'm strugling to have it working. besides, it needs to be done to have a specs compliant
<br>decoder.<br><br>All this shouldn'd take me more than a few (<7) days. I'm working on Michael suggestions now<br>so that can delay things a little -- Its for the best.<br><br>Missing but planed<br>==============
<br><br>1.- Make it 100% spec compliant. (but then again, in that case it wouldn't work :-)<br><br>2.- Qclp in MOV files:<br><br>This is somewhat of a long history, see -- It should have worked but didn't. Turns out that this
<br>will require some parsing or even demuxer work (In the best of cases). I'm still researching and <br>shotguning this with tweaks but haven't succeed. What I do know is this:<br><br> - In getting abnormally long packets from the mov demuxer.
<br> - The size of the packets doesn't always make sense, one would think<br> that some butchered frames are reaching the decoder.<br> - I'm not 100% certain these are spec compliant streams. this could be<br> and even is mentioned somewhere on our literature, a propietary pimped
<br> version of QCELP13K and not the one in the TIA EIA 733 specification.<br> I'm not even sure if what we call Qualcomm purevoice is really spec compliant.<br> - If these do are QCELP13K it could be they are simply interleaved codec
<br> frames as outlined in RFC 2658. Problem is that if they are, we would be<br> over the bundling max value therein discussed, anyway, this is my best<br> bet and its the point around which I'm currently revolving.
<br><br>3.- QCELP8K (RateSmart?) support, this is a different spec but similar enough to hope been able <br>to make it work with the same decoder.<br>
<br>Missing<br>======<br><br>To be honest, what I know is missing its been worked on as stated above. I can<br>think of one thing though: a .qcp demuxer. Qualcomm seems to store its<br>Qualcomm PureVoice streams in such files so I have some work undergoing
<br>to at least understand it, its a RIFF based format, nothing martian.<br><br>Thanks for your reviews & support.<br><br>Best regards<br><br> Reynaldo<br>