[FFmpeg-devel] MXF D10 regression tests

[Michael Niedermayer]

On Wed, Mar 18, 2009 at 10:52:07PM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Wed, Mar 18, 2009 at 02:20:43PM +0100, Reimar D?ffinger wrote:
> >> On Wed, Mar 18, 2009 at 01:44:03PM +0100, Michael Niedermayer wrote:
> >> > It is not supposed to be a restriction for avcodec_encode_video() though
> >> > maybe it is by a bug. (i did not test this)
> >> > The restriction is just on the internal buffers, which for encoding are
> >> > allocated by lavc.
> >> 
> >> Oh, ok. Then attached patch can fix this simpler and more thoroughly (it
> >> seems to fix both intra and inter 4:2:2 encoding on PPC).
> >> Note it may still contain some brainfarts, it still feels a bit
> >> confusing and suboptimal to me currently.
> >
> > [...]
> >> @@ -254,22 +254,17 @@
> >>              h+= EDGE_WIDTH*2;
> >>          }
> >>  
> >> -        ff_fill_linesize(&picture, s->pix_fmt, w);
> >> -
> >> -        for (i=0; i<4; i++){
> >>  //STRIDE_ALIGN is 8 for SSE* but this does not work for SVQ1 chroma planes
> >>  //we could change STRIDE_ALIGN to 16 for x86/sse but it would increase the
> >>  //picture size unneccessarily in some cases. The solution here is not
> >>  //pretty and better ideas are welcome!
> >>  #if HAVE_MMX
> >>              if(s->codec_id == CODEC_ID_SVQ1)
> >> -                stride_align[i]= 16;
> >> -            else
> >> +                stride_align= 16;
> >>  #endif
> >> -            stride_align[i] = STRIDE_ALIGN;
> >> -            picture.linesize[i] = ALIGN(picture.linesize[i], stride_align[i]);
> >> -        }
> >>  
> >> +        ff_fill_linesize(&picture, s->pix_fmt, w, stride_align);
> >> +
> >
> > does something like:
> > retry:
> >     ff_fill_linesize(&picture, s->pix_fmt, w);
> >     if(any linesize % stride_align){
> >         w+= w&~(w-1);
> >         goto retry;
> >     }
> >
> > work?
> 
> You still haven't replied whether you want an account on my PPC
> machine.  You could test this yourself...

i can test it in x86 if i set STRIDE_ALIGN to 16 but that would take
3 times as long as writing above code ...
my todo list is simply too long

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20090319/bfdc4148/attachment.pgp>