[MPlayer-dev-eng] [PATCH] various weirdness in vf_expand when expanded width > frame width

[Jason Tackaberry]

I did a bit more investigating and I think I have a better handle as to
what's going on ...

On Sat, 2006-12-30 at 18:13 -0500, Jason Tackaberry wrote:
>      1. The bars added to either side of the video are gray.  When
>         displaying and hiding OSD, there is cruft remaining from the OSD
>         in the gray parts.  (I think this bug is probably known.)

Looks like this was a symptom of the vo, not expand.  See the attached
very trivial patch which resolves this for vo_xv.  It should have no
performance impact for the common case; it blanks the full xvimage slice
when the mpi slice is offset horizontally.


>      2. When using the osd feature in expand, -vf expand=::::1:16/9, the
>         OSD is not visible at all.

Very likely a bug in vf_expand; haven't really looked into it.


>      3. If I put a filter (one that implements a put_image, so not
>         dsize, for example) in front of expand, e.g. -vf
>         eq,expand=::::1:16/9, the bars on each side are properly black,
>         and in this case, OSD works again.  However when the OSD is
>         hidden, cruft is still left behind (unsurprisingly).

This is because when there's a filter before or after expand that does a
deep copy of the mpi, slices aren't used.

Only when the expand OSD option is used will there be OSD cruft left
behind after it's hidden; if the expand osd option is 0, it's fine.
However, even in the case when expand osd is 0, the OSD is drawn on the
bars.  So I think maybe the easiest workable solution is for vf_expand
to ignore the osd parameter when expanded width > frame width, which
appears to behave as you'd expect.


>      4. Putting scale after expand is a recipe for corruption.  For
>         example, -vf expand=::::1:16/9,scale=640:-2 produces an image
>         where the original frame is left-aligned (not centered) and the
>         right portion of the frame (whose width is the combined width of
>         what the bars would be) has a portion of the frame with some
>         slight corruption.  In this case, expand OSD support no longer
>         works (as in #2 above).

I still have no idea why this happens.  Actually "-vf
expand=:::::16/9,scale -vo xv" looks the same as "-vf expand=:::::16/9
-vo x11 -zoom".  Not sure what's going on here.


Anyway, please review the attached patch and let me know if it's ok.  An
alternative approach which might be preferred (as it's vo-agnostic)
would be to have vf_expand call vf_next_draw_slice without any offsets
and pointing to a buffer full of zeroes before calling
vf_next_draw_slice again with the real slice (and with the offsets).
It's a bit lame, but it does have the advantage of working on all the
VOs.  Let me know if this is preferred and I'll work it up.

Thanks,
Jason.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xv-black-slice.patch
Type: text/x-patch
Size: 528 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20061230/5d0a0b1c/attachment.bin>