Orux AI / モデルノート
Kling v3の動画をフレーム監査:5秒枠の取り込み計画
既存のKling v3動画を調べ、24 fps・121フレーム・5.041667秒を確認。Pythonで全時刻CSVと120フレームの編集案を作り、実際の編集や過去の請求とは区別します。

目次
5秒の編集枠を確定する前に、デコードしたフレームを調べる
Kling v3の動画を、24 fpsで正確に120フレームのタイムライン枠へ配置するには、「5秒で生成を依頼した」という情報だけでは不十分です。 実際に納品されたファイルを確認してください。この記事で分析したOruxの既存ハーモニカリード作例は、リクエスト上の長さが5秒ですが、保存済みMP4には24 fpsで121枚のデコード済み映像フレームがあり、報告される長さは5.041667秒です。これは編集で判断すべき境界の問題であり、この情報だけで生成の失敗や誤請求が分かるわけではありません。
機械の細部を映すインサートを組み込む編集者にとって、役立つ成果物はフレーム番号付きの取り込みレポートです。以下のPythonサンプルは、全フレームのタイムスタンプCSVと編集案を出力します。5秒枠には0始まりのフレーム0–119を使い、フレーム120は別途確認するという案です。動画の変更や書き出しは行いません。元動画も以下に掲載しているので、タイミングだけでなく実際に見える動きも判断できます。

元動画の実際のフレーム72で、表示時刻は3.000000秒です。既存のモデル作例から抽出したもので、新たに生成した画像ではありません。
実際のKling v3作例と保存されている設定
素材はOruxのKling v3モデルページにある作例です。保存された動画は、銅製のハーモニカリードとピンセットの動きを極端なクローズアップで描いています。元のプロンプトをそのまま掲載します。
维修者用细镊子轻拨一片铜簧片,簧片短暂振动后静止,超近距单镜头。
読者向けの訳:「修理する人が細いピンセットで銅製のリードを軽くはじく。リードは短く振動した後に静止する。極端なクローズアップのワンショット。」これは保存された入力を説明する訳であり、新たな生成に使った別のプロンプトではありません。
保存設定はduration: 5、aspect_ratio: "16:9"、mode: "std"、sound: "off"、kling_v3_type: "t2v"です。この作例には参照画像入力が記録されていません。画像から動画への生成で元画像を保持できることを実証したテストとして説明してはいけません。この記事のための新しいモデルリクエストは行っていません。
stdモード、音声オフ、5秒指定で依頼された、保存済みの元のKling v3作例です。今回調べたファイルは24 fpsで121フレームあり、この記事のために新たに生成したものではありません。
2026年11月3日に確認した現在の公開フォームでは、長さ3–15秒、縦横比16:9・9:16・1:1、std/proモード、音声オン/オフを選べます。これは確認済みのOrux連携で提供される選択肢です。この分析では、追加のネイティブモデル設定を推定したり、別のモードを選べば見える動きが直ると主張したりはしません。
6枚のサンプルフレームから分かること、分からないこと
元動画は1,280 × 720で、調べたファイルには音声ストリームがありません。保存されている音声オフ設定と一致します。サンプル時点では、指、ピンセット、リードを近接して映す構図が続いています。3秒付近では、接触部分の周辺でリードの見た目の形が変わり、それより後のサンプルフレームでは、ピンセットがその接触位置から引き戻されています。
こうした観察は、編集上どこに動きを置くかを判断するのに役立ちます。ただし、実物のリードの振動数を測定したり、機械的な正確さを証明したり、すべての中間フレームに破綻がないことを確認したりはできません。1秒に1枚の静止画では、高速な振動の周期は分かりません。説明用のインサート以上の用途に使う前に、元動画を視聴し、関連する中間フレームを確認してください。
| 元動画のフレーム番号(0始まり) | 表示時刻 | そのサンプル時点での編集上の観察 |
|---|---|---|
| 0 | 0.000000 s | クローズアップの構図と、リード近くの指・道具を示す |
| 24 | 1.000000 s | 道具はリードの近くにあり、作業箇所が引き続き見える |
| 48 | 2.000000 s | より大きな見た目の姿勢変化の前に、接触部分を確認するもう1枚 |
| 72 | 3.000000 s | 接触箇所付近でリードが幅広く、または持ち上がったように見える |
| 96 | 4.000000 s | 道具が3秒時点の接触位置から引き戻されている |
| 120 | 5.000000 s | 最後のサンプルフレームが5秒の境界から始まる |
横にスワイプすると表全体を確認できます。

記録された表示時刻における元動画のフレーム0、24、48、72、96、120です。各フレームの構図全体を示し、ラベルと一覧用の配置はローカルで追加しています。
別の視覚的な判断については、Kling 4.0の同一プロンプトによるショット比較で、既存テイクから選ぶ方法を説明しています。この記事で扱う保存済みテイクは1本だけで、問いは実際のフレーム時刻をどう編集枠に合わせるかです。どちらの記事も、少数の観察をモデル全体の信頼性スコアへ置き換えるものではありません。
最終フレームのタイムスタンプと動画の長さを区別する
正確に24 fpsなら、1フレームの間隔は1/24秒、約0.041667秒です。5秒の枠は120フレーム分の間隔を含みます。0始まりの番号を使い、元動画が時刻0から始まる場合、フレームの開始時刻は0、1/24、2/24と続き、119/24、つまり4.958333秒までとなります。
次のフレーム、番号120は5.000000秒から始まります。このフレームもさらに1間隔分含めると、長さは121/24、約5.041667秒になります。そのため、最後の表示タイムスタンプと報告される動画の長さが違っていても矛盾しません。通常、半開区間[0, 5)で表すタイムライン枠には、ちょうど5秒から始まるフレームを含めません。
この監査では、平均フレームレートの表示に単純に掛け算をするのではなく、実際の表示タイムスタンプを確認します。今回返された小数点以下6桁のタイムスタンプ表現を考慮し、デコードした各タイムスタンプが、想定する24 fpsのグリッドから2マイクロ秒以内に収まることを確かめます。この許容値は、このサンプルの解析確認用であり、知覚的な品質の基準ではありません。
可変フレームレートのファイルや23.976 fpsのプロジェクトに、同じ計算を無条件に適用しないでください。これらには異なるタイミング方針が必要です。コードは、平均レートが異なる場合や、一定レートという前提に合わないタイムスタンプ列を意図的に拒否します。出力は範囲を絞った取り込み計画であり、フレームレートを自動変換するツールではありません。
リクエスト設定の予算とファイル監査を分ける
以下の現在のOrux料金は、2026年11月3日に確認しました。設定されている換算は1 Credit = USD 0.005です。各モードと音声設定で生成する1秒あたりの金額を示します。5秒の列は新規リクエスト用の計算上の予算であり、この保存済み作例に対する過去の請求額ではありません。
| Kling v3設定 | 現在のOrux料金/秒 | 5秒リクエストの計画額 |
|---|---|---|
std、音声オフ — 保存済み作例の設定 | 16.00008 Credits (USD 0.0800004) | 80.0004 Credits (USD 0.400002) |
pro、音声オフ | 21.33336 Credits (USD 0.1066668) | 106.6668 Credits (USD 0.533334) |
std、音声オン | 24.00024 Credits (USD 0.1200012) | 120.0012 Credits (USD 0.600006) |
pro、音声オン | 32.00016 Credits (USD 0.1600008) | 160.0008 Credits (USD 0.800004) |
横にスワイプすると表全体を確認できます。
この記事では新たな生成料金は発生していません。既存のローカルファイルを調べ、CSVを書き出し、残すフレームを判断する作業に、モデルの再呼び出しは不要です。また、1フレームを編集で除いたからといって返金が成立したり、過去の生成料金が変わったりするわけではありません。元の作例の請求明細は使用していないため、5.041667秒というファイルメタデータを、課金された秒数の証拠として提示してはいけません。
新しい創作方針が必要な場合は、別のテイクを依頼する前に現在の設定とアカウント向け見積もりを確認します。それ以外は使える結果なのに、正確な枠へ合わせることだけが課題なら、まずタイムライン上の判断を解決してください。連携の詳細はOrux APIドキュメントを参照してください。この作業はAPIのポーリングや再試行処理ではなく、納品ファイルを扱います。
フレームを監査し、元ファイルを保持する
FFmpegをインストールして、コマンドラインからffprobeを使えるようにし、Python 3.9以降を利用してください。ffprobeの公式ドキュメントには、ストリーム調査、デコード済みフレームの集計、フレームごとの情報について説明があります。プログラムが使うのは、ローカルのffprobe実行ファイルとPython標準ライブラリだけです。
埋め込みプレーヤーまたはモデルページから既存動画をsource.mp4として保存し、次のコードをaudit_clip.pyとして保存します。書き込み可能なディレクトリでpython3 audit_clip.py source.mp4を実行してください。動画はサイトの通常のアクセス手順で取得してください。サイトが想定するリクエストの文脈を付けずに直接ダウンロードすると、CDNにアクセスを拒否される場合があります。プログラム自体はメディアをダウンロードせず、モデル用エンドポイントへ接続せず、APIキーも使いません。
import csv
import hashlib
import json
import subprocess
import sys
from decimal import Decimal
from fractions import Fraction
from pathlib import Path
EXPECTED_SHA = '5c948c89baf54c46c85afe65c33636bebb8a6a79acc22eebcce2412aef3e5515'
SOURCE = Path(sys.argv[1] if len(sys.argv) > 1 else 'source.mp4')
TARGET_RATE = Fraction(24, 1)
TARGET_SECONDS = 5
def probe(*args):
command = ['ffprobe', '-v', 'error', *args, '-of', 'json', str(SOURCE)]
return json.loads(subprocess.run(command, check=True, capture_output=True, text=True).stdout)
def audit_timestamps(times, rate):
if not times or rate <= 0:
raise ValueError('missing frames or invalid rate')
origin = times[0]
for index, timestamp in enumerate(times):
expected = origin + Decimal(index * rate.denominator) / rate.numerator
if abs(timestamp - expected) > Decimal('0.000002'):
raise ValueError('timestamps do not match the assumed constant rate')
def main():
if hashlib.sha256(SOURCE.read_bytes()).hexdigest() != EXPECTED_SHA:
raise ValueError('sample changed; inspect the new file before auditing')
info = probe('-count_frames', '-show_entries',
'stream=index,codec_type,width,height,avg_frame_rate,nb_read_frames:format=duration')
video = next(s for s in info['streams'] if s['codec_type'] == 'video')
rate = Fraction(video['avg_frame_rate'])
if rate != TARGET_RATE:
raise ValueError('this example expects an exact 24 fps source')
raw = probe('-select_streams', 'v:0', '-show_frames', '-show_entries',
'frame=best_effort_timestamp_time')['frames']
times = [Decimal(row['best_effort_timestamp_time']) for row in raw]
audit_timestamps(times, rate)
if int(video['nb_read_frames']) != len(times):
raise ValueError('decoded frame counts disagree')
target_count = TARGET_SECONDS * TARGET_RATE.numerator // TARGET_RATE.denominator
if len(times) < target_count:
raise ValueError('source is shorter than the target slot')
with Path('frame-times.csv').open('w', newline='') as handle:
writer = csv.writer(handle)
writer.writerow(['zero_based_frame', 'presentation_seconds'])
writer.writerows((i, str(t)) for i, t in enumerate(times))
plan = {
'width': video['width'], 'height': video['height'],
'source_rate': str(rate), 'decoded_frames': len(times),
'container_seconds': info['format']['duration'],
'last_presentation_seconds': str(times[-1]),
'audio_streams': sum(s['codec_type'] == 'audio' for s in info['streams']),
'target_frames': target_count, 'keep_frames_inclusive': [0, target_count - 1],
'last_kept_presentation_seconds': str(times[target_count - 1]),
'frames_outside_slot': len(times) - target_count,
'edit_applied': False,
}
Path('edit-plan.json').write_text(json.dumps(plan, indent=2) + '\n')
print(json.dumps(plan, indent=2))
if __name__ == '__main__':
main()実行結果はdecoded_frames: 121、target_frames: 120、keep_frames_inclusive: [0, 119]、frames_outside_slot: 1、last_kept_presentation_seconds: "4.958333"、edit_applied: falseでした。生成したCSVにはヘッダーに加えて121行のデータがあります。レポートには、1,280 × 720の寸法と音声ストリーム0本も記録します。
元のMP4、ハッシュ、タイムスタンプCSV、編集案をまとめて保管してください。固定したハッシュは、この再現用サンプルの対象を調査済みファイルに意図的に限定しています。別の利用許可された素材を使う場合は、そのファイルを調べ、想定するハッシュとタイミングの前提を明示的に更新します。合格させるためだけに確認を取り除いてはいけません。このコードはフレームごとのメタデータをメモリに読み込みます。短いクリップ用に設計しており、長尺メディアのアーカイブ処理向けではありません。
編集上の判断を明確にする
このサンプルには、妥当な判断が2つあります。前後のシーケンスに約5.041667秒を置く余裕があるなら、121フレームの元動画全体を残す方法。もう1つは、正確に120フレームの枠に向けてフレーム0–119を提案する方法です。今回は後者の計画を生成しています。トリミング済みの書き出し動画は提供しておらず、作成したとも主張していません。
編集ソフトでこの案を適用する前に、元動画のフレーム119と120、その前後の動き全体を確認してください。選んだアウト点で、意味のある最後の姿勢を失わないか、意図しない飛びが生じないか、隣接ショットとの整合性を損なわないかを確かめます。動きが落ち着いた状態をもっと長く見せる必要があるなら、そもそも5秒という枠が創作上の条件として合わない場合もあります。フレーム数の確認で、その芸術的な判断を代わりに行うことはできません。
自分の作業で編集や書き出しを行った後は、新しいファイルをもう一度調べてください。元ファイルのレポートは、後の書き出しのタイミング、音声、画質を保証しません。ここで得られる実用的な成果は、監査可能な引き継ぎ資料です。特定済みの元ファイル、測定したタイムスタンプ、明示されたフレーム範囲案を揃え、創作上の確認、タイムラインの長さ、生成費用を区別します。
FAQ
5秒のリクエストなら、必ず121フレームが返りますか?
一般的なルールは示していません。今回の保存済みKling v3ファイルには、24 fpsで121枚のデコード済みフレームがあります。このサンプルの境界の振る舞いをモデル全体の保証とせず、納品ファイルごとに調べてください。
この例では、どのフレームが正確な5秒枠に入りますか?
指定した24 fps、120フレームの枠に入るのは、フレーム0から119です。フレーム119は4.958333秒、フレーム120は5.000000秒に始まるため、後者は[0, 5)の外側です。コードはこの範囲を提案しますが、編集は適用しません。
余分な1フレームは、追加時間の請求を証明しますか?
いいえ。ファイルの長さだけでは、課金の基準や過去の請求額は分かりません。価格表は、特定日時のリクエスト設定に基づく計画計算です。保存済み作例の請求明細は確認していません。
フレーム一覧から、リードが正しく振動していると証明できますか?
いいえ。一覧で示すのは選んだ時点の形と道具の位置であり、測定した物理的な振動ではありません。編集に適するかは元動画の動きで確認し、この生成動画を機械的な正確さの証拠にはしないでください。
監査で動画を生成・変更しましたか?
いいえ。既存のMP4を調べ、タイムスタンプCSVと編集案のJSONを書き出しました。有料のモデル呼び出しは行っておらず、トリミング済み動画、フレームレート変換、新しい音声も提供していません。
1 つの API でこれらのモデルを利用
チャット・画像・動画・音声モデルに対応した OpenAI 互換 API。Credits で従量課金です。
関連記事
すべての記事を見る →
低価格の動画API比較:Vidu・Wan・Kling・Seedance
2026年10月29日の候補を対象に、動画APIの秒単価・クリップ費用・入力条件を比較。Pythonの一括生成例と既存動画を載せ、Oruxが高い場合、falと公式の確認日、画像入力・音声・長さの違い、丸め誤差、ID再開と一時リンクの限界まで説明します。公式価格との比較条件も明示します。

Kling 4.0 API:料金・設定・再開コードと動画例
Kling 4.0のOrux秒単価とクリップ費用を、直接確認したfal料金と比較。全パラメーター、ID保存で再開するPython、同一プロンプトの既存動画2本を掲載し、参照画像・被写体・音声・長さの上限、復旧コードの限界、成功した再試行への課金まで明示します。価格確認日も併記します。

FLUX.2 Proの画像をA4観察ワークシートに配置する
既存のFLUX.2 Proのキツネ作例を使い、PythonでA4観察ワークシートを作成。画像を伸ばさず、質問を別途組版し、実効解像度と再利用費用を確認します。