- From: <bugzilla@jessica.w3.org>
- Date: Tue, 09 Dec 2014 22:11:24 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26887 --- Comment #26 from Mark Watson <watsonm@netflix.com> --- r content. > > > > It's always been my assumption that the initData refers only to the keys > > needed for the individual file in which it is embedded (anything else > > complicates packaging). But for adaptive streaming you need the keys for all > > the bitrates of the same content and you want to get those in one server > > round trip. > > That is an optimization we should allow for, but I don't see why this needs > to be explicit in the spec. I don't believe everyone manages adaptive > content keys in this manner. If other retailers want to comment on this, it > would be useful. Ok, so it's good that we've identified a place where we had different assumptions. As a general rule it's important if as much of the file packaging process can be done independently for each of the bitrates. Individual bitrates are re-encoded, re-packaged, added, removed etc. at different times, so if all the files need information about all the other associated files this is a lot of complexity. It needs to be handled in the specification if we need to define what loading by initData really means: which keys are loaded ? If it is only the keys referred to in the initData, the above is not supported. If it is all keys that were provided last time this initData was used, then this breaks your multi-episode use-case. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 9 December 2014 22:11:26 UTC