[PATCH] Fix vf_expand in with non-direct caps
Hi, attached patch makes sure vf_expand is dealing with direct-capable image before trying to use direct rendering for expanding. I've seen this problem with encoding, where the codec's replicated edges could be made visible upon expansion. skal
On Mon, Jan 14, 2008 at 4:55 PM, Pascal Massimino < pascal.massimino@gmail.com> wrote:
attached patch makes sure vf_expand is dealing with direct-capable image before trying to use direct rendering for expanding. I've seen this problem with encoding, where the codec's replicated edges could be made visible upon expansion.
ping? ok, here's a recipe to reproduce the bug: take a 320x? input that ffmp4 can decode, and try to expand it to 352 = 320+2*16: mplayer foo_320x240.avi -vf expand=352 Normally, you should see on the left/right side the 16-pixels wide replicated egdes from ffmpeg's decoded frame. skal
skal
On Sat, Mar 29, 2008 at 4:08 AM, Pascal Massimino <pascal.massimino@gmail.com> wrote:
On Mon, Jan 14, 2008 at 4:55 PM, Pascal Massimino <pascal.massimino@gmail.com> wrote:
attached patch makes sure vf_expand is dealing with direct-capable image before trying to use direct rendering for expanding. I've seen this problem with encoding, where the codec's replicated edges could be made visible upon expansion.
ping?
ok, here's a recipe to reproduce the bug: take a 320x? input that ffmp4 can decode, and try to expand it to 352 = 320+2*16: mplayer foo_320x240.avi -vf expand=352 Normally, you should see on the left/right side the 16-pixels wide replicated egdes from ffmpeg's decoded frame.
ACK? (yeah, this is my 'ping?' night..) skal
On Thu, May 29, 2008 at 01:16:31PM -0700, Pascal Massimino wrote:
On Sat, Mar 29, 2008 at 4:08 AM, Pascal Massimino <pascal.massimino@gmail.com> wrote:
On Mon, Jan 14, 2008 at 4:55 PM, Pascal Massimino <pascal.massimino@gmail.com> wrote:
attached patch makes sure vf_expand is dealing with direct-capable image before trying to use direct rendering for expanding. I've seen this problem with encoding, where the codec's replicated edges could be made visible upon expansion.
ping?
ok, here's a recipe to reproduce the bug: take a 320x? input that ffmp4 can decode, and try to expand it to 352 = 320+2*16: mplayer foo_320x240.avi -vf expand=352 Normally, you should see on the left/right side the 16-pixels wide replicated egdes from ffmpeg's decoded frame.
ACK?
(yeah, this is my 'ping?' night..)
cannot reproduce, what i see with -vf expand=352 -vo x11 looks like some slice copying bug, as if too much would be copied, theres the correct pic on the left and some replicated part on the right but vertically 1 line shifted up with blinking horizontal black lines ... Also vd_ffmpeg.c by default does not draw replicated edges (grep for EMU_EDGE) now if you ask me where the bug is, i have no clue, every time i look at mplayers video filter layer i realize ive forgoten half of how it worked. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle
participants (2)
-
Michael Niedermayer -
Pascal Massimino