I guess currently we are using ffmpeg -i input.mp4 -an output.mp4by adding -c copy parameters we can copy the frames instead of going through a decode->filter->encode process.

So changing to ffmpeg -i input.mp4 -c copy -an output.mp4 will solve the quality loss issue? hopefully.

Change 643759 had a related patch set uploaded (by Diwanshu885; owner: Diwanshu885):
[labs/tools/video-cut-tool-worker@master] Add "-c" & "copy" parameters to solve the quality loss issue

https://gerrit.wikimedia.org/r/643759

Change 643759 merged by Gopavasanth:
[labs/tools/video-cut-tool-worker@master] Add "-c" & "copy" parameters to solve the quality loss issue

https://gerrit.wikimedia.org/r/643759

I don't want to re-open task this but take a look at this output, 180 rotation of Ping!-RKW6rjnYEkc.webm from commons. IMO, the issue is not resolved yet. I've rotated videos by 180 using solutions at https://stackoverflow.com/questions/3937387/rotating-videos-with-ffmpeg on my computer and the results don't appear to have any significant quality loss issues at all.

I spent an hour now (tested locally) and played around with the videos and ffmpeg, I couldn't find any quality loss with the commands which we used in our tool. @Bharatkhatri351, @Sandyabhi, @SarthakKundra, or @Khr2003 any insights?

@Gopavasanth I just tried it on local machine and did not see any quality loss.

I tried to trim this video https://commons.wikimedia.org/wiki/File:Ping!-RKW6rjnYEkc.webm for 5 sec and the resultant video is here https://videocuttool.wmflabs.org/video-cut-tool-back-end/public/publicVideo-1616435522842-0.webm.

Found any quality loss?

i guess this problem persists. i just tried removing audio of https://commons.wikimedia.org/wiki/File:2_Weeks_In_Italy_-_A_Cinematic_Travel_Film.webm without any changes to the video track. the resultant download is only 27 Mb but the original is 498.

Found any quality loss?

Let's look at the ffprobe results.

For File:Ping!-RKW6rjnYEkc.webm

Input #0, matroska,webm, from 'Ping!-RKW6rjnYEkc.webm':
  Metadata:
    ENCODER         : Lavf58.45.100
  Duration: 00:02:42.98, start: -0.007000, bitrate: 1281 kb/s
    Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709), 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)
    Metadata:
      DURATION        : 00:02:42.969000000
    Stream #0:1(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
    Metadata:
      DURATION        : 00:02:42.981000000

For https://videocuttool.wmflabs.org/video-cut-tool-back-end/public/publicVideo-1616435522842-0.webm

Input #0, matroska,webm, from 'publicVideo-1616435522842-0.webm':
  Metadata:
    ENCODER         : Lavf58.20.100
  Duration: 00:00:05.01, start: -0.007000, bitrate: 141 kb/s
    Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv), 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)
    Metadata:
      ENCODER         : Lavc58.35.100 libvpx-vp9
      DURATION        : 00:00:05.012000000
    Stream #0:1(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
    Metadata:
      ENCODER         : Lavc58.35.100 libopus
      DURATION        : 00:00:05.008000000

Notice the bitrate drop? From 1281 kb/s to 141 kb/s.

hey @Gopavasanth if this issue is still open can i work on this?, if yes then can you please guide me on how to get started with it?

Hi @Naman, Yes this is still open, we use ffmpeg for editing videos, please see our code, understand our commands, try out various other commands to improve the video quality and fix the issue :)

Learn more about ffmpeg: https://www.ffmpeg.org/ffmpeg.html

Thanks @abi_ for diving deep into this issue and providing the summary.

Notes:

Based on the analysis of the video file, We have identified several important points that need to be considered.

Firstly, the crf value determines what bitrate to use based on the encoding. In the case of the tested file, which is encoded with VP9, a crf value of 32 was used by default.

Secondly, Webm files usually use VP8 video compression. However, in the case of the tested file, VP9 was used. The VP9 encoding has a specific set of guidelines that need to be followed, as outlined in the VP9 Encode/Decode Guide.

Thirdly, when we removed the audio from the tested file, the resultant bitrate dropped from 1281 kb/s to 1113 kb/s. When we trimmed the video to 5 seconds, the resultant bitrate dropped further to 282 kb/s.

It is unclear why the bitrate dropped to 141 kb/s when the video was trimmed in a previous instance, as our local testing showed it should be around 282 kb/s. It is important to investigate the cause of this discrepancy.

Finally, the impact of the bitrate on the video quality needs to be assessed. This can be done by comparing the original video with trimmed or cropped versions to see if there are any noticeable differences. Additionally, it may be worth experimenting with different crf values and b:v arguments to see if this improves the situation.

In conclusion, it is important to consider the encoding, crf value, and bitrate when handling video files. Thorough testing and experimentation can help to optimize video quality and ensure that the files are optimized for their intended use.

Change 891873 had a related patch set uploaded (by Iampranavdhar; author: Iampranavdhar):

[labs/tools/VideoCutTool@master] Update the command for video conversion

https://gerrit.wikimedia.org/r/891873

I have tested the tool with https://mixkit.co/free-stock-video/people-pouring-a-warm-drink-around-a-campfire-513/ this video which is of 100mb of disk space and after changing the crf to default value which is 23 I have achieved the same quality as the original file.

Numbers:
Original File => 100mb
Converted File1 => 30mb [ With only no audio option selected ]
Converted File2 => 8.6Mb [ With cropping, trimming to 5s and no audio options selected ]

Change 891873 merged by jenkins-bot:

[labs/tools/VideoCutTool@master] Avoid bitrate drop to avoid quality degrading while editing videos

https://gerrit.wikimedia.org/r/891873

Vinod here, just wanted to share that I have successfully set up the development environment for the VideoCutTool project . I have gone through the user feedback on the commons talk page and the codebase to get familiar with the project. I noticed that there is an issue related to quality degradation of the video after editing. I am planning to work on the microtask related to avoiding bitrate drop and quality degrading while editing videos. I will also try to analyze the ffmpeg commands that are being used and see if there are any modifications that can be made to improve the video quality.

hey @Soda @Gopavasanth, is this issue open for gsoc 2023 deliverable? I can see patches related to this issue being merged, so is this still a open one?