This behaviour was not preferred and caused visible image quality
degradations. The real solution would be, to apply a real
deinterlacing filter before scaling the frames.
Fixes bug #615471.
Original commit message from CVS:
* gst/videoscale/Makefile.am:
* gst/videoscale/gstvideoscale.c:
* gst/videoscale/gstvideoscale.h:
* gst/videoscale/vs_4tap.c:
* gst/videoscale/vs_4tap.h:
* gst/videoscale/vs_image.c:
* gst/videoscale/vs_image.h:
* gst/videoscale/vs_scanline.c:
* gst/videoscale/vs_scanline.h:
Add a 4-tap image scaler. Theoretically looks much prettier.
The tap calculation could use some improvement.
Original commit message from CVS:
* gst/videoscale/gstvideoscale.c: (gst_videoscale_init),
(gst_videoscale_prepare_size), (parse_caps),
(gst_videoscale_set_caps), (gst_videoscale_get_size),
(gst_videoscale_prepare_image), (gst_videoscale_transform_ip),
(gst_videoscale_transform):
* gst/videoscale/gstvideoscale.h:
Refactor, make use of BaseTranform really well.
Original commit message from CVS:
2005-07-01 Andy Wingo <wingo@pobox.com>
* gst/videoscale/gstvideoscale.c:
* gst/videoscale/gstvideoscale.h: Clean up, port to 0.9. Derives
from BaseTransform, implements a transform_caps. Removed dead code
including some PAR stuff that was never reached -- should probably
be added back somehow.
Original commit message from CVS:
Remove all config.h includes from header files, add it to each source file and remove duplicate config.h includes from several source files
Original commit message from CVS:
Rewrote much of videoscale. Now handles most common YUV formats
as well as 32 and 24 bit RGB. Only handles "nearest" scaling.
Original commit message from CVS:
* removal of //-style comments
* don't link plugins to core libs -- the versioning is done internally to the plugins with the plugin_info struct,
and symbol resolution is lazy, so we can always know if a plugin can be loaded by the plugin_info data. in theory.
