You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For outgoing streams this makes some sense since it is easily known (but it isn't clear to me what the use-case is), for incoming streams this requires pre-parsing the VPx payload descriptor, the H264 SPS (or PPS?) and the AV1 sequence header OBU.
Is anyone relying on this behavior? Note that it already doesn't work for AV1 so the values are 0/0 and I heard a "we would like to move away from parsing bitstreams" here that I agree with.
While I don't think we can change this to be optional depending on the direction, we can at least consistently set width/height to 0 on incoming streams.
The text was updated successfully, but these errors were encountered:
These are dictionary members without "required" on them, so omitting them is completely consistent with syntax.
I would much prefer "missing member" over 0/0 as "there's nothing here to see" indication.
The video frame metadata come with width and height:
https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframemetadata-width
For outgoing streams this makes some sense since it is easily known (but it isn't clear to me what the use-case is), for incoming streams this requires pre-parsing the VPx payload descriptor, the H264 SPS (or PPS?) and the AV1 sequence header OBU.
Is anyone relying on this behavior? Note that it already doesn't work for AV1 so the values are 0/0 and I heard a "we would like to move away from parsing bitstreams" here that I agree with.
While I don't think we can change this to be optional depending on the direction, we can at least consistently set width/height to 0 on incoming streams.
The text was updated successfully, but these errors were encountered: