When operating on subsampled chroma planes, some rounding is taking
place. The left and top borders are rounded down while the width and
height are rounded up, so all rounding is done outward to guarantee the
logo area is fully covered.
The problem is that the width and height are counted from the
unrounded left and top borders, respectively. So if the left or top
border position has indeed been rounded down, and the width or height
needs no rounding (up), the position of the the right or bottom border
will be effectively rounded down, i.e. inward.
The issue can easily be seen with a yuv240p input and
-vf delogo=45:45:60:40:show=1 -vframes 1 delogo-bug.png
(or virtually any logo area with odd x and y and even width and
height.) The right and bottom chroma borders (in green) are clearly
off.
In order to fix this, the width and height must be adjusted to include
the bits lost in the rounding of the left and top border positions,
respectively, prior to being themselves rounded up.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The original delogo algorithm interpolates both horizontally and
vertically and uses the average to compute the resulting sample. This
works reasonably well when the logo area is almost square. However
when the logo area is significantly larger than high or higher than
large, the result is largely suboptimal.
The issue can be clearly seen by testing the delogo filter with a fake
logo area that is 200 pixels large and 2 pixels high. Vertical
interpolation gives a very good result in that case, horizontal
interpolation gives a very bad result, and the overall result is poor,
because both are given the same weight.
Even when the logo is roughly square, the current algorithm gives poor
results on the borders of the logo area, because it always gives
horizontal and vertical interpolations an equal weight, and this is
suboptimal on borders. For example, in the middle of the left hand
side border of the logo, you want to trust the left known point much
more than the right known point (which the current algorithm already
does) but also much more than the top and bottom known points (which
the current algorithm doesn't do.)
By properly weighting each known point when computing the value of
each interpolated pixel, the visual result is much better, especially
on borders and/or for high or large logo areas.
The algorithm I implemented guarantees that the weight of each of the
4 known points directly depends on its distance to the interpolated
point. It is largely inspired from the original algorithm, the key
difference being that it computes the relative weights globally
instead of separating the vertical and horizontal interpolations and
combining them afterward.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
Also replace custom tests for MD5 with those published in RFC 2202
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This more evenly distributes the load between threads
This also fixes the chroma filtering where the filter was applied twice
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes out of array writes
No FFmpeg release is affected by this
This also fixes some artifacts
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8e673efc6f5b7a095557664660305148f2788d30':
prores: update FATE test to account for alpha plane present in the test sample
configure: Add basic valgrind-massif support
Conflicts:
tests/fate/prores.mak
tests/ref/fate/prores-alpha
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This replaces a large number of checks for the second field by
fixing the pointers when they are setup.
This should also fix I/BI field pictures.
Changes checksums for vc1_sa10143, the file becomes slightly closer
to what the reference decoder outputs.
Based on "vc1dec: the second field is written wrong to the picture"
by Sebastian Sandberg <sebastiand.sandberg@gmail.com>.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is the first 2 MB of the official test7.mkv.
That length seems to be enough to detect the bugs
we had in our code so far.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
* commit 'e036bb7899d0faca9159206be9bf5552e76e7633':
lavc: clear AVBuffers on decoded frames if refcounted_frames is not set
FATE: add an additional indeo3 test
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This makes -t sample-accurate for audio and will allow further
simplication in the future.
Most of the FATE changes are due to audio now being sample accurate. In
some cases a video frame was incorrectly passed with the old code, while
its was over the limit.
The sample is already included in the FATE suite, but is not tested
because cropping wasn't fully supported before.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* qatar/master:
avcodec: Bump minor for JPEG 2000 decoder
JPEG 2000 decoder for DCinema
The mqc code is merged, the rest is added independent of
the existing jpeg2000 decoder and encoder.
Conflicts:
Changelog
doc/general.texi
libavcodec/Makefile
libavcodec/allcodecs.c
libavcodec/mqc.c
libavcodec/mqc.h
libavcodec/mqcdec.c
libavcodec/version.h
tests/fate/video.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Based on the 2007 GSoC project from Kamil Nowosad <k.nowosad@students.mimuw.edu.pl>
Updated to current programming standards, style and many more small
fixes by Diego Biurrun <diego@biurrun.de>.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
The encoder now doesn't produce any extra graphic control extension
block anymore. Only the image is encoded, and the muxer writing
its own GCE containing notably the timing information now includes the
optional palette transmitted through packet side data.
This commit avoid setting clashes between the two GCE, and reduce the
size of the generated file with pal8 output.
* qatar/master:
FATE: add a test for the interlace filter
lavfi: new interlace filter
Conflicts:
Changelog
configure
doc/filters.texi
libavfilter/Makefile
libavfilter/allfilters.c
tests/fate/filter.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Text subtitles packets are not 0-terminated (and if they are,
it is handled by the recoding process since 0 is a valid
Unicode code point). The terminating 0 would overwrite the
last payload octet.
OTOH, packets must be 0-padded.
Fix a problem reported in trac ticket #2431.
* commit '43a8333a16c796b3d855fb3aaa742103cb62731f':
FATE: add a test for the channelsplit filter
FATE: add a test for the channelmap filter
FATE: add a test for the negate filter
FATE: add a test for the overlay filter
Conflicts:
tests/fate/filter.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ea290d919a52f0f8c7e30d69328bb011ed13f61a':
FATE: add a test for the setpts filter
FATE: add a test for the hqdn3d filter
FATE: add a test for the transpose filter
FATE: add a test for the unsharp filter
Conflicts:
tests/ref/fate/filter-hqdn3d
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '1a6d4bd7b60761bd7d955011ce7df4dd6b87b497':
FATE: add a test for the fade filter
FATE: add a test for the drawbox filter
FATE: add a test for the boxblur filter
FATE: add a test for the gradfun filter
Conflicts:
tests/fate/filter.mak
tests/ref/fate/filter-gradfun
our gradfun test is renamed to gradfun-ubitux as its name conflicts and
it was requested to be kept. Feel free to rename, change, finetune ...
Merged-by: Michael Niedermayer <michaelni@gmx.at>
