[FFmpeg-devel] flashsvenc.c path - fix ability to handle negative linesize

[Jason Askew]

Granted.

Comments are not needed, I'll give you that.

Why diff decided to include the other lines, I know not.

I'll try again.

On 5/11/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> Hi
>
> On Fri, May 11, 2007 at 09:23:21AM -0500, Jason Askew wrote:
> > Ok, here's the patch to fix flashsvenc.c to handle negative linesize.
> >
> > Tested on inputs that result in both positive and negative linesize
> > values.  No major functionality changes, changes required ended up
> > being small.
>
> > --- flashsvenc.c      Fri May 11 09:04:07 2007
> > +++ flashsvenc_c.c    Fri May 11 09:09:03 2007
> > @@ -27,7 +27,6 @@
> >   * Flash Screen Video encoder
> >   * @author Alex Beregszaszi
> >   * @author Benjamin Larsson
> > - * @author Jason Askew
> >   */
> >
> >  /* Bitstream description
> > @@ -46,40 +45,15 @@
> >   *
> >   * Encoding ideas, a basic encoder would just use a fixed block size.
> >   * Block sizes can be multipels of 16, from 16 to 256. The blocks don't
> > - * have to be quadratic (square?). A brute force search with a set of different
> > + * have to be quadratic. A brute force search with a set of different
> >   * block sizes should give a better result than to just use a fixed size.
> >   */
> >
> > -/*
> > - * Jason Askew (2007/5/10):
> > - * Added support for instances where linesize[0] is negative
> > - * This occured for me when attempting to encode wmv thru avisynth
> > - * Basicaly changed the previous frame buffer pointer to behave the same as the current frame pointer,
> > - * i.e., move from the last row to first row when linesize is negative
> > - * Also used abs(linesize) value when allocating memory
> > - *
> > - * Also added comments
> > - *
> > - * Also bumped default block size from 16x16 to 48x48, encoding a couple of windows screen caps showed that
> > - * to be a pretty good sweet spot / comprimise on file size.
> > - */
> > -
> > -/*
> > - * TODO:
> > +/* TODO:
> >   * Don't reencode the frame in brute force mode if the frame is a dupe. Speed up.
> >   * Make the difference check faster.
> > - *
> > - * Attempted to do some optimization on key frames by using large block size for key frames (since the
> > - * whole frame needs to be compressed), but testing
> > - * shows that this doesn't work...  key frame is good, but next immediate frame with smaller
> > - * encoded blocks with changes from key frame ONLY show the changed blocks
> > - * Seems strange since block since is included in every frame header
> > - * Current working theory is that all blocks sizes after a key frame must be the same size as the key frame
> > - * which still opens up hope for optimization of block size between key frames, most likely in a 2 pass
> > - * method
> >   */
> >
> > -
> >  #include <stdio.h>
> >  #include <stdlib.h>
> >  #include <zlib.h>
> > @@ -215,6 +189,7 @@ static int encode_bitstream(FlashSVConte
> >                  zsize = 3*block_width*block_height;
> >                  ret = compress2(ptr+2, &zsize, s->tmpblock, 3*ws*hs, 9);
> >
> > +
> >                  //ret = deflateReset(&(s->zstream));
>
> none of this has any relation to a negative linesize fix
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Breaking DRM is a little like attempting to break through a door even
> though the window is wide open and the only thing in the house is a bunch
> of things you dont want and which you would get tomorrow for free anyway
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
>