Profile Information

Name: Varun Shrivastava
GitHub: varun-s22
Gerrit: Reputation22
Phabricator: Reputation22
Location: India
Typical Working Hours: 16:00 (UTC + 5:30) to 02:00 (UTC + 5:30)
Time zone: UTC +5:30 (Indian Standard Time)

Synopsis

VideoCutTool is an open-source, online video editing tool, for videos uploaded on Wikimedia Commons. It is an easy, on-the-go tool, which supports features like cropping, trimming, rotating, etc. This is preferred over other tools as one can directly copy the link of the video from the commons, and edit it online, without having to download the video and then upload it again.
This proposal aims at improving the above tool, by:

• Adding new features / updating existing ones in the tool, to improve the user experience.
• Adding tests on both frontend as well as backend, to improve the functionality of the tool.
• Remove / Fix any pending bugs (if any).
• Reduce the build time for the tool.

Possible Mentor(s)

Sohom Datta (@Soda), Vasanth Gopa ( @Gopavasanth )

Have you contacted your mentors already?

Yes

Deliverables

Here are the deliverables which this proposal promises to complete within the timeline.

Mid Term Evaluation

By the midterm evaluation, the tool will be having:

• Clear and user-friendly UI, on both web and mobile devices.
• Reduce build time for developers.
• Video persistence after refreshing the browser tab.
• Fix Bitrate drop (quality degrading) while editing videos.
• Add a session management, to store cookies and sessions if the tool’s database migrates from Mongo-Db to PostgreSQL ( Use PostgreSQL instead of MongoDB-896129 )

Final Evaluation

By the end of the GSOC – 2023 program (final evaluation), apart from the above deliverables listed, this tool shall be having:

• Error notifications shall be more verbose, to help the user identify the issue.
• Add unit tests for both the client side and server side, using Jest / React-testing library, and integrating with Jenkins/CI.
• Updating the libraries/dependencies to avoid deprecation warnings during build time.
• Add static type checking to the project using JSDoc.
• Update the function to convert other video file formats to webm, before uploading videos to commons.

Timeline

I plan to divide my work into three phases:

Phase 1: Client-Side improvements

Here I’m planning to improve the client side of the tool. This shall be helpful for the users, as it is exposed to the clients and the users. This primarily deals with adding new features, updating existing features, and fixing front-end bugs/warnings. etc.

May 4 – May 18 (Community Bonding Period)

This is the initial week of the program. So, I’ll be collecting some resources about the tool, from the users, mentors, and will be planning to incorporate those changes after discussion with the concerned mentors, and make a quick run through the code base, and address some pending issues meanwhile, like “Fixing the edited video back to commons”, if this is still valid. This issue has been reported by some users, so I’ll be gathering more information about this, like steps to reproduce, software version .etc, and try to reproduce this on my device, and will look into the possible solutions to resolve this. One issue was to check if the video got uploaded to the commons. For checking this, one approach is to check if any errors occurred while uploading the video using the MediaWiki API: upload and make sure the video is uploaded to the commons. I may have to look upon the API, and check if it handles such cases. If not, and if time permits, I can suggest some changes to the MediaWiki Core, for handling such cases, else I will have to look upon other methods for the same .The other one can be to cross-check the upload by the MediaWiki:API usercontribs: Get all edits by a user for listing the videos uploaded by the user, and to check the latest upload and verify whether the video upload, was successful or not.
Apart from this, I’m planning to add some features like a video saturation/brightness adjustment slider, which can be implemented by adding some FFmpeg commands, or flags to the existing ones. Another feature can be adding a blur effect to mask problematic areas of the video. For this, I’ll be going with box blur or gaussian blur of FFmpeg and will be adding the mask to the specific areas of the video. Since this is a video editing tool, so the user will be asked to specify the region to blur.

May 19 – May 29 (Community Bonding Period)

I’m planning to change the UI of the tool, to make it more user-friendly, and easier to follow. I’ll be changing the UI to somewhat similar to this T315143 (as discussed here) and shall be updating the tool accordingly. For this, I’ll be exploring some new icons, and styles, and will be updating the tool accordingly. Also currently, on uploading a video to the tool, the size of the video player component (VideoPlayer.jsx) is free, and depends on the dimensions of the video uploaded. The problem arises when some large videos are uploaded, which makes the window scrollable to get to the end of the player. I’m planning to fix the size of the Video Player so that all videos will be displayed under a fixed constraint size player. This will look better in the new UI, as well as maintain consistency between the videos and the tool.
The sidebar (now header) component of the front end is a toggle sidebar, in the mobile view, which does not go with the current header style of the tool. I’m planning to change it, to a dropdown menu with a hamburger icon, where the menu pops out from the top like a drawer. It’ll be somewhat similar to this(view in CodePen).

May 30 – June 10

Here, I shall be working on client-side issues, like Video Persistence after tab refreshing. I’ll be discussing this with my mentors, and shall be working on the approach decided. One approach could be to store the edited video instance in localstorage or IndexedDB, or some other storage instances, to preserve it after refreshing the tab. Instead of storing the readable stream of the video generated, on the memory, I will be storing the video id or uuid of the edited video on the storage, and when the tab refreshes, it’ll be fetching the instance of video from the database using the primary key, and display it on the screen. Since we are downloading the edited video on the server, I will be storing it temporarily on the database, against the user, and will be storing its video id, on the client, so that on tab refresh. I can easily fetch the video from the server. Alongside this, I’ll be storing the enabled features on the client side only, as they won’t be taking up much space, and so can be easily fetched for the Results page.
Alongside this, currently, the error notifications, do not show the error message for some errors, which can be misleading to new users. I’ll be updating the notifications message, to be more verbose, which shall be helpful for the users to track the errors, and work accordingly.

Phase 2: Developer friendly improvements

Here I’m planning to improve the build time and reduce the bundle size of the tool. This will be helpful for the new developers, who shall be working on this tool soon or are currently working on this. This primarily deals with reducing dependencies, updating older dependencies, and reducing build time for the tool.

June 11 – June 22

Here I’m planning to work on reducing the bundle size of the tool. This can be done by removing extra dependencies or updating the existing ones with ones that take lower space/ more efficient to use. There are dependencies like react-bootstrap, react-bootstrap-icons, which are used only for rendering some components like Buttons, Icons. etc. We are using the Toast and Popover components of the react-bootstrap library. I’m planning to replace them with other npm packages like react-toastify and react-awesome-popover or react-tiny-popover, which are lighter as compared to current library being used.
Follow here to get the bundle size of react-bootstrap-icons, and react-bootstrap. I’m planning to remove these dependencies and write components from scratch, and for icons, we can use react-icons, with a bundle size of 6kb, which will also help in reducing the build time by a respectable amount.
I’m also planning to update the libraries in the later phase of the timeline, due to which we shall be getting "fetch" in-built in the latest node versions. So I’ll be converting all Axios calls to the inbuilt fetch ones, and this will also help in reducing the bundle size of the tool. Follow here to get the bundle size of Axios.

The data about bundle sizes are taken from an open-source website called, BundlePhobia.

June 23 – July 7

Here I’m planning to update the libraries, like React, Node, and MongoDB, which are currently in use of the tool. This will be a big task, as I have to update all the libraries and the corresponding dependencies, for the tool to run warning and bug-free. This might also help us to eliminate the use of docker for running in development. Also as discussed above, new updates to libraries bring some features inbuilt to the tool, like fetch comes inbuilt with node v17+, and more.
Apart from this I will be working on reducing the build time of the tool. This can be achieved by either optimizing the CRA (Create React App) tool, by applying Code Splitting, Using Pure components, Removing unused variables/code. etc. Another approach to this can be migrating from CRA to Vite, which Is a more efficient tool to build react apps now. Vite uses preconfigured Rollup, which is a more efficient bundler than webpack (CRA uses webpack as its bundler). For more information, visit here Decrease development and build time in React apps using Vite over create-react-app with WebPack.. Also currently I’m facing some issues with webpack’s require.context not being parsed as a function by jest, making the tests and build process fail. So I’ll be looking more into this, and will be coming up with permanent solutions for this. I will also look into Vite, and the import functionality it uses, and whether its compatible with jest. For more information, refer here T333797.
I’ll be preferring over Vite, as CRA (Create React App) has been officially taken down from the new React Docs Create React App Gone From React.dev, and since this phase aims at upgrading the libraries, it’s only a matter of time we switch from CRA to Vite. Also, whether it will be worth(and even possible) to migrate to an entirely different build tool is something I'd have to look into.

July 8 – July 14 (Mid-term Evaluation)

This is the midterm evaluation phase, and I will be addressing the reviews of the mentor and will be working to improve on them. I will also be working on the remaining work (if any), from the above timeline.

Phase 3: Server-Side improvements

Here, I’ll be working on the server side of the tool, and improving its functionality of the tool. This primarily deals with adding session management, improving the quality of edited videos, and reducing errors on the function 'convert to webm or ogv' file formats. etc.

July 15 – July 28

Here I’ll be working on upgrading the quality of the video, after editing. This is a big task and requires working on FFmpeg. I’ll be comparing the quality of the videos, before and after editing, i.e. by comparing the bitrate of the two videos. If the bitrate decreases, then the quality of the video is reduced. Then I’ll be breaking up the editing commands (FFmpeg), and will be isolating the command which causes this quality degradation, and then will be looking for other solutions for retaining the quality of the video.
Also currently on uploading other file formats like .mp4, we are encountering errors like File extension '.mp4' does not match the MIME type of 'webm'. Follow here to know more about this T333403 . I’m planning to work on this alongside. This should not take long, and hence I’ll be integrating this with improving the bitrate quality task.

July 29 – August 7

Here I’m planning to add a session management system, for storing the cookies and sessions. If the database gets shifted to PostgreSQL 896129, then for the session management system, I’m planning to use default express-session MemoryStore implementation, as discussed in the issue here, T330755. Although this is only available for the dev-only (development) implementation, and so we will be looking into more options for production, like storing them on disk, i.e postgres itself, or using some external packages like express-pg-session. I’ll be discussing this with the mentors and will be moving forward with the session management system, best suited for the tool.

August 8 – August 20

Here, I’m planning to add static type checks to the code base, for code consistency and readability. I’m planning to use the JSDoc, a type-checking markup language, which shall be useful for the developers. Another option is using Typescript, but that might involve an additional build step i.e. transpiling TypeScript to JavaScript.

August 21 – September 4 (Final Evaluation)

Here, I’ll be adding unit tests for both frontend and backend, using Jest, the React-testing library. I’ll be writing tests for the existing as well as updated code-base and will be integrating this with Jenkins (CI), to run all the checks, when a developer submits a new patch/commit. Etc. I’ll be dividing them into two parts

Client-Side Testing:

These tests majorly focus on the client-side implementation of the tool, and will be of two types:

• Unit Tests: These tests consist of testing the primary functions/ components of the front-end. These can of various types, like:
  • Ensuring Correct Rendering of Components for given props: This ranges from showing the username when logged In, and displaying nothing when logged out, to proper conditional rendering of components, like rendering a component based on some conditions.
  • Ensuring Correct Data Fetching: Since our tool basically fetches data from the server side using API endpoints, its essential to test those endpoints, and check if they return the correct result of not. So here, I will be writing tests for checking the endpoints, by mocking the api, and sending “fake” requests, with dummy data.
  • Other tests: Other test include checking for event listeners and testing them, like testing the dark mode toggle button.

These tests are heavily derived from the react official documentation Testing Recipes, and will be somewhat similar to what listed in the documentation.

• End-To-End Tests: These tests are designed to test the tool, under real-time realistic browser environment. These tests contain checking for the tool, by mimicking what a user would do, when he opens the tool. These can be, checking for a confirmation dialog box, when clicked on logout button, checking for language drop down list when clicked on language toggler button, getting the “in-progress” screen after editing the video, and so on. One important use case for this testing is to ensure that the video got uploaded to commons successfully or not. This is a pending issue, and a deliverable to GSOC - 2023, and so it’ll be checking, if the upload was successful or not.

Server-Side Testing:

These tests focus on the server side of the code, and will be majorly testing the workflow of the api routes, and database connections. Here are the major two classifications of server-side testing:

• Testing API Routes: These ranges from checking if the user logged in, to fetching videos uploaded by a particular user. We will be testing the GET, POST requests made onto the api endpoint, and will be listing all the possible responses like 200, 404 etc, and ensuring the output received should be amongst them.
• Checking Database Connection: These tests are basically for checking the database connections, and whether the connection was successful or not. We can add a extra layer to this checking if we can fetch any user or video from the database successfully or not.

These tests are majorly derived from these blogs Server Side testing With Jest, Testing Your ExpressJs Backend.

I’m planning to divide the time according to the workload, and code-length wise. For instance Client Side Unit Testing can take a longer period of time as compared to others. Alongside this, I’ll be addressing the code reviews received and will be working on them simultaneously, and will be going through the entire code base, just to ensure proper functionality and working of the tool.

Participation

I am active on Zulip, Phabricator and email. I’ll use Gerrit for code reviews and shall respond to the reviews on Gerrit, as well as on Phabricator. I plan on regularly updating my progress to the mentors, and getting feedback for the same.

About Me

Education (In Progress)

I’m currently in my 3rd Year of B.Tech/B.E in Computer Science and Engineering, from Indian Institute of Information Technology, Pune.

How did you hear about this program?

I started writing code during my initial years of college. I have built various projects, and have collaborated on others as well. I came to know about GSOC after my friends got accepted into GSOC. I talked to them, which made me realise how much fun and exciting open source can be. So, I researched more about GSOC and started my preparation for the same.

Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program?

No, I have my summer break starting from May 10th, 2023, so I’ll be free during the duration and shall be contributing more to the organisation.

We advise all candidates eligible for Google Summer of Code and Outreachy to apply for both programs. Are you planning to apply to both programs and, if so, with what organization(s)?

No, I plan on participating only in Google Summer of Code 2023, with Wikimedia Foundation.

What does making this project happen mean to you?

I started contributing to open source from the past year only, and have been wanting to explore more in this field. With VideoCutTool, I shall be exploring this new world and will be helping others, making their work easier, like in this case edit their videos and display the results live to them. It will also give me hands-on real-time developer experience, which will be helpful for my career growth.

Past Experience

I have been contributing to the Wikimedia Foundation, for the past two to three months, and have submitted patches to Wikimedia Commons Tool: VideoCutTool. This helped me to get familiar with the codebase. Here are some of my contributions to VideoCutTool:

Apart from this, here are my other contributions to VideoCutTool

Tasks Authored

Other Projects

Apart from contributing to Wikimedia, I have also worked on some personal and group projects, which have tech stacks related to the tool.

FastTyper

FastTyper is a multi-player speed typing game, where users type a paragraph or text, and are ranked according to their WPM (Word Per Minute). This project is built on React, Express, PostgreSQL, WebSockets (socket.io library), and Google OAuth. This is where I got to know more about React, Sockets, and how a connection is made between the client side and server side.

Slick Chat

A simple real-time chatting application built using WebSockets. The entire application is written in Typescript. React is used for the front end and Express for the back end. The database used is PostgreSQL and Socket.IO is used for implementing WebSockets. This was my first collaborative project, where I was introduced to new technologies like React, socket.io, and TypeScript. Attached are my pull requests, which are merged into the project.

BookHub

BookHub is a free and open-source website, made for reading/downloading books online. One can create an account and can read all the books for free, and download ePubs. Users can also post comments, along with attachments like images, to share their opinions on the book. This is built using Node, Express, MongoDB, Sass, Ejs, and Docker. This was my first JavaScript project, which exposed me to all new technologies, like Express, MongoDB, and Docker.

Apart from these, I have worked on other projects as well, which helped me get more proficient to JavaScript. You can find more about my projects here(view in Github).

Coding Skills

• I’m proficient in Python and JavaScript and have built projects on the same, to get more comfortable with the language.
• Have worked with Express/Node/Flask backend frameworks, and React as frontend frameworks.
• Have experience working on other languages like TypeScript, C/C++, Java .etc.
• Have worked with databases like MongoDB, SQL, SQLite, and PostgreSQL.
• Have worked with Docker.

UI Mockups

Here are some UI changes I’m proposing. This might help get a clear picture

The design here are derived from T315143. I have added some extra functionality to it, like new video editing options like Brightness slider, Saturation Slider. I have also updated the menu icon on the top right of the header(navbar) to be a new gear icon, and have added the title of the video, along with the current status. Here, since we are editing the video, the status is “Editing”.

Here's how I imagine, the UI for mobile view.

Here we have edited the video, and so the current status becomes “Result”, along with file name. We are showing the features enabled, along with two options, i.e. download the result or upload it to commons.
Note: The wikiText to be uploaded to commons, is not shown in the UI mockup, as we are planning to change the raw text to user-readable text T331239 (via the mediaWIki API).