Fix/workaround inflated video duration (Safari only)#1317
Conversation
github-actions
Bot
added
the
status:conflicts
|
This pull request has conflicts ☹ |
github-actions
Bot
removed
the
status:conflicts
Safari has an annoying bug where recordings without audiotracks will produce mp4s with broken duration metadata, which results in videos that are roughly double the correct duration. Adding a fake silent audio track helps Safari to recognize the correct duration by cross checking both tracks. However this fix comes with the downside that non-audio recordings now have that faux audio track baked in, as it can't be easily removed without remuxing the recording. My guess is that this is fine, but it would obviously be nicer if that weren't the case.
|
I tested this fix on my Mac with Safari and can confirm that the length of a recording without audio is correct again. Btw. afterwards, you can deselect the empty audio track in the editor's track selection and publish the recording without the empty audio track. |
|
@gregorydlogan did you intend to merge this? Afaik there was no code review yet. I'm just confused as you never merged Studio PRs, except your own management PRs. I did look over the code and it looks fine to me (even tho I didn't deeply verify everything). So we can keep it as is. Just wondering if you accidentally pressed "merge" on the wrong PR. |
|
Nope, I meant to. I looked over the code, confirmed it worked on my machine, and Sascha confirmed it works on the mac. I'm by no means an expert in Typescript, but I've done enough at this point to spot when I don't know things. This looked good enough to me. |
4 participants
Safari has an annoying bug where recordings without audio tracks will produce mp4s with broken duration metadata. This results in videos that are roughly double the correct duration.
Adding a fake silent audio track helps Safari to recognize the correct duration by cross checking both tracks.
However this fix comes with the downside that non-audio recordings now have that fake audio track baked in, as it can't be easily removed without reprocessing. My guess is that this is fine, but it would obviously be nicer if that weren't the case.
I don't like this workaround, it's weird. At least it is scoped purely to Safari, and from what I can tell it is the simplest solution for this issue. I have looked at other web-based recording tools in Safari to see how they deal with this, but they either
The ones that are open source are in the first category, proprietary ones in the second, so unfortunately I couldn't look at their code.