[Sugar-devel] Installing gstreamer media codecs on XO-1

[Peter Robinson]

On Tue, Mar 20, 2012 at 7:29 AM, Kevin Mark <kevin.mark at verizon.net> wrote:
> On Tue, Mar 20, 2012 at 12:15:03PM +1100, David Leeming wrote:
>>
>> I have tried to install media codecs on an XO-1 running 11.3.0 so that we
>> can play FLV video files directly (from a flashdrive, school server or
>> network location)., in either Sugar or GNOME.
>>
>> I had trouble getting it work using the instructions at
>> http://wiki.laptop.org/go/GStreamer#Totem_plugin - I think it is outdated.
>>
>> After some research and trial and error (lots!!) I have it working, some
>> using XO-1 may find useful
>>
>> The below works on an XO-1 running 11.3.0 freshly installed. It works in
>> Gnome using Totem/Movie Player and in Sugar using Jukebox Activity. It plays
>> mp3 audio and FLV video OK (such as the Khan Academy collection, which we
>> have loaded on the school servers in project schools)
>>
>> We also add the Flash plug in for the browser and disable "click to view".
>> This allows embedded flash animations and FLV videos accessed with Browse,
>> Youtube, etc to play with good performance. Note that Flash version 11 is
>> much better than v10.
>>
>> So bringing it all together, I reproduced the above using the following.
>> - XO-1 running 11.3.0, fresh install
>> - In Gnome view in a terminal, as su
>> - wireless Internet connection
>>
>> yum localinstall --nogpgcheck
>> http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noa
>> rch.rpm
>> http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stab
>> le.noarch.rpm
>>
>> yum install -y gstreamer-plugins-ugly
>>
>> yum install -y gstreamer-ffmpeg
>>
>> rm /home/olpc/Activities/Browse.activity/agent-stylesheet.css
>>
>> rm /home/olpc/Activities/Browse.activity/clickToView.xml
>>
>> navigate to the flash rpm and run
>>
>> rpm -Uhv flash.rpm
>>
>> where flash.rpm is the Flash verion 11 RPM for Linux 32 bit from Adobe.
>>
>> Questions
>> 1. Is the above the right way to do it, if someone with more Fedora
>> experience than I can verify..
>> 2. In our narrowband countries it takes an hour and downloads a lot per
>> laptop, this is unworkable in PNG with large numbers of XOs and where the
>> bandwidth is so expensive and unreliable. Isn't there a way to do this
>> offline with a download, something we can run on a flashdrive?
>
> If you download the rpms, you can store them on a flash drive and run the rpm
> to address the rpms on the flash drive.
> so downloading it once and them using a flash drive N number of times is one
> way.
>
>> 3. is the update step above necessary (it requires downloading 33MB)
>
> I have not tried this, it may be. I dont know the complete list of rpms that it
> installed other then the 2 you said.  those 2 might work with the current
> packages or they might need to update a few packages and download the needed
> dependencies which means the update is needed.  This sounds like it might need
> a local 'proxy'/mirror server to the needed rpms. so the xo's could do the 'rpm
> update' but would get the 'update' and the needed rpms from a local server.
> this would need the XOs to alter their rpm repo list.  i'm not a rpm expert, so
> you'd need to test a solution to ensure it works and does not alter other
> support issues.
>
> old way:
> XO->Fedora server (per each XO over the global internet)
> vs
> new way:
> local Fedora server->Fedora server (via the global internet one time)
> XO->local Fedora server(per each XO over a local area network (LAN))
>
>> 4. In doing the above am I violating a ton of licenses?
>>
> The gstreamer folks have 3 packages for Codecs - good, bad, ugly.
> which translates to 'free softare', some issues, lots of issues.  In this case
> I recall that free software projects can not distribute these files from adobe
> because you are suppose to use them for personal use and accept their license
> terms. And those terms are not compatible with Free Software projects. (as
> binary software with no source code and non-free license terms and not
> redistributable)

That's not entirely accurate, gst-p-good is fully supported free
codecs, ugly is fully supported patent infringing codecs, bad is a
mixture of both but that "bad" indicated the quality and state of the
code, there's a mixure of what will become both good and ugly in there
which is why most distributions now ship a gst-plugins-bad-free option
as well.

Peter