TitleResource... What is it good for.

Clinic332050

After looking through some other threads, and the spec, it still does not seem clear what a TitleResource is good for.

The TitleResource element does not have the attributes autoRun or sync, which might be important items to address when working with Advanced Applications. These two elements are available to the ApplicationResource element, which appears to be a more powerful solution to Resource needs. I have a hunch that the element is redundant and useless.

Has anyone successfully used the TitleResource element, and what might a use case be

thanks.

Peter Torr - MSFT

Title resources are just that -- resources that are available for the entire duration of the title. If you want to ensure that a resource doesn't get kicked out of filecache between two applications, you can make it a title resource and it is more likely to stay in memory (it will have a higher priority than any unused application resources).

[Note: the following might violate the spec; I seem to recall reading something that says you shouldn't do this, but I can't find it right now... I will try ty follow up]

Also, you can a title resource to make a playlist application that is "bigger" than the 64MB filecache. Typically something like an "In Movie Experience" (or "U-Control") will use a lot of resources, but they will only be needed during the main title, not during bonus features or other areas. You can keep those resources as title resources for the main feature and access them from the playlist application. Then when you are playing other titles (eg, a game or a bonus feature) you can load a different set of resources. This lets you share the same script code across multiple titles without having to cram all the images etc. into < 64MB.

Clinic

Ok, so basically, the TitleResource has higher priority. I'll check over the spec to look at this.

But, from all research through the spec, I only see a resource Data Cache area of 64 MB. So, I'm not sure about trusting this, or to what space beyond 64MB could be trusted.

I do see a benefit to providing an area of higher priority cache priority... I would like to know how to execute this, as I believe that this has been executed impropperly in projects that I have seen. I'll write up some code examples to discuss in the future.

thanks Peter...

DrumAllDay

You can't exceed the 64 MB loaded any given time, so as you jump from title to title, resources from previous titles may be removed in order to make room for new resources.  Within a title, resource priority is used to determine which resources get removed first (or last as the case may be).

What I believe Peter meant by making your playlist application "bigger" than 64 MB is that you could potentially store resources that the playlist application needs across several titles as title resources since they have lower priority than playlist application resources, but still higher priority than title application resources.

so, for instance, lets say you have a playlist application that is 50 MB
and in title A you have 14 MB of title resources that are only needed by the playlist app in title A
and in title B you have 14 MB of title resources than are only needed by the playlist app in title B

When you jump from title A to title B, the title A resources are removed from the filecache in order to make room for the title resources from title B.  So, technically, your playlist uses 82 MB of filecache, but never more than 64 and one time.

I believe that in the current implementation of the simulator and the Toshiba player, this works.  However, I'm not positive on whether or not referencing these title resources in the playlist application is a spec violation as they are not referenced in the playlist application tag or in the playlist application manifest.

Peter Torr - MSFT

I found my "Mystery Spec Reference" -- Section 4.3.19.6.2.2 Relation to the Resource (page 4-119) says Playlist Apps shouldn't use Title or Application resources. Since that seems like an arbitrary restriction (assuming you write your code correctly), it seems like a potential candidate for removal.

Clinic

I thought I had remembered reading this as well. Do you suppose this restriction might be related to security to guard access amoung Resource types, or maybe some type of implementation issue to ease player manufacturer issues I would like to pin something down to create a definitive solution now that can work on players in the market. I suppose the way the spec is worded, that the only possible use of Title resources would be to build Title Application Resources that could be only available to Application Segment Resources.

Peter Torr - MSFT

There are no security issues since everything on the disc is treated the same (in terms of FullTrust or Restricted modes), and there is no attempt at segmenting the file cache between applications. I am trying to find out why this restriction is in the spec since there are no technical barriers in the way the resource manager is described / implemented that I can see.