[Bug 765275] matroska: implement reading & writing ContentEncryption headers

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=765275

--- Comment #16 from y.bandou <bandou.yacine at gmail.com> ---
(In reply to George Kiagiadakis from comment #15)
> One thing I don't particularly like about this patch is that it is
> webm-specific. Matroska is meant to be more abstract than that.

> The way I see it, matroska elements should only be dealing with matroska
> headers, not with the way data is formatted inside a data block (which is
> defined in the webm spec). Or perhaps they can be dealing with webm-specific
> stuff, but only when they are working with webm caps; otherwise, it's like
> you are prohibiting the use of matroska with other encryption mechanisms.

In the matroskademux description, we have this :
"Demuxes Matroska/WebM streams into video/audio/subtitles"

It demuxes the webm content thus it should support the webm encrypted
specifications like is done in qtdemux with mp4.

Currently there is no spec about encrypted content in Matroska, I never saw a
mkv encrypted file.

> In my original patch, the idea was just to parse the matroska headers to
> find out if the content is encrypted and then leave downstream to interpret
> the block data. I wrote that in order to interoperate with a proprietary
> element that did its own encryption/decryption on individual frames (a bit
> similar to how the webm standard does it, but not the same). 

I think, if you used your own encryption/decryption wich is out of the
standard, you would use you proprietary element to demuxe this stream.

This Patch follow only the Matroska/WebM spec 

> Btw, that patch
> was badly done - it had hardcoded values for the matroska headers, which is
> why I didn't post it myself at the time for upstreaming...

Could you give me an example of the hardcode values apart from the WebM spec.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.