Sorry to jump in the middle of your discussion but after reading Eric's
questions e.g.
I haven't fully absorbed the MediaStream API, but perhaps it
would be more natural to make a connector in that API rather
than modifying Blob?
I think this use case also applies for other stream/file/blob analysis
and processing e.g. Augmented Reality, Object Recognition, DSP, etc.
I've raised this recently across the related groups [1] with a simple
use case and a number of supporting requirements.
roBman
[1] http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0170.html
On Mon, 2011-08-08 at 23:59 +0200, Simon Heckmann wrote:
> It's actually confidential company data, I was thinking off. Together with the DOMCrypt API I thought this could be a valid use case. But I think there might be more cases in which it might make sense to preprocess locally stored video data.
>
> Kind regards,
> Simon Heckmann
>
>
> Am 08.08.2011 um 23:51 schrieb Glenn Maynard <glenn@zewt.org>:
>
> > On Mon, Aug 8, 2011 at 4:31 PM, Simon Heckmann <simon@simonheckmann.de> wrote:
> > Well, not directly an answer to your question, but the use case I had in mind is the following:
> >
> > A large encrypted video (e.g. HD movie with 2GB) file is stored using the File API, I then want to decrypt this file and start playing with only a minor delay. I do not want to decrypt the entire file before it can be viewed. As long as such as use case gets covered I am fine with everything.
> >
> > Assuming you're thinking of DRM, are there any related use cases other than crypto? Encryption for DRM, at least, isn't a very compelling use case; client-side Javascript encryption is a very weak level of protection (putting aside, for now, the question of whether the web can or should be attempting to handle DRM in the first place). If it's not DRM you're thinking of, can you clarify?
> >
> > --
> > Glenn Maynard
> >
>