Re: [whatwg] VIDEO and pitchAdjustment

2015-08-31 Thread Michael Enright 
On Fri, Aug 28, 2015 at 11:17 AM, Domenic Denicola  wrote:
> From:  Robert O'Callahan
>
>> According to the spec it should work, but it's very low priority for us and
>> implementing it would be very inefficient as Yay295 describes. So I don't
>> think it's going to happen in Firefox in the forseeable future.
>
> I was looking in to this yesterday and it seems like the spec places absolute 
> no limits on playbackRate. Am I right? This seems a bit bad.
>
> If nobody is supporting negative nor has any plans to, we should at least 
> consider throwing for negative. I guess we can leave the upper limit 
> unspecified, unless implementations all happen to agree on one.
>

I have implemented video element implementations which allowed the
video to play in reverse, and scripts that ran on such implementations
that allowed the user to ask for playback in reverse. If it is thought
that browser scripts need guidance on what speeds are possible for a
given server or video, then by all means go that route.

USE CASE: Implementing things like VidiPath or in some other fashion
implementing satellte STB or cable STB UI in HTML 5.

Re: [whatwg] VIDEO and pitchAdjustment

2015-08-31 Thread Garrett Smith 
On 8/31/15, Michael Enright  wrote:
> On Fri, Aug 28, 2015 at 11:17 AM, Domenic Denicola  wrote:
>> From:  Robert O'Callahan
>>
>>> According to the spec it should work, but it's very low priority for us
>>> and
>>> implementing it would be very inefficient as Yay295 describes. So I
>>> don't
>>> think it's going to happen in Firefox in the forseeable future.
>>
>> I was looking in to this yesterday and it seems like the spec places
>> absolute no limits on playbackRate. Am I right? This seems a bit bad.
>>
>> If nobody is supporting negative nor has any plans to, we should at least
>> consider throwing for negative. I guess we can leave the upper limit
>> unspecified, unless implementations all happen to agree on one.
>>
>
> I have implemented video element implementations which allowed the
> video to play in reverse, and scripts that ran on such implementations
> that allowed the user to ask for playback in reverse. If it is thought
> that browser scripts need guidance on what speeds are possible for a
> given server or video, then by all means go that route.
>
> USE CASE: Implementing things like VidiPath or in some other fashion
> implementing satellte STB or cable STB UI in HTML 5.
>

USE CASE: https://www.youtube.com/watch?v=BtSdt1G6mcE
-- 
Garrett
@xkit
ChordCycles.wordpress.com
garretts.github.io
personx.tumblr.com

Re: [whatwg] VIDEO and pitchAdjustment

2015-08-31 Thread Domenic Denicola 
To be clear:

Everyone can imagine use cases for playing videos backward. However, so far the 
only statements we have about implementations are negative. My subthread was 
more concerned with making the spec reflect current reality. If you can 
convince implementers to support backward videos, then that's separate, and we 
can change the spec again.

Re: [whatwg] VIDEO and pitchAdjustment

2015-08-31 Thread Eric Carlson 

> On Aug 31, 2015, at 12:04 PM, Domenic Denicola  wrote:
> 
> My subthread was more concerned with making the spec reflect current reality. 
> If you can convince implementers to support backward videos, then that's 
> separate, and we can change the spec again.
> 


  FWIW, Safari supports negative playback rates on the desktop and on iOS. 


> On Aug 27, 2015, at 11:02 AM, Garrett Smith  wrote:
> 
> Negative playbackRate, to watch videos backwards, currently crashes
> Safari 8


  The crash Garrett noted in Safari 8 is a bug that “only" happens with MSE 
content.

eric

Re: [whatwg] VIDEO and pitchAdjustment

2015-08-31 Thread Domenic Denicola 
From: Eric Carlson [mailto:eric.carl...@apple.com]

>   FWIW, Safari supports negative playback rates on the desktop and on iOS.
>
> ...
>
>   The crash Garrett noted in Safari 8 is a bug that “only" happens with MSE
> content.

That's really helpful, thanks. Combined with Edge's keyframes-only support, it 
sounds like we should probably leave the spec as it is.

Do you have thoughts on a mozPreservesPitch equivalent?