Say Hello👋⌗

Hi There! This is the start of GSOC bi-weekly blog series. Thanks for joining us. Before we dig deeper into the world of GSOC, and my work, allow me to introduce you to my team.

There’s Sohom, who is currently my mentor for this project. He was a past GSOC contributor under Wikimedia, and has been around in the community for 4-5 years i guess. He’s also the GSOC org admin for the GSOC-23 round.

Then we have Vasanth Gopa, who is also my mentor for this project. He’s the maintainer and the creator of my project, VideoCutTool. He built this in around 2019, under GSOC, and is now also serving as the org admin for GSOC-23 round.

We also have Sudhanshu, for helping us out with the redesigning of the tool. He’s a UI/UX designer, and works on improving the designs under Wikimedia.

Last, but not the least, we have Punith, who is also the GSOC contributor for this year.

Oh, I almost forgot to tell you about my project. So Punith and I will be working on a online video editing tool by Wikimedia Commons, called VideoCutTool. It’s widely used by the volunteers to edit videos on the fly and re-upload back to commons in simple few clicks instead of downloading video from commons and using external softwares to edit and re-upload.

Of course we have different things planned, and so while his proposal is all about improving the functionality and adding new designs/features, updating UI .etc Mine is to improve the code health/quality of the tool, along with improving the architecture, and efficiency .etc

Starting over again⌗

I was contributing to the tool for like 2-3 months before GSOC. So after the results were out, I had to start again. Since my proposal wasn’t that user-centric as opposed to Punith’s. So I decided to start my work early during the Community Bonding Period itself.

I wanted to start with something small, something which does not overwhelm me, after a one-month gap. I wanted a delicate start, and gradually pace up the momentum. So I started with some pending issues from my proposal. Here are a few of them.

1) Fix: Enhance notifications to be verbose.⌗

Currently the tool shows the notifications with the template error message, like “An error has occured”, or something like this.

So after digging here and there, I figured that we weren’t sending the concerned error message, and that we weren’t handling the errors and warnings in the APIs. I solved this by changing the layout of every API, by encapsulating them in a try..catch block.

Somewhat like this

try{
    ...
}
catch(e){
    console.log(e)
    throw new Error(e)
}

The above JS-template helps in fixing the catching the error and throwing them to the client.

Note: I can throw the error within the catch block itself, and the client will catch it. This is called try-catch nesting/chaining.

The error thrown from the catch block of the server will be catched by the catch block of the client, and so we can display the error message correspondingly.

The problem arised during the upload process. Since we had concurrent upload requests (i.e upload multiple videos), and so we stored all the videos to be uploaded in a Array, and then used Promise.allSettled, to resolve all those requests. If you are not familiar with allSettled, visit here.

The thing was that irrespective of any errors encountered in any of the requests in the array, allSettled settles all the calls, and returns array of responses, all with status code 200. So to figure out the Errors and Warnings, one has to manually parse through the response object, and throw errors/warnings correspondingly.

There’s a alternate to this, called Promise.all. You can know more about it here. The way it works is like, on encountering a rejection of any promise in the array, it rejects the entire array, and throws the error instantly. But here’s the thing, Consider we are uploading 3 videos, so our array has 3 videos, or should I say 3 promises(ready to be resolved) in the array. Now if the 2nd video gives me the error, Promise.all() would stop here, and would not process the 3rd video, which is so not what we want from our tool. We want to process every video, and try to upload them.

// videos to be uploaded
const videos = [{ Video1 }, { Video2 }, { Video3 }];

// consider Video1 to be giving error

const promises = await Promise.all(videos);
// Expected output: none

const promises = await Promise.allSettled(videos);
// Expected output: Array [Object { status: "rejected", reason: "Video1" }, Object { status: "fulfilled", reason: "Video2" }]

2) Adding a Volume slider to the editing page⌗

The next thing which I worked on was adding a volume slider to the editing page, which enables users to lower or increase the volume of the video, and can edit it accordingly.

This required me to add a new ffmpeg command on our server, so as to change the volume of the video. Currently we were creating a new copy of the video and editing it via tha c:a flag in ffmpeg. But the volume change required to pass the filter:a command. To know more about ffmpeg and its commands, refer here

And as far as the client is considered, for reflecting back the live changes, we are altering the volume attribute of the <video/> html tag.

Here are some screenshots, of the volume slider

That sums it up :)⌗

Apart from these, I have authored/co-authored multiple gerrit patches, some of which includes adding nginx support for dev server, fixing editing of mp4 videos .etc

This brings us to the end of the blog. Hope you enjoyed it. For more such stuff stay tuned!!

This was the 1st blog of the GSOC Biweekly blog series. Next blog coming soon. See you next time :)