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

[Michael Niedermayer]

On Sun, Feb 05, 2012 at 08:50:27PM +0200, Ivan Kalvachev wrote:
> 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.

This issue has been fixed in ffmpegs yadif a year ago (see bad82d3d)
the ffmpeg fix also doesnt need larger frames which makes integration
with direct rendering easier.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120208/326d1c1b/attachment.asc>