Opened 12 years ago

Last modified 9 years ago

#3826 accepted enhancement

Get supported audio and video mime types from gstreamer

Reported by: godiard Owned by: SAMdroid
Priority: Normal Milestone: Unspecified
Component: Sugar Version: Git as of bugdate
Severity: Minor Keywords: patch
Cc: godiard Distribution/OS: Unspecified
Bug Status: Unconfirmed


In the file [1], sugar define a fixed group of mime types to the filter by type (Text, Image, Audio, Video, Link)

The audio and video files supported depends on the gstreamer plugins installed.

A basic script to take that info from gstreamer is available here [2] but is very slow. Probably can be faster using sax, but anyway the call to gst-xmlinspect takes time too.
We need look how can use this or another solution.

[1] (in the gtk3 port sugar-base is merged with sugar-toolkit-gtk3)


Change History (9)

comment:1 Changed 11 years ago by dnarvaez

  • Component changed from sugar-toolkit-gtk3 to Sugar

comment:2 Changed 9 years ago by SAMdroid

  • Owner changed from erikos to SAMdroid
  • Priority changed from Unspecified by Maintainer to Normal
  • Severity changed from Unspecified to Minor
  • Status changed from new to accepted
  • Version changed from Unspecified to Git as of bugdate

comment:4 Changed 9 years ago by SAMdroid

Latest pull request: (try6)

Summary of discussions:

This takes about 1.4sec on an XO4 to run. This could be bad for the first load experience on XO1 and older devices. We will use caching and background processes to reduce the impact on the user.

comment:5 Changed 9 years ago by quozl

Thanks for your work on this.

I've tested on XO-1, with OLPC OS 13.2.1, which is Sugar 0.98 on Fedora 18. Test was repeated eight times, measuring Sugar startup time to activity ring of home view made visible. Tests alternated between either leaving /home/olpc/.sugar/default/gst_mimes.json alone or removing it before the test.

The cost of your patch 80546bb is an additional four seconds. This may be because use of multiprocessing incurs CPU process context switches, and the main thread is in greater contention with other threads on the system, in particular the thread you added.

Presumably the cost of your patch f4f66e6, which is synchronous, would be greater than four seconds. So the improvement you've made is great, but can be better.

Disclaimer: I'm an OLPC contractor, and they have put a few million XO-1 laptops in the hands of children. I'm therefore biased.

comment:6 Changed 9 years ago by godiard

Could you try do the"import mime" _after_ the window is displayed?

Not sure if that will help, if not we can do a method create_cache() or something similar to create the cache in a explicit way.

Another option could be have two places to locate the file, one general in /etc/sugar/, and another in the user profile. Then we could create a file in /etc/sugar/ when the image is created and avoid the initial startup penalty at all.

comment:7 Changed 9 years ago by SAMdroid

  • Cc godiard added

I just pushed a new change

This adds import mime after the window is displayed. It does not add an explicit method as the cache should always be regenerated if not available. If a user removes the cache or updates to a version of sugar with this patch, the cache should regenerate asap, not when it is needed for the first time. This means there is less chance of blocking the ui thread.

As for the /etc/sugar/, is that the directory? I agree that we should add that to the search path, but is that the right folder. I could not find that on my installation.

comment:8 Changed 9 years ago by godiard

  • Keywords patch added

comment:9 Changed 9 years ago by godiard

Probably would be better push this on 0.106

About /etc/sugar, do not exist right now, but we already have /etc/sugar_fonts and a few more (getbooks [1] by example, or conexion profiles in AU images)
Maybe is better create a directory and put all there.


Note: See TracTickets for help on using tickets.