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

Re: Media Fragments - Video fragment temporal loop

From: Philip Jägenstedt <philipj@opera.com>
Date: Fri, 28 Feb 2014 13:46:31 +0700
Message-ID: <CAMQvoCmCPh2UBb8v4mCorByJOXMGo_vJG0iiJ1XAYFxvz3BhiQ@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Eric Carlson <eric.carlson@apple.com>, Raphaël Troncy <raphael.troncy@eurecom.fr>, Leeroy <soupress@gmail.com>, Media Fragment <public-media-fragment@w3.org>
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.)

Will you be filing an HTML bug on the fragment end time issue? Would
it help inform the discussion to have use counters for when fragment
start and end times are applied in Blink?

Received on Friday, 28 February 2014 06:46:58 UTC

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