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 are perfectly
seekable. Or if for some reason a client can do exact seeking very
cheaply for the request (e.g. seeking to the frame immediately after a
keyframe) then that ought to be permitted too.
I'd rather say that the default should be an implementation defined
accuracy, which may happen to be exact, may differ depending on the
input or user preferences, etc.
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
more accurate than those with keyframes.
With keyframes the logical is that if the seek goes to 14:11.500 or an
exact frame number,
then a keyframe based format would ideally be seeked to the exact keyframe,
or the first keyframe before the say B seeked B frame(s).
B frames contain too little info and may need pixels from the keyframe
(or I or P frame etc.)
Any speccing on this should simply be based on the ideal or best-effort
seeking that the 10 most popular
and the 10 oldest (but still in use) formats are able to. (and some
formats are probably in both categories as well)
And just spec based on that.
But I guess that there could be high and low resource modes.
If the system/browser is in a low resource state then it makes sense to
go keyframe (or equivalent)
and just do rough seeks,
but if in a high resource mode then keyframe + "microseek" (just made
that up) for accurate seeking should be used.
--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/
