rfc(feature): Video replay envelope #129
Conversation
Co-authored-by: Billy Vong <billyvg@users.noreply.github.com>
Co-authored-by: Roman Zavarnitsyn <rom4ek93@gmail.com>
|
not sure if this should go into this PR, but what structure the |
text/0129-video-replay-envelope.md
Outdated
|
|
||
| ## Using a video, with EnvelopeItem:ReplayVideo | ||
|
|
||
| - From the SDK, we would send a new envelope with the following items: `Replay`, `ReplayVideo` and `ReplayRecording`. |
There was a problem hiding this comment.
@billyvg How would the player like to be notified that it should download video data? A type value on the replay? The video events in the RRWeb? Infer it from the replay's platform? Something else?
There was a problem hiding this comment.
@cmanallen Thinking of using the rrweb video event
text/0129-video-replay-envelope.md
Outdated
|
|
||
| ```json | ||
| { | ||
| "segment-id": 4, |
There was a problem hiding this comment.
@cmanallen just to confirm: this segment_id and the ones in the Replay item and ReplayRecording's payload should be the same, correct? Shall we also document it here for transparency?
There was a problem hiding this comment.
They should be the same but if you sent a segment 2 video with a segment 3 rrweb event nothing would break. So long as the rrweb video event on segment 2 accurately reflects the segment 2 video. The events are not dependent on one another for processing. They are just associated to the same "segment_id" metadata.
Co-authored-by: Roman Zavarnitsyn <rom4ek93@gmail.com>
Co-authored-by: Roman Zavarnitsyn <rom4ek93@gmail.com>
Co-authored-by: Roman Zavarnitsyn <rom4ek93@gmail.com>
|
@romtsn I think you're the last one to approve this, let me know if there're more changes you'd like to see, otherwise it's good to go |
There was a problem hiding this comment.
LGTM 🎉 maybe @brustolin could take a look on Monday, but we can merge now
How should Video-based replay behave:
Rendered RFC
closes #128
Relates to: getsentry/develop#1144