[FFmpeg-devel] flashsvenc.c path - fix ability to handle negative linesize
Fri May 11 19:09:18 CEST 2007
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 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
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel