Returning to this discussion, I think it is lacking in use cases.
Consider the controllers we are used to - they tend to have frame step,
chapter step and some kind of scrub bar.
Frame stepping is used when you want to mark an accurate in or our point, or
catch a still frame. This needs to be
Rather than trying to sum up all use cases I think that the media asset
should be fully random accessible and frame accurate to cover any current
and future us ecasse. You should be able to write Javascripts that tell the
asset to go to any point in time.
That way a web developer (or implementers
On Mon, 24 Jan 2011 02:36:15 +0100, Robert O'Callahan
rob...@ocallahan.org wrote:
On Sun, Jan 23, 2011 at 12:03 AM, Philip Jägenstedt
phil...@opera.comwrote:
Ah, thanks for clarifying. It might be a bit odd for the spec to forbid
being too clever, but I think that in practice always
This is a very interesting observation, I've been thinking what this means
in terms of UI design for scrubbars/players and there's a design limitation
with (traditional) seekbars:
Seekbars tend to have a physical length in pixels, meaning that there's a
physical limitation how precise one can move
On Mon, Jan 24, 2011 at 11:32 PM, Philip Jägenstedt phil...@opera.comwrote:
On Mon, 24 Jan 2011 02:36:15 +0100, Robert O'Callahan
rob...@ocallahan.org wrote:
Interop problems are going to arise with approximate seeking no matter
what
we do, which is why it shouldn't be the default.
OK,
On Mon, 24 Jan 2011 21:10:21 +0100, Robert O'Callahan
rob...@ocallahan.org wrote:
On Mon, Jan 24, 2011 at 11:32 PM, Philip Jägenstedt
phil...@opera.comwrote:
On Mon, 24 Jan 2011 02:36:15 +0100, Robert O'Callahan
rob...@ocallahan.org wrote:
Interop problems are going to arise with
On Tue, Jan 25, 2011 at 9:34 AM, Philip Jägenstedt phil...@opera.comwrote:
On Mon, 24 Jan 2011 21:10:21 +0100, Robert O'Callahan
rob...@ocallahan.org wrote:
Interesting. It doesn't in Firefox; script always sees a snapshot of a
consistent state until it returns to the event loop or does
On Sat, Jan 22, 2011 at 7:31 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
Basically, as the decoding speed approaches realtime the seeking time
approaches what you'd get by seeking to the prior keyframe and playing
up to the current point, except with the exact seeking you sit around
On Sat, Jan 22, 2011 at 10:04 AM, Philip Jägenstedt phil...@opera.comwrote:
Since, as you say, the behavior is currently inconsistent, there is still
time to agree on something that makes sense and have everyone implement
that. I think the best default is keyframe seeking and haven't seen any
On Sun, Jan 23, 2011 at 12:03 AM, Philip Jägenstedt phil...@opera.comwrote:
Ah, thanks for clarifying. It might be a bit odd for the spec to forbid
being too clever, but I think that in practice always seeking to the same
point is much easier, so that's what would be implemented. It would
On Fri, 21 Jan 2011 23:11:56 +0100, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jan 21, 2011 at 4:40 PM, Philip Jägenstedt phil...@opera.com
wrote:
I'm fine with any terminology, as long as it allows implementations to
seek
to some other time than currentTime if it's (much) faster to do so.
On Sat, 22 Jan 2011 02:19:10 +0100, Chris Pearce ch...@pearce.org.nz
wrote:
On 22/01/2011 7:31 a.m., Gregory Maxwell wrote:
It's usually the decoding, not the file access that kill you. Firefox
seeking on low resolution clips is very snappy index or not. But try a
1080p clip encoded with a
On Sat, Jan 22, 2011 at 4:23 AM, Philip Jägenstedt phil...@opera.com wrote:
Should there be any consistency requirements for fast seeking?
Suppose you have a format that's high-bitrate but cheap to decode.
Accurately seeking is fast if the data is already buffered, but slow
if not, since it's
On Sat, 22 Jan 2011 11:01:26 +0100, Glenn Maynard gl...@zewt.org wrote:
On Sat, Jan 22, 2011 at 4:23 AM, Philip Jägenstedt phil...@opera.com
wrote:
Should there be any consistency requirements for fast seeking?
Suppose you have a format that's high-bitrate but cheap to decode.
Accurately
It seems the needs for a seek bar are different from the api usage of
setting video.currentTime. As people mention rules of 'least surprise'
are important. If you set currentTime to 3.453 you expect it to return
something very close to 3.453 ..
Why not have a separate api for seek bars that just
Based on the discussion on the WebKit bug [1] I wanted to quickly make sure
we're all on the same page with respect to seeking.
My fix for Chromium was rounding up/down to the nearest frame however I
agree that seeking should always land within the duration of a frame as
opposed to rounding.
On 01/13/2011 01:44 AM, Philip Jägenstedt wrote:
Changing the default at this point wouldn't really hurt since not all
browsers are doing exact seeking anyway, right? I think that keyframe
seeking is more often what you want and it'd be better to let the few
who want frame-exact seeking jump
On Fri, Jan 21, 2011 at 1:12 PM, Michael Dale d...@ucsc.edu wrote:
On 01/13/2011 01:44 AM, Philip Jägenstedt wrote:
Changing the default at this point wouldn't really hurt since not all
browsers are doing exact seeking anyway, right? I think that keyframe
seeking is more often what you want
I still want the API to support seeks to exact frames.
eg when I build some GUI that allows the user to click on a button that says
explosion shot 1 at 00:31:02.15 then I want the player to seek to
00:31:02.15 exactly and not to say, 00:31:02.01 simply b/c that's where a
keyframe happens to be.
On Fri, Jan 21, 2011 at 1:38 PM, Rob Coenen coenen@gmail.com wrote:
I still want the API to support seeks to exact frames.
eg when I build some GUI that allows the user to click on a button that says
explosion shot 1 at 00:31:02.15 then I want the player to seek to
00:31:02.15 exactly and
I don't think any rounding should be done, at least not in a way that is
then observable through currentTime. Each frame has a start time, so if
the seeked time falls right between two frames, I'd expect the first of
them to show for half of its duration before the second one shows.
My
On Fri, 21 Jan 2011 20:11:30 +0100, Gregory Maxwell gmaxw...@gmail.com
wrote:
On Fri, Jan 21, 2011 at 1:38 PM, Rob Coenen coenen@gmail.com wrote:
I still want the API to support seeks to exact frames.
eg when I build some GUI that allows the user to click on a button that
says
On Fri, Jan 21, 2011 at 4:04 PM, Philip Jägenstedt phil...@opera.com wrote:
Since, as you say, the behavior is currently inconsistent, there is still
time to agree on something that makes sense and have everyone implement
that. I think the best default is keyframe seeking and haven't seen any
On Fri, 21 Jan 2011 22:15:43 +0100, Gregory Maxwell gmaxw...@gmail.com
wrote:
On Fri, Jan 21, 2011 at 4:04 PM, Philip Jägenstedt phil...@opera.com
wrote:
Since, as you say, the behavior is currently inconsistent, there is
still
time to agree on something that makes sense and have everyone
On 2011-01-21 22:15, Gregory Maxwell wrote:
I don't like keyframe seeking as the default. Keyframe seeking
assumes things about the container, codec, and encoding which may not
be constants or even applicable to all formats. For example a file
with rolling intra may have no keyframes, and yet
On Sat, Jan 22, 2011 at 8:04 AM, Philip Jägenstedt phil...@opera.com wrote:
On Fri, 21 Jan 2011 20:11:30 +0100, Gregory Maxwell gmaxw...@gmail.com
wrote:
On Fri, Jan 21, 2011 at 1:38 PM, Rob Coenen coenen@gmail.com wrote:
I still want the API to support seeks to exact frames.
eg when I
On 2011-01-21 22:04, Philip Jägenstedt wrote:
Concretely: Add seek(time, flags) where flags defaults to nothing.
Accurate seeking would be done via seek(time, accurate) or some
such. Setting currentTime is left as is and doesn't set any flags.
Hmm. I think the default (nothing) should be
On Sat, Jan 22, 2011 at 8:50 AM, Roger Hågensen resca...@emsai.net wrote:
On 2011-01-21 22:04, Philip Jägenstedt wrote:
Concretely: Add seek(time, flags) where flags defaults to nothing.
Accurate seeking would be done via seek(time, accurate) or some such.
Setting currentTime is left as is
On Fri, Jan 21, 2011 at 4:42 PM, Roger Hågensen resca...@emsai.net wrote:
Accurate seeking also assumes things about the codec/container/encoding.
If a format does not have keyframes then it does have something
equivalent.
Formats without keyframes can probably (I might be wrong there) seek
On Fri, Jan 21, 2011 at 4:40 PM, Philip Jägenstedt phil...@opera.com wrote:
I'm fine with any terminology, as long as it allows implementations to seek
to some other time than currentTime if it's (much) faster to do so.
GStreamer has the flags GST_SEEK_FLAG_ACCURATE and GST_SEEK_FLAG_KEY_UNIT,
On 2011-01-21 22:57, Silvia Pfeiffer wrote:
On Sat, Jan 22, 2011 at 8:50 AM, Roger Hågensenresca...@emsai.net wrote:
On 2011-01-21 22:04, Philip Jägenstedt wrote:
Concretely: Add seek(time, flags) where flags defaults to nothing.
Accurate seeking would be done via seek(time, accurate) or some
On Fri, Jan 21, 2011 at 5:11 PM, Glenn Maynard gl...@zewt.org wrote:
Should there be any consistency requirements for fast seeking?
[snip]
This could have unexpected side-effects. Should this be allowed? I'd
suggest that fast seeking should always be consistent with itself, at
least for a
On Sat, Jan 22, 2011 at 9:05 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Fri, Jan 21, 2011 at 4:57 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
* the default is best effort
I fear that the best effort language is misleading. You can always
do exact on a stream that you can seek
On Fri, Jan 21, 2011 at 5:25 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
The language I'd prefer is fast. Fast may be exact, or it might
just be to the nearest keyframe, or something in between. It might
just start you over at the beginning of the stream.
That is putting a
On Fri, Jan 21, 2011 at 5:19 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
It would, but it also results in some pretty perplexing and unfriendly
behavior... where the user hits the 5-seconds forward button and ends
up going 4-seconds backwards, only to press the button again and
repeatedly
On 2011-01-21 23:48, Gregory Maxwell wrote:
It seems surprising to me that we'd want to expose something so deeply
internal while the API fails to expose things like chapters and other
metadata which can actually be used to reliably map times to
meaningful high level information about the
On Sat, Jan 22, 2011 at 9:48 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Fri, Jan 21, 2011 at 5:25 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
The language I'd prefer is fast. Fast may be exact, or it might
just be to the nearest keyframe, or something in between. It might
just
On 2011-01-22 01:27, Silvia Pfeiffer wrote:
It seems surprising to me that we'd want to expose something so deeply
internal while the API fails to expose things like chapters and other
metadata which can actually be used to reliably map times to
meaningful high level information about the
On Fri, Jan 21, 2011 at 7:27 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Sat, Jan 22, 2011 at 9:48 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Fri, Jan 21, 2011 at 5:25 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
The language I'd prefer is fast. Fast may be exact, or
On 22/01/2011 7:31 a.m., Gregory Maxwell wrote:
It's usually the decoding, not the file access that kill you. Firefox
seeking on low resolution clips is very snappy index or not. But try a
1080p clip encoded with a 10 second maximum keyframe interval...
This is true. If you want fast frame
Regarding whether to use fast or accurate seeks by default, it
seems like a balance between the frequency of use cases for each, the
likelihood of either default being wrong, principle of least surprise,
and consistency with other APIs. Looking at various seek use cases:
Seek bars should use
On 22/01/2011 3:23 p.m., Gregory Maxwell wrote:
On Fri, Jan 21, 2011 at 8:19 PM, Chris Pearcech...@pearce.org.nz wrote:
On 22/01/2011 7:31 a.m., Gregory Maxwell wrote:
It's usually the decoding, not the file access that kill you. Firefox
seeking on low resolution clips is very snappy index
On Wed, 19 Jan 2011 05:01:14 +0100, Rob Coenen coenen@gmail.com
wrote:
I'm really happy to see that Chromium has landed a fix for frame-accurate
seeking, making SMPTE timecode compliant operations with HTML5 video
possible.
The fix for Firefox is underway (
I'm really happy to see that Chromium has landed a fix for frame-accurate
seeking, making SMPTE timecode compliant operations with HTML5 video
possible.
The fix for Firefox is underway (
https://bugzilla.mozilla.org/show_bug.cgi?id=626273 ) and I have filed bugs
at both Webkit/Safari (
On Wed, Jan 12, 2011 at 2:49 AM, Philip Jägenstedt phil...@opera.com wrote:
(Also, it might be useful to be able to chose whether seeking should be fast
or exact, as frame-accurate seeking is hardly necessary in most normal
playback situations.)
In an audio engine I worked on I had a seek hint
On Wed, 12 Jan 2011 09:16:59 +0100, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jan 12, 2011 at 2:49 AM, Philip Jägenstedt phil...@opera.com
wrote:
(Also, it might be useful to be able to chose whether seeking should be
fast
or exact, as frame-accurate seeking is hardly necessary in most
2011-01-12 00:40 EEST: Rob Coenen:
Hi David- that is b/c in an ideal world I'd want to seek to a time expressed
as a SMPTE timecode (think web apps that let users step x frames back, seek
y frames forward etc.). In order to convert SMPTE to the floating point
value for video.seekTime I need to
On Jan 12, 2011, at 11:04 AM, whatwg-requ...@lists.whatwg.org wrote:
Date: Wed, 12 Jan 2011 11:54:47 +0200
From: Mikko Rantalainen mikko.rantalai...@peda.net
To: whatwg@lists.whatwg.org
Subject: Re: [whatwg] HTML5 video: frame accuracy / SMPTE
Message-ID: 4d2d7a67.7090...@peda.net
Content
On Wed, Jan 12, 2011 at 10:15 AM, Jeroen Wijering
jer...@longtailvideo.comwrote:
Alternatively, one could look at a step() function instead of a
seek(pos,exact) function. The step function can be used for frame-accurate
controls. e.g. step(2) or step(-1). The advantage over a seek(pos,exact)
On Jan 12, 2011, at 2:05 PM, Rob Coenen wrote:
The need for SMPTE still remains as I want to be able to do things such as
video.seekTo(smpte_timecode_converted_to_seconds, seek_exact=true); so that
my video goes to exactly the exact frame as indicated by
On Jan 12, 2011, at 12:42 AM, Philip Jägenstedt wrote:
On Wed, 12 Jan 2011 09:16:59 +0100, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jan 12, 2011 at 2:49 AM, Philip Jägenstedt phil...@opera.com wrote:
(Also, it might be useful to be able to chose whether seeking should be fast
or exact,
I implemented frame-accurate seeking in Chrome (mostly as an experiment) and
it does have the drawback of potentially being very slow. Depending on the
type of video there can be a noticeable difference in seek time if you seek
to just-before-a-keyframe versus just-after-a-keyframe.
I do like
On Wed, Jan 12, 2011 at 3:42 AM, Philip Jägenstedt phil...@opera.com wrote:
* add HTMLMediaElement.seek(t, [exact]), where exact defaults to false if
missing
Boolean parameters are evil, since it's impossible to guess what they
do from reading the code. Make it a two-value enum instead. The
On Wed, Jan 12, 2011 at 9:42 PM, Philip Jägenstedt phil...@opera.comwrote:
For the record, this is the solution I've been imagining:
* add HTMLMediaElement.seek(t, [exact]), where exact defaults to false if
missing
* make setting HTMLMediaElement.currentTime be a non-exact seek, as that
On Jan 12, 2011, at 4:04 PM, Robert O'Callahan wrote:
On Wed, Jan 12, 2011 at 9:42 PM, Philip Jägenstedt phil...@opera.comwrote:
For the record, this is the solution I've been imagining:
* add HTMLMediaElement.seek(t, [exact]), where exact defaults to false if
missing
* make setting
On Thu, 13 Jan 2011 01:23:57 +0100, Eric Carlson eric.carl...@apple.com
wrote:
On Jan 12, 2011, at 4:04 PM, Robert O'Callahan wrote:
On Wed, Jan 12, 2011 at 9:42 PM, Philip Jägenstedt
phil...@opera.comwrote:
For the record, this is the solution I've been imagining:
* add
On Thu, 13 Jan 2011 01:03:03 +0100, Aryeh Gregor
simetrical+...@gmail.com wrote:
On Wed, Jan 12, 2011 at 3:42 AM, Philip Jägenstedt phil...@opera.com
wrote:
* add HTMLMediaElement.seek(t, [exact]), where exact defaults to false
if
missing
Boolean parameters are evil, since it's
just a follow up question in relation to SMPTE / frame accurate playback: As
far as I can tell there is nothing specified in the HTML5 specs that will
allow us to determine the actual frame rate (FPS) of a movie? In order to do
proper time-code calculations it's essential to know both the
On Jan 11, 2011, at 9:54 AM, Rob Coenen wrote:
just a follow up question in relation to SMPTE / frame accurate playback: As
far as I can tell there is nothing specified in the HTML5 specs that will
allow us to determine the actual frame rate (FPS) of a movie? In order to do
proper time-code
Eric, not sure if I understand what you mean. Are you referring to digitally
encoded files where frame #1 has a different duration than frame #2?
On Tue, Jan 11, 2011 at 6:10 PM, Eric Carlson eric.carl...@apple.comwrote:
On Jan 11, 2011, at 9:54 AM, Rob Coenen wrote:
just a follow up
On Jan 11, 2011, at 12:54 PM, Rob Coenen wrote:
Eric, not sure if I understand what you mean. Are you referring to digitally
encoded files where frame #1 has a different duration than frame #2?
Exactly, every frame can have an arbitrary duration so frame rate may have
no meaning. Even in
Intresting- I didn't know that variable frame-rate videos were actually
being used for HTML5 video.
But still- the vast majority of all video uses a fixed frame rate- ever
since Eadweard Muybridge invented 'motion picture' back in 1878.
For example, most hardware these days record in SMPTE
On 12/01/2011 10:58 a.m., Rob Coenen wrote:
Intresting- I didn't know that variable frame-rate videos were actually
being used for HTML5 video.
WebM videos have no fixed frame rate. This format is supported in
Firefox 4, Chrome, and Opera.
Chris P.
Chris, maybe I'm wording it incorrect, but when I run the mediainfo utility
on my test file it reports frame rate: 25.000 fps
(test for yourself with my test file:
http://www.massive-interactive.nl/html5_video/video/timecoded.webm)
I can imagine there are 'virtual' frames, where say frame 1 to 10
why does the frame rate make any difference on the accuracy of seeking to a
time? Imagine a video that runs at 1 frame every 10 seconds, and I seek to 25
seconds. I would expect to see 5 seconds of the third frame, 10 seconds of the
4th, and so on.
On Jan 11, 2011, at 18:54 , Rob Coenen
Hi David- that is b/c in an ideal world I'd want to seek to a time expressed
as a SMPTE timecode (think web apps that let users step x frames back, seek
y frames forward etc.). In order to convert SMPTE to the floating point
value for video.seekTime I need to know the frame rate.
-Rob
On Tue,
OK, but it does seem kinda a tautology if you say I want to use a
time-expression that represents fractions of seconds as frame numbers, and it's
not very accurate if there aren't very many frames/second... !
On Jan 11, 2011, at 23:40 , Rob Coenen wrote:
Hi David- that is b/c in an ideal
On 12/01/2011 11:20 a.m., Rob Coenen wrote:
I can imagine there are 'virtual' frames, where say frame 1 to 10 is
actually the same frame and internally encoded as frame 1 with a duration of
10 frames?
Yes, as I understand it, this is a legal encoding.
Even then I'd like the 'virtual' FPS of
David I agree- however that's common practice in any video editing tool, in
any digital video camera, etc. It's the defacto industry standard for anyone
working with digital video.
I'm just trying to make readers of this list aware of the fact that HTML5
does a great job in video-play back, but
These goals are orthogonal though - stepping between frames is valuable
whether they are regularly spaced or not.
Timecode is a representation that comes from the legacy video world that
does assume a uniform frame rate
On Tue, Jan 11, 2011 at 2:40 PM, Rob Coenen coenen@gmail.com wrote:
Hi
On Tue, Jan 11, 2011 at 5:40 PM, Rob Coenen coenen@gmail.com wrote:
Hi David- that is b/c in an ideal world I'd want to seek to a time expressed
as a SMPTE timecode (think web apps that let users step x frames back, seek
y frames forward etc.). In order to convert SMPTE to the floating
On 11 Jan 2011, at 18:10, Eric Carlson wrote:
On Jan 11, 2011, at 9:54 AM, Rob Coenen wrote:
just a follow up question in relation to SMPTE / frame accurate playback: As
far as I can tell there is nothing specified in the HTML5 specs that will
allow us to determine the actual frame rate
Right - but that foregoes a bit how subtle the SMPTE timecode definition is
(http://en.wikipedia.org/wiki/SMPTE_time_code is a good start) - and this is
exactly why it is defined in such odd a manner (as you do have exactly this
tautology problem between, say, NTSC and PAL).
So yes - you want
I guess that I'm looking at HTML5 from the POV as a video-producer rather
than a video-consumer.
As a producer I'm much more intrested in the legacy video formats. The way
video is being produced is simply on a frame-by-frame basis. I cannot think
of any 3D animation tool video sequencer, video
On 11 Jan 2011, at 23:00, Chris Pearce wrote:
On 12/01/2011 11:20 a.m., Rob Coenen wrote:
I can imagine there are 'virtual' frames, where say frame 1 to 10 is
actually the same frame and internally encoded as frame 1 with a duration of
10 frames?
Yes, as I understand it, this is a legal
On 11 Jan 2011, at 23:46, Kevin Marks wrote:
These goals are orthogonal though - stepping between frames is valuable
whether they are regularly spaced or not.
Timecode is a representation that comes from the legacy video world that
does assume a uniform frame rate
Not sure if they are
On 11 Jan 2011, at 23:57, Glenn Maynard wrote:
On Tue, Jan 11, 2011 at 5:40 PM, Rob Coenen coenen@gmail.com wrote:
Hi David- that is b/c in an ideal world I'd want to seek to a time expressed
as a SMPTE timecode (think web apps that let users step x frames back, seek
y frames forward
On 12 Jan 2011, at 00:48, Dirk-Willem van Gulik wrote:
the clock relative to shutter/gating to the end user - as this is what you
need to avoid flicker, interlace issues, half the frame showing the next
scene, etc.
Apologies - got some private mail asking for examples. So the simplest
On 12/01/2011 1:37 p.m., Dirk-Willem van Gulik wrote:
On 11 Jan 2011, at 23:00, Chris Pearce wrote:
Even then I'd like the 'virtual' FPS of the WebM file exposed to the
webbrowser- similar to how my other utilities report a FPS.
If the 'virtual' FPS value isn't provided by the container, and
On 12 Jan 2011, at 01:17, Chris Pearce wrote:
On 12/01/2011 1:37 p.m., Dirk-Willem van Gulik wrote:
On 11 Jan 2011, at 23:00, Chris Pearce wrote:
Even then I'd like the 'virtual' FPS of the WebM file exposed to the
webbrowser- similar to how my other utilities report a FPS.
If the
On 12/01/2011 2:22 p.m., Dirk-Willem van Gulik wrote:
On 12 Jan 2011, at 01:17, Chris Pearce wrote:
I cannot think of a format where this would in fact be the case - but for a few
arcane ones like an animated push gif without a loop.
WebM can be variable frame rate. At best the WebM
On Jan 11, 2011, at 5:43 PM, Chris Pearce wrote:
On 12/01/2011 2:22 p.m., Dirk-Willem van Gulik wrote:
On 12 Jan 2011, at 01:17, Chris Pearce wrote:
I cannot think of a format where this would in fact be the case - but for
a few arcane ones like an animated push gif without a loop.
We can't have an API based on frame rate because at least in WebM, the
frame rate is just an informational piece of metadata that may not match
what's in the file and may not be there at all. Thus, the browser has no
way of exposing .framerate or anything like it.
For now, I suggest that
On Wed, 12 Jan 2011 03:16:35 +0100, Eric Carlson eric.carl...@apple.com
wrote:
On Jan 11, 2011, at 5:43 PM, Chris Pearce wrote:
On 12/01/2011 2:22 p.m., Dirk-Willem van Gulik wrote:
On 12 Jan 2011, at 01:17, Chris Pearce wrote:
I cannot think of a format where this would in fact be the
On Jan 9, 2011, at 11:14 AM, Rob Coenen wrote:
I have written a simple test using a H264 video with burned-in timecode
(every frame is visually marked with the actual SMPTE timecode)
Webkit is unable to seek to the correct timecode using 'currentTime', it's
always a whole bunch of frames
Thanks for the update.
I have been testing with WebKit nightly / 75294 on MacOSX 10.6.6 / 13
Macbook Pro, Core Duo.
Here's a test movie that I created a while back. Nevermind the video
quality- the burned-in timecodes are 100% correct, I have verified this by
exploring each single frame by hand.
If you really want to test timecode, you need to get into SMPTE drop-frame
timecode too (possibly the single most annoying standards decision of. all
time was choosing 3/1001 as the framerate of NTSC video)
Eric, can you make BipBop movie for this? - Like the ones used in this demo:
I have written a simple test using a H264 video with burned-in timecode
(every frame is visually marked with the actual SMPTE timecode)
Webkit is unable to seek to the correct timecode using 'currentTime', it's
always a whole bunch of frames off from the requested position. I reckon it
simply
Is it possible to share that video? I wouldn't mind encoding it into
WebM and Ogg, too, and seeing how those work.
Also, this will be very useful for experiments with timing and WebVTT.
Regards,
Silvia.
On Sun, Jan 9, 2011 at 8:14 PM, Rob Coenen coenen@gmail.com wrote:
I have written a
As Eric pointed out, the spec specifies that you can seek to a specific
time, and therefore a specific frame. Firefox seeks video to the frame
which contains the seek target time in Ogg and WebM videos FWIW, and
begins audio playback from, and syncs the clock to, the start of the
Vorbis audio
On Jan 7, 2011, at 8:22 AM, Rob Coenen wrote:
are there any plans on adding frame accuracy and/or SMPTE support to HTML5
video?
As far as I know it's currently impossible to play HTML5 video
frame-by-frame, or seek to a SMPTE compliant (frame accurate) time-code.
The nearest seek seems
91 matches
Mail list logo
