- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 3 Mar 2014 12:52:49 +1100
- 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 6:24 PM, Philip Jägenstedt <philipj@opera.com> wrote: > On Sun, Mar 2, 2014 at 9:00 AM, Silvia Pfeiffer > <silviapfeiffer1@gmail.com> wrote: >> 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: >>>>> >> >>>>> >> 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? > > Gapless looping between some points is possible, but I don't think > it's possible between arbitrary points for most formats. The problem > is that you can't append data starting/ending at arbitrary points, > because compressed data comes in packets. (Perhaps some formats that > have metadata for skipping n samples/frames at the beginning or end of > a packet, I don't know.) > > Even if MSE did support gapless looping between arbitrary points I > don't think it matters, because it's a completely different mode of > playback which you couldn't leverage to get gapless looping for media > fragments on plain HTTP resources. Just saying that it's a quality of implementation issue and not something fundamentally impossible. IMO in this instance, we should not be surprising the web developer with unexpected behaviour. A loop attribute on a video element with a media fragment can fairly be expected to loop over the fragment (in a best effort) and not kill the looping behaviour. The whole Web is about best effort, so I don't see how the potential for gaps in the loop should be allowed to create such an unexpected behaviour. With that argument, we should be disallowing videos on the Web, since it can never be guaranteed that video plays back without pausing for buffering. Raphael, Leeroy: if you are keen, do you want to register a bug in WHATWG to get this discussion going for the HTML spec? (I am a bit swamped, but will be happy to contribute when I can). Cheers, Silvia.
Received on Monday, 3 March 2014 01:53:37 UTC