-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/17/2011 06:57 AM, Stefan Kost wrote:
<snip> > 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. <snip> > "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-1111 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
