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