Re: [webkit-dev] Feature announcement: Web VHS API

2013-04-01 Thread Darin Adler
Finally.

-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Feature announcement: Web VHS API

2013-04-01 Thread Ryosuke Niwa
Why are rewind(), forward(), pause() and eject() all blocking APIs? I don't
think we should be blocking the main thread while those operations are
taking place.  In particular, rewind() can take anywhere from a few seconds
to a few minutes.  We should let authors show some kind of UI for
rewinding, and keep the web page responsive while VHS is rewinded.

I'm also confused by the fact VHSOutput interface has a
method, streamToYouTube, that specifically supports one website.  Are we
expecting to add methods like streamToDailyMotion, streamToUStream, etc...?
 I'd prefer coming up with a generic format and let author specify an URL
to which the video is streamed.

Also, why are VHSInput and VHSOutput separate interfaces?  It appears that
all methods on those two interfaces can just be on VHSAccess.

- R. Niwa


On Mon, Apr 1, 2013 at 4:17 AM, Alexis Menard ale...@webkit.org wrote:

 Hello,

 I would like to let you know that I plan to add support for the Web VHS
 API to WebCore. The Web VHS API is a specification to bring VHS support to
 the Web.

 This support will be behind the ENABLE_WEB_VHS feature define.

 The spec is here:
 http://bit.ly/YVHIga

 Here is the tracking bug:
 https://bugs.webkit.org/show_bug.cgi?id=113697

 Let me know if you have any questions or comments.

 Best regards,
 Alexis

 --
 Software Engineer @
 Intel Open Source Technology Center

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Feature announcement: Web VHS API

2013-04-01 Thread Žan Doberšek
On Mon, Apr 1, 2013 at 7:06 PM, Ryosuke Niwa rn...@webkit.org wrote:


 I'm also confused by the fact VHSOutput interface has a
 method, streamToYouTube, that specifically supports one website.  Are we
 expecting to add methods like streamToDailyMotion, streamToUStream, etc...?
  I'd prefer coming up with a generic format and let author specify an URL
 to which the video is streamed.


Why even incorporate such a specific functionality into the standard for a
site/service that is about to be shut down?

Regards,
-Z
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Feature announcement: Web VHS API

2013-04-01 Thread Geoffrey Garen
 Implementations that use ECMAScript to implement the APIs defined in this 
 specification must implement them in a manner consistent with the ECMAScript 
 Bindings defined in the Web IDL specification [WEBIDL], as this specification 
 uses that specification and terminology.

Why are we still talking about ECMAScript in our standards, now that all web 
apps are written in Dart?

Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Feature announcement: Web VHS API

2013-04-01 Thread Alexis Menard
Hi Ryosuke,

Thank you for the feedback.

On Mon, Apr 1, 2013 at 2:06 PM, Ryosuke Niwa rn...@webkit.org wrote:
 Why are rewind(), forward(), pause() and eject() all blocking APIs? I don't
 think we should be blocking the main thread while those operations are
 taking place.  In particular, rewind() can take anywhere from a few seconds
 to a few minutes.  We should let authors show some kind of UI for rewinding,
 and keep the web page responsive while VHS is rewinded.

The tape WG wanted to preserve the synchronous aspect of the VCR, the
physical eject of a VCR takes few seconds and you're usually watching
it and not doing anything else. It should be the same for the UA.

I tend to agree for rewind() and forward(), we may get them async,
letting UA the freedom to implement a nice rewinding/forwarding
animation while the command is executed.


 I'm also confused by the fact VHSOutput interface has a method,
 streamToYouTube, that specifically supports one website.  Are we expecting
 to add methods like streamToDailyMotion, streamToUStream, etc...?  I'd
 prefer coming up with a generic format and let author specify an URL to
 which the video is streamed.

Yes future-proof APIs were not part of Level 1.


 Also, why are VHSInput and VHSOutput separate interfaces?  It appears that
 all methods on those two interfaces can just be on VHSAccess.

The more complex it appears the more serious it looks like.


 - R. Niwa


 On Mon, Apr 1, 2013 at 4:17 AM, Alexis Menard ale...@webkit.org wrote:

 Hello,

 I would like to let you know that I plan to add support for the Web VHS
 API to WebCore. The Web VHS API is a specification to bring VHS support to
 the Web.

 This support will be behind the ENABLE_WEB_VHS feature define.

 The spec is here:
 http://bit.ly/YVHIga

 Here is the tracking bug:
 https://bugs.webkit.org/show_bug.cgi?id=113697

 Let me know if you have any questions or comments.

 Best regards,
 Alexis

 --
 Software Engineer @
 Intel Open Source Technology Center

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev





--
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Feature announcement: Web VHS API

2013-04-01 Thread Glenn Adams
On Mon, Apr 1, 2013 at 10:39 AM, Michael Saboff msab...@apple.com wrote:

 I had heard that there is some disagreement among browser vendors as to
 video formats being supported with the Web VHS API.  Safari will only
 support the Not Too Saturated Colors (NTSC) format to improve clarity,
 while Chrome has agreed to the Paint As Lines (PAL) vectorizing format.
  Opera will only support See Every Color As Magenta (SECAM) format to
 reduce bandwidth.  I also heard plug-ins are being developed to bridge the
 formats.


correction... NTSC = Never The Same Color (twice) ... will we add VCR+
support as well to schedule recordings? ;)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Feature announcement: Web VHS API

2013-04-01 Thread Gavin Barraclough
On Apr 1, 2013, at 12:36 PM, Glenn Adams wrote:

 correction... NTSC = Never The Same Color (twice)

How do we intend to implement this? – any pseudo random behaviour needs to be 
cryptographically secure to avoid risking an information leak here.

G.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Feature announcement: Web VHS API

2013-04-01 Thread Dirk Schulze

On Apr 1, 2013, at 1:26 PM, Gavin Barraclough barraclo...@apple.com wrote:

 On Apr 1, 2013, at 12:36 PM, Glenn Adams wrote:
 
 correction... NTSC = Never The Same Color (twice)
 
 How do we intend to implement this? – any pseudo random behaviour needs to be 
 cryptographically secure to avoid risking an information leak here.
 

You mean a time attack on VHS content? How does it actually affect request 
animation frame? Always 21 frames for NTSC and 24 for PAL? Can this be used to 
integrate region codes to prevent europeans to see VHS from the US?

Dirk

 G.
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Feature announcement: Web VHS API

2013-04-01 Thread Filip Pizlo
We could do a custom JIT using Intel's crypto acceleration.

Could be even more epic than writing regexp JITs, I'm telling you it'll make 
other engines look like fisher-price toys!

-Filip


On Apr 1, 2013, at 1:26 PM, Gavin Barraclough barraclo...@apple.com wrote:

 On Apr 1, 2013, at 12:36 PM, Glenn Adams wrote:
 
 correction... NTSC = Never The Same Color (twice)
 
 How do we intend to implement this? – any pseudo random behaviour needs to be 
 cryptographically secure to avoid risking an information leak here.
 
 G.
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev