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

[Michael Niedermayer]

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
-------------- 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/20070511/52f68a5f/attachment.pgp>