ABC iView Flash file blacking out on playback

The same problem afflicts the new 11.04 release Banshee Media Player when trying to playback video files of any type.
It occurs on this PC with a half Gb of RAM and on my second desktop PC, also with 11.04 Natty just installed and all updates checked and installed, which has One Gb of RAM. Both are older PCs that must default to the classic GUI rather than the stunning new Unity GUI that works on my Toshiba laptop. I will check whether what appears to my untrained eye to be an issue with the new video drivers on my laptop running the Unity GUi and report back momentarily.

The 7 year old Toshiba laptop running the Unity GUI has no issue with playing videos. Seems to be a backwards compatibility issue with PCs that must use the Ubuntu 10 style classic GUI. Hope that helps.

Still unable to play any video files on any media player that comes with 11.04 Natty Narwhal. Likely cause the newly upgraded (from ubuntu 10.10) video drivers.

Is flashplugin-installer still installed after the upgrade?

Given that you think this is caused by the new video driver in Ubuntu 11.04, please attach the output of lspci -vvnn

Well, I just uninstalled / reinstalled flashplugin-installer using the
software centre to be sure, then restarted the PC, logged in then ran
media player by itself. Sound was fine as before but, also as before, an
image is only available for a fraction of a second if I drag to move
then drop the media player window. As an alternative, I recently
installed VLC media player, which works fine. As for attaching the
output of lspci -vvnn - not being a regular UNIX shell user, I am unsure
how to do that for you. Please advise and I shall be happy to assist
further.

On Sun, 2011-10-02 at 16:20 +0000, madbiologist wrote:

> Is flashplugin-installer still installed after the upgrade?
>
> Given that you think this is caused by the new video driver in Ubuntu
> 11.04, please attach the output of lspci -vvnn
>

Hmm. Interesting that VLC works and GStreamer based apps such as Totem and Banshee do not.

To attach the output of lspci -vvnn, start by opening a command prompt (this should be under Applications > Accessories > Terminal in the classic desktop). Then type "lspci -vvnn" without the quotation marks. You can either copy and paste the output into this bug report, or if you want to use our preferred method of attaching the input to this bug report you can redirect the output of that command to a file by typing "lspci -vvnn > filename.txt" then click "Add attachment or patch" at the bottom of this bug report, after which you will be prompted for the file to upload.

If you are able to attach the output of "glxinfo | grep render" as well that would be great. To run glxinfo you will first need to install mesa-utils. Note that you can only attach one file per comment.

Thanks so much for that help. Please find the output of lspci -vvnn attached.

Now here is the output of "glxinfo | grep render" from my desktop PC.

VGA compatible controller [0300]: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter [1039:6330] (prog-if 00 [VGA controller])

OpenGL renderer string: Software Rasterizer

I suspect these pieces of information point to the problem. The Linux SiS driver has not received much maintenance for some time, let alone development. In fact the 3D portion was recently dropped entirely by upstream Mesa - see http://www.phoronix.com/scan.php?page=news_item&px=OTg0Mg
The first release to go without these drivers will be Mesa 7.12 when released in January. Furthermore, according to http://dri.freedesktop.org/wiki/SiS "There is no DRI driver for "[SiS] 661/741/760 PCI/AGP" chipset..."

"Software Rasterizer" indicates that your system is not using the SiS graphics chip for hardware-accelerated OpenGL rendering (not surprising given that there is no driver), but instead has fallen back to the slower software-based (CPU) rendering.

In conclusion, unfortunately I doubt that there is much that can be done about this. The only slight hope is that future releases of Ubuntu (by then you would probably need to use the lighter Xubuntu or Lubuntu on that machine) will probably switch from using the classic softpipe software rasterizer to the newer and faster LLVMpipe software rasterizer. This has already occurred on Fedora 15 if you want to give that a try - I'm not sure if they have a version with a "light" desktop.

Yes that is unfortunate. I never thought that when I "upgraded" to
Ubuntu 11.04 from 10.x that I'd be stuck with a cumbersome (although
good in some respects) new GUI (which would not activate on anything but
my laptop and had to "revert to classic" on my desktop PCs) and my
movies would no longer play at all. In many ways 11.04 has been a mixed
blessing and a pest. I only wish that there was some way to undo and
revert to 10.10 or even 10.04 LTS. Oh well. VLC Media Player will have
to do the job for now, until I can save up for a less antique PC.
Cheers.

On Tue, 2011-10-04 at 16:30 +0000, madbiologist wrote:

> VGA compatible controller [0300]: Silicon Integrated Systems [SiS]
> 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter [1039:6330]
> (prog-if 00 [VGA controller])
>
> OpenGL renderer string: Software Rasterizer
>
> I suspect these pieces of information point to the problem. The Linux SiS driver has not received much maintenance for some time, let alone development. In fact the 3D portion was recently dropped entirely by upstream Mesa - see http://www.phoronix.com/scan.php?page=news_item&px=OTg0Mg
> The first release to go without these drivers will be Mesa 7.12 when released in January. Furthermore, according to http://dri.freedesktop.org/wiki/SiS "There is no DRI driver for "[SiS] 661/741/760 PCI/AGP" chipset..."
>
> "Software Rasterizer" indicates that your system is not using the SiS
> graphics chip for hardware-accelerated OpenGL rendering (not surprising
> given that there is no driver), but instead has fallen back to the
> slower software-based (CPU) rendering.
>
> In conclusion, unfortunately I doubt that there is much that can be done
> about this. The only slight hope is that future releases of Ubuntu (by
> then you would probably need to use the lighter Xubuntu or Lubuntu on
> that machine) will probably switch from using the classic softpipe
> software rasterizer to the newer and faster LLVMpipe software
> rasterizer. This has already occurred on Fedora 15 if you want to give
> that a try - I'm not sure if they have a version with a "light" desktop.
>

Yeah, your best bet for now is probably VLC. You can download Ubuntu 10.04 LTS from http://www.ubuntu.com/download/ubuntu/download but you would have to do a clean install. As far as I know it is not possible to downgrade to an earlier version, keeping config etc.

Do you mind if we close this bug as Wont Fix?

Sure, feel free to close the bug, but this demonstrates that more
testing needs to be done on older PCs before releasing new versions.
Not everyone can afford the latest and greatest and Ubuntu is supposed
to be developed mindful of community needs and widespread usefulness.
Cheers.

On Wed, 2011-10-05 at 14:06 +0000, madbiologist wrote:

> Yeah, your best bet for now is probably VLC. You can download Ubuntu
> 10.04 LTS from http://www.ubuntu.com/download/ubuntu/download but you
> would have to do a clean install. As far as I know it is not possible
> to downgrade to an earlier version, keeping config etc.
>
> Do you mind if we close this bug as Wont Fix?
>

I fully agree about the need for more testing. If I was you I'd be feeling pretty frustrated right now. Although I think Canonical could do more testing of Ubuntu before release, I would also like to say that testing is something that us users can help out with. Canonical do not have the money or staffing resources to purchase and test all the hardware out there. In this regard, it is disappointing that when you reported this bug immediately after the release of 11.04 (and therefore during the pre-alpha testing phase of 11.10), no one responded in a timely manner.

My observations over the last couple of years have been that even when issues are noticed promptly, it often takes a whole release cycle to correct them, due to may bugs being largely out of Ubuntu's hands as they are in upstream components. In this case the bug seems to be upstream in GStreamer and how it works under the VESA framebuffer + classic softpipe environment. The GStreamer developers are the ones with the most expertise in this area. However it is worth noting that some people, including Greg Kroah-Hartman from Novell/SUSE's kernel team have criticised Canonical/Ubuntu for constantly taking from upstream and giving very little back in the way of patches.

Sometimes it is necessary for various upstream projects, and even Ubuntu itself, to drop support for older hardware and/or software tools to be able to fix other bugs, and more importantly, to enable new features. The reasons described at the first link in comment #10 of this bug are a good example of that.

If this bug can be fixed at all for future releases of Ubuntu, we will have to get the upstream GStreamer developers to do it. I'm not sure whether much can be done given there is no DRI driver for the [SiS] 661/741/760 PCI/AGP chipset (see comment #10), but I'll talk to them. Before I do that, can you try playing the file directly by entering the following command in a terminal:

gst-launch-0.10 playbin2 uri=file:///$HOME/<path to file>

For example, I have a file called Insalata_Caprese_Rec_317_263427.mp4 in Ubuntu's default "Videos" directory, so I use:

gst-launch-0.10 playbin2 uri=file:///$HOME/Videos/Insalata_Caprese_Rec_317_263427.mp4

Please report what you see in the video, if anything, and what is printed in the terminal.

Also, please navigate to /var/log by issuing:

cd .. <ENTER>
cd .. <ENTER>
cd /var/log

and then get the relevant part from the dmesg file by issuing:

cat dmesg |grep drm

and attach the output to this bug report.

Thank you for your analyses and insights. I would suggest that to
advance to a new OS version, firstly one should not break what already
works well in the existing version, then provide some sort on
intelligence to detect what more modern and advanced features are
available on the receiving PC before implementing unusable changes that
break what would otherwise work. For example, 11.04 detected that this
particular PC did not have the necessary resources to run the Unity GUI
and defaulted to a slightly broken version of the version 10.x GUI. If
that intelligence could detect the inability to run the enhanced GUI,
surely it should have also detected a linked inability to run advanced
video playback functionality. It seems unfortunate (to a relative layman
such as myself) that the association between those two issues (advanced
display capability both for GUI and video) and was not recognised at the
time. Although I understand (having been an IT tech writer for years)
that such things can be missed in the turmoil of meeting a release date,
a little community testing might well have picked up that oversight.

Anyway, back to the issue at hand: I typed gst-launch-0.10 playbin2
uri=file:///$HOME/Videos/Aardman/wallaceloaf_10_xx_xx.flv at the
terminal prompt and the video played flawlessly in a small window that I
could resize to near full screen without playback issue (apart from a
momentary video blanking during resizing as the audio continued playing.
Except for the fact that there were no control icons available in that
window to pause or regulate the playback (and that at full screen size
the audio momentarily played catchup with proper synch) it worked a
treat.

Here's the shell output after playing the video.

> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> New clock: GstPulseSinkClock
> ERROR: from element /GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:vbin/GstAutoVideoSink:videosink/GstXvImageSink:videosink-actual-sink-xvimage: Output window was closed
> Additional debug info:
> xvimagesink.c(1318): gst_xvimagesink_handle_xevents (): /GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:vbin/GstAutoVideoSink:videosink/GstXvImageSink:videosink-actual-sink-xvimage
> Execution ended after 36872070286 ns.
> Setting pipeline to PAUSED ...
> Setting pipeline to READY ...
> Setting pipeline to NULL ...
> Freeing pipeline ...

As for getting the relevant part from the dmesg file by issuing: cat
dmesg |grep drm and attaching the output to this bug report. I typed in
that instruction into the shell but could find no output to attach from
that folder. Perhaps you could advise what to attach please. I also
tried to redirect that output to a text file but permission was denied
and when I tried to do so with the sudo command, after entering my
password, nothing seemed to happen.

Please be so kind as to advise where to find what to attach and what
part of the file you need.

Thanks in anticipation.

On Fri, 2011-10-07 at 15:09 +0000, madbiologist wrote:

> I fully agree about the need for more testing. If I was you I'd be
> feeling pretty frustrated right now. Although I ...

Wallace and Gromit! We have to get this working! :)

It is interesting that the direct GStreamer playback worked. I wonder if the problem is due to compositing, or to Totem, or both. We can also see in the terminal output that Xvideo is being used - I'm not sure if this is the case when playing the file in Totem. I presume the ERROR message appeared when you closed the window after 36.87 seconds of playback, before the end of the video.

I think I've just figured out why the dmesg grep for drm didn't work. Grep is a search tool and your result is likely to be expected if DRM (the kernel's Direct Rendering Manager) is not being used at all. I've just tried grepping dmesg for "gromit" and there was no output. So just attach the entire dmesg file:

cat dmesg > filename.txt

Don't forget to navigate to /var/log first.

Hopefully that will tell us what is going on graphics-wise in the kernel during boot.

Cracking cheese madbiologist!

Yes, I closed the playback window prematurely, as I did not have the
time to see the whole movie again just then. (It is one of the many
hundreds of ABC TV Australia shows I have stored thanks to Jeremy
Visser's wonderful Python iView application
https://jeremy.visser.name/2009/08/python-iview/ which legitimately
downloads shows available from the ABC iView site. It only works for
those of us living in the .au domain though.)

As the cat dmesg > whatever.txt cops a Permission denied response, even
after using my sudo command, I have attached the entire dmseg file
from /var/log/ as it is simply a plain text file anyway.

Hope that helps.

Cheers,

Michael

On Sat, 2011-10-08 at 16:07 +0000, madbiologist wrote:

> Wallace and Gromit! We have to get this working! :)
>
> It is interesting that the direct GStreamer playback worked. I wonder
> if the problem is due to compositing, or to Totem, or both. We can also
> see in the terminal output that Xvideo is being used - I'm not sure if
> this is the case when playing the file in Totem. I presume the ERROR
> message appeared when you closed the window after 36.87 seconds of
> playback, before the end of the video.
>
> I think I've just figured out why the dmesg grep for drm didn't work.
> Grep is a search tool and your result is likely to be expected if DRM
> (the kernel's Direct Rendering Manager) is not being used at all. I've
> just tried grepping dmesg for "gromit" and there was no output. So just
> attach the entire dmesg file:
>
> cat dmesg > filename.txt
>
> Don't forget to navigate to /var/log first.
>
> Hopefully that will tell us what is going on graphics-wise in the kernel
> during boot.
>

OK, there's not much in there at all. Only this:

[ 0.094984] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
[ 0.094988] vgaarb: loaded

and

[ 0.544767] Linux agpgart interface v0.103

and

[ 15.786051] agpgart-sis 0000:00:00.0: SiS chipset [1039/0661]

and

[ 15.954720] agpgart-sis 0000:00:00.0: AGP aperture is 64M @ 0xe0000000

I'll try and raise the GStreamer developers on IRC, although they may be busy preparing for the GStreamer Conference being held October 24 - 25, 2011 in Prague.

Thanks for the link. I'm a bit of an iView fan and have bookmarked the Python iView page.