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

Re: Media Fragments - Video fragment temporal loop

From: Eric Carlson <eric.carlson@apple.com>
Date: Thu, 27 Feb 2014 16:10:06 -0800
Cc: RaphaŽl Troncy <raphael.troncy@eurecom.fr>, Leeroy <soupress@gmail.com>, Media Fragment <public-media-fragment@w3.org>, Philip Jšgenstedt <philipj@opera.com>
Message-id: <DA8EC1E7-B5E5-4B28-BFA5-67642FB51953@apple.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>

On Feb 27, 2014, at 3:54 PM, 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:
>>>>> To make it loop exactly between the start time and the end time you
>>>>> have to integrate with the media framework, otherwise the looping
>>>>> won't be gapless and it won't loop exactly the same number of samples
>>>>> each time.
>>>> Let's consider the case <video src="holidays.webm#t=320,960" loop>. The
>>>> first playback might starts at second 319,56 and ends at 960,14 because you
>>>> look for the closest I frame. When looping, you will have exactly the same
>>>> behavior.
>>> In HTML the fragment start time is integrated as an exact seek to that
>>> time. But even even if both times were rounded to keyframe times, it
>>> doesn't really make exact, gapless looping any simpler.
>>>>> An implementation that doesn't loop accurately doesn't add
>>>>> anything that you can't do by seeking in JavaScript at the appropriate
>>>>> time.
>>>> Yes, you can seek in javascript. The use case here is different: you might
>>>> want to share a media fragment URI and just expect your client to play this
>>>> fragment (starting at start fragment time and pausing at end fragment time).
>>> It is the combination of looping and media fragments that I'm most
>>> skeptical of, and when you have just a URI there can be no looping.
>>> (If end times with no looping are to be supported some spec still
>>> needs to say what HTMLMediaElement does when reaching that time and
>>> when play() is called while paused at that time, but that wasn't what
>>> the thread started out about.)
>>>>> I suspect that implementors will say "just use Web Audio API" if
>>>>> asked to implement accurate looping for <audio src="sound#t=1,2"
>>>>> loop>.
>>>> 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?
  While gapless looping at the end of a full file is equally difficult without low level support from the media engine, at least the loop is guaranteed to happen at exactly the same time. This is not necessarily true when looping at a media fragment end time  - unless the media engine has native support for temporal fragments.

Received on Friday, 28 February 2014 00:10:35 UTC

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