[MPlayer-dev-eng] [PATCH] yadif green line

Ivan Kalvachev ikalvachev at gmail.com
Sun Feb 5 19:50:27 CET 2012


A user provided me with a sample file that generated a random garbage
at the bottom line.

It turned out that the secret for repeating this bug is in the parity.
It is always reproducible if the function filter(...)  is rigged so
the parity check calls filter_line() for the last image line.
In the filter_line_c() function the line "int e=cur[+ref];"
unconditionally reads the next line of the image. If we are at the
last line, it would read the line past the last one. ( mode<2 reads
and +2 lines)

It seems that this quirk of the yadif have been known, so the filter
copies the image into buffer that have 3 lines pad at top and bottom.

Unfortunately the store_ref() function that does that, doesn't pad the
additional lines, so they are left uninitialized. The solid green line
is obtained if malloced buffers are zeroed.


The patch that I attach pads 2 additional lines top and bottom.
It also fixed the allocation so the height is not aligned to 32 lines
(useless) but instead there are always 6 pad lines (3+3), even for
chroma planes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: yadif_pad.patch
Type: application/octet-stream
Size: 1322 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120205/51c8ba4f/attachment.obj>


More information about the MPlayer-dev-eng mailing list