[FFmpeg-devel] [PATCH]wmv3 encoder

[Michael Niedermayer]

Hi

On Wed, Jun 27, 2007 at 10:31:35PM +0200, Denis Fortin wrote:
> Michael Niedermayer a ?crit :
> > Hi
> [...]
> >> +void ff_vc1_inv_trans_put(uint8_t *dest, int linesize, DCTELEM block[64])
> >> +{
> >> +    int i,j;
> >> +    uint8_t *cm = ff_cropTbl + MAX_NEG_CROP;
> >> +
> >> +    vc1_inv_trans_8x8_c(block);
> >> +
> >> +    /* read the pixels */
> >> +    for(i=0;i<8;i++) {
> >> +        dest[0] = cm[block[0]];
> >> +        dest[1] = cm[block[1]];
> >> +        dest[2] = cm[block[2]];
> >> +        dest[3] = cm[block[3]];
> >> +        dest[4] = cm[block[4]];
> >> +        dest[5] = cm[block[5]];
> >> +        dest[6] = cm[block[6]];
> >> +        dest[7] = cm[block[7]];
> >> +
> >> +        dest += linesize;
> >> +        block += 8;
> >> +    }
> >> +}
> > 
> > duplicate of put_pixels_clamped*
> > 
> > all encoder specific things MUST be in files seperate from the decoder
> > so that compilation of them can be skiped if the user doesnt want the
> > encoder
> > 
> 
> Actually i checked and it's not the correct way to reconstruct a mb.
> I must inv transf dct coeff, do overlap smoothing if enabled, add 
> constant 128 and then clamp to 0-255.
> So clamping should not happen here and i need a way to plug this vc1 
> specific decoding procedure into mpegvideo.c.
> But i have the strange feeling that a patch like above will get rejected 
> by you :
> inside s->encoding part of MPV_decode_mb  :
> if(codec_id= wmv3 ) {vc1_decode_mb}
> 
> 
> Am i right? If so do you have suggestions about the path i should take 
> to support overlap filtering ?

the whole wmv3/vc1 things is an incredible mess and i would wish thouse
who designed it where never born or that at least smpte would have given
MS a kick in the ass and told them to get lost ...

so the options are
* do something wrong and simple, its irrelevant anyway as no sane person
  would encode to this format unless she has no other options
  also doing something wrong would fit well in the whole wmv design ...

* write a clean, simple and minimal implementation which is correct and
  which doesnt mess with speed critical functions from mpegvideo


> 
> BTW reading vc1 decoder, it seems that clamping is done prior to overlap 
> which is not correct (overlap should work on 10 bits values).

who cares? if you have a sample which is decoded vissibly wrong, id guess
kostya will eventually fix it when he has time otherwise i dont see why
this would matter

OTOH if you are insane and want to waste your time on this, i wont stop
you, a patch fixing this _cleanly_ is not unwelcome 

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070628/7da214f6/attachment.pgp>