Altivec does unaligned reads from this buffer in
hscale_altivec_real(), and can thus read up to 16 bytes beyond
the end of the buffer. Therefore, add an extra 16 bytes of
padding at the end of the conversion buffer.
This fixes fate-lavfi-pixfmts_scale on AltiVec-enabled builds
under valgrind.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Tested with both Basic and Digest authentication, and tested with
both proxy authentication and authentication for the requested
resource at the same time.
Signed-off-by: Martin Storsjö <martin@martin.st>
The error was hidden before, to avoid showing an error on the
first request where no auth has been provided, when the server
indicates which authentication method to use.
Now the error is printed if an authentication method was used,
but failed.
Signed-off-by: Martin Storsjö <martin@martin.st>
Update the reference to the conversion tool to use avconv and
make sure the example line works as supposed.
Remove the paragraph pointing to the svn repo
The decoder already skips data at the end of the packet without this.
Also remove 2 APEContext fields that were only used for the end-of-frame
normalization.
The chunksize internal variable has two different uses - for
reading, it's the amount of data left of the current chunk
(or -1 if the server doesn't send data in chunked mode), where
it's only an internal state variable. For writing, it's used
to decide whether to enable chunked encoding (by default), by
using the value 0, or disable chunked encoding (value -1).
This, while consistent, doesn't make much sense to expose
as an AVOption. This splits the usage of the internal variable
into two variables, chunksize which is used for reading (as
before), and chunked_post which is the user-settable option,
with the values 0 and 1, where 1 is default.
Signed-off-by: Martin Storsjö <martin@martin.st>
It is found in some 8svx files (e.g. ones created by SoX).
Currently the decoder reuses the 8svx functions because we already have
handling of a single large planar packet for the compressed 8svx codecs.
The current code is a generalization of the earlier progressive MV
prediction code. This was supposed to predict MVs for both interlaced
and progressive pictures. But the interlaced MV prediction is buggy
and works mostly by luck.
This partially fixes interlaced MV prediction.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
