W3C home > Mailing lists > Public > public-media-fragment@w3.org > March 2014

Re: Media Fragments - Video fragment temporal loop

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 2 Mar 2014 13:00:18 +1100
Message-ID: <CAHp8n2mJW_8Os6OgVck3uw+hcFQ-66mHgY2kcgEt4A4gqUTWTg@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Media Fragment <public-media-fragment@w3.org>, Leeroy <soupress@gmail.com>, Raphaël Troncy <raphael.troncy@eurecom.fr>, Eric Carlson <eric.carlson@apple.com>
On Sun, Mar 2, 2014 at 2:54 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Fri, Feb 28, 2014 at 5:11 PM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> On 28 Feb 2014 17:46, "Philip Jägenstedt" <philipj@opera.com> wrote:
>>> On Fri, Feb 28, 2014 at 6:54 AM, Silvia Pfeiffer
>>> <silviapfeiffer1@gmail.com> wrote:
>>> > On Fri, Feb 28, 2014 at 4:16 AM, Eric Carlson <eric.carlson@apple.com>
>>> > wrote:
>>> >>
>>> >> On Feb 27, 2014, at 8:31 AM, Philip Jägenstedt <philipj@opera.com>
>>> >> wrote:
>>> >>
>>> >>> On Thu, Feb 27, 2014 at 10:53 PM, Raphaël Troncy
>>> >>> <raphael.troncy@eurecom.fr> wrote:
>>> >>>
>>> >>>> What about <video>? And let's not looking at corner cases such as
>>> >>>> #t=1,2.
>>> >>>> People are sharing *real* fragments!
>>> >>>
>>> >>> The problem is the same with video, if you want to loop a particular
>>> >>> scene over and over you don't want a random number of frames from the
>>> >>> following scene to be shown just before the loop. This will happen if
>>> >>> the looping isn't implemented inside the media framework.
>>> >>>
>>> >>
>>> >>   For whatever it is worth, I agree with Philip - consistent and
>>> >> accurate gapless looping is not possible without low level support from the
>>> >> media engine.
>>> >
>>> > Isn't that true also for looping over full files? So doesn't that mean
>>> > that the @loop attribute is useless?
>>> As Eric pointed out there is a difference. Without media framework
>>> support looping a fragment will play beyond the loop point, while the
>>> looping the entire resource will pause for a random number of
>>> milliseconds at each loop. (I honestly don't know if the loop
>>> attribute is useful or not, since I've never seen it used outside of
>>> test cases and demos.)
>> Surely it can't be worse than what we are doing with MSE and HLS.
> I'm not sure what you mean by worse, but MSE can't do gapless looping
> between arbitrary points.

How would it determine whether the next chunk is provided from a
consecutive part of the video or from a completely different position?
The browser just gets the data and interprets it. If it can decode it
fast enough, it will be gapless, if not, it won't. I don't understand
how looping is any different from seeking?

>>> Will you be filing an HTML bug on the fragment end time issue?

I am thinking about it...

>>> Would
>>> it help inform the discussion to have use counters for when fragment
>>> start and end times are applied in Blink?
>> If you could also count how many are using JS to imitate looping (given that
>> FAIK not all browsers support the loop attribute), then we would get good
>> numbers of use cases.
> In my ad hoc testing all current browsers support the
> HTMLMediaElement.loop IDL attribute at least, which browsers lack
> support?

Oh, last time I checked, Firefox wasn't supporting it yet but it seems
that has been fixed since.

> I don't really know how one would detect and count scripted looping,
> as currentTime could be set at any time for any reason.

Right, I don't think we would do a use counter in blink. We could,
however, check on a collection of Web pages that use the <video> or
<audio> elements whether they do seeking in JS. Anyone doing seeking -
no matter whether it's for the media fragment use case or for
something else - would want gapless playback (always assuming those
seek actions are during playback). Is there a web page collection
anywhere that we could use to do some of this analysis? (I know I've
used it in several applications and I know from FOMS that all of the
HTML5 video player providers are concerned about gapless playback).

Received on Sunday, 2 March 2014 02:01:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:48 UTC