W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > May 2011

[Bug 12643] <video> change of fragment in media fragment URI consequences

From: <bugzilla@jessica.w3.org>
Date: Tue, 10 May 2011 12:12:13 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QJlnR-0004uq-9d@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12643

--- Comment #7 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-05-10 12:12:12 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > At large, I have yet to see (or understand) a case where it's not sufficient to
> > just go through the resource selection algorithm again and treat it as a
> > quality-of-implementation issue how well a browser is able to reuse the data
> > and decoding pipelines it already has.
> 
> At the risk of sounding like all I ever do is agree with Philip, I agree with
> this. Given that all the data is cached, this should be fast.

(In reply to comment #5)
> (In reply to comment #4)
> 
> > I think for any change of fragment that doesn't indicate a time offset, we have
> > to reset to currentTime=0. Including v.src=v.src. I don't think we need to
> > re-load the resource even for a track change.
> 
> Do you mean re-load as in re-transferring data over the network? If so, that
> can be avoided simply by caching. If you mean going through the resource
> selection algorithm again, I'm not sure I see why that would be a problem.
> 
> At large, I have yet to see (or understand) a case where it's not sufficient to
> just go through the resource selection algorithm again and treat it as a
> quality-of-implementation issue how well a browser is able to reuse the data
> and decoding pipelines it already has.


Ah, maybe we were talking past each other. All I want to avoid is a retransfer
of data over the network and reparsing of the media file. Maybe then I agree,
too. :-)

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 10 May 2011 12:12:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:10 UTC