W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2006

[whatwg] Video

From: Charles Iliya Krempeaux <supercanadian@gmail.com>
Date: Mon, 30 Oct 2006 22:42:13 -0800
Message-ID: <84ce626f0610302242k7cb61302nb44b05fb25590726@mail.gmail.com>
Hello,

On 10/30/06, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
>
> Ian Hickson wrote:
> > On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote:
> >> Would you be open to hearing suggestions about how to add native video
> >> and video player support?
> >
> > Sure. FWIW, there's a lot of interest in browser vendors about
> introducing
> > a <video> element or some such (or maybe making browsers natively
> support
> > video in <object>, or both).
>
> I don't like the idea of a <video> element just for the purpose of
> embedding video.  What I think needs to happen is for browser vendors
> and plugin vendors to improve the usability and add better support for
> video formats.  Places like YouTube and Google Video work around this by
> building their own interface using Flash, which handles multiple formats
> seamlessly for the user.


Not exactly.  Flash players only play FLV video files.  And that's it
(AFAIK).

Behind the scenses... server-side... other video formats a transcoded to
FLV.

The problem with Flash is that Flash is NOT a video.  It's an "application"
like Java applets.  (Although Java has way way way more power than Flash.)

The point is that potenially you do NOT have access to the video file(s) at
all.  And that is a big problem!!!


With the current plugin architecture, each plugin provides it's own UI.
>   So that, for example, a Quick Time video (.mov) gets the Quick Time UI
> and a WMV gets Windows Media Player.  That's a bad user experience, the
> browser should provide a common UI for all videos, regardless of the
> format.


As I'm going to mention more in my list... I'd recommend that web developers
can create their of UIs... create their own Video Players.

There could be a default styling.  But web developers should be able to have
full control of the look.


Perhaps, to go along with the Audio() interface, we could have a Video()
> interface as well.  Maybe it would be wise to introduce a MultiMedia()
> interface, which is then inherited by both the Audio() and Video()
> interfaces and extended by each with APIs specifically for their
> respective media.  e.g. Video() could have an API for capturing a frame
> and exporting it as a JPG or PNG.


The frame capturing would be cool (and useful).


I guess I wasn't paying attention when the Audio interface was being
discussed, because I totally missed it.

Looking at it now, I'd make some alterations to it.

For example, there's a difference between "pausing" and "stopping".  (With
"pausing" you still have your "position" and a "velocity" in the audio
stream.  With "stopping", each of those are null/nil.)  And there should be
different procedures for each.

Also, there should be a way of playing at different speeds and playing
backwards too.

Previously, I've defined this as the "velocity" in APIs.  A velocity of "1"
is normal playing.  A velocity of "-1" is playing backwards.  A velocity of
"-2.5" plays backwards 2.5 times the normal speed.  A velocity of "0.25" is
playing forward at 1/4 the speed.

Also... when implementing UIs, it's useful to have a "toggle()" procedure.
Something that makes it "pause" if it is "playing".  And makes it "play" if
it is "pausing".  Without this you have to keep track of the state of the
player.

(This is part of my item #6 on my list.)


Those interfaces could also possibly be implemented on the <object> and
> <embed> elements.
>
> Charles Iliya Krempeaux wrote:
> >> #1: A natively supported video format.  (Like the way GIF's, JPEG's,
> and
> >> PNG's are natively supported.)
>
> Defining which video format for browsers to support is out of scope of
> the WHATWG and HTML5.


That's unfortunate.


However, I do agree that there needs to be a more
> widely supported format so that websites don't have to offer the user a
> choice (commonly WMV, Quick Time and Real).


Getting a little off topic... but those aren't the main ones I've seen.  I
don't even see Real used anymore.  (Maybe I'm not looking hard enough
though, but....)

Certainly QuickTime and WMV are common.  But (as I remember from a survey
someone did on the Videoblogging mailing list) people are also procuding M4V
(for iPods/iTunes), MP4 (for PSPs),  DivX, and some people are even
producing Ogg Theora.  (I think there were some others too... but I don't
remember off the top of my head.)



  If offered a choice, it
> should only be to pick one suitable for their bandwidth.
>
> > Given this, I would suggest Ogg Theora be the natively supported video
> > format common to all browsers.
>
> It would be very nice to have a widely supported, non-proprietary,
> patent free format on the web, which is also completely free of DRM.  I
> would love to see Ogg Vorbis/Theora become as successful in the audio
> and video market as PNG has for images, but the current problem holding
> it back is the lack of implementation in the major media players and
> browsers.


This might be the chicken and the egg problem.


In comparison, alpha transparency in PNG hasn't taken off significantly
> despite having major benefits over index transparency, primarily because
> IE hasn't supported it until now.  I suspect that will change once IE7
> becomes more widely deployed.
>
> I aware that there are many implementations of ogg available, but
> Windows Media Player,


Use this...
http://www.illiminable.com/ogg/


Quick Time


Use this...
http://xiph.org/quicktime/


and Real Player



Use this...
https://helixcommunity.org/frs/?group_id=7


don't.  Of course, it
> would also be nice if VLC (when it matures enough) became the most
> popular player, but that's not going to happen any time soon.


A little off topic... but VLC is extremely popular where I live.

Most people know about it and use it.


So, I
> think it would be a good idea for the video and audio community to
> strongly encourage native implementation of ogg in the major players and
> authoring tools.
>
> Once the major players support it, we'd then need to see digital cameras
> and other authoring equipment adopt ogg as the native format, instead of
> MPEG and Quick Time.  Aside from the companies who have a stake in
> proprietary formats, I'm sure they would like to because they could save
> money on licensing fees.
>


See ya


-- 
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20061030/bc539491/attachment.htm>
Received on Monday, 30 October 2006 22:42:13 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:49 UTC