Periodic sharpness and luminance shifts in DJI footage

What a regular cadence does make unlikely

These are unlikely, not impossible. A repeating camera move over repeating scene content can coincidentally align with a frame interval. That is why Section 4 exists.

Clues that strengthen the coding hypothesis

• The effect repeats at a stable frame interval.
• It is strongest in fine, low-contrast texture.
• It survives an independent decode outside Resolve.
• The visual cadence lines up with measured picture types or keyframe positions in that specific file. This is the strongest single piece of evidence, and Section 5 shows how to get it.

Why the intra picture can look different

The camera works to a bitrate ceiling set by the recording mode and has to divide that budget across the GOP. Encoders generally quantise intra pictures less aggressively than predicted ones, because a cleaner reference keeps later pictures cleaner. Software encoders expose this directly: x264 and x265 call it ip-ratio, default 1.4. Hardware encoders in cameras apply the same principle internally.

What can legitimately be measured

• Picture type (I, P, B), where the bitstream and decoder expose it.
• Packet size per frame, which can vary substantially.
• Timestamps and frame order.
• Image-domain measures such as high-frequency energy or edge strength.
• Whether a visible pulse is temporally aligned with a repeating coding structure.

An illustration of the size difference

The table below comes from a controlled synthetic test encode, not from a DJI camera: 1280x720, deliberately bitrate-starved, GOP of 10, two B-pictures. It shows that picture types can receive very different amounts of data. It says nothing about what any particular drone does.

Abridged. Across the full range the intra pictures averaged 1.45 times the high-frequency energy of the others. The same script run on a well-fed encode of the same source returned 1.05 times, which is the negative control.

Bit depth

10-bit provides 1024 code values per channel against 256 for 8-bit. That is substantially more room before quantisation becomes objectionable under a heavy grade. It does not make a coding artifact disappear, and 8-bit log is where this problem is hardest to avoid.

Chroma

Recording formats vary by aircraft and mode. Check DJI's published specification for the specific model rather than generalising from another drone.

List picture types, numbered by frame

ffprobe -v error -select_streams v:0 \
  -show_entries frame=pict_type -of csv=p=0 DJI_0001.MP4 \
  | head -60 | cat -n

Output is in presentation order, so the numbers correspond to timeline frames. A GOP of 10 looks like this:

     1  I          11  I
     2  B          12  B
     3  P   ...    13  B
    10  P          21  I

List keyframe timestamps only (faster on long clips)

ffprobe -v error -select_streams v:0 -skip_frame nokey \
  -show_entries frame=pts_time -of csv=p=0 DJI_0001.MP4 | head -20

Show data allocated per picture, printed as size,type

ffprobe -v error -select_streams v:0 \
  -show_entries frame=pkt_size,pict_type -of csv=p=0 DJI_0001.MP4 \
  | head -30 | cat -n

6A. The variation is in the source encode

You cannot reconstruct information the camera never wrote. The goal is to reduce the remaining temporal difference.

6B. Resolve is decoding differently

1. StudioLeave hardware decode disabled (Preferences › System › Decode Options, Studio only) and confirm the improvement holds across several clips.
2. Update GPU drivers. On NVIDIA, prefer the Studio driver branch.
3. Transcode outside Resolve to an intra-frame codec and cut with that. This removes Resolve's H.264 and H.265 decoder from the equation entirely, and as a bonus every frame becomes independently decodable, so scrubbing gets much faster.

# ProRes 422 HQ
ffmpeg -i DJI_0001.MP4 -c:v prores_ks -profile:v 3 \
  -pix_fmt yuv422p10le -c:a pcm_s16le DJI_0001_prores.mov

# DNxHR HQX
ffmpeg -i DJI_0001.MP4 -c:v dnxhd -profile:v dnxhr_hqx \
  -pix_fmt yuv422p10le -c:a pcm_s16le DJI_0001_dnxhr.mov

For ProRes, -profile:v 3 is 422 HQ and -profile:v 2 is standard 422 if storage is tight.

6C. The grade is amplifying it

• Remove unnecessary sharpening. DJI already sharpens in camera, and additional sharpening directly increases the difference you are trying to hide.
• Normalise with a colour space transform rather than adding contrast through a creative LUT that was not designed for the job.
• Soften steep contrast curves. A surprising proportion of the visible effect often comes from the last part of the contrast you added.
• Grade in a wide gamut intermediate so you are not compounding expansions in a display-referred space.

6D. The delivery encode is introducing it

• Raise quality or bitrate and compare. Values in the region of 50 to 120 Mbps are reasonable test points for demanding 4K material. They are not thresholds: the requirement depends on resolution, frame rate, codec, content complexity and encoder implementation.
• Use quality-based rate control where the encoder offers it, rather than a low constant bitrate.
• Test a shorter keyframe interval if the encoder exposes it. This reduces the distance between intra-coded pictures, but it also changes compression efficiency and bitrate requirements, so measure rather than assume.
• Account for grain. Grain is expensive to encode and competes with real texture for the bit budget. Grain plus a low bitrate reliably produces this artifact.
• Keep an intra-frame master in ProRes or DNxHR and generate delivery encodes from it. This does not repair a source artifact, but it prevents an unnecessary extra long-GOP generation from becoming a new one.

Which tools require Resolve Studio

Picture type per frame, numbered

ffprobe -v error -select_streams v:0 \
  -show_entries frame=pict_type -of csv=p=0 DJI_0001.MP4 \
  | head -60 | cat -n

Keyframe timestamps only

ffprobe -v error -select_streams v:0 -skip_frame nokey \
  -show_entries frame=pts_time -of csv=p=0 DJI_0001.MP4 | head -20

Data per picture, as size,type

ffprobe -v error -select_streams v:0 \
  -show_entries frame=pkt_size,pict_type -of csv=p=0 DJI_0001.MP4 \
  | head -30 | cat -n

Stream summary: codec, profile, bit depth, frame rate

ffprobe -v error -select_streams v:0 -show_entries \
  stream=codec_name,profile,pix_fmt,bit_rate,r_frame_rate \
  -of default=noprint_wrappers=1 DJI_0001.MP4

Decode a frame range to PNG

ffmpeg -i DJI_0001.MP4 -vf "select=between(n\,100\,130)" \
  -fps_mode passthrough frame_%06d.png

Transcode to ProRes 422 HQ

ffmpeg -i DJI_0001.MP4 -c:v prores_ks -profile:v 3 \
  -pix_fmt yuv422p10le -c:a pcm_s16le DJI_0001_prores.mov

Transcode to DNxHR HQX

ffmpeg -i DJI_0001.MP4 -c:v dnxhd -profile:v dnxhr_hqx \
  -pix_fmt yuv422p10le -c:a pcm_s16le DJI_0001_dnxhr.mov

Batch a folder to ProRes

for f in *.MP4; do
  ffmpeg -i "$f" -c:v prores_ks -profile:v 3 \
    -pix_fmt yuv422p10le -c:a pcm_s16le "${f%.MP4}_prores.mov"
done

Interpreting the separation figure

• Above about 1.10 means the intra pictures carry measurably more high-frequency content, which is consistent with a coding-related cause. Corroborate it against Section 9 before concluding.
• Around 1.00 means picture type does not predict the effect in that range. Look elsewhere, and widen the range in case it contained too few intra pictures to be meaningful.
• Remember what is being measured. Noise, ringing and sharpening all raise this figure. It tests alignment, not quality.

#!/usr/bin/env python3
"""Test whether a visible pulse is aligned with picture type.

Usage:  python3 gop_pulse.py CLIP.MP4 [start_frame] [num_frames]
Needs:  ffmpeg and ffprobe on PATH, plus  pip install numpy pillow

Reports Laplacian variance per frame. A HIGH VALUE MEANS MORE HIGH-FREQUENCY
CONTENT, NOT MORE GENUINE DETAIL: noise, ringing and sharpening raise it too.
Use this to test alignment with picture type, never as a quality measure.
"""
import subprocess, sys, tempfile, pathlib
import numpy as np
from PIL import Image

clip  = sys.argv[1]
start = int(sys.argv[2]) if len(sys.argv) > 2 else 0
count = int(sys.argv[3]) if len(sys.argv) > 3 else 60
end   = start + count - 1

# Picture type of every frame, in presentation order.
probe = subprocess.run(
    ["ffprobe", "-v", "error", "-select_streams", "v:0",
     "-show_entries", "frame=pict_type", "-of", "csv=p=0", clip],
    capture_output=True, text=True, check=True)
types = [t.strip(",") for t in probe.stdout.split()]

# Decode the range with sequential numbering, so nothing depends on how the
# container stores timestamps.
tmp = pathlib.Path(tempfile.mkdtemp())
subprocess.run(
    ["ffmpeg", "-v", "error", "-i", clip,
     "-vf", f"select=between(n\\,{start}\\,{end})",
     "-fps_mode", "passthrough",
     str(tmp / "f_%06d.png")], check=True)

pngs = sorted(tmp.glob("f_*.png"))
if len(pngs) != count:
    sys.exit(f"Extracted {len(pngs)} frames but asked for {count}. The range "
             f"probably runs past the end of the clip, so frame numbering "
             f"would be wrong. Stopping rather than reporting bad numbers.")

K = np.array([[0, 1, 0], [1, -4, 1], [0, 1, 0]], dtype=np.float64)

def hf_energy(png):
    g = np.asarray(Image.open(png).convert("L"), dtype=np.float64)
    h, w = g.shape
    lap = sum(K[i, j] * g[i:h - 2 + i, j:w - 2 + j]
              for i in range(3) for j in range(3) if K[i, j])
    return lap.var()

rows = [(start + off, types[start + off] if start + off < len(types) else "?",
         hf_energy(p)) for off, p in enumerate(pngs)]

base = np.median([v for _, _, v in rows])
print(f"{'frame':>7}  {'type':<4}  {'hf energy':>10}  {'vs median':>9}")
for n, t, v in rows:
    bar = "#" * int(round(30 * v / (base * 1.5))) if base else ""
    print(f"{n:>7}  {t:<4}  {v:>10.1f}  {v / base:>8.2f}x  {bar}")

# The question that matters: does picture type predict the pulse?
i_vals = [v for _, t, v in rows if t == "I"]
o_vals = [v for _, t, v in rows if t != "I"]
print()
if not i_vals:
    print("No I-picture in this range. Widen it and run again.")
elif not o_vals:
    print("All-intra stream. Picture type cannot explain a pulse here.")
else:
    ratio = float(np.mean(i_vals) / np.mean(o_vals))
    print(f"I-pictures  n={len(i_vals):<3} mean {np.mean(i_vals):8.1f}")
    print(f"Others      n={len(o_vals):<3} mean {np.mean(o_vals):8.1f}")
    print(f"Separation  {ratio:.3f}x")
    if ratio > 1.10:
        print("I-pictures carry measurably more high-frequency content.")
        print("Consistent with a coding-related cause. Corroborate before concluding.")
    else:
        print("No clear separation by picture type across this range.")
        print("Look for another cause before calling this GOP pulsing.")

Example output

  frame  type   hf energy  vs median
     10  I          218.6      1.26x  #########################
     11  B          173.7      1.00x  ####################
     13  P          173.3      1.00x  ####################
     15  B          155.8      0.90x  ##################
     19  P          163.8      0.95x  ###################
     20  I          258.6      1.49x  ##############################

I-pictures  n=3   mean    249.1
Others      n=18  mean    172.3
Separation  1.446x
I-pictures carry measurably more high-frequency content.
Consistent with a coding-related cause. Corroborate before concluding.

Every FFmpeg and ffprobe command in this document was executed and its output checked. The chroma quantisation behaviour described in Section 3 follows the chroma QP derivation defined in H.264 and HEVC. Resolve edition requirements follow Blackmagic's published feature documentation. Figures drawn from controlled test encodes are labelled as such and should not be read as characteristic of any DJI product; measure your own file.