Repository navigation
Seed the E2EE sender cryptor with the publish codec #2131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
6858e8f
29ae791
46b5fa7
e0d6dd7
2a55ad7
0f9dd59
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| --- | ||
| 'livekit-client': patch | ||
| --- | ||
|
|
||
| When an SEI or AUD NALU precedes the slice, encrypt h264 frames from the correct offset. Those NALUs read as h265 slice types, so detection returned h265 and the unencrypted prefix ended inside the leading NALU. The slice header was encrypted and no error was raised. The frame bytes now take precedence over a caller-supplied codec. The sender cryptor is also seeded with the publish codec for h264 and h265. A fallback to VP8 handling now logs the first bytes of the frame. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -620,11 +620,15 @@ export class E2EEManager | |
| if (!sender) this.log.warn('early return because sender is not ready'); | ||
| return; | ||
| } | ||
| const isVideo = isVideoTrack(track); | ||
| // Safari exposes no per-frame codec info until trackInfo arrives. Seed only h264/h265: | ||
| // a wrong vp8 seed would skip the NALU path, a wrong NALU seed only costs a logged fallback. | ||
| const publishedCodec = isVideo ? track.publishOptions?.videoCodec : undefined; | ||
| this.handleSender( | ||
| sender, | ||
| track.mediaStreamID, | ||
| undefined, | ||
| isVideoTrack(track) | ||
| publishedCodec === 'h264' || publishedCodec === 'h265' ? publishedCodec : undefined, | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. question: I'm not sure if I understand why this has to only be h264 / h265 - based on the issue description, wouldn't be ok to be able to pass in any codec here and let downstream code fall back to this always if
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The seed never reaches The value available here is |
||
| isVideo | ||
| ? (track.publishOptions?.frameMetadata ?? track.publishOptions?.packetTrailer) | ||
| : undefined, | ||
| ); | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.