All 3 entries tagged <em>Opensuse</em>Mike Willisit's just this blag, y'know?https://blogs.warwick.ac.uk/mikewillis/tag/opensuse/?atom=atomWarwick Blogs, University of Warwick(C) 2024 Mike Willis2024-03-29T08:44:30ZCodec support for openSUSE Leap 42.1 by Mike WillisMike Willishttps://blogs.warwick.ac.uk/mikewillis/entry/codec_support_for/2016-07-26T19:11:55Z2016-07-26T19:11:36Z<p>Do you use openSUSE Leap 42.1? Do you want Twitter to stop displaying "This browser does not support video playback." when you're looking at it in Firefox? Do you want support for stuff like watching DVDs and H.264/ACC in an mp4 container in gstreamer (used by the GNOME Videos application (Totem), Parole and others)? Do you want to do these things without polluting your install by adding third party repositories and replacing packages provided by openSUSE? Do you want to do that stuff on a machine you don't have root on? If you answered yes to any of the previous questions, keep reading.<br />
<br />
For some years I used to maintain machines running SUSE Linux Enterprise Desktop and rolled my own solution for adding codec support to them by way of a single package that doesn't conflict with anything provided by SUSE. (The last iteration can be found at <a href="https://www.suse.com/communities/blog/additional-multimedia-codec-support-sled-12/">https://www.suse.com/communities/blog/additional-multimedia-codec-support-sled-12/</a>) Having installed openSUSE Leap 42.1 I found that the recommend method for adding codec support was a page which said something like "this isn't available for technical reasons try this other place" and that other place talked about the phonon backend with no mention of gstreamer. Then I decided to build my own solution for openSUSE too. You can get it by clicking <a class="downloadLink image_tbz" href="/files/mikewillis/multimediacodecs_opensuseleap421.tbz">Stuff to add codec support to openSUSE Leap 42.1</a><br />
<br />
<br />
You need to read the README.txt file for full details, but to give you an idea of what’s involved, the build process is as follows:<br />
<br />
</p>
<pre>$ ./build<br /></pre>
<p><br />
It'll tell you if there are packages you need to install. Install those, then run the script again. By default the plugins will be built to live in /opt/multimedia If you want them to live somewhere else then change the line<br />
</p>
<pre>prefix=/opt/multimedia;</pre>
<p>to reflect where you want to put them. E.g if you want them in your home directory you could use</p>
<pre>prefix="${HOME}/.multimedia";</pre>
<p>By default an rpm will be built but if you set the prefix to something in your home directory the rpm won’t be built as it’s assumed you’re specifying your home directory as the prefix because you don’t have root and hence can’t install an rpm.</p>
<p>What the script basically does is build a bunch of gstreamer plugins, stick them somewhere they don't clash with what's in openSUSE packages, and put something in place so gstreamer can find them. Making Firefox play videos in Twitter rather than display the "This browser does not support video playback." is done by including ffmpeg, which Firefox will use for video playback if it's installed. (Far as I can tell, the significant file is libavcodec.so. The ffmpeg binaries like ffmpeg, ffserver etc are also included.)</p>
<p>There's nothing for hardware decoding of H.264 included. I have an Nvidia card and use the propriety Nvidia drivers. I can get hardware acceleration for H.264 by installing gstreamer-plugins-vaapi which is in the standard Leap 42.1 repos. Unfortunately installing it renders Totem unable to play H.264 video. It displays black for a few seconds than borks. The version of gstreamer-plugins-vaapi included in Leap 42.1 is 0.5.10. I found that 0.7.0 is the latest version that will build with gstreamer 1.4.5 that's included in Leap, but that didn't work any better for me. (Seems it did for this guy though <a href="https://blogs.gnome.org/ovitters/2015/12/23/hardware-accelerated-video-playing-with-totem/bl">https://blogs.gnome.org/ovitters/2015/12/23/hardware-accelerated-video-playing-with-totem/bl</a> ). Parole, the XFCE video application, works though. It uses GTK and gstreamer and works fine in GNOME. If you want to get minimalist about it, you could also use gst-play-1.0</p>
<pre>$ gst-play-1.0 --interactive video.mp4</pre><p>Do you use openSUSE Leap 42.1? Do you want Twitter to stop displaying "This browser does not support video playback." when you're looking at it in Firefox? Do you want support for stuff like watching DVDs and H.264/ACC in an mp4 container in gstreamer (used by the GNOME Videos application (Totem), Parole and others)? Do you want to do these things without polluting your install by adding third party repositories and replacing packages provided by openSUSE? Do you want to do that stuff on a machine you don't have root on? If you answered yes to any of the previous questions, keep reading.<br />
<br />
For some years I used to maintain machines running SUSE Linux Enterprise Desktop and rolled my own solution for adding codec support to them by way of a single package that doesn't conflict with anything provided by SUSE. (The last iteration can be found at <a href="https://www.suse.com/communities/blog/additional-multimedia-codec-support-sled-12/">https://www.suse.com/communities/blog/additional-multimedia-codec-support-sled-12/</a>) Having installed openSUSE Leap 42.1 I found that the recommend method for adding codec support was a page which said something like "this isn't available for technical reasons try this other place" and that other place talked about the phonon backend with no mention of gstreamer. Then I decided to build my own solution for openSUSE too. You can get it by clicking <a class="downloadLink image_tbz" href="/files/mikewillis/multimediacodecs_opensuseleap421.tbz">Stuff to add codec support to openSUSE Leap 42.1</a><br />
<br />
<br />
You need to read the README.txt file for full details, but to give you an idea of what’s involved, the build process is as follows:<br />
<br />
</p>
<pre>$ ./build<br /></pre>
<p><br />
It'll tell you if there are packages you need to install. Install those, then run the script again. By default the plugins will be built to live in /opt/multimedia If you want them to live somewhere else then change the line<br />
</p>
<pre>prefix=/opt/multimedia;</pre>
<p>to reflect where you want to put them. E.g if you want them in your home directory you could use</p>
<pre>prefix="${HOME}/.multimedia";</pre>
<p>By default an rpm will be built but if you set the prefix to something in your home directory the rpm won’t be built as it’s assumed you’re specifying your home directory as the prefix because you don’t have root and hence can’t install an rpm.</p>
<p>What the script basically does is build a bunch of gstreamer plugins, stick them somewhere they don't clash with what's in openSUSE packages, and put something in place so gstreamer can find them. Making Firefox play videos in Twitter rather than display the "This browser does not support video playback." is done by including ffmpeg, which Firefox will use for video playback if it's installed. (Far as I can tell, the significant file is libavcodec.so. The ffmpeg binaries like ffmpeg, ffserver etc are also included.)</p>
<p>There's nothing for hardware decoding of H.264 included. I have an Nvidia card and use the propriety Nvidia drivers. I can get hardware acceleration for H.264 by installing gstreamer-plugins-vaapi which is in the standard Leap 42.1 repos. Unfortunately installing it renders Totem unable to play H.264 video. It displays black for a few seconds than borks. The version of gstreamer-plugins-vaapi included in Leap 42.1 is 0.5.10. I found that 0.7.0 is the latest version that will build with gstreamer 1.4.5 that's included in Leap, but that didn't work any better for me. (Seems it did for this guy though <a href="https://blogs.gnome.org/ovitters/2015/12/23/hardware-accelerated-video-playing-with-totem/bl">https://blogs.gnome.org/ovitters/2015/12/23/hardware-accelerated-video-playing-with-totem/bl</a> ). Parole, the XFCE video application, works though. It uses GTK and gstreamer and works fine in GNOME. If you want to get minimalist about it, you could also use gst-play-1.0</p>
<pre>$ gst-play-1.0 --interactive video.mp4</pre>0zypper equivalent of yum --downloadonly by Mike WillisMike Willishttps://blogs.warwick.ac.uk/mikewillis/entry/zypper_equivalent_of/2009-05-19T11:15:08Z2009-02-02T12:28:10Z<p>Looking at moving from yum to zypper I found myself unable to work out how to get <a href="http://en.opensuse.org/Zypper">zypper</a> to download packages but not install them. Yum can do this with the downloadonly plugin:</p>
<pre>yum -y update --downloadonly</pre>
<p>According to this <a href="https://bugzilla.novell.com/show_bug.cgi?id=348733">bug report</a>, zypper should be able to do it but I couldn't find any explanation as to how. In the end I emailed the guy who marked that bug report as fixed and he was kind enough to reply and point me in the direction of the keep-packages option. This is a per-repo setting which means download packages are kept in cache. Knowing this a Google search took me <a href="http://en.opensuse.org/Zypper/Changes/11.0">here</a> where it is mentioned along with the --dry-run option. So to get zypper to download updates but not install them, enable caching of packages on all repos with</p>
<pre>zypper mr -k -all</pre>
<p>and then use</p>
<pre>zypper -l -y update --dry-run</pre>
<p><br />
</p>
<p><br />
</p><p>Looking at moving from yum to zypper I found myself unable to work out how to get <a href="http://en.opensuse.org/Zypper">zypper</a> to download packages but not install them. Yum can do this with the downloadonly plugin:</p>
<pre>yum -y update --downloadonly</pre>
<p>According to this <a href="https://bugzilla.novell.com/show_bug.cgi?id=348733">bug report</a>, zypper should be able to do it but I couldn't find any explanation as to how. In the end I emailed the guy who marked that bug report as fixed and he was kind enough to reply and point me in the direction of the keep-packages option. This is a per-repo setting which means download packages are kept in cache. Knowing this a Google search took me <a href="http://en.opensuse.org/Zypper/Changes/11.0">here</a> where it is mentioned along with the --dry-run option. So to get zypper to download updates but not install them, enable caching of packages on all repos with</p>
<pre>zypper mr -k -all</pre>
<p>and then use</p>
<pre>zypper -l -y update --dry-run</pre>
<p><br />
</p>
<p><br />
</p>0Altering AutoYaST profiles on the fly... by Mike WillisMike Willishttps://blogs.warwick.ac.uk/mikewillis/entry/altering_autoyast_profiles_1/2008-11-05T13:24:22Z2008-11-05T13:24:22Z<p>...or: How to have one or more variants of an AutoYaST profile without having to actually maintain them.<br />
<br />
Say you maintain a bunch of machines running some SUSE variant, you install them using AutoYaST so they're all identical but you find that sometimes you want to install a machine in a way which is slightly different to normal. For example, you want to be able to re-install a machine whilst preserving the contents of a particular partition. This presents a problem because it means you need more than one AutoYaST profile, the one you usually use and the variant. If you change the main profile you have to make the same changes to the variant. Maintaining a variant is going to be prone to human error, forgetfulness and possibly problems could be caused by trying to use a variant which you don't realise hasn't been maintained.<br />
</p>
<p>Faced with such a situation myself a neat solution occurred to me. My AutoYaST profile is accessed from a web sever at time of installation, so a script on the web server can be used to manipulate the XML on the fly and serve the modified version. This way only one AutoYaST profile has to be maintained but you can can have as many variants of it as you like provided you write a script to produce that variant. E.g. This PHP:<br />
</p>
<pre><?php<br /># reads the autoinst.xml file, alters the partition config data so that<br /># partitions are re-used rather than created, and /local is not formatted<br /># then outputs the new xml.<br /><br />$sourcexmlfile="autoyast.xml";<br /><br />$data=simplexml_load_file($sourcexmlfile);<br /><br />foreach ($data->partitioning->drive->partitions->partition as $partition) {<br /> $partition->create="false";<br /> if ($partition->mount=="/local") $partition->format="false";<br />}<br /><br />header('Content-Type: text/xml');<br />print $data->asXML();<br />?><br /></pre>
<p>saved as a suitably named file on the web server and it's url provided as the source of the AutoYaST profile at install time allows machines to be re-installed whilst preserving the contents of the partition that gets mounted at /local.</p><p>...or: How to have one or more variants of an AutoYaST profile without having to actually maintain them.<br />
<br />
Say you maintain a bunch of machines running some SUSE variant, you install them using AutoYaST so they're all identical but you find that sometimes you want to install a machine in a way which is slightly different to normal. For example, you want to be able to re-install a machine whilst preserving the contents of a particular partition. This presents a problem because it means you need more than one AutoYaST profile, the one you usually use and the variant. If you change the main profile you have to make the same changes to the variant. Maintaining a variant is going to be prone to human error, forgetfulness and possibly problems could be caused by trying to use a variant which you don't realise hasn't been maintained.<br />
</p>
<p>Faced with such a situation myself a neat solution occurred to me. My AutoYaST profile is accessed from a web sever at time of installation, so a script on the web server can be used to manipulate the XML on the fly and serve the modified version. This way only one AutoYaST profile has to be maintained but you can can have as many variants of it as you like provided you write a script to produce that variant. E.g. This PHP:<br />
</p>
<pre><?php<br /># reads the autoinst.xml file, alters the partition config data so that<br /># partitions are re-used rather than created, and /local is not formatted<br /># then outputs the new xml.<br /><br />$sourcexmlfile="autoyast.xml";<br /><br />$data=simplexml_load_file($sourcexmlfile);<br /><br />foreach ($data->partitioning->drive->partitions->partition as $partition) {<br /> $partition->create="false";<br /> if ($partition->mount=="/local") $partition->format="false";<br />}<br /><br />header('Content-Type: text/xml');<br />print $data->asXML();<br />?><br /></pre>
<p>saved as a suitably named file on the web server and it's url provided as the source of the AutoYaST profile at install time allows machines to be re-installed whilst preserving the contents of the partition that gets mounted at /local.</p>0