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.
