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 <gl...@zewt.org>:
>
> > On Mon, Aug 8, 2011 at 4:31 PM, Simon Heckmann <si...@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
> >
>
