WPT addition is covered under https://github.com/web-platform-tests/wpt/issues/39642 and I haven't been able to prioritize that yet. I don't know what other vendors do. You're welcome to file a bug in the mediarecorder - not sure I think the issue raised here is terribly important but I could support the implementation doing > instead of >= when it comes to duration.
On Fri, May 31, 2024 at 5:34 PM Peter Kasting <pkast...@chromium.org> wrote: > 0 is actually the one unambiguous case -- it clearly means you want a key > frame every frame. > > Seems strange that someone whose steam has a key frame every 30 frames > should specify a count of 29. I dunno though, if that's also what other > vendors do then changing is far more trouble than benefit. Do we know what > other vendors do? Is there any kind of wpt test for this, or similar? > > PK > > > On Fri, May 31, 2024, 7:37 AM Markus Handell <hande...@google.com> wrote: > >> It was a while, but the discussions we had were not revolving around this >> corner case. >> I think it makes sense for the implementation to keep adhering to the >> "exclusive of" to get rid of the ambiguity of what 0 means in Interval. I >> also don't see another way to interpret the spec text. >> For the duration I don't think it practically matters whether >= or > is >> used as we're talking microseconds. If you think this is important, please >> file a MediaRecorder bug. >> >> Thanks! >> Markus >> >> On Fri, May 31, 2024 at 3:28 PM Peter Kasting <pkast...@chromium.org> >> wrote: >> >>> >>> >>> On Fri, May 31, 2024, 5:43 AM Markus Handell <hande...@google.com> >>> wrote: >>> >>>> Hi Peter, from the spec text: >>>> >>>> "If videoKeyFrameIntervalCount is not null ... the video encoder >>>> produces a keyframe on the *first* frame arriving *after* >>>> *videoKeyFrameIntervalCount >>>> frames passed* *since* the last key frame" >>>> >>>> It sounds to me like the blink impl is correctly implementing the spec >>>> meaning. If videoKeyFrameIntervalCount is 0, the spec text implies every >>>> frame should be a key frame. If your alternative interpretation were true, >>>> what would a value of 0 mean? >>>> >>> >>> A value of 0 would in practice have the same effect as a value of 1, >>> both meaning, "key frame every frame". Though also in practice I don't >>> think either actually works, given that the blink impl API only requests >>> key frames in response to receiving delta frames. >>> >>> If "first frame after" is intended to imply "exclusive of", then the >>> count part is correct but the time part is wrong (it would need to switch >>> to > from >=). I think the intent of the wording was to imply "inclusive >>> of", though. But I wasn't in the meetings, so I'm not sure. >>> >>> PK >>> >>> >>>> On Thu, May 30, 2024 at 7:50 PM Peter Kasting <pkast...@chromium.org> >>>> wrote: >>>> >>>>> On Thursday, May 30, 2024 at 9:32:50 AM UTC-7 Peter Kasting wrote: >>>>> >>>>> The spec says that both the duration and frame count refer to the >>>>> interval "between key frames". >>>>> >>>>> >>>>> More spec text: "If videoKeyFrameIntervalCount is not null and >>>>> videoKeyFrameIntervalDuration is null, the video encoder produces a >>>>> keyframe on the first frame arriving after videoKeyFrameIntervalCount >>>>> frames passed since the last key frame." I think that means Blink's >>>>> current >>>>> impl is indeed off-by-one. >>>>> >>>>> PK >>>>> >>>> -- 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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJjiFfFsqwPFiqQCJFjEo%2B4HdnPK3ohQBTqwqQbkpih117gGMg%40mail.gmail.com.
