This enhancement was really about eliminating the need to re-do all your profile mods every time a new release comes out, but does have some benefit for troubleshooting/profile management.
npuser wrote:if an user has an issue with a device profile, with the option proposed here, it would be tough to pin point whether attributes in userdefined-profiles.xml or profiles.xml are the culprit
I saw it the opposite way - that it aids troubleshooting:
- presently, if a user has modified a profile and they need support, they need to specifically state that they have modified the profile. I have had instances when assisting someone who states they are using the xxx profile... only to find some time later that they had modified the xxx profile. This way it will be clear - as Iveky states, they cannot have the same named profile so they will need to provide their modifications with their problem (it also helps as sometimes they forget what they modified - this way its separately identified).
- this will enable users (or people assisting them) to revert back to standard profile easier, so should assist troubleshooting;
- this is targeted at advanced users. I would expect those users to have a full understanding of inheritance - whether its inheriting from a profile in the same file or another I cannot see as a big issue.
The only priority based attribute I am proposing is for detection. This way the user can write a custom profile and have their device auto-detect without also having to remove the detection from the standard profile (it also allows them to revert back to the standard profile easily). Consider a simple mod I currently do every upgrade (it affects only two files in my library) - in the PS3 profile I add the line:
- Code:
<Matches container="mp4" vCodec="mpeg4"/> <!-- DenyAll -->
(I use the comment to remember my mods). Under this scheme I would create a new profile in the separate file:
- Code:
<Profile id="myps3" name="My Playstation 3" extendsProfileId="4">
<Detection>
<HttpHeaders>
<X-AV-Client-Info>.*PLAYSTATION 3.*</X-AV-Client-Info>
</HttpHeaders>
</Detection>
<Transcoding>
<Video targetContainer="mpegts" targetACodec="ac3" targetVCodec="mpeg2video" aBitrate="384">
<Matches container="mp4" vCodec="mpeg4"/>
</Video>
</Transcoding>
<ThumbnailsResolution>HD</ThumbnailsResolution>
</Profile>
It is more complex than simply adding one line (remember its for more advanced users) - but its also only something I do once, not every upgrade. Auto detection would pick up this profile (as it has priority) and not the standard ps3 profile (which I do not modify in any way).
Now having done this I realise my idea has a flaw. For this to work as I had hoped, all local transcoding blocks in all standard profiles will need to have
forceInheritance="true" set to allow user profiles to inherit them. It's a pity that local transcode blocks didn't inherit by default (with an option to set Inheritance="false" where needed) as this would align them more with what happens with most (all?) other elements, but I suspect that that is a historic thing.
ps. It could still work, but with the "myps3" profile as a full copy of the existing playstation profile with the added line. Not as elegant in this case. The other profile I add (for the ios app 8player), would be no issue as it inherits from profile 1, which already has forceInheritance set for its one transcode block.