FFMetrics -- Yet another program for quality metrics calculation

Comments

Musicvid wrote on 10/28/2022, 9:11 PM

Be aware that the start frames must be visually aligned perfectly; even a one-frame offset can invalidate results from any QMT by a whopping 20%.

nicc wrote on 11/7/2022, 3:29 AM

@Musicvid you can believe me, that I am aware of this :-)

The fact that ffmpeg still does not really use SMPTE Timecodes for frame alignment, trims and offsets really bothers me. But since I'm in Europe with straight 24 or 25 fps in most assets the conversion to miliseconds isn't too hard ;-)

Howard-Vigorita wrote on 11/7/2022, 9:07 AM

The way I would trim pre-roll frames from the beginning of of a clip is with ffmpeg using the -ss option ahead of the -i input clip specification. Only complication is the command takes a time specification, not a frame count, so you need to compute it out in advance. Once the 2 clips at least start on the same frame, you can compare them for identity with either ffmetrics or ffmpeg directly. But personally, I wouldn't do the identity comparison that way. I'd use a file checksum/hash utility which would take into account everything including frame count and metadata... the one that comes with Windows is called certutil.

fifonik wrote on 11/7/2022, 10:31 PM

While trimming before comparison with ffmpeg you should not forgot:

1. In most cases you will need to use "accurate trim" that require video stream decoding and so it is slow, especially if you trimming quite a lot;

2. In most cases re-encoding will occur so you should save as uncompressed/lossless (even slower, require a lot of disk space, you should be careful with colours);

3. In my experiments sometimes -ss before -i does not work as expected. This is the reason ffmetrics uses 'trim' instead that I've found more reliable.

 

I'm not sure how hash/checksum can help as here we are not trying to find out if two files are exactly equal.

Camcorder: Panasonic X920

Desktop: MB: MSI B450M MORTAR TITANIUM, CPU: AMD Ryzen 5700X, RAM: G'Skill 16 GB DDR4@3200, Graphics card: MSI RX6600 8GB, SSD: Samsung 970 Evo+ 1TB (NVMe, OS), Samsung 870 Evo, HDD Seagate 3TB, HDD Toshiba 4TB, OS: Windows 10 Pro 22H2

NLE: Vegas Pro [Edit] 11, 12, 13, 15, 17, 18, 19

fifonik wrote on 3/17/2023, 7:49 AM

Version 1.3.2b published
- Bugfix:    High CPU/GPU utilisation caused by hidden Progress Bars with IsIndeterminate="True" (bugfix back-ported from 1.4.7b)


Version 1.4.0b published
- New:    Added a new command line parameter "-exit" that works in conjunction with "-run"
- Change:    Updated components HarfBuzzSharp, SkiaSharp, SkiaSharp.HarfBuzz, SkiaSharp.Views.Desktop.Common and System.Memory
- Bugfix:    Fixed crash that could happen while processing short command line arguments


Version 1.4.1b published
- Change:    Default LAVFI template changed from:
            [0:v]{{main}}[main];[1:v]{{ref}}[ref];[main][ref]{{filter}}
            to:
            [0:v]{{main-trim}},{{main-settb}},{{main-setpts}},{{main-scale}},{{main-setrange}},{{main-format}}[main];[1:v]{{ref-trim}},{{ref-settb}},{{ref-setpts}},{{ref-setrange}},{{ref-format}}[ref];[main][ref]{{filter}}
            All values in double curly brackets are substituted as required.


Version 1.4.2b published
- Change:    Updated components: System.Drawing.Common (6.0.0 => 7.0.0), Newtonsoft.Json (13.0.1 => 13.0.2), OxyPlot.Core, OxyPlot.SkiaSharp, OxyPlot.SkiaSharp.Wpf, OxyPlot.Wpf, OxyPlot.Wpf.Shared (all Oxy*: 2.1.0 => 2.1.2)
- Change:    Changes to make sure that external program (ffmpeg.exe) is closed (possible fix for crash while extracting bad frames)
- Bugix:    For ffmpeg with in-build VMAF models option 'model=path=file.json' is used for external json models instead of old option 'model_path=file.json'. The old option claimed as deprecated, but in fact does not work at all (#107)


Version 1.4.3b published
- New:    A number of bad frames that should be extracted can be configured in FFMetrics.conf (see FFMetrics.conf.example)
- New:    FFMpeg arguments for getting FFMpeg version info, checking VMAF models, getting media info, extracting bad frames and getting thumbnails can be defined in FFMetrics.conf (see FFMetrics.conf.example)
- Change:    Timeout for extracting bad frames increased to 30 seconds.
- Change:    FFMetrics.conf format is changed (see FFMetrics.conf.example)


Version 1.4.3b2 published
- Bugfix:    Fixed bug with escaping FFMpeg command line parameters (introduced in 1.4.3b)


Version 1.4.5b published
- New:    FFMpeg arguments for getting metrics can be defined in FFMetrics.conf (see FFMetrics.conf.example)
- Change:    -r <framerate> added before -i <filespec> to FFMpeg arguments while getting metrics (as per VMAF recommendation)
- Change:    TBR is used instead of FPS if available and not differ too much from FPS (should help with some VFR footage)
- Bugfix:    Skip was ignored when extracting bad frames
- Bugfix:    Project options were not always restored correctly on program startup


Version 1.4.6b published
- New:    Click on metric column header order files by metric value (#98)


Version 1.4.7b published
- Bugfix:    High CPU/GPU utilisation caused by hidden Progress Bars with IsIndeterminate="True"


Version 1.4.8b published
- Change:    "Action | Show plots window" in menu should not be tickable option
- Change:    Updated component: Newtonsoft.Json (13.0.2 => 13.0.3)
 

Camcorder: Panasonic X920

Desktop: MB: MSI B450M MORTAR TITANIUM, CPU: AMD Ryzen 5700X, RAM: G'Skill 16 GB DDR4@3200, Graphics card: MSI RX6600 8GB, SSD: Samsung 970 Evo+ 1TB (NVMe, OS), Samsung 870 Evo, HDD Seagate 3TB, HDD Toshiba 4TB, OS: Windows 10 Pro 22H2

NLE: Vegas Pro [Edit] 11, 12, 13, 15, 17, 18, 19