[MM-53432] Improve recording start time accuracy #44
Conversation
streamer45
added
the
Do Not Merge
|
To note, this requires a few more PRs to work (offloader, calls plugin and rtcd) but need to polish so many things so I am starting from the one with the fewer dependencies. |
| @@ -201,7 +228,58 @@ func (rec *Recorder) runBrowser(recURL string) error { | |||
| } | |||
|
|
|||
| func (rec *Recorder) runTranscoder(dst string) error { | |||
| args := fmt.Sprintf(`-y -thread_queue_size 4096 -f alsa -i default -r %d -thread_queue_size 4096 -f x11grab -draw_mouse 0 -s %dx%d -i :%d -c:v h264 -preset %s -vf format=yuv420p -b:v %dk -b:a %dk -movflags +faststart %s`, | |||
| ln, err := net.Listen("unix", transcoderProgressSocketPath) | |||
There was a problem hiding this comment.
This whole method is pretty cool, I learned a lot. Thanks.
cmd/recorder/recorder.go
Outdated
| @@ -181,6 +201,13 @@ func (rec *Recorder) runBrowser(recURL string) error { | |||
| return nil | |||
| } | |||
| continue | |||
| case <-rec.transcoderStartedCh: | |||
| if err := chromedp.Run(ctx, | |||
| chromedp.Evaluate("window.callsClient?.ws?.send('job_started');", nil), | |||
There was a problem hiding this comment.
Slightly too clever for my taste but it was the quickest way to achieve what I needed. I am actually thinking of redesigning this a bit and make a proper HTTP endpoint since we have another requirement to inform back the plugin side in case of pre-connection failures. Will think some more on this.
| n, err := conn.Read(buf) | ||
| if err != nil { |
There was a problem hiding this comment.
So if I'm reading this correctly, we wait until the transcoder fills up one progress buffer, then we send out the started event? Just wondering if that will cause a timing mismatch (transcoding started, but there's a delay in sending out the started ws event), or is the delay so little it won't matter?
There was a problem hiding this comment.
Yeah, so the logic here is trivial, ffmpeg will output one progress line per processed video frame so we act as soon as we receive the first one. To be more accurate we could parse the actual output but so far I don't think it's needed.
And yes, there's always going to be some latency to account for but fortunately we are not looking for lip-sync accuracy here. Delay here should be a few milliseconds at most.
cpoile
added
3: Reviews Complete
streamer45
removed
the
Do Not Merge
Summary
PR improves the accuracy of the recording job start time so that it becomes a little easier to synchronize future transcriptions.
We do this by plugging into
ffmpeg's progress log and send a ws event to the stream when the actual transcoding process starts.Semantically the change is that a recording doesn't start any longer when the bot connects via websocket but when it sends this new
job_startedevent since it could happen a few seconds later as the transcoding process needs a couple of seconds to initialize.Other notable changes included here:
/datadir to store files. Same happens on the transcriber and it makes it just easier to generalize jobs at the offloader level.Ticket Link
https://mattermost.atlassian.net/browse/MM-53432