Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sync #1

Merged
merged 242 commits into from
Jul 16, 2023
Merged

Sync #1

merged 242 commits into from
Jul 16, 2023

Conversation

agonza1
Copy link
Owner

@agonza1 agonza1 commented Jul 16, 2023

No description provided.

chcunningham and others added 30 commits February 8, 2022 20:16
Current spec always defines a timestamp for user constructed
VideoFrames. Setting a real timestamp is especially important for frames
that sent to VideoEncoder, as the timestamp is used for rate control.

With no way for users to generate a null timestamp, it makes sense to
make the type non-nullable. This also aligns with AudioData.timestamp.

This patch also addresses the one lingering opporutnity for null
timestamps: ImageDecoder used null as a default for output VideoFrames.
This patch updates that default to be zero. While it could be argued
that null is technically more correct (we don't often present images on
timeline), this is outweighed by the practical impact of using zero
which allows us to define a clear contract: VideoFrame always has a
timestamp.
A `<div>` cannot appear within a `<dl>`. Bikeshed used to automatically tie
notes with the previous `<dd>` in a list but no longer does that, and generated
HTML is now invalid.
Trailing `</dt>` has nothing to do here and now makes Bikeshed generate invalid
HTML markup.
We decided not to do this, but forgot to remove it from the spec. The fact that
decode() calls stall until the next frame is available and the availability of the
`completed` promise make it largely unnecessary.

Clients which don't want to wait for for `completed` can instead handle a
RangeError exception during decode() if no more frames remain. While not
ideal it's inefficient to implement something like onchange since common
formats like GIF would require us to attempt decode in order to update the
frame count.
Co-authored-by: Chris Needham <chrisn@users.noreply.github.com>
Revise processing model, fix queue size attributes
Djuffin and others added 29 commits April 27, 2023 09:38
Add per-frame QP support to AVC
Enable configuration of AV1 screen content coding tools
Clone configuration should perform a deep copy
Fix usage of RFC2119 words in privacy and security section
Editorial: account for SharedArrayBuffer change in Web IDL
Fix remaining normative language issues
Changes:

- Adds a requirement for a public specification that is stable
- The WG may consult external expertise as part of its review
- Fixes the numbering in the source document
multiply -> mutliply

Also trigger spec publishing
This should be helpful for developer to test the browser implement
or compare the performance of different codecs on different platforms.

Note that the previous version of mp4box is not able to parse AV1
video codec string correctly, so to support AV1, we also need to
upgrade mp4box to version 0.5.2.

Safari doesn't support `gl.createShader` so change the default
renderer to `2d`.

All sample videos are encoded from `bbb-1920x1080-cfg06.mp4` using
ffmpeg and shaka packager.
Replace RFC2119 wording in Security Considerations
Fix normative language issues
Add AudioDataInit.transfer
Add ImageDecoderInit.transfer
@agonza1 agonza1 merged commit d360e09 into agonza1:main Jul 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet