[MPlayer-dev-eng] mplayer 1.4.0 release

Erik Auerswald auerswal at unix-ag.uni-kl.de
Tue Apr 9 23:55:00 EEST 2019


Hi,

On Tue, Apr 09, 2019 at 01:03:20AM +0200, Alexander Strasser wrote:
> On 2019-04-06 23:28 +0200, Erik Auerswald wrote:
> > On 4/6/19 22:18, Alexander Strasser wrote:
> > > On 2019-04-04 09:14 +0200, Erik Auerswald wrote:
> > > > On Wed, Apr 03, 2019 at 11:51:58PM +0200, Alexander Strasser wrote:
> > > >
> > > > > I will have a look into the vo xv issues. Sounds like it could be
> > > > > a regression.
> > > >
> > > > There have been just a few commits to vo_xv.c since the release of
> > > > 1.3.0, but I did not see anything obviously problematic. An older commit
> > > > pertained to setting the background color (according to the commit log),
> > > > but I did not look at that patch. But then I do not know that code at all.
> > > >
> > > > It seems as if the borders are actually drawn, but not in black, but
> > > > using some other memory contents, sometimes from the video, sometimes
> > > > from the root window ("desktop"). It does not look as if unitialized
> > > > memory is copied.
> > > >
> > > > Since the commits since 1.3.0 pertained to formats: on the 18.04 system
> > > > MPlayer reports "VO: [xv] 1280x720 => 1280x720 Planar YV12".
> > >
> > > Did that line change compared to the version you didn't have the
> > > border drawing problems?
> >
> > No, it did not.
> >
> > More data points:
> >
> > - Fullscreen black borders work with current SVN without an external
> >   monitor connected (Ubuntu 18.04).
> >
> > - Maximising the video image results in wrong image content instead
> >   of black bars with current SVN (all tested systems and
> >   configurations).
> 
> It's a regression since r33522 (May 2011)
> 
> I suspect a debugging modification sneaked in. If I make the
> following change, borders look fine again:
> 
> --- a/libvo/vo_xv.c
> +++ b/libvo/vo_xv.c
> @@ -139,7 +139,7 @@ static void deallocate_xvimage(int foo);
>  static void resize(void)
>  {
>      calc_src_dst_rects(image_width, image_height, &src_rect, &dst_rect, NULL, NULL);
> -//    vo_x11_clearwindow_part(mDisplay, vo_window, dst_rect.width, dst_rect.height, vo_fs);
> +    vo_x11_clearwindow_part(mDisplay, vo_window, dst_rect.width, dst_rect.height, vo_fs);
>      vo_xv_draw_colorkey(dst_rect.left, dst_rect.top, dst_rect.width, dst_rect.height);
>  }

I have just tested this, it does improve the situation, but it is not
yet completely correct.

The problem occurs only when the window aspect does not match the movie
aspect (otherwise no black bars would be needed).

The problem seems to primarily occur when the MPlayer window aspect
changes. For example, one video with the same vertical resolution as my
screen (1080 on the build-in laptop screen of the Ubuntu 18.04 machine)
will show wrong image content on the sides in window mode. I think
MPlayer will try to open a window with vertical size 1080, which is
prevented by Gnome. The result is a window of the original horizontal
size, but reduced vertical size, needing black bars on the right and
left sides. Those are not drawn. Using -vo gl or -vo gl2 works fine,
i.e. the needed black borders are drawn.

MPlayer prints:

    Movie-Aspect is 1.34:1 - prescaling to correct movie aspect.
    VO: [xv] 1444x1080 => 1444x1080 Planar YV12 

The window geometry is:

    xwininfo: Window id: 0x2e00001 "MPlayer"
    [...]
    -geometry 1444x1023+103-0

This happens easily while resizing for example on Ubuntu 14.04 with
Unity, which allows arbitrary window aspects when manually resizing. It
happens on both Ubuntu 14.04 with Unity and Ubuntu 18.04 with Gnome when
maximizing a window, because the top bar and the panel on the side of
the desktop result in window aspect ratio changes in regard to fullscreen
or initial window aspect ratios.

Another info point: the commented out call to vo_x11_clearwindow_part()
in libvo/vo_xv.c is present in the Ubuntu 18.04 version of MPlayer 1.3.0,
but that version does not exhibit said problems. (I have checked the
.orig.tar.xz and the patches applied during the build process, but have
not build the package from its sources.) This seems to be something else.

Thanks,
Erik
-- 
Reality continues to ruin my life.
                        -- Calvin


More information about the MPlayer-dev-eng mailing list