This is done as far as the pre-bitstream freeze is concerned. Once we have a final version of AOM, we'll need to resolve the two linked issues for profiles and mime type.
Nothing more can be done at this point, so we're now waiting for the bitstream finalization. Once that is complete the following is still left to do in Chrome:
- We currently don't handle the I440 pixel formats.
- We currently only handle a single profile, but more are expected ( issue 784993 )
- Decoding for AV1 content should probably be offloaded from the media thread using OffloadingVideoDecoder.
- Decoding should be zero copy, i.e. support added for FrameBufferPool using the AV1 set frame buffer commands; this is blocked by AV1s weird 8-bit in 16-bit packaging currently.
- A fuzzertest needs to be added along with corpus data.
- What should canPlayType()/isTypeSupported() return for this? ( issue 784607 )
- Changes to MediaSourceExtensions for SourceBuffer creation and
demuxing true AV1 data instead of VPx data.
Assigning to jaik@ for tracking, please hand back to me when you're ready for me to undertake any of the above.
In third_party/libaom, the source lists for ARM targets are not yet configured.
Would patches toward enabling Android/ARM builds be welcome?
I am familiar with building libaom and looking to resume contributing to chromium.
We are currently waiting for the hard bitstream freeze before updating the library, but if you look at BUILD.gn.cmake and cmake_update.sh you can test things out.
Note however, in options.gni that we do not currently build on arm. It will likely be a bit of time before we can enable it by default, but if you want to set things up that would be very welcome.
The arm/arm-neon/arm-neon-cpu-detect variants can be enabled with only build configuration change - no updates to the library are required to compile and link.
With a change to enable the PipelineIntegrationTest suite on Android, we can verify that the resulting binary can decode the test sequences.
Enabling on Android, behind the enable_av1_decoder flag, can be done independently of configuring the ARM build if we test on x86/Android and ARM/Linux targets, respectively.
Should new bugs be opened for these cases or is tracking against this bug okay?
Using this bug is fine if it's just a few small patches; if you anticipate quite a few large patches please create a new bug and block this issue on it instead. Thanks for your help!
Hey Dale,
Reassigning this to you for the outstanding to-do list. Updated Issue 784993 and issue 784607 with links to AOM documentation. Please reassign to Tom, Johann, or myself if you need additional information.
Thanks,
Jai
The revert was due to msan builds failing because cmake_update.sh doesn't generate linux/generic config while BUILD.gn selects that target for msan.
We could either try msan with linux/x64 or add the linux/generic config to resolve this.
The last two things left from the chrome side are:
- Add support for parsing the AV1 configuration from mp4 and webm. This is blocked by not having any spec compliant media yet. The webm spec is not even defined I believe. I have started the mp4 av1c processing at least though: https://chromium-review.googlesource.com/c/chromium/src/+/1107260
- Enable offloading and zero-copy optimizations from the av1 decoder. This requires fixing libaom to not pack 8-bit content in 16-bit values or to teach chrome how to handle this.
Comment 1 by dalecur...@chromium.org
, Nov 13 2017