[gst-devel] Does GStreamer has a plan to support DRM (e.g. OMADRM)?

Lin, Mengdong mengdong.lin at intel.com
Wed Oct 20 08:37:25 CEST 2010


Could you give me more information about a " encrypted memory interface"?

And it seems that I have to write a big DRM sink plug-in that do all the following task: 
- detect & removing OMA DRM wrapper, -
- decryption 
- original media format parsing (mp3, AAC ...)
- decoding 
- rendering

The decryption/parsing/decode shall occur in a secure hardware. 
It means I can no longer use the open source file parser plug-ins and there is only two plug-ins (filesrc & DRM sink)  in the pipe line :-(

Is this the only way to build a secure path in GStreamer?

Many Thanks!
Amanda

-----Original Message-----
From: Gruenke, Matt [mailto:mgruenke at Tycoint.com] 
Sent: Tuesday, October 19, 2010 12:25 PM
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] Does GStreamer has a plan to support DRM (e.g. OMADRM)?

-----Original Message-----
From: Michael Smith [mailto:msmith at xiph.org] 
Sent: Tuesday, October 19, 2010 00:13
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] Does GStreamer has a plan to support DRM (e.g.
OMADRM)?

<snip/>

> Of course, then the output of the DRM wrapper filter is the
> unencrypted original file, so a user could trivially set up
> a pipeline like filesrc ! drmremover ! filesink, and just get
> rid of the DRM permanently. This is great for the user, but
> probably not what you actually wanted.
>
> Providing a _secure_ path for decrypt/decode/output is a much
> more complex task. You'll need to do a lot of thinking about that.

Depending on the security requirements and how accessible the platform
will be, that might be an issue.  For instance, if the platform-level
security requirement is low or the security issues have already been
solved at the platform level (e.g. an embedded process with an encrypted
memory interface), then you don't need to worry about security at the
gstreamer level.

The way this problem is usually solved is by having the decryption &
decode occur in secured hardware (like a GPU), which is either built
into the display device or uses another secured channel (e.g. HDCP) to
send the decoded output to the display device.

What this would look like, from a GStreamer perspective, is having a
different sink for the device that's doing the decryption & decoding.
Depending on how that sink works (i.e. whether or not it needs to tell
the hardware that the stream is encrypted), you might need special caps
to indicate encryption.


Matt


------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel




More information about the gstreamer-devel mailing list