- From: Philip Jägenstedt <philipj@opera.com>
- Date: Fri, 14 Aug 2009 13:08:16 +0200
On Fri, 14 Aug 2009 12:48:59 +0200, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: > On Fri, Aug 14, 2009 at 7:54 PM, Dr. Markus Walther<walther at svox.com> > wrote: >> >> >> Silvia Pfeiffer wrote: >>> 2009/8/14 Dr. Markus Walther <walther at svox.com>: >>>> Hi, >>>> >>>>> The .start/.end properties were dropped in favor of media fragments, >>>>> which the Media Fragments Working Group is producing a spec for. >>>> Who decided this? Has this decision been made public on this list? >>>> >>>>> It will >>>>> be something like http://www.example.com/movie.mov#t=12.33,21.16 >>>> var audioObject = new Audio(); >>>> audioObject.src >>>> ='data:audio/x-wav;base64,UklGRiIAAABXQVZFZm10IBAAAAABAAEAIlYAAESsAAACABAAZGF0Yf7///8AAAAA....'; >>>> // play entire audio >>>> audioObject.play(); >>>> // play (0.54328,0.72636) media fragment >>>> ????? >>> >>> Not in this way. In fact, the new way will be much much simpler and >>> does not require javascript. >> >> With the code snippet given I was pointing out that it is not obvious >> (to me at least) how the proposed media fragment solution covers data >> URIs. If it is not meant to cover them, it is limited in a way that the >> solution it seeks to replace is not. > > I see no reason why they should not be applicable to data URIs when it > is obvious that the data URI is a media file. This has not yet been > discussed, but would be an obvious use case. > > BTW: Did the start and end attribute implementations that you refer to > cover the "data" scheme, too? To my knowledge/experience, there is nothing special about data URIs. Any differences in how they work with the DOM interface or media fragments are more than likely implementation bugs. -- Philip J?genstedt Opera Software
Received on Friday, 14 August 2009 04:08:16 UTC