SmartCut extreme quality degradation for encoded part due to incorrect detected bitrate from stream

adzm commented 1 month ago

The fewer issues I have to read, the more new features I will have time to implement, so I ask that you please try these things first

[X] Try with the newest version from GitHub (also it might have already been fixed in latest nightly build)
[X] Read the documentation and FAQ, Known issues, Troubleshooting
[X] Search for your problem under Issues or Discussions
[X] If you have a problem only with a particular file (or file type), use this form instead
[X] Windows 7, 8 and 8.1 are no longer supported. This is not a question about Windows 8.1 or older.

Operating System

Windows 10

Steps to reproduce

I was experimenting with SmartCut on a file; using developer tools I saw that the bitrate parsed for the stream is only 97 kb/s. The average bitrate based on file size is around 4000 kb/s. Using ffprobe I see this info:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'smartcuttest.mp4': Metadata: major_brand : dash minor_version : 0 compatible_brands: iso6avc1mp41 creation_time : 2019-07-25T11:46:15.000000Z Duration: 00:03:50.46, start: 0.000000, bitrate: 4007 kb/s Stream #0:00x1: Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 97 kb/s, 29.97 fps, 29.97 tbr, 30k tbn (default)

which explains where the 97 kb/s part comes from. I am uncertain why ffprobe is giving this value, unfortunately. The video file only has one stream, no audio.

I put a copy of the file here for now: http://adzm.net/losslesscut/smartcuttest.mp4

While I am uncertain how to handle this situation, it would be nice to have an option at least to toggle between estimating a bitrate based on file size and attempting to determine the bitrate from the stream, perhaps, or allow setting it explicitly. Since this is usually a small part of the overall exported segment, I would personally prefer that the bitrate is as high quality as possible.

Expected behavior

The encoded part of the SmartCut segment should be visually similar in quality to the rest of the file.

Actual behavior

The encoded part of the SmartCut segment is laughably poor quality at 1/40th of the bitrate in this particular case.

Share log from developer tools

No response

adzm commented 1 month ago

Unfortunately, modifying the source to just always use (for example) an 8 megabit bitrate still ends up producing strange / glitched output in some situations, though i think that is a different issue.

Also, I noticed the encode of the smartcut parts is not put into the ffmpeg command log, it appears? which makes it trickier to try to reproduce and debug locally.

mifi commented 1 month ago

I will think about this.

Also, I noticed the encode of the smartcut parts is not put into the ffmpeg command log, it appears? which makes it trickier to try to reproduce and debug locally.

i will fix that

sthibaul commented 1 week ago

I'm also seeing this kind of issue, apparently because this is a zoom recording that knows that it's essentially static slides, and thus the bitrate with proper compression is very low (50Kbps). I tried version 3.61.1 and force-set the bitrate to 10Mbps, but the quality is still very low (as seen right from the beginning). Here are the files:

https://people.debian.org/~sthibault/tmp/12-01-intro.mp4 https://people.debian.org/~sthibault/tmp/12-01-intro-proj.llc https://people.debian.org/~sthibault/tmp/12-01-intro-cut-merged-1718979747775.mp4

mifi / lossless-cut