Odysee 16 GB upload limit vs a 1800-second Sume source

You will not hit Odysee's 16 GB cap with a clip that Sume can process. Odysee's file selection page says uploads are restricted to 16 GB. Sume video inspect, trim and audio detach all take sources up to 1800 seconds, and trim outputs are at most 900 seconds. Filling 16 GB in 1800 seconds would take an average of about 71 Mbps, which is far above the 8 Mbps that Odysee recommends.

So the useful question is not whether you will go over 16 GB. It is which of the other Odysee numbers you will meet first. The answer is the 8 Mbps recommendation, which is a viewer experience guideline on the encoding page, and then the audio codec rule.

The arithmetic

The arithmetic uses 1 GB as 1,000 MB and 1 MB as 8 megabits, so 16 GB is 128,000 megabits. Divided by 1800 seconds that is 71.1 Mbps. Divided by the 900 seconds of a maximum trim output it is 142.2 Mbps. The Odysee page does not say whether GB is decimal or binary, so the real figure may be a few percent higher.

Both numbers come from different sides. The 1800-second figure is the source limit that the Sume docs give for video inspect, video trim and audio detach, and the 16 GB figure is Odysee's. The table that follows is arithmetic on those two published numbers and nothing else, so you can redo it yourself.

Worked sizes for 1800 seconds

The table shows how large a 1800-second file is at several average bitrates. Only the last row gets near the cap.

For completeness, the same table at the 900-second trim output limit halves each size. At 8 Mbps a 900-second output is 0.9 GB, at 25 Mbps it is 2.8125 GB, and at 50 Mbps it is 5.625 GB. None of these is close to 16 GB either.

The takeaway is simple. Treat the Odysee size cap as a non-issue for clips prepared with Sume, and spend your effort on the codec and bitrate guidance that Odysee gives for playback quality.

What this means for planning

That shows where the real limit sits. The bitrate recommendation matters long before the size cap does. A file that stays near 8 Mbps is far from 16 GB at any length Sume can handle, while a file at 50 Mbps would already be unpleasant for viewers on a slow connection and is still under the cap.

If you plan a long programme, the opposite problem appears. Odysee is a place for long-form video, and Sume processes at most 1800 seconds per source. Anything longer than 30 minutes has to be cut into parts before Sume sees it.

There is a second use for the arithmetic. If you archive masters on Odysee, you can estimate storage by hours. At 8 Mbps one hour is 3,600 seconds times 8 megabits, which is 28,800 megabits or 3.6 GB. At 25 Mbps one hour is 11.25 GB. The cap would be hit by a single file only at around 1.4 hours at 25 Mbps. Those are your own numbers to compute, and Sume only sees the first 1800 seconds of any source, so for a long master you would work in parts.

Check both limits

The helper below turns a probe into a verdict for both numbers at once. It reads size_bytes and duration_seconds, and flags a file that is over 16 GB or over 8 Mbps.

CAP_BYTES = 16 * 1_000_000_000
MAX_MBPS = 8.0

def verdict(probe):
    size = probe["size_bytes"]
    secs = probe["duration_seconds"]
    mbps = size * 8 / secs / 1_000_000
    return {
        "under_16_gb": size <= CAP_BYTES,
        "under_8_mbps": mbps <= MAX_MBPS,
        "average_mbps": round(mbps, 2),
    }

print(verdict({"size_bytes": 1_650_000_000, "duration_seconds": 1800}))

Caveats

Two caveats. First, a probe's size_bytes can be null, so handle that case in real code rather than reading the key directly as the sample does. Second, the Odysee help pages carry no date, so check them again before you build a rule on top of the number.

A third caveat is that a clip longer than the Sume source limit cannot be probed or cut at all. The job refuses it with source_duration_exceeded, so a two-hour recording must be split by another tool before it gets here. Sume's role begins after that split.