Rescaling may produce sample aspect ratio other than 1:1
When the capturing area was defined via the mouse, the resulting MP4 export may have an SAR (sample aspect ratio) other than 1:1. When uploading such a video to Twitter, the reencoded video will show a noticable discoloration (greenish tint).
Note that this may only be reproducible on Retina displays, where the capture area resolution does not match the final video resolution. I'm still trying to come up with reliable reproduction steps.
Partial screenshot of tweet with reencoded video:

I've temporarily shared some examples here (some even reencoded via Handbrake): https://twitter.com/iratoom
The respective ffprobe output (ffprobe -hide_banner -show_data) shows:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Kapture 2020-10-16 at 00.38.25.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.24.101
Duration: 00:00:14.07, start: 0.000000, bitrate: 149 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1302x1080 [SAR 1787:1789 DAR 387779:322020], 146 kb/s, SAR 6255:6262 DAR 973:808, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
Metadata:
handler_name : Core Media Video
vendor_id : [0][0][0][0]
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'observable-1581549137.mp4':
Metadata:
major_brand : mp42
minor_version : 512
compatible_brands: isomiso2avc1mp41
creation_time : 2020-02-12T23:18:16.000000Z
encoder : HandBrake 1.3.1 2020010400
Duration: 00:00:04.82, start: 0.000000, bitrate: 3473 kb/s
Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1600x1080 [SAR 27:40 DAR 1:1], 3466 kb/s, 50 fps, 50 tbr, 90k tbn, 180k tbc (default)
Metadata:
creation_time : 2020-02-12T23:18:16.000000Z
handler_name : VideoHandler
vendor_id : [0][0][0][0]
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'sand-sim-plane-mm-editor.mp4':
Metadata:
major_brand : mp42
minor_version : 512
compatible_brands: isomiso2avc1mp41
creation_time : 2020-04-14T13:44:34.000000Z
encoder : HandBrake 1.3.1 2020010400
Duration: 00:00:42.96, start: 0.000000, bitrate: 1689 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1544x1080 [SAR 270:383 DAR 386:383], 1687 kb/s, 29.93 fps, 240 tbr, 90k tbn, 180k tbc (default)
Metadata:
creation_time : 2020-04-14T13:44:34.000000Z
handler_name : VideoHandler
vendor_id : [0][0][0][0]
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'sand-sim-sorted-draw-demo.mp4':
Metadata:
major_brand : mp42
minor_version : 512
compatible_brands: isomiso2avc1mp41
creation_time : 2020-04-18T21:26:33.000000Z
encoder : HandBrake 1.3.1 2020010400
Duration: 00:00:22.90, start: 0.000000, bitrate: 12981 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1440x1080 [SAR 1335:1784 DAR 445:446], 12977 kb/s, 30 fps, 30 tbr, 90k tbn, 60 tbc (default)
Metadata:
creation_time : 2020-04-18T21:26:33.000000Z
handler_name : VideoHandler
vendor_id : [0][0][0][0]
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Kapture 2021-05-28 at 23.51.50.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.24.101
Duration: 00:00:28.70, start: 0.000000, bitrate: 1139 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1076x1080 [SAR 3789:3794 DAR 113249:113820], 1135 kb/s, SAR 17429:17452 DAR 595:598, 60 fps, 60 tbr, 15360 tbn, 120 tbc (default)
Metadata:
handler_name : Core Media Video
vendor_id : [0][0][0][0]
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'bw3-scaled.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.24.101
Duration: 00:00:02.88, start: 0.000000, bitrate: 31 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1080x978 [SAR 3234:3235 DAR 116424:105461], 23 kb/s, SAR 12937:12941 DAR 1047837:949168, 60 fps, 60 tbr, 15360 tbn, 120 tbc (default)
Metadata:
handler_name : Core Media Video
vendor_id : [0][0][0][0]
Also, I believe I ran into the same issue in the past when capturing directly via Quicktime.
I could confirm SAR as the root issue for Twitter's encoding problems by changing it via ffmpeg.
Changing SAR on a previously broken video and reuploading it, the greenish tint is gone:
ffmpeg -i bw3-scaled.mp4 -c copy -bsf:v h264_metadata=sample_aspect_ratio=1 bw3-scaled-sar1.mp4
Vice versa, changing SAR for a correctly reencoded video produced the tint when reuploading:
ffmpeg -i bw4-1200x1200-s540x540.mp4 -c copy -bsf:v h264_metadata=sample_aspect_ratio=3234/3235 bw4-1200x1200-s540x540-sar3234-3235.mp4
Oops, this is the wrong repository, sorry! Can you please move this issue over to https://github.com/wulkano/Kap?
Steps to reproduce:
- On a retina / HiDPI display, define a capture area of 400x399. Perhaps related: aspect ratio still shows
1:1. - Capture a short clip. In the clip preview, the clip resolution should show as 800x798.
- Export to mp4, check SAR via
ffprobe -show_data, which should output:800x798 [SAR 1:1 DAR 400:399] - Set width to
400, reexport, check SAR:400x400 [SAR 400:399 DAR 400:399]
So it seems to be the clip resizing that's messing up the aspect ratio.
Appreciate the detailed issue @mootari!