Add file:// support to createVideoComposition()

  • Feature Description:
    We have a feature where you can create clips from a video, however, because createVideoComposition() doesn’t support file:// and only supports overwolf://media, if you change the video recording folder, our app would break. We currently do have a workaround where we pass the file url to the createvideocompositionfiles() to create a clip that gets a guaranteed overwolf media url.
  • impact for my app: [low, mid, high, show-stopper].
    High as this is blocking our feature development unless we create our own plugin.
  • What is your current pain point?
    The current workaround takes a long time to clip short clips from a long video and it copies the file taking up resources from the user.
  • What do you have in mind to solve it?
    We would have to create our own C# plugin.

Hi @jkorean,

I’m not sure what your concern is precise. Can you describe an example of an issue?
The overwolf.io.paths API gives you the current paths of the videos folder, images, and more.

Thanks.

Hi @eransharv,

Apologies for the confusion. Basically, the overwolf.io.paths API gives me a static default video location, which isn’t necessarily the location users can record the videos to. Since we allow users to change their recording folder location, let’s say you have the overwolf video folder at c:/folder1 and then record a video, you’ll get a web url something like overwolf://media/videos/video.mp4. If you change the video folder to c:/folder2 then the weburl breaks. This can be demonstrated by performing an HTTP GET on the web url before and after changing the recording folder. This makes it so that web URLs aren’t suitable for long term use.

The specific use case for our app is:

  1. a user would record a video
  2. change the saved recording folder directory
  3. try to clip the previously recorded video
  4. fails with the error “video not found” because the web URL isn’t valid anymore

So the workaround we do is call the createVideoCompositionFiles() since it accepts a file url (file://) and provides a new overwolf://media url. This is “guaranteed” to be a valid url. However, this incurs a large performance cost since essentially what it is doing is copying the video before clipping which is why trying to clip a large file size video, it takes a long time to clip as well as consumes a large amount of resources. If createVideoComposition() can accept file://, then even if the user changes the saved folder location, the clipping feature would work.

@jkorean, the paths API doesn’t return a general “Default” static path - it returns the path defined by the user through the Overwolf client UI. If the user changes it through the OW UI - the path API will return the new path.

if you mean overwolf.io.paths will return a new path if you change it through the OW UI, then is it a bug that it’s not returning the new path? (example pic below)

if you are talking about overwolf://media/recordings, then that still doesn’t help us because changing it breaks old urls from before it was changed.

@jkorean, you are saying that overwolf.io.paths is not updated? The top screenshot is before the change, and the bottom is after the change? If so, I will reproduce it and create a bug.

Unless overwolf.io.paths.videos is broken in another way, it doesn’t seem to be related to the overwolf recording folder ( getOverwolfVideosFolder(callback) ). It appears to be a way to retrieve the user’s videos folder ie. %USERPROFILE%\videos

Both the user video folder AND the path returned by getOverwolfVideosFolder(callback) (which we are already using) do not help us in this usecase.

If the user changes the recording folder either via the overwolf settings UI or using setOverwolfVideosFolder(path, callback) , then searching in the newly specified location for an old video will break because the video only exists in the old location and not the new one.

This doesn’t address our original issue of not being able to use file urls with createVideoComposition(sourceVideoUrl, segments, callback) in the first place. We need the sourceVideoUrl parameter of createVideoComposition() to accept a file url like createVideoCompositionFiles() so that we don’t have to do the workaround of using the output of createVideoCompositionFiles() as the input of the sourceVideoUrl of createVideoComposition() which uses up a lot of users’ resources when they are trying to clip a short video from a large file size video and takes a long time due to copying of the video.

  1. Regarding searching videos in the “old” folder, if the user changed it - you will have to work around it. For example - save the path on app launch and search it as well, etc.
  2. I want to confirm: what you are saying actually is that createVideoComposition has a bug: it suppose to accept the file:// format AND the overwolf://media, but it accepts only overwolf://media format? What exactly happens if you send it in a file:// format? erorr?

It’s technically not a bug because the documentation doesn’t suggest that createVideoComposition will accept file urls. When calling it with a file url it results in an error. This would be a feature request to allow createVideoComposition to accept a file url (file://).

{
  error: "Cannot find source video."
  reason: "Cannot find source video."
  status: "error"
  success: false
}

Ok, now it’s clear. So we will discuss the matter internally, and we will update you here.

Thanks.

1 Like

We added this feature request to our backlog.
We don’t have an ETA, though, and that can take some time to implement and release. Thank you for your patience.
We will update you here once it is ready.

Thanks.

No worries. Sounds good.

Update: implemented in version 0.185.
The version will be released in a few days in the Developers channel.

1 Like

Hey,

An update: so we did add file:// URI support, but it’s not going to solve your issue (videos capture folder being changed) because it will only allow paths under the extension folder (%localappdata%/overwolf/extensions/…) or extension videos folder (overwolf/videos/…) .

We will need to come up with a better (and secure) solution that will allow any past capture folders to be used as a path in a future iteration. We are on it, but it will not be ready for this version (no ETA yet).

Thanks

1 Like