Same model across sites: pHash, GD, and stream history

A performer can broadcast on two or three platforms at the same time, using a completely different username on each. Name search cannot solve that case, while manually comparing screenshots does not scale to a large catalog. There is a simpler, inexpensive approach: use a perceptual hash (pHash) to find visually similar frames, then check whether the streams repeatedly start and end at similar times. No facial recognition, AI image API, or GPU is required.

Here is how the technique works, using real 16-character hashes, their distances, stream histories, and observed processing costs. The goal is a method other webmasters can reproduce, not a description of any particular site's private infrastructure.

Why usernames are not enough

anna_live and anna-live are easy to normalize. A search can also tolerate a typo or a few digits at the end. But how would a name matcher connect hottdoll611 on Chaturbate with Carrie1337 on BongaCams? Their names provide no useful clue.

Similar names are not proof, either: popular aliases are reused. It helps to separate the task into two stages. An image suggests a candidate; repeated stream timing supports or rejects the match. One screenshot should never be enough, particularly if it contains a blank screen or a generic placeholder.

What GD does, and what pHash does

In PHP, the GD extension can decode JPEG, WebP, or PNG files, resize them, and read pixel values. That is a convenient first stage, but GD does not calculate pHash by itself. You must implement the fingerprinting step or use a library implementing the same algorithm.

One common pHash pipeline looks like this:

1. Load the frame with GD, normalize its orientation, and resize it to 32 × 32 pixels.
2. Convert it to grayscale, using the same luminance calculation for every image.
3. Apply the discrete cosine transform (DCT), which captures broad changes in brightness rather than exact pixel values.
4. Take the low-frequency 8 × 8 region of the DCT coefficients. Compare coefficients with their median and encode the 64 comparisons as bits in a fixed order. Decide how to handle the zero-frequency (DC) coefficient consistently: libraries differ here.
5. Store the 64-bit fingerprint as 16 hexadecimal characters, such as f8949667272fc82a.

The result describes the image's overall composition, not its bytes. Different sizes, compression settings, or small platform overlays may still produce nearby fingerprints. A major pose or crop change can increase the distance considerably. pHash is not facial recognition, and it does not establish a person's identity.

Calculate the fingerprint once when a frame is saved. The matching process can then work with short values instead of opening thousands of images again.

A real pair: different names, the same room

Consider hottdoll611 on Chaturbate and Carrie1337 on BongaCams. Their saved frames show matching details: a black office chair, colorful binders on a shelf, a gold heart balloon, a red star, a white blouse, and a pink skirt. The platforms use different framing, and the screenshots were not taken at precisely the same moment.

Two frame pairs were preserved:

The second pair was captured around 5 minutes 23 seconds apart. Its low distance suggests that these profiles deserve closer examination. Why 10 in the first row and 6 in the second? pHash represents the arrangement of the image, so even a small pose or camera change alters some bits. Look for nearby hashes, not just identical ones.

• 6 of 64 bits
• 38 matching sessions

MATCH

The two frames are not the same picture, pixel for pixel. The camera and the pose have shifted a little. pHash still sees a similar frame structure, and the broadcast history adds the confirmation.

Calculating the distance of 6

Hamming distance counts the bits at which two fingerprints disagree. XOR the values, then count the set bits. For the second pair above, that count is 6.

In PHP, you can compare two 16-character hex strings without casting a potentially signed 64-bit value to int:

function hammingHex(string $a, string $b): int
{
    if (!preg_match('/^[0-9a-f]{16}$/i', $a) ||
        !preg_match('/^[0-9a-f]{16}$/i', $b)) {
        throw new InvalidArgumentException('Expected two 64-bit hex hashes');
    }

    $ones = [0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4];
    $distance = 0;

    for ($i = 0; $i < 16; $i++) {
        $distance += $ones[hexdec($a[$i]) ^ hexdec($b[$i])];
    }

    return $distance;
}

// 6
hammingHex('f8949667272fc82a', 'f094d6e7662ec82a');

Smaller means visually closer. There is no universally safe cutoff: calibrate it on your own screenshots, including false positives. Only compare hashes generated with the same grayscale conversion, DCT convention, coefficient selection, and bit order.

Why a similar screenshot is only half the evidence

A black frame may produce the pHash 0000000000000000. Completely unrelated blank streams can have exactly the same fingerprint. A distance of 0 then proves image similarity, not a common performer. Generic holding screens and matching room layouts can create similar false positives.

That is why the next step is stream history. Someone simulcasting to two platforms will often start and finish both broadcasts at roughly similar times. They need not match down to the second: sites can connect more slowly, report an end late, or temporarily lose the stream.

A reproducible starting point is to save each platform's started_at and ended_at intervals, then match two sessions when both the starts and the ends are sufficiently close—for example, within 30 minutes. This is an illustrative initial setting, not a magic threshold. Matching start times alone is weaker evidence. Also enforce one-to-one matching: a single session on platform A must not count as confirmation of several sessions on platform B.

Then examine several weeks, not one evening. Count matching sessions, the number of different days on which they occurred, and the proportion of each profile's broadcasts that matched. A newly created account may simply lack enough history; that is uncertainty, not a negative result.

What the history revealed

For hottdoll611 and Carrie1337, there were 38 corresponding broadcast sessions. Within the observed period, those represented 57.6% of one profile's sessions and 27% of the other's. The percentages differ because the accounts did not necessarily broadcast equally often or simultaneously every time.

Together, the signals are considerably stronger than one image: the same distinctive setting, a pHash distance of 6 out of 64, screenshots just over five minutes apart, and dozens of broadcasts with similar start and end times. Their usernames would not have helped.

A second example is your_wild_lexi on Chaturbate and AlexisGrays on BongaCams. Their fingerprints, d64ff814856fc286 and c64ff814876dc28e, differ by just 4 bits, with 13 corresponding sessions in the observed history.

When similar frames do not mean the profiles match

pHash is a fast way to find images worth comparing. But even a small distance between fingerprints does not prove that two profiles belong to the same performer. Dark frames, standard holding screens, and streams with similar lighting or backgrounds can all look deceptively alike.

One instructive case involved EthanLowell on Xlove and Laena_Castillo on Amateur.tv. The pHash distance between their frames was 10 out of 64 bits. That made the pair worth investigating, but the broadcast histories did not support a link.

Across the available records, only two streaming sessions aligned in time — 4.8% of one profile's history and 2% of the other's. Most broadcasts started and ended independently. An early version of the rules accepted the pair because the schedule check was too permissive. Under stricter rules, this evidence should not be enough to merge the profiles automatically.

• 10 of 64 bits
• 2 matching sessions
• 4.8% and 2%

NO MATCH

NO MATCH: insufficient evidence to link the profiles. This is an algorithmic decision, not proof that the accounts necessarily belong to different people. For an aggregator, keeping an uncertain pair separate is safer than mixing two profiles' histories, schedules, and other data by mistake.

Compare that with hottdoll611 on Chaturbate and Carrie1337 on BongaCams. Their selected frames had a distance of 6 out of 64 bits, and the recorded histories contained 38 corresponding streaming sessions. Two different signals support the match: similar imagery and a repeated pattern of overlapping broadcasts.

The lesson: pHash finds candidates at very low computational cost. Comparing stream start and end times helps decide which candidates are credible matches. Hamming distance is not a “probability of a match,” and the share of rejected candidates is not a measured false-positive rate.

Search efficiently instead of comparing everything

Comparing every image with every other image quickly becomes wasteful. With 7,000 frames, there are almost 24.5 million unordered pairs before any stream history checks. Even if that is manageable once, repeating it continuously is unnecessary.

Several straightforward optimizations provide a larger improvement than moving the task to a GPU:

1. Compare only recent frames from different platforms, not every image ever collected.
2. Calculate and store pHash when each frame is ingested.
3. Split the 64-bit fingerprint into smaller blocks and initially look for a matching block. Only calculate the full Hamming distance for candidates. Choose the number of blocks together with the permitted distance; an incorrect combination can miss genuine matches.
4. Fetch stream histories only for image candidates, not for the entire catalog.
5. Cache the results and avoid writing duplicate links for profiles already associated.

In one observed run, the matcher processed approximately 6,000–7,500 recent hashes, with only 9–22 candidate pairs proceeding to the history check. The entire run took 3–5 seconds and about 39–45 MB of memory. These are measurements of one workload, not universal performance guarantees.

Why this is cheaper than AI-based image matching

You do not have to send every screenshot to an AI vision service, pay per image, or maintain a GPU just to produce candidate pairs. GD processes ordinary images on the CPU, pHash reduces them to 64 bits, and distance checks are simple operations. Session timestamps are data an aggregator may already collect.

The method is not literally free: images must be stored, hashes computed, events recorded, empty frames filtered out, and uncertain candidates reviewed. But the main computational cost is small and predictable. AI might still help with difficult edge cases; it is not required for high-volume candidate discovery.

Results from one matching run

On November 10, 2026, one run found 17 high-confidence pairs on different platforms. Nine could also have been found from similar usernames. Another two had recognizable names but were in different catalog categories. Six pairs could not have been found by username alone.

This is neither an accuracy percentage nor an estimate of all duplicates across the internet. It is a snapshot showing why the additional signal matters: combining images with repeated broadcast schedules finds connections that name search misses.

For another webmaster, the practical starting point is straightforward: save screenshots periodically, calculate a consistent 64-bit pHash, record stream start/end events, then add efficient candidate filtering and conservative confirmation using repeated sessions. Never merge profiles on one similar screenshot alone. A false merge of two unrelated performers is usually worse than leaving one duplicate unresolved.

On Cloud9Cams, these connections help visitors discover a familiar performer on another platform even when the username changes. The broader method works for any catalog where the same subject appears across sources and both images and activity times can be compared.