Odysee 8 Mbps bitrate warning and Sume's missing bitrate field

Control the bitrate on Odysee by controlling resolution and frame rate, then measure the result. Odysee's encoding page says videos over 8 Mbps trigger a suggestion to transcode, and that if the bitrate is still too high after a 1080p at 30 FPS encode you should reduce to 720p. Sume video trim has no bitrate or crf field and refuses ffmpeg-style fields, but it does accept an output object with width, height and fps.

This is a workflow for a creator who wants the clip to play smoothly for viewers on slower connections. Odysee's page describes the 8 Mbps level as a recommendation for the best viewer experience, and it describes the transcoding suggestion as a message you may see, so it is guidance and not a hard refusal.

What 8 Mbps means in file size

The page frames 8 Mbps as a threshold for viewer buffering. A rate of 8 Mbps is one megabyte per second, so file size is easy to predict at the ceiling.

You can also read the table backward. If you want a file of at most 300 MB, then at 8 Mbps the clip can run about 300 seconds. That is a quick planning rule for deciding how long a segment can be before you cut it.

What Sume lets you set

The Sume docs state the rules for the output object. It works with exact precision only, so keyframe precision with an output object is refused with video_trim_output_requires_exact. Width and height must be between 256 and 2160, and fps must be 24, 25, 30 or 60. If you do not send output, the result keeps the source values.

The docs describe output as a conform and do not say how a source with a different aspect ratio is handled. So send a width and height that match the source aspect ratio, for example 1280 by 720 for a 16:9 source, and look at the probe afterward.

A frame-rate change deserves one more sentence. Dropping from 60 to 30 fps removes half the frames, and the encoder spends fewer bits on the clip as a result, but motion looks less smooth. For screen recordings and talking heads, 30 fps is normally fine. For fast gameplay or sports, test first, since the loss is visible.

Resolution is the bigger lever. A 1280 by 720 frame has less than half the pixels of 1920 by 1080, which is why Odysee's page names 720p as the step down.

A measure-and-step-down loop

Take Odysee's own order of steps. First encode at 1080p and 30 fps. Probe the result and compute the average. If it is over 8 Mbps, try 1280 by 720, and probe again. Dropping from 60 to 30 fps is the other lever, and for a clip that was rendered at 24 fps, keeping 24 avoids resampling and saves bytes.

The check below reads size_bytes and duration_seconds from a probe and flags anything over 8 Mbps.

MAX_MBPS = 8.0

def average_mbps(probe):
    size = probe.get("size_bytes")
    secs = probe.get("duration_seconds")
    if size is None or not secs:
        return None
    return size * 8 / secs / 1_000_000

def advice(probe):
    mbps = average_mbps(probe)
    if mbps is None:
        return "probe is missing size or duration"
    if mbps <= MAX_MBPS:
        return "ok at %.2f Mbps" % mbps
    return "%.2f Mbps: try 1280x720 or a lower fps" % mbps

print(advice({"size_bytes": 95_000_000, "duration_seconds": 120}))
print(advice({"size_bytes": 60_000_000, "duration_seconds": 120}))

Limits of this approach

The average includes audio, so the video share is a little lower than the number you compute. A probe average also hides peaks, and Odysee does not say whether it judges the average or the peak. Treat 8 Mbps as a target with margin, and aim a little under it.

Each trim attempt is a $0.02 job at the public rate, so a three-step loop is a few cents. That price is in the docs, and you can confirm it in the catalog.

Also remember that trim re-encodes only on exact precision, and each re-encode of an already compressed file loses a little quality. If you plan several attempts, always trim from the original imported source and not from the previous result. The source never changes, since every job writes a new artifact, so the original stays available for the next attempt.

A second limit is that a probe reports the file as it is. Odysee may transcode the upload itself, and the page does not describe what it does with a file that is under the threshold, so the viewer-side result is outside what Sume can show you.