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/CAAHOzFD82DaDcGgrGARc9JhNNL4cT%2Bck3ec7a1RxQ-Yqe6RHdA%40mail.gmail.com.
