RadCam 4K videos not being recorded/played on Electron/Browser by ArturoManzoli · Pull Request #1822 · bluerobotics/cockpit

ArturoManzoli · 2025-04-16T10:57:07Z

The video processing as a whole was failing on 4k RadCam streams, thus preventing the subtitles to be created.
This was due to three main reasons:

1- The thumbnail extraction, when failing, was causing the whole video processing event to also fail. Quite often the thumbnails were being generated without the first chunk even being written on the memory. To fix that, the thumbnail extraction was put in parallel with the rest of the video processing logic.

2- Since 4k recordings were demanding more time to write the first chunk on storage (sometimes up to 20 seconds). Stopping the recording before that first chunk, was causing the videos to fail processing; Also the recording timer was starting before the first chunk was written, making a difference between rec timer and real video duration, not noticeable when recording low res videos. (A separate issue #1823 was created to fix this preparation/timer-difference).

3- The absence of a mime type option on the MediaRecorder method was preventing the video from being processed normally. A method to extract this information from the Web RTC Manager was added to ensure the correct codec was selected.

Fix #1638
fix #1823

rafaellehmkuhl · 2025-04-16T12:23:33Z

src/components/mini-widgets/MiniVideoRecorder.vue

      :class="{
-        'blob red w-5 opacity-100 rounded-sm': isRecording,
+        'blob red w-5 opacity-100 rounded-sm mr-[6px]':
+          isRecording || videoStore.preparingToRecord === nameSelectedStream,


preparingToRecord is a system logic state, while nameSelectedStream is a string reference.

From what I'm reading in the code, there's no reason for it not to be a boolean.

This was made so when there are more than one MiniVideoRecorder instantiated, this status isn't shared between them.
Otherwise, when one video starts recording, the 'preparing' message would be displayed on both mini-widgets. We already have this issue with the isProcessingVideo variable being a boolean. When you press stop in one recorder, they all are set to 'Video processing' state.

In this case, the variable should be renamed to something that indicates that it is not a boolean, but the name of the stream being prepared.

Also, since it only stores the name of one stream, what happens if there are two streams and the user clicks the "start recording all streams" action? It looks by the logic that only the last one will be on "preparing" state, while the first one will be overwritten.

rafaellehmkuhl · 2025-04-16T12:26:08Z

src/stores/video.ts

-    activeStreams.value[streamName]!.mediaRecorder!.start(1000)
+    activeStreams.value[streamName]!.mediaRecorder!.start(500)


Is this change strictly needed? I ask it because it's a breaking change for any tool that is using the default size of 1 second for video chunks.

I see. I'll try to make it 1000ms

I still don't get it. In which kind of storage Is 600KB/ writing speed a problem?

You were right. There was no limitation going on in this case, and the consequences of changing that would not be easy to deal with.

Switched back to 1000ms

rafaellehmkuhl · 2025-04-16T12:27:23Z

src/stores/video.ts

  const lastRenamedStreamName = ref('')
+  const preparingToRecord = ref<string | undefined>(undefined)
+
+  const options = { mimeType: 'video/webm; codecs=vp9' }


Is this change strictly needed? What does it change and why?
I ask it for the same reason as the chunk-size change.

This is not great for performance: it will enforce a re-encoding from h264/h265 to vp9.

Agreed, I'll double check to see if there is an alternative or if this is indeed an important change

joaoantoniocardoso · 2025-04-17T15:52:57Z

src/stores/video.ts

+  // Picks the best codec available for the stream
+  let streamCodecOptions
+  if (MediaRecorder.isTypeSupported('video/mp4;codecs=hvc1.1.6.L120.90')) {
+    // HEVC (H.265)
+    streamCodecOptions = { mimeType: 'video/mp4;codecs=hvc1.1.6.L120.90' }
+  } else if (MediaRecorder.isTypeSupported('video/mp4;codecs=avc1.42E01E')) {
+    // AVC (H.264)
+    streamCodecOptions = { mimeType: 'video/mp4;codecs=avc1.42E01E' }
+  } else {
+    // WebM/VP9
+    streamCodecOptions = { mimeType: 'video/webm;codecs=vp9' }
+  }


This is tricky. I'm not completely sure about the behavior difference of the MediaRecorder when recording with or without specifying the mimeType.

In the absence of specification in the standard about this behavior, it's up to each browser implementation to decide whether it would re-encode or not. If we want to understand this, we could extensively test it or look at Chrome's source code to see what they are doing.

There is a possibility that when we don't specify the mimeType, it does not re-encode, and with this change, we lose this performance opportunity.

The problem is that when mimeType is not specified, the video processing fails.

What I'm trying to do here is to get the stream's specs so there is no need to re-encode.

related: w3c/mediacapture-record#139

The problem is that when mimeType is not specified, the video processing fails.

What I'm trying to do here is to get the stream's specs so there is no need to re-encode.

We could strategically try without setting the mimeType, with a fallback to setting it.

The problem is that when mimeType is not specified, the video processing fails.

What I'm trying to do here is to get the stream's specs so there is no need to re-encode.

Are you sure? If that was true, people wouldn't be able to process at all, since we don't force the specification of the MimeType today...

Oh, good to remind that the browser will only record the encodings it supports -- if the browser can't play H265, likely, it won't record H265.

Are you sure? If that was true, people wouldn't be able to process at all, since we don't force the specification of the MimeType today...

Regular videos are processing as usual without specifying the mimeType, but 4k videos from the RadCam do not process at all.

Maybe is my camera setup.. Are you able to process any video from RadCam on Electron or even web using master branch?

Yup. And Tony is also, as it uses it regularly. I suggest talking to him to better understand the problem. The original issue was only about subtitles generation, not video files (those were processing fine).

When talking to Tony it became clear that the video processing as a whole wasn't ending normally. The chunk files were being stitched together but the processing was braking before being completed.
He was receiving the error Fail to process video file but was still able to get the video files from the folder (Electron version), even though the telemetry subtitles generation was being halted by the video processing failing.

A method that gets RTCP peer connection details from the Web RTC Manager was added on the last patch, so the appropriate codec is used on the stream being recorded. Now the processing issues seem to be solved and the correct codec should be always selected.

@rafaellehmkuhl can you test on your radcam if the videos and telemetry subtitles recorded with this modifications are processing fine?

rafaellehmkuhl · 2025-04-22T18:31:43Z

src/stores/video.ts

+  const getRecorderOptions = async (streamData: StreamData): Promise<MediaRecorderOptions> => {
+    // Check on WebRTCManager to exposed RTCPeerConnection details.
+    const waitForPeerConnection = async (): Promise<RTCPeerConnection | null> => {
+      const until = Date.now() + 1_500


1500 is a small number. No need for Literal underscores here.

rafaellehmkuhl · 2025-04-22T18:32:27Z

src/stores/video.ts

+        const pc =
+          (streamData.webRtcManager as any).peerConnection ?? (streamData.webRtcManager as any).session?.peerConnection
+        if (pc) return pc as RTCPeerConnection
+        await new Promise((r) => setTimeout(r, 80))


There's a sleep function in utils.ts.

rafaellehmkuhl · 2025-04-22T18:33:53Z

src/stores/video.ts


+  const getRecorderOptions = async (streamData: StreamData): Promise<MediaRecorderOptions> => {
+    // Check on WebRTCManager to exposed RTCPeerConnection details.
+    const waitForPeerConnection = async (): Promise<RTCPeerConnection | null> => {


Since this function is very simple and only used here, can we make it not a function, and just code it inside the context?

rafaellehmkuhl · 2025-04-22T18:35:01Z

src/stores/video.ts

+    const peerConnection = await waitForPeerConnection()
+    let detectedMime: string | null = null
+
+    if (peerConnection?.getStats) {
+      const stats = await peerConnection.getStats()
+      stats.forEach((r) => {
+        if (r.type === 'inbound-rtp' && r.kind === 'video' && r.codecId) {
+          const codec = stats.get(r.codecId)
+          if (codec?.mimeType) detectedMime = codec.mimeType.toLowerCase()
+        }
+      })
+      if (detectedMime) console.debug('[Recorder] Detected codec via getStats →', detectedMime)
+    }
+    // SDP fallback – if getStats doesn't expose the coded yet, parse it out of the SDP
+
+    if (!detectedMime && peerConnection?.remoteDescription) {
+      const sdp = peerConnection.remoteDescription.sdp
+      const match = sdp.match(/^m=video .+$/m)
+      if (match) {
+        const pts = match[0].split(' ').slice(3)
+        for (const pt of pts) {
+          const rp = new RegExp(`a=rtpmap:${pt} ([A-Za-z0-9]+)/`).exec(sdp)
+          if (rp) {
+            detectedMime = `video/${rp[1].toLowerCase()}`
+            console.debug('[Recorder] Detected codec via SDP →', detectedMime)
+            break
+          }
+        }
+      }
+    }
+
+    if (detectedMime) {
+      if (MediaRecorder.isTypeSupported(detectedMime)) {
+        console.debug('[Recorder] Using detected codec.')
+        return { mimeType: detectedMime }
+      }
+
+      const codecOnly = detectedMime.replace(/^video\//, '')


There are a lot of cryptic strings here. Can we puts some comments here and there explaining exactly what is happening, so people reading this code in the future can better situate themselves?

rafaellehmkuhl · 2025-04-22T18:35:14Z

src/stores/video.ts

  const namessAvailableAbstractedStreams = computed(() => {
    return streamsCorrespondency.value.map((stream) => stream.name)
  })
-


No need to remove the line.

rafaellehmkuhl · 2025-04-22T18:36:00Z

src/stores/video.ts

+      video.src = videoObjectUrl

      video.addEventListener('error', () => {
        URL.revokeObjectURL(videoObjectUrl)
        reject('Error loading video')
      })

-      video.src = videoObjectUrl
-


Any reason for moving the code line to the top, since nothing happens to the object in the meanterm?

It was a leftover from an earlier modification.
Returning to the original place..

rafaellehmkuhl · 2025-04-22T18:38:10Z

src/stores/video.ts

+        const tryExtractFrame = (time: number): Promise<Blob> => {
+          return new Promise((resolveFrame, rejectFrame) => {
+            const onSeeked = (): void => {
+              try {
+                context.drawImage(video, 0, 0, width, height)
+                canvas.toBlob(
+                  (blob: Blob | null) => {
+                    video.removeEventListener('seeked', onSeeked)
+                    if (blob) {
+                      resolveFrame(blob)
+                    } else {
+                      rejectFrame('Failed to create blob')
+                    }
+                    URL.revokeObjectURL(videoObjectUrl)
+                  },
+                  'image/jpeg',
+                  0.6
+                )
+              } catch (err) {
+                video.removeEventListener('seeked', onSeeked)
+                URL.revokeObjectURL(videoObjectUrl)
+                rejectFrame(err)
+              }
            }
-            resolve(blob)
-            URL.revokeObjectURL(videoObjectUrl)
-          }
-          canvas.toBlob(blobCallback, 'image/jpeg', 0.6)
+            video.addEventListener('seeked', onSeeked)


The canvas.toBlob call changed from on line to 12 lines. Can the code be written in a way that it is easier to read? This would be a better place to put a function instead.

Agreed, fixed!

rafaellehmkuhl · 2025-04-22T18:38:20Z

src/stores/video.ts

+                canvas.toBlob(
+                  (fallbackBlob: Blob | null) => {
+                    if (fallbackBlob) {
+                      resolve(fallbackBlob)
+                    } else {
+                      resolve(new Blob())
+                    }
+                    URL.revokeObjectURL(videoObjectUrl)
+                  },
+                  'image/jpeg',
+                  0.6
+                )


Same here.

Try to avoid those infinite indentation hell at all cost. It makes reading the code an homeric task.

Agreed. The whole function could be improved.
A new approach for that was pushed on the last patch. I think it's way more clear now

rafaellehmkuhl · 2025-04-22T18:39:30Z

src/stores/video.ts

-        try {
+        ;(async () => {
          const videoChunk = await tempVideoStorage.getItem(chunkName)
-          if (videoChunk) {
-            const firstChunkBlob = new Blob([videoChunk as Blob])
-            const thumbnail = await extractThumbnailFromVideo(firstChunkBlob)
-            // Save thumbnail in the storage
-            await tempVideoStorage.setItem(videoThumbnailFilename(recordingHash), thumbnail)
-            unprocessedVideos.value = { ...unprocessedVideos.value, ...{ [recordingHash]: updatedInfo } }
-          }
-        } catch (error) {
-          console.error('Failed to extract thumbnail:', error)
-        }
+          if (!videoChunk) return
+          activeStreams.value[streamName]!.timeRecordingStart = new Date()
+          streamsPreparingToRecord.value = streamsPreparingToRecord.value.filter((name) => name !== streamName)
+          const firstChunkBlob = new Blob([videoChunk as Blob])
+
+          extractThumbnailFromVideo(firstChunkBlob)
+            .then((thumbnail) => tempVideoStorage.setItem(videoThumbnailFilename(recordingHash), thumbnail))
+            .catch((error) => {
+              console.warn('Failed to extract thumbnail:', error)
+            })
+        })().catch((error) => {
+          console.error('Unexpected error extracting thumbnail:', error)
+        })


Any reason for the await code to be replaced with then/catch?

Both versions would work fine for the thumb extraction and the the change to then/catch was meant to isolate thumbnail‑extraction errors without turning the code into a sequence of additional try/ catch blocks.

rafaellehmkuhl · 2025-04-24T21:10:13Z

@ArturoManzoli could you add the explanation on the commits on what each one tries to solve, as we discussed previously?

ArturoManzoli · 2025-04-25T09:45:45Z

@ArturoManzoli could you add the explanation on the commits on what each one tries to solve, as we discussed previously?

Yep, @rafaellehmkuhl after we spoke I did improve the description of the commits on their titles (1) and also added a long description on the PR's summary (2).

(1)
Stores: Video: Make the thumbnail generation paralel to video and telemetry processing
Mini-Widgets: Mini-video-recorder: Add stream recording preparation state - Fix timer and video duration diff
Stores: Video: Add WebRTC stream codec detection logic - Fix mimeType mismatch

(2)
1- The thumbnail extraction, when failing, was causing the whole video processing event to also fail. Quite often the thumbnails were being generated without the first chunk even being written on the memory. To fix that, the thumbnail extraction was put in parallel with the rest of the video processing logic.

2- Since 4k recordings were demanding more time to write the first chunk on storage (sometimes up to 20 seconds). Stopping the recording before that first chunk, was causing the videos to fail processing; Also the recording timer was starting before the first chunk was written, making a difference between rec timer and real video duration, not noticeable when recording low res videos. (A separate issue #1823 was created to fix this preparation/timer-difference).

3- The absence of a mime type option on the MediaRecorder method was preventing the video from being processed normally. A method to extract this information from the Web RTC Manager was added to ensure the correct codec was selected.

rafaellehmkuhl · 2025-04-25T13:14:22Z

@ArturoManzoli could you add the explanation on the commits on what each one tries to solve, as we discussed previously?

Yep, @rafaellehmkuhl after we spoke I did improve the description of the commits on their titles (1) and also added a long description on the PR's summary (2).

(1) Stores: Video: Make the thumbnail generation paralel to video and telemetry processing Mini-Widgets: Mini-video-recorder: Add stream recording preparation state - Fix timer and video duration diff Stores: Video: Add WebRTC stream codec detection logic - Fix mimeType mismatch

(2) 1- The thumbnail extraction, when failing, was causing the whole video processing event to also fail. Quite often the thumbnails were being generated without the first chunk even being written on the memory. To fix that, the thumbnail extraction was put in parallel with the rest of the video processing logic.

2- Since 4k recordings were demanding more time to write the first chunk on storage (sometimes up to 20 seconds). Stopping the recording before that first chunk, was causing the videos to fail processing; Also the recording timer was starting before the first chunk was written, making a difference between rec timer and real video duration, not noticeable when recording low res videos. (A separate issue #1823 was created to fix this preparation/timer-difference).

3- The absence of a mime type option on the MediaRecorder method was preventing the video from being processed normally. A method to extract this information from the Web RTC Manager was added to ensure the correct codec was selected.

The descriptions (why it does what it does) that you quoted here are not on the commits. Only the titles are there:

…emetry processing The thumbnail extraction, when failing, was causing the whole video processing event to also fail. Quite often the thumbnails were being generated without the first chunk even being written on the memory. To fix that, the thumbnail extraction was put in parallel with the rest of the video processing logic. Signed-off-by: Arturo Manzoli <[email protected]>

…tate - Fix timer and video duration diff Since 4k recordings were demanding more time to write the first chunk on storage (sometimes up to 20 seconds). Stopping the recording before that first chunk, was causing the videos to fail processing; Also the recording timer was starting before the first chunk was written, making a difference between rec timer and real video duration, not noticeable when recording low res videos. (A separate issue bluerobotics#1823 was created to fix this preparation/timer-difference).

ArturoManzoli · 2025-04-25T13:25:06Z

@ArturoManzoli could you add the explanation on the commits on what each one tries to solve, as we discussed previously?

Yep, @rafaellehmkuhl after we spoke I did improve the description of the commits on their titles (1) and also added a long description on the PR's summary (2).
(1) Stores: Video: Make the thumbnail generation paralel to video and telemetry processing Mini-Widgets: Mini-video-recorder: Add stream recording preparation state - Fix timer and video duration diff Stores: Video: Add WebRTC stream codec detection logic - Fix mimeType mismatch
(2) 1- The thumbnail extraction, when failing, was causing the whole video processing event to also fail. Quite often the thumbnails were being generated without the first chunk even being written on the memory. To fix that, the thumbnail extraction was put in parallel with the rest of the video processing logic.
2- Since 4k recordings were demanding more time to write the first chunk on storage (sometimes up to 20 seconds). Stopping the recording before that first chunk, was causing the videos to fail processing; Also the recording timer was starting before the first chunk was written, making a difference between rec timer and real video duration, not noticeable when recording low res videos. (A separate issue #1823 was created to fix this preparation/timer-difference).
3- The absence of a mime type option on the MediaRecorder method was preventing the video from being processed normally. A method to extract this information from the Web RTC Manager was added to ensure the correct codec was selected.

The descriptions (why it does what it does) that you quoted here are not on the commits. Only the titles are there:

Done

rafaellehmkuhl · 2025-04-29T11:15:54Z

@ArturoManzoli I've tried to review this functionality yesterday, but my power supply is failing to supply enough current to the radcam. I'm getting a new power supply so I can properly test it.

rafaellehmkuhl · 2025-05-19T17:21:26Z

@ArturoManzoli my power supply arrived. I should be conducting the tests today.

rafaellehmkuhl

Just tested it. The browser version is working fine, and is indeed solving the subtitles issue as well as the thumbnail one, but the Electron version seems to be downsampling the recorded video somehow.

This is a recording on the master branch:

Cockpit.May.21.2025.-.10.10.36.GMT-3.472c82c8.webm

This is a recording on this PR:

Cockpit.May.21.2025.-.09.59.18.GMT-3.682e4f40.webm

The stream is smooth, and my CPU and RAM usages are low.

Running on macOS 15.4.1.

ArturoManzoli · 2025-05-22T16:14:13Z

Just tested it. The browser version is working fine, and is indeed solving the subtitles issue as well as the thumbnail one, but the Electron version seems to be downsampling the recorded video somehow.

The video/webm;codecs="h264" codec the browser is switching to caps the stream at ~2 Mbps, which is fine for 720p but visibly mushy on 4K.

I'm currently working on solution based on a custom bitrate config.

ArturoManzoli · 2025-05-23T18:56:32Z

@rafaellehmkuhl The bandwidth ceiling was increased to 40 Mbits.
Looks like it's all good now.

The codec was the same on master and on this branch, the only difference was the bandwidth cap.

rafaellehmkuhl · 2025-05-23T19:26:59Z

@rafaellehmkuhl The bandwidth ceiling was increased to 40 Mbits. Looks like it's all good now.

The codec was the same on master and on this branch, the only difference was the bandwidth cap.

Nice!

Is there any problem on pushing to 60 Mbits? So we can also support 4K 60 FPS. There are some other people using high-fps 4K cameras, so if there's no harm, I would push for already supporting it.

ArturoManzoli · 2025-05-23T20:22:04Z

@rafaellehmkuhl The bandwidth ceiling was increased to 40 Mbits. Looks like it's all good now.

The codec was the same on master and on this branch, the only difference was the bandwidth cap.

Nice!

Is there any problem on pushing to 60 Mbits? So we can also support 4K 60 FPS. There are some other people using high-fps 4K cameras, so if there's no harm, I would push for already supporting it.

I think it's okay to do that. At least on high end machines running Cockpit-electron

I'll crank up the values and we keep an eye on users feedback

ArturoManzoli · 2025-05-23T21:00:11Z

@rafaellehmkuhl Done!

Ready to review

rafaellehmkuhl

With the latest changes, the lag apparently went away, but the bitrate is still low. Check the following:

Kapture.2025-05-27.at.11.49.37.mp4

Cockpit.May.27.2025.-.11.49.27.GMT-3.dbcad0d2.webm

Signed-off-by: Arturo Manzoli <[email protected]>

ArturoManzoli · 2025-05-30T19:32:11Z

On last patch:

Set specific webm/H264 codec and 8 Mbit/s bitrate to match Chrome's default mimetype and bitrates;

Recorded on Electron:

Cockpit.May.30.2025.-.15.41.11.GMT-3.c2f86202.webm

ArturoManzoli · 2025-06-12T17:28:04Z

Converting this PR to draft, as @joaoantoniocardoso is experimenting with important aspects of video streaming that are directly related to the issues it aims to resolve.

rafaellehmkuhl · 2025-10-21T23:05:39Z

@ArturoManzoli this one can probably be closed.

rafaellehmkuhl · 2026-01-16T17:24:48Z

Closed in favor of #2164.

ArturoManzoli marked this pull request as draft April 16, 2025 10:59

ArturoManzoli force-pushed the 1761-subtitles-not-being-generated-on-standalone branch from 20d2ed1 to b320848 Compare April 16, 2025 11:07

ArturoManzoli marked this pull request as ready for review April 16, 2025 11:07

ArturoManzoli requested a review from rafaellehmkuhl April 16, 2025 11:09

rafaellehmkuhl requested changes Apr 16, 2025

View reviewed changes

ArturoManzoli changed the title ~~RadCam 4K videos not being recorded / played on Electron / Browser~~ RadCam 4K videos not being recorded/played on Electron/Browser Apr 17, 2025

ArturoManzoli force-pushed the 1761-subtitles-not-being-generated-on-standalone branch from b320848 to 9bc26ff Compare April 17, 2025 13:36

ArturoManzoli requested review from joaoantoniocardoso and rafaellehmkuhl April 17, 2025 13:41

joaoantoniocardoso reviewed Apr 17, 2025

View reviewed changes

ArturoManzoli force-pushed the 1761-subtitles-not-being-generated-on-standalone branch from 9bc26ff to fb0fe19 Compare April 17, 2025 16:11

ArturoManzoli marked this pull request as draft April 17, 2025 16:12

ArturoManzoli force-pushed the 1761-subtitles-not-being-generated-on-standalone branch 4 times, most recently from 7d4f97d to 8f16c0a Compare April 22, 2025 16:29

ArturoManzoli requested a review from joaoantoniocardoso April 22, 2025 16:41

rafaellehmkuhl requested changes Apr 22, 2025

View reviewed changes

ArturoManzoli marked this pull request as ready for review April 22, 2025 18:54

ArturoManzoli force-pushed the 1761-subtitles-not-being-generated-on-standalone branch 3 times, most recently from 71bcb17 to d01662e Compare April 22, 2025 20:46

ArturoManzoli requested a review from rafaellehmkuhl April 22, 2025 20:49

ArturoManzoli added 2 commits April 25, 2025 10:20

ArturoManzoli force-pushed the 1761-subtitles-not-being-generated-on-standalone branch from d01662e to ffb092f Compare April 25, 2025 13:24

rafaellehmkuhl requested changes May 21, 2025

View reviewed changes

ArturoManzoli force-pushed the 1761-subtitles-not-being-generated-on-standalone branch from ffb092f to 7c4d31c Compare May 23, 2025 18:53

ArturoManzoli requested a review from rafaellehmkuhl May 23, 2025 18:56

ArturoManzoli force-pushed the 1761-subtitles-not-being-generated-on-standalone branch from 7c4d31c to 9cc8dac Compare May 23, 2025 20:59

rafaellehmkuhl requested changes May 27, 2025

View reviewed changes

ArturoManzoli force-pushed the 1761-subtitles-not-being-generated-on-standalone branch from 9cc8dac to 7f6e87e Compare May 30, 2025 17:33

Video-store: Set specific codec and bitrate on recording start

1023375

Signed-off-by: Arturo Manzoli <[email protected]>

ArturoManzoli force-pushed the 1761-subtitles-not-being-generated-on-standalone branch from 7f6e87e to 1023375 Compare May 30, 2025 19:29

ArturoManzoli requested a review from rafaellehmkuhl May 30, 2025 19:32

rafaellehmkuhl mentioned this pull request Jun 2, 2025

Video thumbnail extraction is not working for 4K/Radcam videos on Electron #1921

Closed

ArturoManzoli marked this pull request as draft June 12, 2025 17:28

rafaellehmkuhl closed this Jan 16, 2026

		activeStreams.value[streamName]!.mediaRecorder!.start(1000)
		activeStreams.value[streamName]!.mediaRecorder!.start(500)

Comments

Conversation

ArturoManzoli commented Apr 16, 2025 • edited by rafaellehmkuhl Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ArturoManzoli Apr 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ArturoManzoli Apr 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rafaellehmkuhl commented Apr 24, 2025

ArturoManzoli commented Apr 16, 2025 •

edited by rafaellehmkuhl

Loading

ArturoManzoli Apr 17, 2025 •

edited

Loading

ArturoManzoli Apr 22, 2025 •

edited

Loading

ArturoManzoli commented Apr 25, 2025 •

edited

Loading

rafaellehmkuhl left a comment •

edited

Loading

ArturoManzoli commented May 23, 2025 •

edited

Loading