Re: [whatwg] make video always focusable and interactive content
On Wed, Jun 20, 2012 at 5:47 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: They are in Opera. The spec allows it. Yes, thankfully one browser has video keyboard interaction. I just tested Firefox and the keys work. See Media Shortcuts here: https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly I could tab to the video, a focus ring appears around it, and use the keys in that list. Did that not work when you tried it? Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video element not ready for prime time
On Fri, Jan 13, 2012 at 6:46 AM, Francis Boumphrey boumphre...@gmail.com wrote: Firstly if I use a video with the src attribute e.g. video src='myvideo.mp4' controls and my user agent does not support the format, all I get (in my versions of Opera and Firefox) is a blank screen. Recent versions of Firefox display a message for the user if the mime type of the video is not supported instead of a blank screen. -- http://www.bluishcoder.co.nz
Re: [whatwg] HTML5 video seeking
On Wed, Nov 16, 2011 at 7:19 AM, Aaron Colwell acolw...@chromium.org wrote: I'm just trying to determine if we are intentionally requiring frame accurate seeking at this point or am I just misinterpreting some part of the spec. My understanding from the discussion at the time was that it was intentionally requiring frame accurate seeking and this is what Mozilla ended up implementing in Firefox as a result. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] How to handle multitrack media resources in HTML
On Thu, Apr 21, 2011 at 12:31 PM, David Dailey ddai...@zoominternet.net wrote: When we do get around to it, it would be nice, as well, to be able to create sounds (as from wave forms) from scratch, in the browser. There's experimental work being done on this. For example: https://wiki.mozilla.org/Audio_Data_API http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Html 5 video element's poster attribute
On Wed, Sep 22, 2010 at 6:00 PM, Shiv Kumar sku...@exposureroom.com wrote: No, this won’t work. I don’t want the poster to be shown during a seek so the question of showing it until seek completes is moot. I think Chris meant that the poster should remain shown if the user chose to seek instead of play when the video first loads. Showing the poster during any other seek wouldn't make sense. So really, what you’re saying is simply forget about using the poster attribute altogether. Which is exactly what a few others have done including us, so this whole dialog has been futile. In that case you don’t need to tihghten up the spec either. Unfortunately, as has been pointed out by others, the 'using an image' approach becomes problematic when you are using the built in browser controls. I like the idea of being able to manually turn on and off the poster display. Removing the poster attribute is an option to turn the poster off but there is no way to turn it back on again. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Html 5 video element's poster attribute
On Mon, Sep 20, 2010 at 1:15 PM, Monty Montgomery xiphm...@gmail.com wrote: Firefox 3.x practically never shows the poster. Firefox 3.5 didn't have poster implemented so it definitely won't show there. Firefox 3.6 does implement poster and it works for me. If you look at the following page the bottom 3 videos have a poster set: http://tinyvid.tv 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. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Timed tracks: feedback compendium
On Wed, Sep 8, 2010 at 11:19 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 26 Aug 2010, Chris Double wrote: Firefox (in the case of video) uses file extensions to identify video files. We have an internal maping of file extensions to mime types. We don't sniff the content. I imagine we'd do the same with whatever file extension is used for WebSRT. (I assume this is only for the filesystem, not data from the wire!) Yes, this is only for the filesystem. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Thu, Aug 26, 2010 at 2:39 AM, Philip Jägenstedt phil...@opera.com wrote: It's actually easier for a browser to ignore the MIME type than it is to be strict about it, at least when the format is easily identified by sniffing (sniffing code is needed anyway for local files). Firefox (in the case of video) uses file extensions to identify video files. We have an internal maping of file extensions to mime types. We don't sniff the content. I imagine we'd do the same with whatever file extension is used for WebSRT. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Thu, Aug 26, 2010 at 2:39 AM, Philip Jägenstedt phil...@opera.com wrote: The main reason to care about the MIME type is some kind of doing the right thing by not letting people get away with misconfigured servers. Sometimes I feel it's just a waste of everyone's time though, it would generally be less work for both browsers and authors to not bother. I disagree that this is the main reason. I was a web developer before being a browser developer and I can say it was highly annoying dealing with browsers that sniff content types. There were times where we wanted to send a file as plain text or binary data but the browser would sniff it and attempt to handle it. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Thu, Aug 26, 2010 at 5:25 AM, Eric Carlson eric.carl...@apple.com wrote: FWIW, I agree with Silvia that a new file extension and MIME type make sense. I also think that a new file extension and MIME type is the way to go. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)
On Mon, Aug 23, 2010 at 11:03 PM, Philip Jägenstedt phil...@opera.com wrote: It's too late, all scripted controls for video that display a timeline are already using the duration property. And they're probably using it as a duration not an end time. Doesn't this change cause problems? -- http://www.bluishcoder.co.nz
Re: [whatwg] HTML5 video source dimensions and bitrate
On Sat, Aug 14, 2010 at 4:05 AM, Zachary Ozer z...@longtailvideo.com wrote: It would still be nice if the video made dropped frame information available, but that's probably not in the cards. I have a work in progress bug with patch that adds this to the video implementation in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=580531 It adds a 'mozDroppedFrames' as well as a couple of other stats people have queried about here (download rate, framerate, etc). I'd be keen to see something like this get discussed/added. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] HTML5 video source dimensions and bitrate
On Sat, Aug 14, 2010 at 2:26 PM, Eric Carlson eric.carl...@apple.com wrote: mozDownloadRate - What are the units, bit per second? Bytes per second. mozPlaybackRate - Is this the movie's data rate (total bytes / duration)? Yes. This and mozDownloadRate were available internally already for 'can play through' calculations so I just exposed what we already have. 'mozPlaybackRate' is a bad name though since there is already a concept of 'playback rate' for playback speed. mozFrameCount - What do you propose a UA report for a partually downloaded VBR movie, or for a movie in a container that doesn't have a header (ie. one where you don't know the fame count until you have examined every byte in the file)? This is another bad name for what it actually is. It's a count of each frame as it is displayed. So the inverse of mozDroppedFrames really - it probably should be mozDisplayedFrames or something. I'm not sure if it's useful but it's the original stat I had for computing framerate playback in JavaScript in my tests. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] HTML5 video source dimensions and bitrate
On Tue, Aug 10, 2010 at 11:00 AM, Zachary Ozer z...@longtailvideo.com wrote: As a result, I was wondering if there's some way to attach metadata like the dimensions and bitrate to source elements of HTMLMediaElements in the DOM. I realize that we could wait for metadata to arrive for each source, but it would be nice if it was possible to make an intelligent choice before attempting to play all of them. You don't get metadata for each source, you only get the metadata for the source that is actually selected to play. I don't think listing video's which are only different due to bitrate in the source as being a good approach since most players will iterate through all sources trying to play them. So if you have 5 '.ogg' videos first in the source list, different only by bitrate, a non-ogg player is going to check each of those, possibly sniffing them and causing network traffic. Since your player is already JavaScript is having a JS object holding the URL, dimensions and bitrate not an option? Or you could have a seperate file that is retrieved via XMLHttpRequest that is parsed to extract these details and dynamically adjust 'source' elements after that? How are you working out the current playback rate to decide when to switch to a different bitrate version? Is having an attribute of the media element that contains this information useful? Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video application/octet-stream
On Thu, Jul 22, 2010 at 1:53 AM, Philip Jägenstedt phil...@opera.com wrote: Opera does not, that would lead to an extra network roundtrip. Instead, when the MIME type is not one of the allowed ones, the connection is closed immediately. Same with Firefox. There's also no guarantee that after you've done the HEAD that the subsequent GET retrieves the same resource and mime type. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video application/octet-stream
On Thu, Jul 22, 2010 at 1:59 AM, Mike Shaver mike.sha...@gmail.com wrote: That's what I expected, so I guess I don't understand what the how much are you willing to sniff? question is about. When content sniffing are we ignoring the mime type served by the server and always sniffing? If so then incorrectly configured servers can result in more downloaded data due to having to read the data looking for a valid video. For example: video source src='foo.ogg' source src='foo.mkv' /video If the web browser doesn't support Ogg but does support matroska, and the server sends the video/ogg content type, the browser can stop and go to the next source after downloading very little data. If the web browser is expected to ignore the mime type and content sniff it must see if 'foo.ogg' is a matroska file. According to the matroska spec arbitary ASCII data can be placed before the EBML identifier. This means reading a possible large amount of data (even the entire file) before being able to say that it's not a matroska file. That type of scenario is what I was getting at about how much of the file should be read before giving up. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video application/octet-stream
On Thu, Jul 22, 2010 at 2:15 AM, Mike Shaver mike.sha...@gmail.com wrote: ...I would probably suggest that the developers of said browser implement basic Ogg support (enough to say this is Ogg, so we don't support it), and go back to solving more pressing problems! Or the developers of said browser could obey the mime type that the server sent, not have to write or maintain error prone content sniffing code that could behave differently across browsers (Chrome content sniffs this as Ogg but you dont!!, etc), and solve even more pressing problems! Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video application/octet-stream
On Thu, Jul 22, 2010 at 6:10 AM, Boris Zbarsky bzbar...@mit.edu wrote: I don't like sniffing any more than the next guy, but the work needed to properly MIME label a modern media format (with the whole container and multiple streams thing) is ... excessive. I doubt anyone's going to do it, so we're really talking about just labeling the container format, right? Yes, in the majority of cases the MIME type will be for the container format. We'd treat the MIME type much like canPlayType in that we'd try to play any 'maybe' result from that MIME type I expect. You might say Hey, but aren't you content sniffing then to find the codecs and you'd be right. But in this case we're respecting the MIME type sent by the server - it tells the browser to whatever level of detail it wants (including codecs if needed) what type it is sending. If the server sends 'text/plain' or 'video/x-matroska' I wouldn't expect a browsers to sniff it for Ogg content. As I mentioned in a previous email, the sniffing could result in a reasonable amount of data being consumed. I'm sure people who run sites that share HTML 5 video would appreciate browsers not consuming data bandwidth to sniff files that they've already specified as being something the browser doesn't support. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video application/octet-stream
On Thu, Jul 22, 2010 at 12:22 PM, Robert O'Callahan rob...@ocallahan.org wrote: Also, in your example the author could have provided type= attributes on the source elements to control what gets downloaded. I assume that no-one is proposing we ignore those. This is true but the provider of the server with the video and the author of the page containing the video element can be two different people. There is no cross domain restriction on serving video so while the server may want the 'type' attribute to be included in the source element they can't control third parties doing this who embed the video in their site. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video application/octet-stream
On Tue, Jul 20, 2010 at 9:48 PM, Philip Jägenstedt phil...@opera.com wrote: I'd like to hear from Mozilla, Google and Apple which of these (or other) solutions they would find acceptable. You'll probably get different responses depending on who in Mozilla responds. For example, I prefer option (1) and am against content sniffing. Other's at Mozilla disagree I'm sure. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] On the subtitle format for HTML5
2010/5/23 Odin Omdal Hørthe odin.om...@gmail.com: Anyway, as of now I'm just waiting for a way to tell my webapp what slide we're on (sync with the live streaming video). Can't you use the timeupdate event, get the 'currentTime' from the video, and decide what slide to show based on that? Or poll currentTime in a setTimeout? That's how most of the JavaScript subtitle examples work with video at the moment I think. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] On the subtitle format for HTML5
On Sun, May 23, 2010 at 11:40 PM, Odin Omdal Hørthe odin.om...@gmail.com wrote: So it's quite impossible to use that for syncing. I asked about that here in this list, and got the answer that this is what we have startTime property for, -- but it is not implemented correctly in any browsers. startTime would then maybe say 0:00:00 for most clips, but on streaming Leslie would have 0:10:00, and then I can use that for syncing. Ah right, I missed the 'live' part of the streaming. If 'startTime' would enable you to do what you want and browsers have implemented it incorrectly (or not at all), raise bugs. I'm sure they'll get onto it. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Introduction of media accessibility features
On 10/04/10 10:41, Silvia Pfeiffer wrote: This proposal introduces declarative markup to associate external timed text resources (such as captions and subtitles) with a media resource. It introducestrack andtrackgroup elements to be used inside media elements and provides some recommendations on how to render the text resources. -- The proposal mentions SRT. There is no official specification for SRT is there? If so, will there be a definition of the version of SRT that is expected to be supported? The Wiki entry [1] mentioned lists a number of optional extensions for example. Are these expected to be supported? Is it expected that all of TTML will be required? The proposal suggests 'starting with the simplest profile', being the transformation profile. Does this mean only the transformation profile is needed to provide subtitle features equivalent to SRT? The later note (two formats are proposed to be supported, one of which is trivially simple and the other has all the bells and whistles required for high-quality caption and subtitles) seems to imply that more than the transformation profile will be required. I am wary of being required to implement the entire TTML specification and an underspecified SRT format. [1] http://wiki.videolan.org/SubRip Chris. -- http://bluishcoder.co.nz
Re: [whatwg] Codecs for audio and video
On 02/02/10 06:05, Chris McCormick wrote: I think I speak for all procedural audio people when I say, can't we get the browsers to allow sample-block access to audio? Dave Humphrey has been working on adding an API to do this to Firefox. He's been blogging about it here: http://vocamus.net/dave/?cat=25 Chris. -- http://bluishcoder.co.nz
Re: [whatwg] Make Vorbis a baseline codec for audio
2009/7/16 Ian Fette (イアンフェッティ) ife...@google.com: Widely adopted ... in portable media players? Really? iPod? Zune? Almost every media player I've purchased from the local electronics store here in NZ has Vorbis support. Many of them even support Flac. The notable exception is Apple products. This was without even trying to get one that supported these formats. Xiph maintains a list. There are quite a few: http://wiki.xiph.org/PortablePlayers Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Codecs for audio and video
Could you elaborate on what your use cases are? Is it just the ability to manually decode audio tracks? I actually have thought about this. Having an ability to post-process, mix, or generate audio content manually is useful for certain classes of games and applications. There's been some discussion about this type of functionality in this Mozilla bug too: https://bugzilla.mozilla.org/show_bug.cgi?id=490705 Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] HTML 5 video tag questions
On Mon, Jun 15, 2009 at 1:46 PM, jjcogliati-wha...@yahoo.com wrote: 1. What happens if the user agent supports the video tag but does not support the particular video codec that the video file has? Should it display the fallback content in that case, and if so, can a video tag be put inside another video tag? It does not display the fallback if the codec/format is not supported. The fallback is only displayed in a browser if the video element is not supported at all. 2. What is the recommended way for website authors to determine what video and audio codecs and containers are supported by a user agent? Ideally all user agents will have one codec that is supported across all implementations. Failing that there's a JavaScript API for querying codec support. Look for 'canPlayType'. Chris -- http://www.bluishcoder.co.nz
Re: [whatwg] HTML 5 video tag questions
On Mon, Jun 15, 2009 at 5:27 PM, Tab Atkins Jr.jackalm...@gmail.com wrote: (That said, I don't think there's anything wrong with nesting videos, it's just unnecessary.) This won't work since fallback content is not displayed unless video is not supported. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Start position of media resources
On Fri, Apr 10, 2009 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote: http://example.com/video.ogg#t=5s displaying the selected frame, but displaying a timeline for the full video and allowing the user to directly go to any position. For this to work with custom user interfaces in JavaScript, the JS needs to be able to find out the start time position of the video. Should this be available as an attribute of the video DOM object, or is it ok to require them to parse the information from the URL? Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Start position of media resources
On Mon, Apr 6, 2009 at 9:40 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: If we want to display that there is some more context around the video, we should display the offset time. I personally would prefer the latter option, since it relates directly with the original resource. This is what Firefox does at the moment for oggz-chop generated videos which have these non-zero start times. The issue was brought to my attention by a user that compared it to Safari using the XiphQT plugin. In that case the time offset starts at zero apparently. Possibly a difference in how XiphQT reports the time from the file. I doubt though we need another attribute on the element - the information is stored in the src URL, so should be retrieved from there IMHO. In this case it is not stored in the src URL in a way the author of the document can retrieve. An oggz-chopped file can be copied and served with a normal filename for example. The time is embedded in the Ogg file. There is no way for the author to retrieve it. Hence the need for an attribute. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Start position of media resources
On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson eric.carl...@apple.com wrote: Media time values are expressed in normal play time (NPT), the absolute position relative to the beginning of the presentation. I don't see mention of this in the spec which is one of the reasons I raised the question. Have I missed it? If not I'd like to see the spec clarified here. Chris. -- http://www.bluishcoder.co.nz
[whatwg] Start position of media resources
Ogg based media resources can start from a time position that is not zero. Examples of files that do this are those generated by the program oggz-chop. For example: http://ia331342.us.archive.org/2/items/night_of_the_living_dead/night_of_the_living_dead.ogv?t=0:20:00/0:20:50 If this is played in VLC the start time of the video is 0:20:00. When seeking the time requested for the seek must be between 0:20:00 and 0:20:50. Does the HTML5 spec allow media resources that don't start from 0? I see in the spec mention: Media elements have a current playback position, which must initially be zero. The current position is a time. In the case of the Ogg file above, the current playback position would initially be zero, but when the first frame is loaded it will be 0:20:00. Is this valid per the spec? If so, would we need an attribute on the media object so the web page author can retrieve the start time of the video (in the same way they can get the duration). They would need this to be able to display progress bars/scrubbers to position the thumb correctly based on the currentTime. Detecting the first frame or metadata loaded events and getting the position of the that won't work as some of the video may have been played by the time that event is handled by user code. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Video and Audio schema for validators
On Fri, Jan 23, 2009 at 1:55 PM, Arne Claassen ar...@mindtouch.com wrote: In particular, I came across a couple of event handlers in examples that i can't find defined anywhere in the specs, like ondataunavailable and oncanshowcurrentframe These are probably some of my examples that I wrote back when the spec used to have those. I've not updated the examples on that page to match the current spec. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] media elements: Relative seeking
On Mon, Dec 1, 2008 at 11:28 PM, Ian Hickson [EMAIL PROTECTED] wrote: For the few servers that don't support seeking, duration is not available. Note that that is non-conforming at the moment. You have to have a duration available (though it can be +Infinity if you think that the resource is a stream, and can be an estimate, so long as you keep updating it as your information gets better.) I think the spec should be changed to allow duration to be NaN in the case where it cannot be determined. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] media elements: Relative seeking
On Tue, Dec 2, 2008 at 3:06 PM, Ian Hickson [EMAIL PROTECTED] wrote: We removed some other features (e.g. bufferedBytes and totalBytes) because implementors said they would always provide accurate values in the buffered and duration attributes. If we allow duration to be NaN, then we'd have to re-add the other features again. It's not possible to always provide accurate values for duration - we've already discussed that and you suggested estimating. I don't see that as an accurate value. Can you link to the post where implementors said they would always provide accurate values? The only accurate value I can provide with Ogg is the exact duration if the http server supports byte range requests, or some other out of band duration metadata (X-Content-Duration, etc). Without byte range requests, accurate duration is not possible. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video tag: pixel aspect ratio
On Mon, Dec 1, 2008 at 7:11 PM, Peter Kasting [EMAIL PROTECTED] wrote: I don't think it is the end of the world if this attribute goes in, but I see very little benefit to it, and I am always for removing items with marginal utility. I'm inclined to agree. I think it's odd that an attribute is being added to fix video's encoded incorrectly. Why can't the author of the video fix the actual video? One of the arguments for captions being embedded in video's rather than having some way of defining captions by the page author was that it's important not to use HTML to fix broken videos, and allow captions to travel with the file. The same argument could be made for pixel ratio. Fixing it in the HTML means everyone linking to the file using video will need to remember to add pixelratio to their HTML. Better to fix the file. Can someone provide examples of videos on the web that are currently broken, and a pixel ratio that would fix it? As an HTML author that wants to embed a video on my website I don't think I'd have any idea how to come up with a pixel ratio to fix it. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] media elements: Relative seeking
On Wed, Nov 26, 2008 at 12:28 AM, Silvia Pfeiffer [EMAIL PROTECTED] wrote: In any case - if you (and also Chris Double) are satisfied with the estimates you're getting for file duration/length - I'll stop arguing for it. It would be nice to hear some experimental evidence about how well it's doing, e.g. for typical movie trailers, so we can lay that argument to bed knowing we've done our homework. I won't be estimating the duration - the user experience of a fluctuating duration is terrible. For now for Ogg files, I'm seeking to the end and getting the duration. For the few servers that don't support seeking, duration is not available. I may check for X-Content-Duration which I believe mod_annodex and soon oggz-chop support. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Can AUDIO/VIDEO element have a balance attribute
On Sun, Nov 16, 2008 at 5:50 PM, Nils Dagsson Moskopp [EMAIL PROTECTED] wrote: Not to be rude, but can you desribe a use case that is not some kind of game ? Wouldn't games be one of the major uses of audio? Chris.
Re: [whatwg] Issue when Video currentTime used for seeking.
On Wed, Nov 12, 2008 at 6:36 PM, Biju [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
video_element.src=http://www.double.co.nz/video_test/ascannerdarkly480.ogg;;
video_element.currentTime=10;
video_element.play();
You can use:
v.src = foo.ogg;
v.addEventListener(loadedmetadata, function() { v.currentTime=10;
v.play(); }, false);
Chris.
--
http://www.bluishcoder.co.nz
Re: [whatwg] Issue when Video currentTime used for seeking.
On Wed, Nov 12, 2008 at 6:36 PM, Biju [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: toKeyFrame - optional, boolean, default false. if true indicates goto the nearest keyframe of the value provided in secondsToSeek. this is to improve performance while avoiding bug https://bugzilla.mozilla.org/show_bug.cgi?id=463358 Good question. Should seeks go to the previous keyframe to the requested time, the next keyframe after the time, the closest keyframe, or the exact frame requested? Regarding that bug, I think it should be going to the last keyframe then decoding up to the point of the requested frame so it can display non-garbage data. But is there a requirement to be able to identify keyframes from JavaScript? I suspect not but don't know. .seek() will return the time to which it is seek-ed to. What time is that exactly? Is that the time of the actual frame the seek ended on? Seek can take some time if it requires multiple http byte range requests to find the right location, and to search for the keyframe. You wouldn't want this to be a blocking call but it would need to be if you want to return the time. Chris. -- http://www.bluishcoder.co.nz
[whatwg] Video element and duration attribute
Some video formats don't make it easy to get the duration. For example, Ogg files can be concatenated to form a single playable file. To compute the duration you need to do multiple seeks to find the chains and total the durations of each chain. Even in the unchained case a seek is required to go to the end of the file and work backwards finding a packet with a timestamp. While this is not difficult to implement it can be expensive over HTTP, requiring multiple byte range requests. The most common player for Ogg files on the web is probably the Cortado Java applet, and it has an applet parameter to specify the duration. There have been requests in #theora from people wishing that video supported a duration attribute that could be set in the HTML. Would such an attribute be useful? It seems to be a commonly used in current Ogg web solutions. Are there any other video formats that could benefit from this? Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video tag : loop for ever
On Thu, Oct 30, 2008 at 7:38 AM, Eduard Pascual [EMAIL PROTECTED] wrote: Wouldn't multiple audio elements be better here? I can see use cases where multiple audio elements might not be as useful as one containing multiple samples. I might have a single audio file containing 500 'parts of speech' which I form together to make my browser speak lojban, or create some sound effect. I don't want 500 audio elements. Each instantiation of an audio element requires that audio element to parse the metadata. I can't call play on that audio element until 'metadataloaded' occurs so I have to wait for the event and structure my code around that and the subsequent delay. I'm not sure that type of use case is very likely though. In my JavaScript 8080 emulator I took the approach of multiple audio elements for the sounds and it works quite well. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video tag : loop for ever
On Thu, Oct 30, 2008 at 1:46 PM, Nils Dagsson Moskopp [EMAIL PROTECTED] wrote: I'm not sure that type of use case is very likely though. In my JavaScript 8080 emulator Wait, what ? http://www.bluishcoder.co.nz/js8080 Needs a fast modern browser with recent canvas support. Webkit and Firefox nightly builds work. 'Enable Sound' loads multiple audio elements with the sound files and uses 'play' when the sound should play. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Video Element Events? - Use Case: Custom Progress Bar
On Wed, Oct 29, 2008 at 5:22 PM, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Perhaps I didn't read the spec carefully enough, but I don't see any such event. You're looking for the 'timeupdate' event. This gets raised whenever the current playback position changes. From the spec section 4.8.10.8: If the time was reached through the usual monotonic increase of the current playback position during normal playback, the user agent must then queue a task to fire a simple event called timeupdate at the element. (In the other cases, such as explicit seeks, relevant events get fired as part of the overall process of changing the current playback position.) Although this is hidden away in the cue ranges section, it happens on normal playback without cue ranges. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video tag javascript library for contemporary browsers
On Thu, Oct 16, 2008 at 7:35 AM, Michael A. Puls II [EMAIL PROTECTED] wrote: I *think* it has to do with the lack of hardware acceleration (even in webkit's implementation). It seems like it's all CPU driving the video element. No beefy CPU, no usable video element. Yes, this is certainly an issue. A player using hardware acceleration will outperform a player that doesn't. You won't be able to do things like overlay HTML over the plugin area, perform effects and transformations, copy the image of the video frame to canvas, etc with the plugin as a result. But, I don't know details. Just know that the videolan plugin can play theora videos with very little cpu usage, while the *experimental* video implementations use 100% cpu, display video at like 2fps and play audio like crap, unless you have a fast computer where you can't notice. Can you provide details of the specs of the computer, operating system, and the page that you see these issues so I can test and fix any issues? Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video tag : loop for ever
On Thu, Oct 16, 2008 at 4:07 PM, Eric Carlson [EMAIL PROTECTED] wrote: However I also think that playing just a segment of a media file will be a common use-case, so I don't think we need start and end either. How would you emulate end via JavaScript in a reasonably accurate manner? If I have a WAV audio file and I want to start and stop between specific points? For example a transcript of the audio may provide the ability to play a particular section of the transcript. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Scripted querying of video capabilities
On Tue, Aug 12, 2008 at 7:47 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: What is the advantage of using JavaScript to determine a viable embedding method over using alternative streams and fallback content that can include the OBJECT element where appropriate? video src=foo.ogg fallback content /video On a browser that doesn't support video this will use the fallback content (OBJECT, etc) to instantiate something that can play the Ogg file. On a browser that supports video and Ogg it will play the video. On a browser that supports video but not Ogg, how do you then instantiate a fallback that can play the Ogg file. Without JavaScript and without providing an alternative source re-encoded in a different format. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Scripted querying of video capabilities
On Wed, Aug 13, 2008 at 3:35 AM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Falling back to another method of displaying media is possible without a dedicated media API. In this particular case, you can have a video element with an ogg source and an object running Cortado to display it. I don't believe this to be the case. See my previous message about this. There's one specific instance of it not working as far as I know: video src=foo.ogg objectfallback for Ogg playback using plugin/object /video A browser that supports video but not Ogg will not use the fallback object. Instead it will just give an error when loading the foo.ogg file. If some way of having this case work is supplied then a media sniffing API is possibly not needed. Tim, can you confirm that? Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Scripted querying of video capabilities
On Sat, Aug 9, 2008 at 7:13 AM, Tim Starling [EMAIL PROTECTED] wrote: Where do I go from here with this? Should I make a concrete proposal? A sample implementation? Get that Mozilla bug fixed? Or have I been shot down already? I think it is important for web sites to be able to detect in some way what a browser supports. Lot's of sites currently do this (Wikimedia obviously, but there's also Metavid, the numerous 'video blogging' scripts, etc). While they could all switch overnight to only supporting video I doubt that suggesting that solution is going to result in people looking favourably on migrating towards it. Can the functionality provided by HTML 5 video do what is needed for these sorts of detection scripts? If not, I'd be interested in seeing a proposal of something that would work. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Video : Slow motion, fast forward effects
On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 7 Aug 2008, Biju [EMAIL PROTECTED] wrote: On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson [EMAIL PROTECTED] wrote: playbackRate is the right way to do it, but maybe Firefox doesn't yet support it. So can I assume HTML5 spec also allow playbackRate to be negative value. ie to support go backward at various speed Yes. Would you expect the audio to be played backwards too? Given that codecs are often highly optimized for forward playback the cost in memory can be excessive to go the other way. Could there be a possibility to say 'reverse playback not supported'? Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Video : Slow motion, fast forward effects
On Thu, Aug 7, 2008 at 4:58 PM, Biju [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: PS: On Firefox I tried changing playbackRate attribute by Markup as well as script, but did not see any effect. playbackRate is not yet supported by the Ogg backend. The build I have on my site with the gstreamer backend does have it however. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Consider changing the default volume for audio and video to be 1.0 instead of 0.5
On Fri, Jun 27, 2008 at 1:27 PM, Adele Peterson [EMAIL PROTECTED] wrote: The spec currently says that the default volume level is 0.5. In WebKit's initial implementation, we have received feedback that the audio seems much too soft. If a user has already adjusted their device's volume to their liking, then I think 1.0 should correspond to that level, and that should be the default. This will enable the browser to have similar volume levels to other applications on the system, and will respect the system volume. I agree. I've noticed with the Firefox implementation that defaulting to 0.5 is too quiet and can cause a bit of confusion with people adjusting the system volume to make it louder - which makes other apps even louder. Chris. -- http://www.bluishcoder.co.nz
[whatwg] Video, Closed Captions, and Audio Description Tracks
The video element description states that Theora, Voribis and Ogg container should be supported. How should closed captions and audio description tracks for accessibility be supported using video and these formats? I was pointed to a page outlining some previous discussion on the issue: http://wiki.whatwg.org/wiki/Video_accessibility Is there a way of identifying which track is the closed caption track, which is the alternate audio track, etc? How are other implementors of the video element handling this issue? Is CMML for the closed captions viable? Or a speex track for the alternate audio? Or using Ogg Skeleton in some way to get information about the other tracks? Chris -- http://www.bluishcoder.co.nz
