Bug#699394: gnome-mplayer: [Ctrl+T] fails to take screenshot

Sun Feb 3 17:38:17 UTC 2013

On Sun, 3 Feb 2013 14:37:58 +0100 Sebastian Ramacher wrote:

[...]
> The code to take the screenshots is in gtmk, hence I'm reassigning it to
> gmtk.

OK, thanks!

> The patch to display an error message if mplayer failed to take a
> screenshot is attached. This patch has been applied upstream.

Very good, thanks for preparing it!

> 
> On 2013-02-01 19:25:03, Francesco Poli wrote:
> > > > I've installed mplayer (instead of mplayer2) to
> > > > check if that might be a problem and in fact it is. With mplayer I can
> > > > see the same error message in the log.
> > 
> > Woah!  I hadn't noticed the mplayer2 package in Debian!
> > Shame on me: I see that it's in testing since 2011...
> > 
> > Is it mature enough to replace mplayer?
> 
> I haven't had any problems with it so far.

Thanks for replying: I am giving it a try right now.
Let's see...

> 
> > > My analysis is wrong. It also depends on the video output used. In any
> > > case, an error message would be appropriate.
> > 
> > In this case, maybe my mplayer configuration can help to pinpoint the
> > issue:
> > 
> >   $ cat ~/.mplayer/config 
> >   [default]
> >   ao=jack,alsa
> >   volume=20 
> >   vo=xv
> 
> There is some special casing based on the selected vo, but the vo
> selected in ~/.mplayer/config is ignored in gnome-mplayer.

This is not good at all, in my own personal opinion.
I would rather avoid configuring the same program (mplayer) over and
over again, just because I use it through different interfaces!

> So there are
> some things left I want you to try: explicitly select the vo in
> gnome-mplayer's preferences, try to take a screenshot with both mplayer
> and mplayer2 and maybe also try another vo.
> 
> I'm not familiar enough with all the quirks of the different video
> outputs, so I need to rely on upstream's understanding of them.

I tried to test all the available options for the video output in
gnome-mplayer (with mplayer) and found the following awkward results.

Leaving the setting blank seems to automatically select xv, according
to the verbose output:
  GMLIB-Message: VO: [xv] 400x304 => 400x304 Planar YV12 
but screenshots do not work:
  GMLIB-Message: sending VFCTRL_SCREENSHOT!
  GMLIB-Message: failed (forgot -vf screenshot?)

Explicitly selecting xv works:
  GMLIB-Message: VO: [xv] 400x304 => 400x304 Planar YV12
and screenshots may be taken:
  GMLIB-Message: sending VFCTRL_SCREENSHOT!
  GMLIB-Message: *** screenshot 'shot0001.png' ***

Selecting gl works:
  GMLIB-Message: VO: [gl] 400x304 => 400x304 Planar YV12
and screenshots may be taken:
  GMLIB-Message: sending VFCTRL_SCREENSHOT!
  GMLIB-Message: *** screenshot 'shot0002.png' ***

Selecting gl2 works:
  GMLIB-Message: VO: [gl2] 400x304 => 400x304 Planar YV12
and screenshots may be taken:
  GMLIB-Message: sending VFCTRL_SCREENSHOT!
  GMLIB-Message: *** screenshot 'shot0003.png' ***

Selecting x11 works:
  GMLIB-Message: VO: [x11] 400x304 => 400x304 Planar YV12  [zoom]
and screenshots may be taken:
  GMLIB-Message: sending VFCTRL_SCREENSHOT!
  GMLIB-Message: *** screenshot 'shot0004.png' ***

Selecting vdpau seems to lead to gl being used:
  GMLIB-Message: VO: [gl] 400x304 => 400x304 Planar YV12
but screenshots do not work:
  GMLIB-Message: sending VFCTRL_SCREENSHOT!
  GMLIB-Message: failed (forgot -vf screenshot?)

Selecting xvmc or vaapi fails to work (high CPU load, endless stream
of error messages and no visible video...).

Then I installed mplayer2, thus removing the conflicting mplayer.

Explicitly selecting xv works:
  GMLIB-Message: VO: [xv] 400x304 => 400x304 Planar YV12
and screenshots may be taken, but a single [Ctrl+T] produces two identical
files:
  GMLIB-Message: *** screenshot 'shot0005.png' ***
  GMLIB-Message: *** screenshot 'shot0006.png' ***

Please note that
  $ diff -sq shot000[56].png
  Files shot0005.png and shot0006.png are identical

Leaving the setting blank seems to automatically select xv, according
to the verbose output:
  GMLIB-Message: VO: [xv] 400x304 => 400x304 Planar YV12 
and again screenshots may be taken, but a single [Ctrl+T] produces
two identical files:
  GMLIB-Message: *** screenshot 'shot0007.png' ***
  GMLIB-Message: *** screenshot 'shot0008.png' ***

Selecting gl works:
  GMLIB-Message: VO: [gl] 400x304 => 400x304 Planar YV12 
and (double identical) screenshots may be taken:
  GMLIB-Message: *** screenshot 'shot0009.png' ***
  GMLIB-Message: *** screenshot 'shot0010.png' ***

Selecting x11 works:
  GMLIB-Message: VO: [x11] 400x304 => 400x304 Planar YV12  [zoom]
and single screenshots may be taken:
  GMLIB-Message: No VO support for taking screenshots, trying VFCTRL_SCREENSHOT!
  GMLIB-Message: No VO support for taking screenshots, trying VFCTRL_SCREENSHOT!
  GMLIB-Message: *** screenshot 'shot0011.png' ***

Selecting vdpau seems to lead to gl being used:
  GMLIB-Message: VO: [gl] 400x304 => 400x304 Planar YV12
and single screenshots may be taken:
  GMLIB-Message: *** screenshot 'shot0012.png' ***

Selecting xvmc seems to lead to xv being used:
  GMLIB-Message: VO: [xv] 400x304 => 400x304 Planar YV12
and single screenshots may be taken:
  GMLIB-Message: *** screenshot 'shot0013.png' ***

Selecting gl2 or vaapi fails to work (high CPU load, endless stream
of error messages and no visible video...).

OK, after this systematic test of all the options, I must confess that
I have no idea of which I should actually choose...  :-(

Please help!  :p

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20130203/98e09f7b/attachment-0001.pgp>