[FFmpeg-soc] QCELP Status

[Reynaldo Verdejo]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20070828/438f3443/attachment.htm>