Missing CaptureTime

[Diceshake]

I am interested in using CaptureTime to sync remote WebRTC videos but the attribute seems to be missing when I requestVideoFrameCallback while all other attributes are present.

Is there something my RTCPeerConnections need for this property? Do I need to handle the Sender/Report packets?

[tguilbert-google]

I'm not sure what's going on there. Could you open a bug at crbug.com with a repro case? I'll be able to route it to the right people there. Thanks!

[tguilbert-google]

@Diceshake, did you figure out the issue or open a bug? Otherwise, I will close this issue by EOW.

Thanks!

[Diceshake]

@tguilbert-google, thanks for following up!

In my original post I was connecting a Golang implementation of Webrtc to the browser, so I felt the problem was out of scope.

I was able to get things working following this Webrtc Sample.

Enjoying the API so far 😄

[tguilbert-google]

Great, thanks! Happy coding!

[ngauthier12]

Hello there. I have encountered the same issue. After further testing, it appears a bidirectional video stream is required in order to receive the capture time. Packets must be send both ways too, an inactive track/stream won't do it.

As a workaround, I was able to capture stream from a blank canvas, add it to the peer connection outbound, and modify one pixel in it to force frames to be sent.

I have several data channels open as well and those do not trigger the captureTime to be received either.

[tguilbert-google]

I opened a chromium bug, since this is likely a Chrome implementation issue, more than a spec issue.

I am re-opening this thread for visibility, but the core of the investigation/discussion should go into the Chromium bug.

[fippo]

see webrtc/samples#1408 (comment)
this is an issue with how RTCP works by design. rrtr can be negotiated as a workaround

[murillo128]

Should the value of the abs-capture-time header extension be used when available?

https://w3c.github.io/webrtc-extensions/#dom-rtcrtpcontributingsource-capturetimestamp

[aboba]

As of Canary 129.0.6632.0 am seeing captureTime show up for remote tracks. This is in a WebCodecs worker encode/decode sample, so there is no transport involved. This would seem to imply that captureTime is propagated from VideoFrame to EncodedVideochunk in the encoder, and then from EncodedVideoChunk to VideoFrame in the decoder, across MediaStreamTrackGenerator to the VideoElement.

Am also seeing this behavior in a WebTransport echo sample that includes serialization and transport. The sample is not serializing captureTime on the wire, just timestamp so I'm not sure how captureTime is being set on the received EncodedVideoChunk.

Live demo: https://webrtc.internaut.com/wc/wcWorker3/
GitHub Repo: https://github.com/aboba/wc-demo