Re: [whatwg] HTML5 Video - Issue and Request for improvment

2011-01-29 Thread Monty Montgomery
 If I want to toggle play/pause
 on video area click, then I cannot do this, because clicking on the play
 control button, fires play, then click event fires for video tag and when I
 toggle It pauses. So this behavior that every popular flash player has
 cannot be achieved. There is no way to understand that the click.target is
 the embedded browser controls area.

You can do it by writing your own controls for an overlay div.

It's not as involved as it sounds. One of the demos at OVC this past
fall was a ten-minute demo of writing full custom controls from
scratch, including drawing the buttons, etc.

Monty


Re: [whatwg] Live video streaming with html5.

2010-09-22 Thread Monty Montgomery
 I run a HTML5 streaming business. I use icecast to send Ogg with
 Theora+Vorbis. It works splendidly in Opera and Firefox. Chromium has
 some problems because they use ffmpeg which is not always that good
 when decoding Theora, but if I use the old, bad versions of Theora, it
 also works in Chromium (and thus Chrome).

ffmpeg fixed the Theora probems earlier this year (after being kinda
standoffish for many years before that), but Google has not updated
their fork since well before the WebM announcement.

Monty


Re: [whatwg] Html 5 video element's poster attribute

2010-09-20 Thread Monty Montgomery
 They are not designed to be independent. If you want them to be independent,
 use a real independent image placed over the video.

Is there a way to do this without also obscuring the controls [making
them inacessible]?

Monty


Re: [whatwg] Html 5 video element's poster attribute

2010-09-19 Thread Monty Montgomery
Ah, interesting, I just wasted most of last night trying to figure out
why I couldn't get poster to do anything sane or useful in Chrome or
Firefox (actually-- FF4 betas change behavior completely and the
poster.. sort of... behaves as expected).

 Currently the poster disappears as soon as the first frame has been
 downloaded, which typically takes a second. The player then shows this first
 frame, but 99% of the time the first frame is black. So what you see is a
 black box.

 Not quite: this is an implementation decision that Webkit-based browsers
 made. Neither Opera nor Firefox work that way (haven't checked IE yet).

Firefox 3.x practically never shows the poster.  As soon as it has a
frame, boom, poster is gone and I've got a big blank square.  This is
almost instant.  I'm in the process of scripting my own controls from
scratch so I can force-overlay the video element with an absolute
div to show the poster until the user hits play (I have to
reimplement controls, as overlaying a div hides the native controls;
they don't pop and they wouldn't get events if they did, or even if I
forwarded them as the native FF controls ignore synthesized events).

FF4 beta shows the poster until the first frame is played (yay).
Chrome is the polar opposite from FF3 and shows the poster anytime it
doesn't have a frame ready right now, meaning it shows up constantly
during seeking, layout changes and stutters.  [But Chrome's video
playback is darned near unusable anyway.  Why is the first minute of
every video just missing?]

 The poster frame of a video is probably the most important not only for
 the viewer but also for the content producer. It’s the one shot the content
 producer gets at enticing the viewer to watch her video. Most video websites
 therefore provide multiple ways in which the content producer can define a
 poster frame for her video.

Now that I'm doing production to force myself to see this from the
viewpoint of the content producer, I couldn't agree more.

 The solution would be the following:

 The poster frame should remain visible until the video is played.

 The poster should not show while the player is seeking (some browser
 implementation do show the poster while seeking, resulting a flashes)

Yes, at a minimum Chrome does this.  With my producer hat on, it makes no sense.

 The poster should show again after the video has ended.

 I think this would be confusing and would prefer it it just stays at
 displaying the last played frame. That gives users the visual queue that the
 playback has finished.

If the default action is to redisplay the poster, the other
possibilities are available via trivial scripting (remove it or even
replace it with a different poster after we start playing).  If the
poster does not redisplay and the content presenter wants it to, we're
back into scripting an entire control system from scratch, as
overlaying a div/image [to get the poster back] hides the native
controls and makes them inaccessable again.

FTR, if there is a way to overlay without muffling the controls under
an impenetrable [transparent/translucent/opaque] layer, do let me
know.

 The visibility of the poster should be scriptable and/or controllable
 using an attribute. Meaning that one should be able to turn on/off the
 poster (without changing the poster attrbute’s value)

 Is this really necessary? What would be the use case? Either you want to
 poster - then you provide the attribute - or you don't want it - then you
 don't provide it. Also, per script you can remove the attribute and reset
 it, if you really need it. I don't see what an extra attribute would add?

Yes, I think this suggestion is one bridge too far and agree with Silvia.

I don't want exactly what I want with no scripting-- I want what I
want without a thousand lines of scripting to undo and subtly
reimplement a similar amount of C.

Monty
Xiph.Org


Re: [whatwg] Html 5 video element's poster attribute

2010-09-19 Thread Monty Montgomery
Actually, the browser behavior is all more complicated than this
the preload attribute is influencing it strongly  eg, FF4 doesn't
show the poster if 'preload' is not set to 'none' And I was wrong
now that I recheck chrome... it too replaces poster with first frame,
but the poster shows up constantly in flickers (eg, during seeking).

 You should see the poster - press play and it goes away and the video
 plays. This seems to work fine in FF 3.6 and 4.0 beta for me. If it
 doesn't work for you, please report a bug.

You have preload set to none in these; if you set to metadata or auto,
no poster :-(

Monty


Re: [whatwg] Html 5 video element's poster attribute

2010-09-19 Thread Monty Montgomery
[apologies, FF4 is working properly... tracked it down to setting
'video.currentTime=0' kicks off dropping the poster and actively
preloading]

...but not losing sight of the original post, I agree with the
suggestions, and am happy to find FF4 is already following them.

Monty


Re: [whatwg] On implementing videos with multiple tracks in HTML5

2010-05-31 Thread Monty Montgomery
2010/5/31 Lachlan Hunt lachlan.h...@lachy.id.au:

 WebM, just like Matroska, certainly does support multiple video and audio
 tracks.  The current limitation is that browser implementations don't yet
 provide an interface or API for track selection.

It could, but the spec currently explicitly disallows it.  Has that
changed while I was not looking?

Also, Silvia-- one reason Ogg was designed the way it was so that
remuxing was trivial-- it was a simple as deciding what pages to send
out.  The remuxing was trivial (shuffling a deck of cards; the cards
remain unchanged)

Monty


Re: [whatwg] On implementing videos with multiple tracks in HTML5

2010-05-31 Thread Monty Montgomery
2010/5/31 Monty Montgomery xiphm...@gmail.com:
 2010/5/31 Lachlan Hunt lachlan.h...@lachy.id.au:

 WebM, just like Matroska, certainly does support multiple video and audio
 tracks.  The current limitation is that browser implementations don't yet
 provide an interface or API for track selection.

 It could, but the spec currently explicitly disallows it.  Has that
 changed while I was not looking?

I just looked through the docs I have, and I'm clearly worng-- none
specify such a restriction.

Monty