Here is the latest VP9 latest status update.
May 19: Extend the prediction sub divisions above to 4x4 (4x4 8x4, 4x8
structure and deprecate the existing splitmv and i4x4 modes.).
May 19: HW Requested reduction in Entropy context size and counters
Further investigation reveals counters less of a problem than previously
thought as they require increment only and once per token not per bool decode.
We are still looking at ways of reducing the actual context size.
May 19: 444, alpha and depth channel complete (In response to HW requests this
will be a separate feature-set not required for v1 hardware).
May 19: A hardware partner has raised a dependency issue, where reconstruction of neighbouring motion vectors is required in order to decode the current motion vector. We will review the implications of this dependency and report back by next week on solutions / impact.
Here is the VP9 latest status update.
May 24: Extend the prediction sub divisions (4x4 8x4, 4x8 structure and deprecate the existing splitmv and i4x4 modes.) This work is essentially bit stream complete and should hopefully be merged out from under its configure flag later today. There are a few loose ends including correct behaviour of the loop filter and selection of the reference motion vector for small sub-blocks that should be resolved by the end of the week, along with some encoder side work and re-factoring relating to rd.
May 24: 444, alpha and depth channel: The 444 code has been shown to
work end to end but some issues remain in the support for the 4th plane. The
target is to resolve the remaining issues this week, but some of the changes
are likely to remain under a configure flag until next week. NOTE:
This work will now be placed under a version/profile flag in the bit stream
header and support will not be required in version 1 hardware.
HW Requested reduction in Entropy context size and counters
A patch has been submitted that reduces the size of the coefficient context in memory. The first three values in each context are still updated as before, but the remainder can be derived using a static lookup (combined size much smaller than the original context).
May 24: Dependency issue raised by a HW partner, where reconstruction of neighbouring motion vectors was required in order to decode the current motion vector. A patch has been submitted that should resolve this by only using the modes of neighbours to provide the context. This may need minor tweaking in the light of the work on the 8x4,4x8 etc. and does currently hurts compression performance by about 0.25%.
Intra prediction consistently tied to transform size. Work to insure that intra prediction is tied consistently to the transform size (as discussed at the VP9 summit) is bit stream complete and should be checked in today. Note that some further work is required (encoder side only) to insure the correct behaviour in the rate distortion loop.
A hardware partner has requested that we review the order of operations in the VP9 loop filter: Filter the vertical edges first, then the horizontal. This request is being reviewed and we will try and respond before the end of the week.
In response to a request, we have changed the frame sync code so that it is distinct from that used in VP8.
May 24: Color space / version / feature-set header bits added
and defined:
May 24: Bitstream Final Candidate (only minor bugs fixed)
May 25: June 17: Work on syntax test vectors / unit tests / further
optimizations /
any necessary last minute fixes.
June 17th : No more bitstream changes - Code checked into chrome / YouTube
10 bit: A number of strong representations have been made to us about the importance of 10-bit support for certain use cases and in the future for 4k video. In the light of these representations, and given that the 4:4:4 / alpha etc. work will now be subject to a version / profile flag (and not be a requirement for version 1 hardware), we are actively considering whether at some point in the future we should add support for 10 bit (also under a profile flag). We do not have any time-scale but continue to value your feedback on this and other issues.
Paul Wilkins
Here is the VP9 latest status update.
Extended the prediction sub divisions (4x4 8x4, 4x8 structure and deprecate the existing splitmv and i4x4 modes.) Removing the i4x4 and splitmv modes (from a bitstream perspective) is mainly checked in. Still some clean up and debug work to do and the splitmv and i4x4 modes still exist as "non bitstream normative" place holders for now, pending further re-factoring of the code.
444, alpha and depth channel: Mainly complete. Some ongoing work relating to requested changes to the loop filtering order (see below). NOTE: This work will now be placed under a version/profile flag in the bit stream header and support will not be required in version 1 hardware.
A hardware partner has requested that we review the order of operations in the VP9 loop filter and filter the vertical edges first, then the horizontal. Further changes have been requested to insure that all vertical edges in an SB64 are filtered before filtering of any horizontal edges.
Hw vendor request for a change to the scan order for 32x32 blocks is under review.
Outside submission of an alternate WHT implementation that uses fewer shift operations is under review.
Color space / version / feature-set header bits added and defined: Patch for new color space bits submitted (waiting on some refactoring work for the uncompressed frame header). Definition of feature / profile bits etc. and their meanings on hold pending further input from partners.
Bitstream Final Candidate (only minor bugs fixed or issues raised by HW vendors) internal freeze delayed till the end of this week.
Now - June 17: Work on syntax test vectors / unit tests / further optimizations /
any necessary last minute fixes..
Paul Wilkins
Here is the VP9 latest status update.
444, alpha and depth channel: Mainly complete.
Issues raised by / suggestions from HW partners.
· Loop filter order. Variant submitted and being tested in SW and re-checked by HW team.
· Optimised 32x32 scan order. A new more HW friendly scan order for 32x32 has been tested and merged.
· Last frame use for mv reference. Small change suggested by HW team tested and merged.
· Prior token context. Small change to calculation of prior token energy (suggested by HW team) tested and merged
· Fixed tile count off by one bug identified by HW partner.
Some header bits moved to the uncompressed partition.
Alternate WHT implementation tested and merged.
Removal of experiments that did not make the cut.
Version / feature-set header Definition of feature / profile bits etc. and their meanings on hold pending further input from partners.
Bitstream Final Candidate (only minor bugs fixed or issues raised by HW vendors).
Here is the latest VP9 status update.
As of last night the VP9 (profile 0) bitstream is FINAL and the process of validating it on multiple platforms and in different build environments and testing for submission into Chrome is under way.
The last few days have been pretty hectic as we had to make several last minute changes. As always seems to be the case, these were more complex than we had hoped and I want to thank the whole team for working long hours to bring about closure. I also want to thank partners and hardware vendors who have submitted comments and suggestions over the past few weeks.
Details of the final issues resolved over the last 7 days are as follows:-
Changes to the loop filter. Changes to make the loop filter more HW friendly had to go through several iterations and gave rise to a couple of late bugs. As is often the case, initial attempts to make it more hardware friendly turned out to make things more difficult in SIMD software implementations. Hopefully the final solution is a comfortable compromise for both.
Changes to the way compound prediction modes are coded in the bitstream. Though not conceptually complex and necessary to correctly constrain the allowable compound prediction modes, this change touched a lot of files and getting it done on time and debugged was a Herculean effort by those involved.
Definition and implementation of behaviour at the edge of images. This relates to what prediction modes/sizes and transforms are allowed near the edge of an image that does not break down nicely into 64x64 blocks. I mentioned this at the summit and while it sounds simple, like all the simplest changes, it was actually quite hard to get right. Again a big thank you to all involved in working through the issues.
Some minor changes to the frame header (E.g. coding of frame size not needed for all frames)
Some minor changes to the entropy coding of some symbols and some updates to the default tables.
Paul Wilkins
vp9_use_mv_hp? So far CABAC engine still needs to store the colocated motion vectors of last frame to find the best_mv(used to determed use_mv_hp) which adds a lot more complexity.
Bryan Chen
--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webm-discuss...@webmproject.org.
To post to this group, send email to webm-d...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/webm-discuss/.
FWIW I agree - mangling new codecs into an old mime type only leads to problems.
Silvia.
Also, FWIW, you should consider requiring a codecs partisan on the video/webm2 mime type so you can in future as other codecs to webm2 and also to distinguish between vp8 and vp9.
Cheers,
Silvia.
Here's the problem:
v=document.createElement("video");
v.canPlayType("video/webm");
-> returns "probably" in Firefox, which is perfectly fine, because
"video/webm" was originally defined to only contain vorbis and vp8
-> returns "maybe" in Chrome, which follows more
http://www.webmproject.org/docs/container/ (which I'm pretty sure was
changed from originally recommending to use "probably")
v.canPlayType('video/webm; codecs="vp8, vorbis"');
-> returns "probably" in both.
So, if you use v.canPlayType("video/webm") on a file containing opus
or VP9 in future, you will get "probably" even if your browser
(current version of Firefox) doesn't support these codecs.