[FFmpeg-devel] [PATCH] wmapro decoder
Michael Niedermayer
michaelni
Fri Jun 5 19:08:33 CEST 2009
On Fri, Jun 05, 2009 at 07:06:32PM +0200, Sascha Sommer wrote:
> Hi,
>
> On Freitag, 5. Juni 2009, Michael Niedermayer wrote:
> > On Mon, Jun 01, 2009 at 05:28:07PM +0200, Sascha Sommer wrote:
> > > Hi,
> > >
> > > attached patch adds support for decoding wmapro.
> > >
> > > I'm awaiting your review so that we can sort out the remaining issues.
> >
> > I think the first thing to do is to compare it to wma and merge what is
> > similar
> > rle decoding for example looks very similar
> >
> > ill do a proper review in the next days, of course if you can reduce
> > code duplication relative to wma, that would make my review easier
> > and ill insist on all code duplication to be removed anyway when i
> > find some.
> >
> > [...]
>
> Well, let's see
>
> Parsing the start of a packet:
>
> wmadec.c:
>
> skip_bits(&s->gb, 4); /* super frame index */
> nb_frames = get_bits(&s->gb, 4) - 1;
>
>
>
> wmapro:
>
> /** parse packet header */
> init_get_bits(&gb, buf, s->buf_bit_size);
> packet_sequence_number = get_bits(&gb, 4);
> s->bit5 = get_bits1(&gb);
> s->bit6 = get_bits1(&gb);
>
> /** get number of bits that need to be added to the previous frame */
> num_bits_prev_frame = get_bits(&gb, s->log2_frame_size);
>
> => not similar
>
>
> The same is true for the included packet headers. (Wma1/2 for example store
> the length of the previous subframe in the header wmapro has some header that
> contains the sizes of all subframes, wma1/2 only supports M/S stereo to
> improve compression for multichannel streams, wmapro supports channel
> grouping...)
>
> Decoding of the scale factors:
>
> The vlc version of wmadec.c is similar to the one of wmapro apart from the
> first value and the used vlc table. Also wmapro does the pow before the imdct
> because the decoded scale factors can be recycled for other subframes.
> The run level coding is not part of wmadec.c. The lsp coding not part of
> wmapro.
>
> When it comes to coefficient decoding, you are right that the run level part
> (wmadec does not have the vector coding part like wmapro that happens before
> this step) also uses more than one run and level tables and uses code==1 to
> exit the loop, code > 1 for normal coefficients and code == 0 for escape
> decoding. Unfortunatelly the escape decoding is different:
>
>
> } else if (code == 0) {
> /* escape */
> level = get_bits(&s->gb, coef_nb_bits);
> /* NOTE: this is rather suboptimal. reading
> block_len_bits would be better */
> run = get_bits(&s->gb, s->frame_len_bits);
> } else {
>
> vs.
> val = wma_get_large_val(s);
> /** escape decode */
> if (get_bits1(&s->gb)) {
> if (get_bits1(&s->gb)) {
> if (get_bits1(&s->gb)) {
> av_log(s->avctx,AV_LOG_ERROR,
> "broken escape sequence\n");
> return 0;
> }else
> cur_coeff += get_bits(&s->gb,s->esc_len) + 4;
> }else
> cur_coeff += get_bits(&s->gb,2) + 1;
> }
> }
>
> As this loop should be quit speed critical, I don't know if an if(codec ==
> wmapro) is a good idea.
the escape code should be rare enough for the if() to be a non issue except
if gcc pessimizes code outside the escape branch as a result
>
>
> Tansformations:
> M/S stereo coding can probably be shared but it is only a
> a = s->coefs[0][i];
> b = s->coefs[1][i];
> s->coefs[0][i] = a + b;
> s->coefs[1][i] = a - b;
>
>
> The imdct and windowing should be the same but one would first have to make
> wmadec.c use ff_imdct_half. But then this are only a few calls to the imdct
> and dsp functions that are probably similar for other imdct based codecs like
> AAC (for the sine window case), too.
> Apart from that, the float to short conversion and the memcpy of the second
> half of the output buffer for the next iteration are identical. I'm not sure
> here, if the decoders should not be changed to output floats instead or at
> least use the appropriate dsp helper function.
i guess if they use floats internally floats should be output yes
>
> All in all I don't see so many code duplications that would make it a
> requirement that the decoder is twiddled into the existing wma1/2 decoder but
> it is possible that I missed a few things...
iam not asking for twiddling it into the exising decoder but to not duplicate
(near) identical code. that can be done in many ways ...
I did not review all code so i dont know how much is reasonable to merge,
my mail was mostly a kind of note that i will insist on (near) identical
code to be merged when i find some, it could surely be that i wont find
any beyond the rle stuff ...
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090605/46bae72a/attachment.pgp>
More information about the ffmpeg-devel
mailing list