Hi Christopher, sure. For the test user, I just go to the top right cog menu, select ”Startup Applications…” and ”Add” Firefox (/usr/bin/firefox). Firefox remembers the window size, so I start it once (manually), maximize the window and then close it. On the next login, it should start maximized.
Verifying that for both test cases the issue is no longer reproducible with the proposed packages. In other words, results with packages from -proposed are as described in ”Expected:” for each test case. (For both cases the issue was reproducible here with 1:0.9.7.0~bzr19-0ubuntu10.)
jani@saegusa:~$ LC_ALL=C apt-cache policy compiz-plugins-main compiz-plugins-main-default
compiz-plugins-main:
Installed: 1:0.9.7.0~bzr19-0ubuntu10.1
Candidate: 1:0.9.7.0~bzr19-0ubuntu10.1
Version table:
*** 1:0.9.7.0~bzr19-0ubuntu10.1 0
500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
100 /var/lib/dpkg/status
1:0.9.7.0~bzr19-0ubuntu10 0
500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
compiz-plugins-main-default:
Installed: 1:0.9.7.0~bzr19-0ubuntu10.1
Candidate: 1:0.9.7.0~bzr19-0ubuntu10.1
Version table:
*** 1:0.9.7.0~bzr19-0ubuntu10.1 0
500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
100 /var/lib/dpkg/status
1:0.9.7.0~bzr19-0ubuntu10 0
500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
I tested 5.20 from Shuduo’s PPA and for me it reproduces the issue just the same as -proposed. To be sure, I then went back down to release versions in all the other packages (so that the only change wrt. released is again just Unity being 5.20, just now from the PPA), and the issue remained. Downgrade Unity to 5.18 and it again goes away.
But this looks like a speed issue, so Unity may not be directly at fault: any apps started once the desktop is fully loaded open as truly maximized, so a workaround is setting autostarted apps to start after a delay. Perhaps Unity going from 5.18 to 5.20 here causes just enough delay for those apps to start before whatever the component is that should fuse the menus with appindicator. The autostarting facility should wait for that component, or the component should be also able to fuse menus for existing windows once it gets up and running.
Incidentally, any appindicator-related packages’ versions also don’t seem to matter for this once Unity is 5.20. I think I’ll try upgrading just those to their -proposed versions next (so that Unity remains at 5.18) just to cover all angles.
With Unity 5.20.0-0ubuntu1 from -proposed, maximized windows opened during login by autostarting apps have their top bar visible underneath the desktop top bar (indicator-appmenu) as if unmaximized, but with the window ’maximize’ button indicating a maximized window – i.e. first click on it results in the window getting smaller. The second click on it then actually maximizes the window so that the top bar merges into the desktop top bar (indicator-appmenu).
This problem appears consistently on every login, after I’ve enabled -proposed and installed Unity 5.20 from there. It never appears when I have 5.18 from -updates. Annoyingly, I am unable to reproduce it in a VM (for a nice demonstration video), but I am able to reproduce it with a newly created user account on the host (i.e. without the configuration from my main user account).
I could’ve taken a screenshot of how it looks right after login. I’ll do that in a minute.
Edit: autostarting apps.
Hi Daniel. As I commented above, this is still reproducible in Saucy (I’m attaching a screenshot). Does this mean it’s a bug in avconv and not in libvpx, or did I misunderstand you?
Just reproduced this in Raring and Saucy. The latter currently has libvpx 1.2.0-2 which supposedly contains the fix I linked to above, so I’m not so sure about it anymore.
With some input video (such as LQ MP4 from [1]), the second pass fails when a preset enabling automatic placement of alternate reference frames with ”auto-alt-ref=1” (such as all of those provided by libav-tools) is used. (Example of non-problematic input is MP4 from [2].) This is apparently an upstream issue, already fixed in v1.1.0-184-g429743c [3].
Steps to reproduce:
1. wget ’http://archive.org/download/Mario2_919/Mario2_919_LQ.avi’
2. avconv -y -i Mario2_919_LQ.avi -c:v libvpx -pre libvpx-360p -pass 1 -an -sn -t 1 out.webm
3. avconv -y -i Mario2_919_LQ.avi -c:v libvpx -pre libvpx-360p -pass 2 -an -sn -t 1 out.webm
What happens:
The second pass ends with:
[webm @ 0x7ab6c0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 100 >= 100
av_interleaved_write_frame(): Invalid argument
What I expect to happen:
The second pass to finish successfully.
Workaround:
Copy preset file to ˝/.avconv/, comment out (#) auto-alt-ref=1.
*[1] http://archive.org/details/Mario2_919
*[2] http://archive.org/details/014674
*[3] http://code.google.com/p/webm/issues/detail?id=468#issueheader
I just tried this in Raring, and there it seems avconv now (correctly) errors out if using ”-preset”.
Apparently avconv silently ignores a ”-preset” option passed to it on the command-line. The correct option for passing a preset file is -pre, but -preset behaves differently from other incorrect options, as no error message is output and the avconv command is executed if otherwise valid. Not erroring out on erroneous usage is confusing, particularly with presets, as the output also does not specifically say when a preset *is* being applied (you have to deduce it from the data). Unless -preset is currently being used as a placeholder in the source, I suggest it be made to error out as other incorrect options do.
I’m pasting output from five demonstration runs below. 1) is an example of correct usage of -pre, 2) of correct usage of -pre with non-existing preset, 3) of trying to use a non-existing option -asdf, and 4) of using -preset in place of -pre, one run with an existing and one with a non-existing preset name.
1) Correct usage of -pre, as indicated by ”q=0-63” (which gets read from /usr/share/avconv/libvpx-360p.avpreset):
jani@saegusa:avconv-preset-test$ avconv -y -i input.mpeg -c:v libvpx -pre libvpx-360p -an -t 1 out.webm
avconv version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013 the Libav developers
built on Apr 2 2013 17:02:36 with gcc 4.6.3
[mpeg @ 0x1bae9c0] max_analyze_duration reached
Input #0, mpeg, from ’input.mpeg’:
Duration: 01:43:01.65, start: 0.184656, bitrate: 2632 kb/s
Stream #0.0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720×576 [PAR 16:15 DAR 4:3], 1844 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 224 kb/s
[buffer @ 0x1bb0060] w:720 h:576 pixfmt:yuv420p
[libvpx @ 0x1baf380] v1.0.0
Output #0, webm, to ’out.webm’:
Metadata:
encoder : Lavf53.21.1
Stream #0.0: Video: libvpx, yuv420p, 720×576 [PAR 16:15 DAR 4:3], q=0-63, 768 kb/s, 1k tbn, 25 tbc
Stream mapping:
Stream #0:0 -> #0:0 (mpeg2video -> libvpx)
Press ctrl-c to stop encoding
frame= 25 fps= 13 q=0.0 Lsize= 95kB time=1.00 bitrate= 778.2kbits/s
video:94kB audio:0kB global headers:0kB muxing overhead 0.681033%
2) Correct usage of -pre with non-existing preset, as indicated by ”could not be opened” error message:
jani@saegusa:avconv-preset-test$ avconv -y -i input.mpeg -c:v libvpx -pre xlibvpx-360p -an -t 1 out.webm
avconv version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013 the Libav developers
built on Apr 2 2013 17:02:36 with gcc 4.6.3
[mpeg @ 0x8f99c0] max_analyze_duration reached
Input #0, mpeg, from ’input.mpeg’:
Duration: 01:43:01.65, start: 0.184656, bitrate: 2632 kb/s
Stream #0.0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720×576 [PAR 16:15 DAR 4:3], 1844 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 224 kb/s
Preset xlibvpx-360p specified for stream 0:0, but could not be opened.
3) Trying to use non-existing option -asdf, as indicated by ”Unrecognized option” error message:
jani@saegusa:avconv-preset-test$ avconv -y -i input.mpeg -c:v libvpx -asdf libvpx-360p -an -t 1 out.webm
avconv version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013 the Libav developers
built on Apr 2 2013 17:02:36 with gcc 4.6.3
[mpeg @ 0x6829c0] max_analyze_duration reached
Input #0, mpeg, from ’input.mpeg’:
Duration: 01:43:01.65, start: 0.184656, bitrate: 2632 kb/s
Stream #0.0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720×576 [PAR 16:15 DAR 4:3], 1844 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 224 kb/s
Unrecognized option ’asdf’
Failed to set value ’libvpx-360p’ for option ’asdf’
4) Now, using -preset instead of -pre, regardless of validity of the parameter passed to it, the preset specified is not loaded, as indicated by ”q=-1–1”, but no ”Unrecognized option” error occurs:
jani@saegusa:avconv-preset-test$ avconv -y -i input.mpeg -c:v libvpx -preset libvpx-360p -an -t 1 out.webm
avconv version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013 the Libav developers
built on Apr 2 2013 17:02:36 with gcc 4.6.3
[mpeg @ 0xbe69c0] max_analyze_duration reached
Input #0, mpeg, from ’input.mpeg’:
Duration: 01:43:01.65, start: 0.184656, bitrate: 2632 kb/s
Stream #0.0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720×576 [PAR 16:15 DAR 4:3], 1844 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 224 kb/s
[buffer @ 0xbeef60] w:720 h:576 pixfmt:yuv420p
[libvpx @ 0xbe7380] v1.0.0
Output #0, webm, to ’out.webm’:
Metadata:
encoder : Lavf53.21.1
Stream #0.0: Video: libvpx, yuv420p, 720×576 [PAR 16:15 DAR 4:3], q=-1–1, 200 kb/s, 1k tbn, 25 tbc
Stream mapping:
Stream #0:0 -> #0:0 (mpeg2video -> libvpx)
Press ctrl-c to stop encoding
frame= 25 fps= 17 q=0.0 Lsize= 25kB time=1.00 bitrate= 208.2kbits/s
video:25kB audio:0kB global headers:0kB muxing overhead 2.589469%
jani@saegusa:avconv-preset-test$ avconv -y -i input.mpeg -c:v libvpx -preset xlibvpx-360p -an -t 1 out.webm
avconv version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013 the Libav developers
built on Apr 2 2013 17:02:36 with gcc 4.6.3
[mpeg @ 0x163a9c0] max_analyze_duration reached
Input #0, mpeg, from ’input.mpeg’:
Duration: 01:43:01.65, start: 0.184656, bitrate: 2632 kb/s
Stream #0.0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720×576 [PAR 16:15 DAR 4:3], 1844 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 224 kb/s
[buffer @ 0x1642f60] w:720 h:576 pixfmt:yuv420p
[libvpx @ 0x163b380] v1.0.0
Output #0, webm, to ’out.webm’:
Metadata:
encoder : Lavf53.21.1
Stream #0.0: Video: libvpx, yuv420p, 720×576 [PAR 16:15 DAR 4:3], q=-1–1, 200 kb/s, 1k tbn, 25 tbc
Stream mapping:
Stream #0:0 -> #0:0 (mpeg2video -> libvpx)
Press ctrl-c to stop encoding
frame= 25 fps= 17 q=0.0 Lsize= 25kB time=1.00 bitrate= 208.2kbits/s
video:25kB audio:0kB global headers:0kB muxing overhead 2.589469%
After commenting out the one line in my (/usr/share/doc/devilspie/README-suggested test) script, devilspie gets an assertion failure when reading it.
jani@saegusa:~$ cat .devilspie/test.ds
;(debug)
jani@saegusa:~$ devilspie
got eof
** (devilspie:7126): CRITICAL **: e_sexp_eval: assertion `f->tree != NULL’ failed
** (devilspie:7126): CRITICAL **: e_sexp_eval: assertion `f->tree != NULL’ failed
** (devilspie:7126): CRITICAL **: e_sexp_eval: assertion `f->tree != NULL’ failed
** (devilspie:7126): CRITICAL **: e_sexp_eval: assertion `f->tree != NULL’ failed
** (devilspie:7126): CRITICAL **: e_sexp_eval: assertion `f->tree != NULL’ failed
** (devilspie:7126): CRITICAL **: e_sexp_eval: assertion `f->tree != NULL’ failed
** (devilspie:7126): CRITICAL **: e_sexp_eval: assertion `f->tree != NULL’ failed
** (devilspie:7126): CRITICAL **: e_sexp_eval: assertion `f->tree != NULL’ failed
** (devilspie:7126): CRITICAL **: e_sexp_eval: assertion `f->tree != NULL’ failed
According to Debian’s bug report [1] on the issue, this occurs for all semantically empty scripts.
*[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412042