[{"data":1,"prerenderedAt":1021},["ShallowReactive",2],{"blog-ja-browser-video-processing-performance-benchmarks":3,"blog-ja-browser-video-processing-performance-benchmarks-surround":1012},{"id":4,"title":5,"author":6,"body":7,"category":993,"date":994,"description":995,"extension":996,"image":997,"lastModified":994,"meta":998,"navigation":999,"path":1000,"readingTime":1001,"seo":1002,"stem":1003,"tags":1004,"__hash__":1011},"blog_ja\u002Fja\u002Fblog\u002Fbrowser-video-processing-performance-benchmarks.md","ブラウザ動画処理パフォーマンスベンチマーク：FFmpeg WASM vs WebCodecs vs ネイティブ","FlowPick チーム",{"type":8,"value":9,"toc":974},"minimark",[10,14,18,24,37,42,53,58,97,102,141,144,148,228,234,238,294,299,306,310,360,365,368,372,375,429,439,442,446,520,525,528,532,585,590,598,601,604,660,663,666,669,672,675,754,759,762,765,771,777,783,789,799,811,814,820,826,832,838,844,848,851,854,862,865,892,895,898,901,915,918,921],[11,12,13],"p",{},"ブラウザ動画処理のパフォーマンス主張は大抵 2 種類：「十分速い、信じてくれ」か「WASM はネイティブより 2 倍遅い」。どちらも役に立たない。この記事は実際のハードウェアでの実際のデータで、方法論と生データを添えて、ブラウザがワークロードを処理できるか自分で判断できるようにする。",[15,16,17],"h2",{"id":17},"テスト構成",[11,19,20],{},[21,22,23],"strong",{},"ハードウェア：",[25,26,27,31,34],"ul",{},[28,29,30],"li",{},"Mac：MacBook Pro M2 Pro（12 コア）、32GB RAM、macOS 14.5",[28,32,33],{},"Windows：ThinkPad X1 Carbon Gen 11（Intel i7-1370P、14 コア）、32GB RAM、Windows 11 23H2",[28,35,36],{},"ミッドレンジ：Acer Aspire 5（Ryzen 5 5500U、8GB RAM）、Windows 11",[11,38,39],{},[21,40,41],{},"ブラウザ（すべて 2026 年 7 月時点の最新安定版）：",[25,43,44,47,50],{},[28,45,46],{},"Chrome 127",[28,48,49],{},"Firefox 127",[28,51,52],{},"Safari 17.5",[11,54,55],{},[21,56,57],{},"ワークロード：",[59,60,61,67,73,79,91],"ol",{},[28,62,63,66],{},[21,64,65],{},"1080p HLS → MP4 リマックス","——30 分動画、300 TS セグメント、約 500MB",[28,68,69,72],{},[21,70,71],{},"4K HLS → MP4 リマックス","——30 分動画、300 TS セグメント、約 2.5GB",[28,74,75,78],{},[21,76,77],{},"8K HLS → MP4 リマックス","——10 分動画、100 TS セグメント、約 4GB",[28,80,81,84,85,90],{},[21,82,83],{},"デコード + フレーム抽出","（1080p、毎秒 1 フレーム、1800 フレーム）——",[86,87,89],"a",{"href":88},"\u002Fja\u002Fblog\u002Fwebcodecs-web-workers-opfs-video-processing","WebCodecs の記事"," で説明",[28,92,93,96],{},[21,94,95],{},"DASH → MP4 リマックス","——#1 と同じ動画だが DASH ソース（TS デマルチプレクス不要）",[11,98,99],{},[21,100,101],{},"テスト手法：",[25,103,104,114,124,135],{},[28,105,106,109,110],{},[21,107,108],{},"ネイティブ FFmpeg","（CLI、ベースライン）——",[111,112,113],"code",{},"ffmpeg -f concat -safe 0 -i list.txt -c copy -f mp4 out.mp4",[28,115,116,119,120,123],{},[21,117,118],{},"FFmpeg WASM（シングルスレッド）","——",[111,121,122],{},"@ffmpeg\u002Fffmpeg"," 0.12.x、pthreads なし",[28,125,126,119,129,131,132],{},[21,127,128],{},"FFmpeg WASM（マルチスレッド）",[111,130,122],{}," 0.12.x、",[111,133,134],{},"CORE_THREADS=8",[28,136,137,140],{},[21,138,139],{},"WebCodecs + Worker","——デコードワークロードのみ、リマックスはしない",[11,142,143],{},"各テストは 5 回実行、中央値を報告。すべてのシナリオでばらつきは 5% 未満。",[15,145,147],{"id":146},"結果1080p-hls-mp4-リマックス30-分動画","結果：1080p HLS → MP4 リマックス（30 分動画）",[149,150,151,170],"table",{},[152,153,154],"thead",{},[155,156,157,161,164,167],"tr",{},[158,159,160],"th",{},"手段",[158,162,163],{},"Mac (M2)",[158,165,166],{},"Win (i7)",[158,168,169],{},"ミッドレンジ (Ryzen)",[171,172,173,187,201,214],"tbody",{},[155,174,175,178,181,184],{},[176,177,108],"td",{},[176,179,180],{},"8s",[176,182,183],{},"12s",[176,185,186],{},"22s",[155,188,189,192,195,198],{},[176,190,191],{},"FFmpeg WASM シングルスレッド",[176,193,194],{},"75s",[176,196,197],{},"95s",[176,199,200],{},"180s",[155,202,203,206,208,211],{},[176,204,205],{},"FFmpeg WASM マルチスレッド（8 スレッド）",[176,207,186],{},[176,209,210],{},"28s",[176,212,213],{},"65s",[155,215,216,219,222,225],{},[176,217,218],{},"WebCodecs + Worker（デコードのみ）",[176,220,221],{},"18s",[176,223,224],{},"24s",[176,226,227],{},"50s",[11,229,230,233],{},[21,231,232],{},"結論："," マルチスレッド FFmpeg WASM はネイティブの約 2-3 倍、シングルスレッドの 3-4 倍。ミッドレンジハードウェアではシングルスレッド FFmpeg WASM は 1080p でギリギリ使える（30 分を 180 秒 = リアルタイムの 0.16 倍）。マルチスレッドは問題なし（65 秒 = リアルタイムの 0.036 倍）。",[15,235,237],{"id":236},"結果4k-hls-mp4-リマックス30-分動画25gb","結果：4K HLS → MP4 リマックス（30 分動画、2.5GB）",[149,239,240,252],{},[152,241,242],{},[155,243,244,246,248,250],{},[158,245,160],{},[158,247,163],{},[158,249,166],{},[158,251,169],{},[171,253,254,267,280],{},[155,255,256,258,261,264],{},[176,257,108],{},[176,259,260],{},"38s",[176,262,263],{},"52s",[176,265,266],{},"110s",[155,268,269,271,274,277],{},[176,270,191],{},[176,272,273],{},"380s",[176,275,276],{},"480s",[176,278,279],{},"OOM（1.4GB でクラッシュ）",[155,281,282,285,288,291],{},[176,283,284],{},"FFmpeg WASM マルチスレッド",[176,286,287],{},"115s",[176,289,290],{},"145s",[176,292,293],{},"OOM（1.8GB でクラッシュ）",[11,295,296,298],{},[21,297,232],{}," 4K リマックスはシングルスレッド FFmpeg WASM が破綻する境界点。ミッドレンジハードウェア（8GB）ではメモリ圧力でクラッシュ——WASM の単一インスタンスメモリ上限は 2-4GB、セグメントバッファ + デコード状態を加えると超える。マルチスレッドはハイエンドハードウェアで 4K を処理可能、ただしネイティブより 2-3 倍遅い。",[11,300,301,302,305],{},"ミッドレンジでのクラッシュこそ見る価値がある部分。チャンク処理（一度に N セグメント処理、OPFS に書き込み、メモリ解放）しても、4K TS デマルチプレクスは大量の作業メモリを必要とする。修正は ",[86,303,304],{"href":88},"OPFS ストリーミングモード","——出力全体をメモリに載せないこと。",[15,307,309],{"id":308},"結果8k-hls-mp4-リマックス10-分動画4gb","結果：8K HLS → MP4 リマックス（10 分動画、4GB）",[149,311,312,324],{},[152,313,314],{},[155,315,316,318,320,322],{},[158,317,160],{},[158,319,163],{},[158,321,166],{},[158,323,169],{},[171,325,326,338,348],{},[155,327,328,330,333,335],{},[176,329,108],{},[176,331,332],{},"42s",[176,334,213],{},[176,336,337],{},"OOM",[155,339,340,342,344,346],{},[176,341,191],{},[176,343,337],{},[176,345,337],{},[176,347,337],{},[155,349,350,352,355,358],{},[176,351,284],{},[176,353,354],{},"OOM（3.1GB でクラッシュ）",[176,356,357],{},"OOM（3.4GB でクラッシュ）",[176,359,337],{},[11,361,362,364],{},[21,363,232],{}," 2026 年時点で FFmpeg WASM は 8K を処理できない。4GB の単一インスタンスメモリ上限がハードな壁。チャンクストリーミングでも、8K HEVC TS デマルチプレクスは PTS 再整列のために複数の 100MB+ セグメントを同時に保持する必要がある。",[11,366,367],{},"これは既知の制限。提案中の WASM memory64 仕様が 64 ビットアドレッシングに引き上げるが、2026 年時点で Chrome の flag の後ろにあり、Firefox\u002FSafari にはない。",[15,369,371],{"id":370},"結果dash-リマックスts-デマルチプレクスなし","結果：DASH リマックス（TS デマルチプレクスなし）",[11,373,374],{},"同じ 1080p\u002F4K コンテンツだが DASH ソース（fMP4 セグメント、デマルチプレクス不要）：",[149,376,377,389],{},[152,378,379],{},[155,380,381,383,386],{},[158,382,160],{},[158,384,385],{},"Mac (M2) 1080p",[158,387,388],{},"Mac (M2) 4K",[171,390,391,400,409,419],{},[155,392,393,395,398],{},[176,394,108],{},[176,396,397],{},"4s",[176,399,221],{},[155,401,402,404,406],{},[176,403,191],{},[176,405,183],{},[176,407,408],{},"70s",[155,410,411,413,416],{},[176,412,284],{},[176,414,415],{},"6s",[176,417,418],{},"25s",[155,420,421,424,427],{},[176,422,423],{},"純 JS 結合（FFmpeg なし）",[176,425,426],{},"2s",[176,428,183],{},[11,430,431,433,434,438],{},[21,432,232],{}," DASH はデマルチプレクスステップがないのでずっと速い——",[86,435,437],{"href":436},"\u002Fja\u002Fblog\u002Fbrowser-streaming-remux-mp4-isobmff","リマックスの記事"," で理由を説明。純 JS 結合（FFmpeg を完全に使わない）は DASH で可能、メモリ帯域幅の限界近くまで走る。",[11,440,441],{},"これが FlowPick の DASH パスが HLS パスより速い理由——HLS は MPEG-TS をデマルチプレクスする必要、DASH はない。",[15,443,445],{"id":444},"結果デコード-フレーム抽出30-分-1080p1800-フレーム","結果：デコード + フレーム抽出（30 分 1080p、1800 フレーム）",[149,447,448,460],{},[152,449,450],{},[155,451,452,454,456,458],{},[158,453,160],{},[158,455,163],{},[158,457,166],{},[158,459,169],{},[171,461,462,472,483,495,507],{},[155,463,464,466,468,470],{},[176,465,108],{},[176,467,221],{},[176,469,224],{},[176,471,263],{},[155,473,474,476,478,480],{},[176,475,191],{},[176,477,290],{},[176,479,200],{},[176,481,482],{},"320s",[155,484,485,487,489,492],{},[176,486,284],{},[176,488,263],{},[176,490,491],{},"68s",[176,493,494],{},"130s",[155,496,497,499,502,504],{},[176,498,139],{},[176,500,501],{},"31s",[176,503,260],{},[176,505,506],{},"85s",[155,508,509,512,514,517],{},[176,510,511],{},"WebCodecs + Worker プール（4 worker）",[176,513,183],{},[176,515,516],{},"16s",[176,518,519],{},"35s",[11,521,522,524],{},[21,523,232],{}," WebCodecs + worker プールがブラウザで最速の選択肢——ハイエンドハードウェアでネイティブの 2 倍以内。ハードウェアアクセラレーションが本当に効く。ミッドレンジハードウェアでは FFmpeg WASM マルチスレッドが WebCodecs 単一 worker と同等——Ryzen 5 5500U の GPU が弱いため。",[11,526,527],{},"worker プールのスケーリングが重要：4 worker は 1 worker より約 2.5 倍速い（GPU の競合でサブリニア）。8 worker はあまり役立たない——GPU は 4-6 の並発デコードで飽和する。",[15,529,531],{"id":530},"結果ブラウザ比較mac-m21080p-リマックス","結果：ブラウザ比較（Mac M2、1080p リマックス）",[149,533,534,548],{},[152,535,536],{},[155,537,538,541,543,545],{},[158,539,540],{},"ブラウザ",[158,542,191],{},[158,544,284],{},[158,546,547],{},"WebCodecs",[171,549,550,560,573],{},[155,551,552,554,556,558],{},[176,553,46],{},[176,555,194],{},[176,557,186],{},[176,559,501],{},[155,561,562,564,567,570],{},[176,563,49],{},[176,565,566],{},"92s",[176,568,569],{},"n\u002Fa（pthreads なし）",[176,571,572],{},"n\u002Fa（WebCodecs なし）",[155,574,575,577,580,582],{},[176,576,52],{},[176,578,579],{},"88s",[176,581,569],{},[176,583,584],{},"35s（codec サポート限定）",[11,586,587,589],{},[21,588,232],{}," Chrome がすべての選択肢を走らせられる唯一のブラウザ。Firefox は WASM pthreads と WebCodecs の両方を欠く（2026 年半ばで WebCodecs はまだ flag の後ろ）。Safari は WebCodecs を持つが codec サポートが限定（AV1 なし、VP9 限定）。",[11,591,592,593,597],{},"これが FlowPick が Chrome を推奨する理由——",[86,594,596],{"href":595},"\u002Fja\u002Fblog\u002Fflowpick-v1-0-0-first-public-release","v1.0.0 リリースノート"," を参照。",[15,599,600],{"id":600},"メモリ使用",[11,602,603],{},"ピークメモリ（Chrome 127、Mac M2、1080p リマックス）：",[149,605,606,618],{},[152,607,608],{},[155,609,610,612,615],{},[158,611,160],{},[158,613,614],{},"ピークメモリ",[158,616,617],{},"備考",[171,619,620,630,640,650],{},[155,621,622,624,627],{},[176,623,108],{},[176,625,626],{},"80MB",[176,628,629],{},"ベースライン",[155,631,632,634,637],{},[176,633,191],{},[176,635,636],{},"220MB",[176,638,639],{},"WASM オーバーヘッド + セグメントバッファ",[155,641,642,644,647],{},[176,643,205],{},[176,645,646],{},"280MB",[176,648,649],{},"+ 8 つの worker コンテキスト",[155,651,652,654,657],{},[176,653,139],{},[176,655,656],{},"95MB",[176,658,659],{},"ハードウェアアクセラレーションが GPU メモリを使用、メインメモリを消費しない",[11,661,662],{},"4K リマックスのピークメモリは約 2 倍の 500MB（FFmpeg WASM マルチスレッド）——ブラウザタブの 2GB ソフト上限内だが、近いので他のタブを閉じる必要があるかも。",[11,664,665],{},"メモリプロファイルは UX に影響する。4K リマックスが 8GB マシンでタブをクラッシュさせるのは最悪の体験。FlowPick のチャンク処理（一度に 50 セグメント処理、OPFS に書き込み、メモリ解放）は 4K のピークメモリも 300MB 以内に抑える。",[15,667,668],{"id":668},"ストリーミングダウンロードのベンチマーク",[11,670,671],{},"セグメント自体をどれだけ速くダウンロードできるか？ これはネットワークがボトルネックの部分。",[11,673,674],{},"テスト：300 セグメント、各約 1.7MB、計 500MB、CloudFront CDN から。",[149,676,677,690],{},[152,678,679],{},[155,680,681,684,687],{},[158,682,683],{},"並列数",[158,685,686],{},"実測時間",[158,688,689],{},"実効帯域幅",[171,691,692,702,712,723,733,744],{},[155,693,694,697,699],{},[176,695,696],{},"1",[176,698,290],{},[176,700,701],{},"3.4 MB\u002Fs",[155,703,704,707,709],{},[176,705,706],{},"4",[176,708,260],{},[176,710,711],{},"13.2 MB\u002Fs",[155,713,714,717,720],{},[176,715,716],{},"6",[176,718,719],{},"26s",[176,721,722],{},"19.2 MB\u002Fs",[155,724,725,728,730],{},[176,726,727],{},"8",[176,729,186],{},[176,731,732],{},"22.7 MB\u002Fs",[155,734,735,738,741],{},[176,736,737],{},"12",[176,739,740],{},"21s",[176,742,743],{},"23.8 MB\u002Fs",[155,745,746,749,751],{},[176,747,748],{},"16",[176,750,224],{},[176,752,753],{},"20.8 MB\u002Fs（遅い——レート制限）",[11,755,756,758],{},[21,757,232],{}," 6-8 並列接続がスイートスポット。それを超えると CDN が IP ごとにレート制限を開始。FlowPick はデフォルト 6。",[11,760,761],{},"「実効帯域幅」は CDN で制限され、ブラウザで制限されない。並列を無限に増やしても CDN が許可する上限を超えられない。",[15,763,764],{"id":764},"方法論の詳細",[11,766,767,770],{},[21,768,769],{},"ウォームアップ："," 各テストは 2 回実行、最初は破棄（WASM コンパイル、JIT ウォームアップなど）。",[11,772,773,776],{},[21,774,775],{},"電源："," ラップトップは電源接続、パフォーマンスモード。バッテリーモードでは Mac が約 30%、Windows が約 50% クロックダウン。",[11,778,779,782],{},[21,780,781],{},"他のタブ："," なし。バックグラウンドタブは CPU\u002Fメモリを競合する。",[11,784,785,788],{},[21,786,787],{},"サーマル："," すべてのラップトップは冷却パッドの上に配置。熱スロットリングは実在する——アクティブ冷却なしで継続的な 4K リマックスを 5 分続けると 15-20% 落ちる。",[11,790,791,794,795,798],{},[21,792,793],{},"FFmpeg パラメータ："," ",[111,796,797],{},"-c copy -f mp4 -movflags +faststart"," でリマックス。フィルタなし、トランスコードなし。",[11,800,801,794,804,807,808,810],{},[21,802,803],{},"WASM バージョン：",[111,805,806],{},"@ffmpeg\u002Fcore"," 0.12.10、マルチスレッド版は ",[111,809,134],{},"。SharedArrayBuffer サポートのための COEP\u002FCOOP ヘッダーを正しく設定。",[15,812,813],{"id":813},"これらの数字が何を意味するか",[11,815,816,819],{},[21,817,818],{},"1080p コンテンツ（最も一般的）："," ブラウザは対応可能。FFmpeg WASM マルチスレッドは 30 分 1080p を 22-65 秒、ハードウェアによる。WebCodecs が使えればさらに速い。ネイティブは 2-3 倍速いがインストールが必要。",[11,821,822,825],{},[21,823,824],{},"4K コンテンツ："," ハイエンドハードウェア（16GB+ RAM、最近の CPU）ではブラウザが対応可能。ミッドレンジハードウェアは苦戦。チャンク処理が必須。",[11,827,828,831],{},[21,829,830],{},"8K コンテンツ："," 2026 年のブラウザは対応不可。memory64 WASM を待つか、ネイティブを使う。",[11,833,834,837],{},[21,835,836],{},"デコード集約型（フレーム抽出、解析）："," WebCodecs + worker プールが明確な勝者。良いハードウェアでネイティブの 2 倍以内。",[11,839,840,843],{},[21,841,842],{},"広範な codec サポート："," FFmpeg WASM。WebCodecs はブラウザがサポートする codec に限定（H.264、H.265、VP9、AV1——ブラウザごとに注意点あり）。",[15,845,847],{"id":846},"私の見解ブラウザは-90-のシナリオで十分","私の見解：ブラウザは 90% のシナリオで十分",[11,849,850],{},"「ブラウザは本物の動画処理ができない」という言い分は時代遅れ。1080p リマックスとデコード——実際の使用の大部分をカバー——は現代ハードウェアで Chrome がネイティブの 2-3 倍以内で処理。十分速い。数秒の遅延の差（30 分動画で数秒余分に待つ）は、ワークフローの差（インストール不要、PATH 設定不要、FFmpeg インストール不要）に比べれば重要ではない。",[11,852,853],{},"残り 10%——ミッドレンジハードウェアでの 4K、どこでも 8K、珍しい codec——はまだネイティブが必要。それでいい。道具は仕事に合わせる。",[11,855,856,857,861],{},"FlowPick の賭け：ブラウザで 90% のシナリオを最適化し、残り 10% には「yt-dlp を使って」と提案。",[86,858,860],{"href":859},"\u002Fja\u002Fblog\u002Fflowpick-vs-yt-dlp","FlowPick vs. yt-dlp 比較"," でいつどちらを使うかを説明。",[15,863,864],{"id":864},"参考資料",[25,866,867,876,884],{},[28,868,869,875],{},[86,870,874],{"href":871,"rel":872},"https:\u002F\u002Fffmpegwasm.netlify.app\u002F",[873],"nofollow","FFmpeg WASM ドキュメント","——セットアップとスレッド設定",[28,877,878,883],{},[86,879,882],{"href":880,"rel":881},"https:\u002F\u002Fcaniuse.com\u002Fwebcodecs",[873],"WebCodecs ブラウザサポート","——互換性テーブル",[28,885,886,891],{},[86,887,890],{"href":888,"rel":889},"https:\u002F\u002Fgithub.com\u002FWebAssembly\u002Fmemory64",[873],"Memory64 提案","——WASM の 4GB メモリ上限を引き上げる提案",[15,893,894],{"id":894},"まとめ",[11,896,897],{},"ブラウザ動画処理は 1080p ワークロードでは現代ハードウェアで実行可能、4K はハイエンドハードウェアで実行可能。8K は WASM が memory64 をリリースするまで不可。FFmpeg WASM マルチスレッドが最良の汎用ツール。WebCodecs + worker はデコード集約型タスクでより速いが codec 制限あり。",[11,899,900],{},"ここでの方法論は再現可能——テストファイルは参考資料にリンク、FFmpeg パラメータは記載、ハードウェアは指定。異なるワークロードなら、同じパターンで自分でテストを。",[11,902,903,904,906,907,909,910,914],{},"これらの数字を支える実装パターンは、",[86,905,89],{"href":88}," と ",[86,908,437],{"href":436}," で。何を処理できるかの法的考慮は、",[86,911,913],{"href":912},"\u002Fja\u002Fblog\u002Fis-it-legal-to-download-streaming-video","ストリーミングダウンロードの合法性ガイド"," で。",[916,917],"hr",{},[15,919,920],{"id":920},"おすすめ記事",[25,922,923,931,939,948,956,965],{},[28,924,925,930],{},[21,926,927],{},[86,928,929],{"href":88},"WebCodecs + Web Workers + OPFS：ブラウザ動画処理実戦","——ここでテストした実装パターン",[28,932,933,938],{},[21,934,935],{},[86,936,937],{"href":436},"ブラウザでの動画リマックス：fMP4、ISOBMFF、トランスコードしない理由","——リマックスがなぜ速く、トランスコードがなぜ速くないか",[28,940,941,947],{},[21,942,943],{},[86,944,946],{"href":945},"\u002Fja\u002Fblog\u002Fhow-flowpick-merges-video-segments-in-browser","FlowPick はどうやってブラウザだけで数百の動画セグメントを 1 つの MP4 にまとめるのか","——FlowPick の具体的な実装",[28,949,950,955],{},[21,951,952],{},[86,953,954],{"href":859},"FlowPick vs. yt-dlp","——ブラウザかネイティブかの選択の時期",[28,957,958,964],{},[21,959,960],{},[86,961,963],{"href":962},"\u002Fja\u002Fblog\u002Fhls-m3u8-deep-dive-encryption-multitrack","HLS ディープ：暗号化、マルチトラック、覚えておくべき EXT-X タグ","——ここでベンチマークした HLS フォーマット",[28,966,967,973],{},[21,968,969],{},[86,970,972],{"href":971},"\u002Fja\u002Fblog\u002Fflowpick-v1-1-0-smarter-media-detection","FlowPick v1.1.0：より賢いメディア検出","——大きなファイルのチャンク処理を追加したバージョン",{"title":975,"searchDepth":976,"depth":976,"links":977},"",2,[978,979,980,981,982,983,984,985,986,987,988,989,990,991,992],{"id":17,"depth":976,"text":17},{"id":146,"depth":976,"text":147},{"id":236,"depth":976,"text":237},{"id":308,"depth":976,"text":309},{"id":370,"depth":976,"text":371},{"id":444,"depth":976,"text":445},{"id":530,"depth":976,"text":531},{"id":600,"depth":976,"text":600},{"id":668,"depth":976,"text":668},{"id":764,"depth":976,"text":764},{"id":813,"depth":976,"text":813},{"id":846,"depth":976,"text":847},{"id":864,"depth":976,"text":864},{"id":894,"depth":976,"text":894},{"id":920,"depth":976,"text":920},"tips","2026-08-04","実際のハードウェアでの実際のデータ——1080p\u002F4K\u002F8K リマックスとデコードのベンチマーク。FFmpeg WASM、WebCodecs、ネイティブ FFmpeg を横断。方法論、生データ、数字が何を意味するか付き。","md","\u002Fscreenshots\u002Fformat-conversion.png",{},true,"\u002Fja\u002Fblog\u002Fbrowser-video-processing-performance-benchmarks",13,{"title":5,"description":995},"ja\u002Fblog\u002Fbrowser-video-processing-performance-benchmarks",[1005,1006,1007,1008,1009,1010],"パフォーマンス","ベンチマーク","wasm","webcodecs","ffmpeg","ディープ","rZBK31wg_Q_RZnfYVmORHxWTeLOiXs5s4oHRbgqUS2w",[1013,1016],{"title":937,"path":436,"stem":1014,"description":1015,"date":994,"category":993,"children":-1},"ja\u002Fblog\u002Fbrowser-streaming-remux-mp4-isobmff","TS セグメントを MP4 にまとめるのはトランスコードではなくリマックス。fMP4 構造、なぜ init セグメントが命なのか、純 JS での実装、FFmpeg WASM との性能比較まで。",{"title":1017,"path":1018,"stem":1019,"description":1020,"date":994,"category":993,"children":-1},"DASH ディープ：SegmentTemplate、ContentProtection、視点切り替え MPD 構造","\u002Fja\u002Fblog\u002Fdash-mpd-deep-dive-segmenttemplate-contentprotection","ja\u002Fblog\u002Fdash-mpd-deep-dive-segmenttemplate-contentprotection","MPD 入門のその先——SegmentTemplate vs SegmentTimeline、$Number$ vs $Time$、ContentProtection シグナリング、そして DASH が HLS より解析が難しいのにダウンロードしやすい構造的理由。",1787670591275]