[Matroska-devel] Re: mkvmerge support for Matroska ContentEncodingType
davidnduffy at yahoo.co.uk
Fri Mar 2 20:50:06 CET 2007
Thank-you for your reply, it has provided me with further insight into the requirements.
I have tried to lay out some more detail and ideas in this area (below) and I appreciate your feedback.
>> What about just to create a file with those properties set but leave
>> it up to the user to do whatever encryption of the data they specified
>No. This will most likely destroy interoperability. For example, what
>about seeking? Does each frame have to be decryptable on its own? Or is
>it enough that key frames are decryptable on their own and non-keyframes
>may need decrypting of all frames starting with the previous key frame?
>This hasn't even been defined in the Matroska specs so far.
I see your point; if that level of control needs to be specified and enforced by the spec then there is clearly a lot missing in that area of the Matroska spec.
On the other hand, at what point would that much detail start to be a limiting factor such that the format would not be adaptable despite not causing interoperability problems? I think there is a very fine line there depending on how it is viewed but I do agree that the spec is perhaps too open in that area at the moment.
>> Personally I just want to set the properties without actually having
>> mkvmerge do any encryption, maybe that could be an option?
>And risk that users start creating their own pesudo standards for the
>contents of those elements? I don't think that this would be a good
>decision. Therefore I won't do it, sorry.
I agree with your concern and I think what may be good solution to the problem, without limiting flexibility, would be to clearly define what the "official" settings/options are for how mainstream spec. compliant demuxers are to handle "known" encryption but provide further properties to allow technical users to create their own "pseudo standards" that would not be confused with the officially supported approaches. My idea here is not to cause an interoperability nightmare but to be able to handle the ever changing world of DRM, particularly for portable devices, without the official Matroska spec having to become the official DRM spec of the world.
I see it being the same as codec support, you have a list of officially supported codecs but there is also the VFW 4CC compatibility mode where anything goes. I think the same should be true for encryption, there can be the official list of algorithms and modes (e.g. CBC like you mentioned) and a user definable mode for people who want a proprietary implementation (just like an "unknown" codec).
I think it is important for the format to clearly layout structure and settings so that files can be demuxed with the highest degree of interoperability, however, I also believe that the handling of the data in each block is the responsibility of the appropriate codec and that the same should be true of decryption. Any given system should always be able to demux a file but the ability to decode or decrypt the data in the file lies outside of the file format and its demuxers in the existence (or absence) of appropriate codecs.
Thank-you and I look forward to your continued thoughts on this.
What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship.
More information about the Matroska-devel