[whatwg] possible new parameters to video.play() ?

[Melvin Carvalho]

Apologies if this has come up before, but I was wondering if it would be
possible to add simple parameters to the play() function.

They would be

play(start, end)

Where start and end are the times in seconds.

I know you can do

video.currentTime = start ; video.play()

But there's no real easy way to stop it to play a clip

The media fragments URIs spec [1] handles this quite nicely by adding to
the URI

#t=start,end

But yet there seems to be no way to do this in JS, resorting to changing
location.hash and then doing a reload, which seems a bit of a kludge

I may be missing something extremely obvious, if so, I'd love to know!

[1] https://www.w3.org/TR/media-frags/

[Yay295]

You can add an event listener to the video element on the `timeupdate`
event and pause the video when the videos' time is at/past the time you
want to stop, but your idea does sound more convenient.

On Sat, Sep 17, 2016 at 5:21 PM, Melvin Carvalho <***@gmail.com>
wrote:

> Apologies if this has come up before, but I was wondering if it would be
> possible to add simple parameters to the play() function.
>
> They would be
>
> play(start, end)
>
> Where start and end are the times in seconds.
>
> I know you can do
>
> video.currentTime = start ; video.play()
>
> But there's no real easy way to stop it to play a clip
>
> The media fragments URIs spec [1] handles this quite nicely by adding to
> the URI
>
> #t=start,end
>
> But yet there seems to be no way to do this in JS, resorting to changing
> location.hash and then doing a reload, which seems a bit of a kludge
>
> I may be missing something extremely obvious, if so, I'd love to know!
>
> [1] https://www.w3.org/TR/media-frags/
>

[Simon Pieters]

On Sun, 18 Sep 2016 01:21:27 +0200, Melvin Carvalho
<***@gmail.com> wrote:

> Apologies if this has come up before, but I was wondering if it would be
> possible to add simple parameters to the play() function.
>
> They would be
>
> play(start, end)
>
> Where start and end are the times in seconds.
>
> I know you can do
>
> video.currentTime = start ; video.play()
>
> But there's no real easy way to stop it to play a clip
>
> The media fragments URIs spec [1] handles this quite nicely by adding to
> the URI
>
> #t=start,end
>
> But yet there seems to be no way to do this in JS, resorting to changing
> location.hash and then doing a reload, which seems a bit of a kludge
>
> I may be missing something extremely obvious, if so, I'd love to know!
>
> [1] https://www.w3.org/TR/media-frags/

The pauseOnExit attribute on VTTCue can be used for this purpose. See
https://html.spec.whatwg.org/multipage/embedded-content.html#text-track-api:the-audio-element
for an example.

--
Simon Pieters
Opera Software

[Melvin Carvalho]

On 18 September 2016 at 14:44, Simon Pieters <***@opera.com> wrote:

> On Sun, 18 Sep 2016 01:21:27 +0200, Melvin Carvalho <
> ***@gmail.com> wrote:
>
> Apologies if this has come up before, but I was wondering if it would be
>> possible to add simple parameters to the play() function.
>>
>> They would be
>>
>> play(start, end)
>>
>> Where start and end are the times in seconds.
>>
>> I know you can do
>>
>> video.currentTime = start ; video.play()
>>
>> But there's no real easy way to stop it to play a clip
>>
>> The media fragments URIs spec [1] handles this quite nicely by adding to
>> the URI
>>
>> #t=start,end
>>
>> But yet there seems to be no way to do this in JS, resorting to changing
>> location.hash and then doing a reload, which seems a bit of a kludge
>>
>> I may be missing something extremely obvious, if so, I'd love to know!
>>
>> [1] https://www.w3.org/TR/media-frags/
>>
>
> The pauseOnExit attribute on VTTCue can be used for this purpose. See
> https://html.spec.whatwg.org/multipage/embedded-content.html
> #text-track-api:the-audio-element for an example.


Thank you for both answers!

I found pauseOnExit to work very well for my use case. I ended up with.

v.addTextTrack('metadata')
cue = new VTTCue(start, end, '')
cue.pauseOnExit = true
cues.addCue(cue)
v.currentTime = start
v.play()

Regarding

var cue = new VTTCue(start, end, '');

As best I could tell that last parameter is a 'message', tho Im not sure I
got any message when the video stopped, even when I populated it. Maybe I
wasnt supposed to.

I'm quite happy to use this solution. My slight concert is whether there
are any side effects from adding a TextTrack to a video.

Should this be considered best practice, or would there perhaps still be
room in future for (start, end) parameters?


>
> --
> Simon Pieters
> Opera Software
>

[Nigel Megitt]

IMO this should be a feature of TextTrackCue and has no relevance to VTTCue specifically. There's implementation overloading here that is mixing concerns unhelpfully.

Discuss!

Nigel

On 18 Sep 2016, at 17:46, Melvin Carvalho <***@gmail.com<mailto:***@gmail.com>> wrote:

On 18 September 2016 at 14:44, Simon Pieters <***@opera.com<mailto:***@opera.com>> wrote:

On Sun, 18 Sep 2016 01:21:27 +0200, Melvin Carvalho <
***@gmail.com<mailto:***@gmail.com>> wrote:

Apologies if this has come up before, but I was wondering if it would be
possible to add simple parameters to the play() function.

They would be

play(start, end)

Where start and end are the times in seconds.

I know you can do

video.currentTime = start ; video.play()

But there's no real easy way to stop it to play a clip

The media fragments URIs spec [1] handles this quite nicely by adding to
the URI

#t=start,end

But yet there seems to be no way to do this in JS, resorting to changing
location.hash and then doing a reload, which seems a bit of a kludge

I may be missing something extremely obvious, if so, I'd love to know!

[1] https://www.w3.org/TR/media-frags/


The pauseOnExit attribute on VTTCue can be used for this purpose. See
https://html.spec.whatwg.org/multipage/embedded-content.html
#text-track-api:the-audio-element for an example.


Thank you for both answers!

I found pauseOnExit to work very well for my use case. I ended up with.

v.addTextTrack('metadata')
cue = new VTTCue(start, end, '')
cue.pauseOnExit = true
cues.addCue(cue)
v.currentTime = start
v.play()

Regarding

var cue = new VTTCue(start, end, '');

As best I could tell that last parameter is a 'message', tho Im not sure I
got any message when the video stopped, even when I populated it. Maybe I
wasnt supposed to.

I'm quite happy to use this solution. My slight concert is whether there
are any side effects from adding a TextTrack to a video.

Should this be considered best practice, or would there perhaps still be
room in future for (start, end) parameters?



--
Simon Pieters
Opera Software

[Simon Pieters]

On Sun, 18 Sep 2016 18:45:51 +0200, Melvin Carvalho
<***@gmail.com> wrote:

>> The pauseOnExit attribute on VTTCue can be used for this purpose. See
>> https://html.spec.whatwg.org/multipage/embedded-content.html
>> #text-track-api:the-audio-element for an example.
>
>
> Thank you for both answers!
>
> I found pauseOnExit to work very well for my use case. I ended up with.
>
> v.addTextTrack('metadata')
> cue = new VTTCue(start, end, '')
> cue.pauseOnExit = true
> cues.addCue(cue)
> v.currentTime = start
> v.play()
>
> Regarding
>
> var cue = new VTTCue(start, end, '');
>
> As best I could tell that last parameter is a 'message', tho Im not sure
> I
> got any message when the video stopped, even when I populated it. Maybe
> I
> wasnt supposed to.

It's not a message, it's the cue's text. For a metadata track, you can use
it for anything you want, and access it with `cue.text`. For caption or
subtitle tracks, it's text that gets rendered on top of the video.

> I'm quite happy to use this solution. My slight concert is whether there
> are any side effects from adding a TextTrack to a video.
>
> Should this be considered best practice, or would there perhaps still be
> room in future for (start, end) parameters?

There is always room for adding convenience APIs, it's a matter of
demonstrating that it's a common enough need to make it worth the cost of
adding it.

https://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94

HTH,
--
Simon Pieters
Opera Software

[Michael A. Peters]

On 09/19/2016 07:41 AM, Simon Pieters wrote:

>
> There is always room for adding convenience APIs, it's a matter of
> demonstrating that it's a common enough need to make it worth the cost
> of adding it.
>
> https://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94
>
> HTH,

* OFF TOPIC *

Going off topic but an excellent example of what can happen when those
things in the link aren't considered are the ramifications of adopting
of Google's HPKP (RFC 7469)

* Even though TLS is used over a wide range of protocols, it is specific
to one protocol - HTTP. The Internet is bigger than the web, a proper
solution to a problem that exists across protocols isn't limited to just
one protocol.

* It is blind trust on first use, which means the pins have to be cached
for a relatively long time (to reduce window when that blind trust can
be exploited)

* Thus you have to have at least one spare private key before deploying,
so that its keypin can be cached by browsers as well.

* That spare private key can't be kept as the same place as the main key
because if the main key is stolen via file access, the spare key will
likely be compromised too.

* In addition to needing to keep the spare key in a separate place that
is secure, it ties you in to specific technology because of the long
cache life. Thus if your private key is compromised because of a zero
day that only works on RSA keys you can't switch to ECDSA unless your
spare key is already ECDSA.

* Puts you at the mercy of the browser vendors. What happens if you were
using secp521r1 when Chrome decided to drop it? I hope people had backup
keys that weren't secp521r1/

* If an employee leaves a company that potentially had access to private
keys, it means you can't immediately rotate all the private keys to
shiny new ones.

All those problems exist because it was implemented (initially in
Chrome) without careful consideration. Rich companies like Google can do
that. And it has hampered the adoption of a better technology (DANE)
that doesn't have any of those issues.

So yes, adding new features really does require very careful thought.

* BACK ON TOPIC *

That being said, I like the attribute idea for audio and suspect it may
have less accessibility issues than using JavaScript might have, notably
it being easier for software to notify the user what the start and stop
times are by reading them directly from the audio tag attributes.

So I like the idea.