LGTM3 On Tue, Apr 8, 2025 at 9:45 AM Dale Curtis <dalecur...@chromium.org> wrote:
> Bump on this one; it still needs a third approval. Thanks! > > - dale > > On Thu, Apr 3, 2025 at 1:33 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> LGTM2 >> >> On Wed, Apr 2, 2025 at 7:36 PM Vladimir Levin <vmp...@chromium.org> >> wrote: >> >>> >>> >>> On Wednesday, April 2, 2025 at 12:04:23 PM UTC-4 Dale Curtis wrote: >>> >>> On Wed, Apr 2, 2025 at 8:37 AM Vladimir Levin <vmp...@chromium.org> >>> wrote: >>> >>> >>> >>> On Wednesday, April 2, 2025 at 12:05:53 AM UTC-4 Dale Curtis wrote: >>> >>> On Tue, Apr 1, 2025 at 7:16 PM Vladimir Levin <vmp...@chromium.org> >>> wrote: >>> >>> Some cameras and media will immediately begin exposing orientation >>> information. In uncommon cases this orientation may change. If orientation >>> changes during encoding through VideoEncoder frames with different >>> orientation than the first are currently encoded with incorrect size and >>> orientation. However the operation completes without a hard error. During >>> discussions in the media working group it was decided that these cases >>> should instead throw a non-fatal exception during encode(). There is >>> already precedent for exception handling during encode() so authors should >>> already be handling this case. >>> >>> Can you clarify if "uncommon" here means that some cameras are known to >>> change the orientation and those cameras are typically rare, or that most >>> cameras will change the orientation if say the user changes the >>> orientation, but that user behavior is rare? :) >>> >>> >>> I meant most cases will have a single fixed orientation for the duration >>> of the session. Users changing their orientation is uncommon. It will >>> almost always happen with users on mobile / hand-held devices accidentally >>> or intentionally reorienting the device itself. >>> >>> >>> I'm not sure how to reason about common-ness of the user device >>> orientation changes, so I'm not convinced by this specific argument. >>> >>> >>> Sorry, I forgot to cite my source: https://uma.googleplex.com/p/chrome/ >>> timeline_v2?sid=9db1427b181520ab8c02f338ff6bb809 (internal only >>> unfortunately), but ~99% of streams never see more than the initial >>> transform. >>> >>> >>> Cool thanks for the source! >>> >>> >>> >>> >>> >>> This does seem to introduce a new exception reason that seems almost >>> expected to happen in some cases. Can you comment on whether the other >>> exceptions that the author should already be happening are likewise >>> "common"? There's a bit of a concern that authors that don't handle these >>> exceptions will start breaking on orientation changing cases where >>> previously they did not. >>> >>> >>> Anecdotally, I'd say exceptions are uncommon for encode(). Exceptions >>> will be thrown if a frame is already closed or the codec has been closed >>> due to an error or reclaimed by system pressure (an automatic process which >>> is not uncommon, but also generates an error signal). >>> >>> We discussed this concern in the working group. Keep in mind, encoding >>> is already broken in these cases. It's just that instead of an exception >>> the frame is either squished (perpendicular orientation) or encoded in >>> mirror. As such the working group preferred a clear error signal to the >>> silent issues that exist today. >>> >>> Additionally, given low WebCodecs VideoEncoder usage on mobile the >>> actual risk of any issues seems unlikely: >>> https://chromestatus.com/metrics/feature/timeline/popularity/3458 >>> >>> >>> That seems a more compelling argument: the current state would be broken >>> in a different way, and the usage is very low. So this makes me think the >>> change is pretty safe. Nevertheless, can you comment on the type of website >>> that could potentially be impacted? Ie what are the common usages of this >>> API? >>> >>> >>> The most common of those affected would be some semi-RTC based site >>> doing its own camera/capture work on Android. E.g., Zoom who we're working >>> with on this. >>> >>> >>> Ok, that's good to know, thanks. >>> >>> LGTM1 >>> >>> >>> >>> >>> >>> Thanks! >>> Vlad >>> >>> >>> >>> >>> Thanks! >>> Vlad >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+unsubscr...@chromium.org. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4f46eb2b-e01d-4103-be00-50ecc05589a0n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4f46eb2b-e01d-4103-be00-50ecc05589a0n%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrweoeHudp9rpLFMttib16-4w99ZAOQaudUVhS%2B5okPV%3DQw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrweoeHudp9rpLFMttib16-4w99ZAOQaudUVhS%2B5okPV%3DQw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8MPEiueKkBVEuUcLeLgPMjrGdz7RnE9WGy9WE9Q58zZw%40mail.gmail.com.
