The current design of MPEGlet interface deriving from Runnable() was reviewed in detail. It was clarified that the design premise behind this is so that so that multiple thread unaware applets can execute at the same time and the system could manage and switch between them. It was noted that this is different from MIDlets where typically only one MIDlet is expected (typically) to execute at a time. It was decided that current design will be maintained.
4.4Application Properties
The following changes were made to the current Application Properties:
-
MPEGlet-Jar-Size should be made optional as archiving using JAR is optional.
-
MPEGlet-Jar-URL should be changed to MPEGlet-URL to accommodate cases where Jar is not used.
-
Add MPEGlet-Display-Name: This would be the name of the application that is displayed to the user. This is an optional field, and if not present, MPEGlet-Name would be used. Alternatively, MPEGlet-Name could be changed to MPEGlet-Class and MPEGlet-Name could be used as the Display Name.
-
MIDlet-Data-Size: The decision was to remove this field as it was not determined to be useful.
The following shows the modified Application Properties:
Required attributes:
-
MPEGlet-Class. Specifies the fully qualified name of the application.
-
MPEGlet-Version. The MPEGlet version.
-
MPEGlet-Vendor. The MPEGlet vendor.
-
MPEGlet-URL. The URL from where the application can be downloaded.
-
Renderer-Class. Specific the name of the class that implements Renderer interface.
Optional attributes:
-
MPEGlet-Name. The friendly name of the application that is displayed to the user.
-
MPEGlet-Jar-Size. The size of the JAR file.
-
MPEGlet-Description. A brief description of the application for the user
-
MPEGlet-Icon. An icon that will be associated with the application (if terminal supports it). PNG file format is used.
-
Renderer-Version. Version of the renderer.
-
Renderer-URI. Universal Resource Identifier (URI) for the renderer.
Application specific attributes:
-
Any attributes others than those listed in this section can be used to configure the application.
The current TexInfo design was reviewed carefully. The following two issues were discussed:
-
Orientation, and
-
Synchronizing with video decoder output .
4.5.1Orientation
The ambiguity and necessity to support different orientations in the TexInfo was discussed. It was decided that multiple modes similar to the EXIF format will be supported in the TexInfo getOrigin(). This method will become getOrientation().
-
getOrientation() returns the orientation of the camera that took the image relative to the scene. The relation of the '0th row' and '0th column' to visual position is shown as below. Note that the numbering follows EXIF standard:
-
Value
|
0th row
|
0th column
|
example
|
1
|
Top
|
Left
|
|
2
|
Top
|
Right
|
|
3
|
Bottom
|
Right
|
|
4
|
Bottom
|
Left
|
|
5
|
Left
|
Top
|
|
6
|
Right
|
Top
|
|
7
|
Right
|
Bottom
|
|
8
|
Left
|
Bottom
|
|
4.5.2Synchronizing with Video Decoder Output
The current TexInfo design works well for MPEG-4 Systems based implementations. It would also works for synchronizing with image-based data. However, it is not sufficient for synchronizing the graphics application with video decoder output. There may be some issues that need to be looked into, particularly in the case of M3G.
The renderer needs to be able to distinguish between a pointer to memory to be copied to a texture and a pointer (or handle) to a video decoder buffer that is not to be copied. To use GLES as an example, a new method can be added, e.g. glBindTexImage for the non-copy case or there needs to be a way to determine whether the value passed to glTexImage is a pointer to memory or a video buffer handle. EGL 1.1 actually has an eglBindTexImage call that takes a handle to a pbuffer (pointer to a buffer) surface. This or a similar API can be added to our Renderer superclass. The issue there is that we need a renderer independent way to identify texture objects. Alternatively each renderer could provide a custom way to bind a video decoder buffer to a texture.
The current BifsInfo design was also reviewed. It was determined that BifsInfo is OK as is. It provides a handle to the scene manager. All nodes etc. can be accessed through that handle.
Share with your friends: |