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?