Re: [MeeGo-dev] Will clutter, mutter be configured to use gles in OBS?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/26/2011 04:37 AM, Zhao, Juan J wrote: > On Tue, 2011-04-26 at 10:29 +0200, Brendan Le Foll wrote: >> Is there any benchmarks to show GLES performs better than GL in >> platforms supporting both like the SGX535? > The comparison between es2gears and glxgears in mesa-demos can be one in > my opinion. http://www.google.com/search?q=glxgears+is+not+a+benchmark - -- Cory T. Tusar Senior Software Engineer Videon Central, Inc. 2171 Sandy Drive State College, PA 16803 (814) 235- x316 (814) 235-1118 fax "There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." --Sir Charles Anthony Richard Hoare -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk221HkACgkQHT1tsfGwHJ+etwCdHlXFVUIhWSY1JwLTQ2pCsnad HS0AnixxFyb8Twt0v6loLUg6me3Mp4Dt =qcgC -END PGP SIGNATURE- ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Candidate specification for a generic video player from the TV list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/25/2011 11:23 AM, Edward Hervey wrote: >> On Fri, 2011-03-25 at 10:58 -0400, Cory T. Tusar wrote: >>> On 03/17/2011 06:57 AM, Stefan Kost wrote: >> >> >> >>> In "7 Transparency" you need to highlight what your proposal adds to the >>> existing features. >>> * Transport protocol: handled e.g. by gstreamer already, standarts like >>> DLNA specify subsets for interoperability already >>> * Transparent Encapsulation and Multiplexing: could you please elaborate >>> why one would need the non-automatic mode. I think it does not make >>> sense to let the application specify what format the stream is in, if >>> the media-framework can figure it (in almost all of the cases). In some >>> corner cases one can e.g. use custom pipelines and specify the format >>> (e.g. a ringtone playback service might do that if it knows the format >>> already). >> >> As a possible example (pulled from recent experience), automagic >> determination of stream parameters takes time (and CPU cycles). A >> "non-automatic" mode would be (was) helpful in instances where the >> application knows exactly what type of stream to expect, and there is >> a requirement for an absolute minimum of start-up time between the user >> pressing the "Play" button and video appearing on the screen. >> > A lot of improvement has gone into GStreamer over the past year to > speed up the pre-roll/typefinding/setup of playback pipelines. This was > mainly to get gst-discoverer to be faster than exiftool to get > information about media files, which it now is ... considering it also > decodes the first audio/video frame(s). > The only case I can think of where you would gain time would be for > live mpeg-ts streams where you could provide the PAT/PMT information > which you would have cached previously (in order not to have to wait for > the next occurence). But that would still require you to wait for the > next keyframe to appear unless you already have a few seconds live > back-buffer on the machine (in which case you would also have cached > PAT/PMT). > Did you have another use-case in mind ? Pretty much the above, or slight variations thereof. Short version: there were product requirements regarding startup time and display of the first keyframe received over the network within N milliseconds. Explicit knowledge of stream type when constructing the decode pipeline proved helpful in meeting those requirements (this particular case was with a GStreamer pipeline on Moblin). I'm not arguing against automatic detection - it's what works and works well in a vast majority of cases - just leave the "power-user" option of explicitly specifying codec use / buffer sizing / etc. available for times when it's needed. >>> * Transparent Target: Whats the role of the UMMS here? How does the URI >>> make sense here. Are you suggesting to use something like >>> opengl://localdisplay/0/0/854/480? MAFW was introducing renderers, where >>> a local renderer would render well locally and one could e.g. have a >>> UPnP DLNA renderer or a media recorder. >>> * Transparent Resource Management: That makes a lot of sense and so far >>> was planned to be done on QT MultimediaKit >>> * Attended and Non Attended execution: This sounds like having a media >>> recording service in the platform. >>> >>> "8 Audio Video Control" >>> This is a media player interface. Most of the things make sense. Below >>> those that might need more thinking >>> * Codec Selection: please don't. This is something that we need to solve >>> below and not push to the application or even to the user. >> >> Agreed, in part. As a general rule, the underlying detection and codec >> selection should be transparent to an application, however there are >> corner cases where this may not be desirable, and specific selection of >> a codec may be necessary. >> >> Consider a system which has an external (to the main CPU) >> PowerDrain-5000(tm) video processor capable of both MPEG-2 and MPEG-4 >> decode. If the system is in a commanded low-power state, it may be >> more prudent to decode standard-definition MPEG-2 content in software on >> the main CPU and leave the external video processor powered-down. >> However, when decode of MPEG-4 content is desired, soft-decode may not >> be feasible and the external video hardware needs to be used. >> >> In instances, as above, where the system has multiple codecs (hardware >> and software) capab
Re: [MeeGo-dev] Candidate specification for a generic video player from the TV list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/17/2011 06:57 AM, Stefan Kost wrote: > In "7 Transparency" you need to highlight what your proposal adds to the > existing features. > * Transport protocol: handled e.g. by gstreamer already, standarts like > DLNA specify subsets for interoperability already > * Transparent Encapsulation and Multiplexing: could you please elaborate > why one would need the non-automatic mode. I think it does not make > sense to let the application specify what format the stream is in, if > the media-framework can figure it (in almost all of the cases). In some > corner cases one can e.g. use custom pipelines and specify the format > (e.g. a ringtone playback service might do that if it knows the format > already). As a possible example (pulled from recent experience), automagic determination of stream parameters takes time (and CPU cycles). A "non-automatic" mode would be (was) helpful in instances where the application knows exactly what type of stream to expect, and there is a requirement for an absolute minimum of start-up time between the user pressing the "Play" button and video appearing on the screen. > * Transparent Target: Whats the role of the UMMS here? How does the URI > make sense here. Are you suggesting to use something like > opengl://localdisplay/0/0/854/480? MAFW was introducing renderers, where > a local renderer would render well locally and one could e.g. have a > UPnP DLNA renderer or a media recorder. > * Transparent Resource Management: That makes a lot of sense and so far > was planned to be done on QT MultimediaKit > * Attended and Non Attended execution: This sounds like having a media > recording service in the platform. > > "8 Audio Video Control" > This is a media player interface. Most of the things make sense. Below > those that might need more thinking > * Codec Selection: please don't. This is something that we need to solve > below and not push to the application or even to the user. Agreed, in part. As a general rule, the underlying detection and codec selection should be transparent to an application, however there are corner cases where this may not be desirable, and specific selection of a codec may be necessary. Consider a system which has an external (to the main CPU) PowerDrain-5000(tm) video processor capable of both MPEG-2 and MPEG-4 decode. If the system is in a commanded low-power state, it may be more prudent to decode standard-definition MPEG-2 content in software on the main CPU and leave the external video processor powered-down. However, when decode of MPEG-4 content is desired, soft-decode may not be feasible and the external video hardware needs to be used. In instances, as above, where the system has multiple codecs (hardware and software) capable of decoding given content, is there envisioned some method of specifying codec priority so that a given method of decode is used preferentially? > * Buffer Strategy: same as before. Buffering strategy depends on the > use-case and media. The application needs to express whether its a > media-player/media-editor/.. and from that we need to derive this. But not all use-cases may have the same requirements. Again, from recent experience, my system's requirements for low-latency may or may not match yours. That's not to say that providing some sane defaults that cover a majority of expected use cases isn't a good idea, just don't restrict the application to those and those alone. > "15 GStreamer" > It is GStreamer (with a upper case 'S') :) In general please spell check > the section. > Regarding the three weak points: > * smooth fast forward is a seek_event with a rate>1.0. There might be > elements not properly implementing that, but I fail to understand how > you can fix that on higher layers instead of in the elements. It might > make sense to define extended compliance criteria for base adaptation > vendors to ensure consistent behavior and features. +1. - -Cory - -- Cory T. Tusar Senior Software Engineer Videon Central, Inc. 2171 Sandy Drive State College, PA 16803 (814) 235- x316 (814) 235-1118 fax "There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." --Sir Charles Anthony Richard Hoare -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk2MraoACgkQHT1tsfGwHJ+W0wCghQdfIej8YDiGQ/o1bmDVGohs rf4AoI26XSbPONI24mzCDJo5hAOM+PEN =kGk+ -END PGP SIGNATURE- ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] I2C device in MeeGo 1.1
On 01/27/2011 10:04 AM, Roman Gezikov wrote: > Hi, > > Thanks for your answer. Could you please suggest something to read about > the subject? Documentation/i2c in the kernel source is probably a good start. -Cory -- Cory T. Tusar Senior Software Engineer Videon Central, Inc. 2171 Sandy Drive State College, PA 16803 (814) 235- x316 (814) 235-1118 fax "There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." --Sir Charles Anthony Richard Hoare ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] kernel: config-generic policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2010 09:43 AM, Igor Stoppa wrote: > On 08/04/2010 04:04 PM, ext Arjan van de Ven wrote: >> >> actually, especially in the embedded space we need something like this >> >> there's no way we can scale having to update 15 to 30 kernel config >> files individually every time there is a new config option. >> > > I'd rather expect to see something like config-minimal that is the base > for a config-x86 and config-mach-omap2, etc > > At this level you can be fairly generic for the derived products. > >> MeeGo phones will have components that aren't strictly needed for phone, >> but are there for other device categories. >> MeeGo IVI will have the 3G phone components that they have no use for, >> to stay consistent >> etc etc. >> > > I strongly doubt it: probably the first thing done by system integrators > will be to disable the features not neededh Hear hear. One of the very first things I did when setting up Moblin for use on the IVI system we developed was to create a custom .config that removed the extraneous fluff we had zero interest in supporting on our device, and then modified the kernel .spec file to _only_ build our configuration. Rebuilding the kernel N times may be fine once you have a "stable" baseline you wish to replicate, but during early development and tweaking it's just a time sink. - -Cory - -- Cory T. Tusar Senior Software Engineer Videon Central, Inc. 2171 Sandy Drive State College, PA 16803 (814) 235- x316 (814) 235-1118 fax "There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." --Sir Charles Anthony Richard Hoare -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxZblMACgkQHT1tsfGwHJ/VjQCfT2PQvx7nXC47dG6vCg4O9pwH gu4AnRG30++xAkBQ3kscPLdYbWb5vqbC =St2L -END PGP SIGNATURE- ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] FW: moblin-2.1-pr-final-ivi-201002090924.img
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arthur Hsiao wrote: > Sigh... > > Let me try to understand it straight, and please correct me if I am > wrong here: > > Menlow uses US15W (System Controller Hub: North+South bridges), and > therefore GMA500 is part of US15W. If I am correct so far, I don't see > why GMA500 is not supported, because IEGD 10.3 *graphics* drivers > support US15W. Now if I am wrong about US15W and GMA500 relationship, I > suppose my Menlow platform should work with IEGD 10.3, because US15W is > used. Unless there is another pitfall... Yes, US15W includes the GMA500. AFAIK, there is no other publicly available chip(set) that includes a GMA500 core. Yes, IEGD can be made to work with a Menlow-based system. We're currently using it on Z520PT+US15WPT hardware with a software stack based on Moblin 2.1. IEGD does not support DRI2, which means that Moblin UX doesn't work (well), but we've run Xfce, twm, and Matchbox without issue, along with various OpenGL-based and hardware-accelerated video decode applications. - -Cory - -- Cory T. Tusar Senior Software Engineer Videon Central, Inc. 2171 Sandy Drive State College, PA 16803 (814) 235- x316 (814) 235-1118 fax "There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." --Sir Charles Anthony Richard Hoare -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAku96HYACgkQHT1tsfGwHJ9akACdGeO5Feyst6N/6Vxg6fNYpcgN oaIAn27tILuvj1rEqAljOwWWHum5m834 =d/q6 -END PGP SIGNATURE- ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Preview + Menlow + GMA500
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arjan van de Ven wrote: > On 4/7/2010 10:00, Arthur Hsiao wrote: >> But again, I was told that Sodaville also uses GMA500?! > > you were told incorrectly. Sodaville does not use GMA500. Erm... I believe the CE4100 family (Sodaville) does include the same PowerVR SGX535 core as in the GMA500, no? http://www.tensilica.com/uploads/images/intel_4100big.gif - -Cory - -- Cory T. Tusar Senior Software Engineer Videon Central, Inc. 2171 Sandy Drive State College, PA 16803 (814) 235- x316 (814) 235-1118 fax "There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." --Sir Charles Anthony Richard Hoare -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAku8vpsACgkQHT1tsfGwHJ/LlwCgh+RQYahZUH/AMbZla87Uge/Q JXAAnjQc9eRjGszAlrQzjGgbnY+g6og+ =Z6eT -END PGP SIGNATURE- ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
