[{"data":1,"prerenderedAt":1029},["ShallowReactive",2],{"blog-ko-browser-video-processing-performance-benchmarks":3,"blog-ko-browser-video-processing-performance-benchmarks-surround":1019},{"id":4,"title":5,"author":6,"body":7,"category":1000,"date":1001,"description":1002,"extension":1003,"image":1004,"lastModified":1001,"meta":1005,"navigation":1006,"path":1007,"readingTime":1008,"seo":1009,"stem":1010,"tags":1011,"__hash__":1018},"blog_ko\u002Fko\u002Fblog\u002Fbrowser-video-processing-performance-benchmarks.md","브라우저 비디오 처리 성능 벤치마크: FFmpeg WASM vs WebCodecs vs 네이티브","FlowPick 팀",{"type":8,"value":9,"toc":981},"minimark",[10,14,19,25,38,43,54,59,98,103,142,145,149,229,235,239,295,300,307,311,361,366,369,373,376,430,440,443,447,521,526,529,533,586,591,599,603,606,662,665,668,672,675,678,757,762,765,769,775,781,787,793,803,815,819,825,831,837,843,849,853,856,859,867,871,898,901,904,907,921,924,928],[11,12,13],"p",{},"브라우저 비디오 처리 성능 주장은 대개 2종류:\"충분히 빠르다, 믿어달라\" 또는 \"WASM은 네이티브보다 2배 느리다\". 둘 다 쓸모없다. 이 글은 실제 하드웨어에서의 실제 데이터로, 방법론과 생 데이터를 곁들여, 브라우저가 워크로드를 처리할 수 있는지 스스로 판단할 수 있게 한다.",[15,16,18],"h2",{"id":17},"테스트-구성","테스트 구성",[11,20,21],{},[22,23,24],"strong",{},"하드웨어:",[26,27,28,32,35],"ul",{},[29,30,31],"li",{},"Mac: MacBook Pro M2 Pro(12코어), 32GB RAM, macOS 14.5",[29,33,34],{},"Windows: ThinkPad X1 Carbon Gen 11(Intel i7-1370P, 14코어), 32GB RAM, Windows 11 23H2",[29,36,37],{},"미드레인지: Acer Aspire 5(Ryzen 5 5500U, 8GB RAM), Windows 11",[11,39,40],{},[22,41,42],{},"브라우저(모두 2026년 7월 기준 최신 안정 버전):",[26,44,45,48,51],{},[29,46,47],{},"Chrome 127",[29,49,50],{},"Firefox 127",[29,52,53],{},"Safari 17.5",[11,55,56],{},[22,57,58],{},"워크로드:",[60,61,62,68,74,80,92],"ol",{},[29,63,64,67],{},[22,65,66],{},"1080p HLS → MP4 리먹스","——30분 영상, 300 TS 세그먼트, 약 500MB",[29,69,70,73],{},[22,71,72],{},"4K HLS → MP4 리먹스","——30분 영상, 300 TS 세그먼트, 약 2.5GB",[29,75,76,79],{},[22,77,78],{},"8K HLS → MP4 리먹스","——10분 영상, 100 TS 세그먼트, 약 4GB",[29,81,82,85,86,91],{},[22,83,84],{},"디코딩 + 프레임 추출","(1080p, 매초 1프레임, 1800프레임)——",[87,88,90],"a",{"href":89},"\u002Fko\u002Fblog\u002Fwebcodecs-web-workers-opfs-video-processing","WebCodecs 글","에서 설명",[29,93,94,97],{},[22,95,96],{},"DASH → MP4 리먹스","——#1과 동일 영상이지만 DASH 소스(TS 디먹싱 불필요)",[11,99,100],{},[22,101,102],{},"테스트 방법:",[26,104,105,115,125,136],{},[29,106,107,110,111],{},[22,108,109],{},"네이티브 FFmpeg","(CLI, 베이스라인)——",[112,113,114],"code",{},"ffmpeg -f concat -safe 0 -i list.txt -c copy -f mp4 out.mp4",[29,116,117,120,121,124],{},[22,118,119],{},"FFmpeg WASM(싱글스레드)","——",[112,122,123],{},"@ffmpeg\u002Fffmpeg"," 0.12.x, pthreads 없음",[29,126,127,120,130,132,133],{},[22,128,129],{},"FFmpeg WASM(멀티스레드)",[112,131,123],{}," 0.12.x, ",[112,134,135],{},"CORE_THREADS=8",[29,137,138,141],{},[22,139,140],{},"WebCodecs + Worker","——디코딩 워크로드만, 리먹스 아님",[11,143,144],{},"각 테스트는 5회 실행, 중앙값 보고. 모든 시나리오에서 변동은 5% 미만.",[15,146,148],{"id":147},"결과-1080p-hls-mp4-리먹스30분-영상","결과: 1080p HLS → MP4 리먹스(30분 영상)",[150,151,152,171],"table",{},[153,154,155],"thead",{},[156,157,158,162,165,168],"tr",{},[159,160,161],"th",{},"수단",[159,163,164],{},"Mac (M2)",[159,166,167],{},"Win (i7)",[159,169,170],{},"미드레인지 (Ryzen)",[172,173,174,188,202,215],"tbody",{},[156,175,176,179,182,185],{},[177,178,109],"td",{},[177,180,181],{},"8s",[177,183,184],{},"12s",[177,186,187],{},"22s",[156,189,190,193,196,199],{},[177,191,192],{},"FFmpeg WASM 싱글스레드",[177,194,195],{},"75s",[177,197,198],{},"95s",[177,200,201],{},"180s",[156,203,204,207,209,212],{},[177,205,206],{},"FFmpeg WASM 멀티스레드(8스레드)",[177,208,187],{},[177,210,211],{},"28s",[177,213,214],{},"65s",[156,216,217,220,223,226],{},[177,218,219],{},"WebCodecs + Worker(디코딩만)",[177,221,222],{},"18s",[177,224,225],{},"24s",[177,227,228],{},"50s",[11,230,231,234],{},[22,232,233],{},"결론:"," 멀티스레드 FFmpeg WASM이 네이티브의 약 2-3배, 싱글스레드의 3-4배. 미드레인지 하드웨어에서 싱글스레드 FFmpeg WASM은 1080p에서 겨우 쓸만한 수준(30분을 180초 = 실시간의 0.16배). 멀티스레드는 문제없음(65초 = 실시간의 0.036배).",[15,236,238],{"id":237},"결과-4k-hls-mp4-리먹스30분-영상-25gb","결과: 4K HLS → MP4 리먹스(30분 영상, 2.5GB)",[150,240,241,253],{},[153,242,243],{},[156,244,245,247,249,251],{},[159,246,161],{},[159,248,164],{},[159,250,167],{},[159,252,170],{},[172,254,255,268,281],{},[156,256,257,259,262,265],{},[177,258,109],{},[177,260,261],{},"38s",[177,263,264],{},"52s",[177,266,267],{},"110s",[156,269,270,272,275,278],{},[177,271,192],{},[177,273,274],{},"380s",[177,276,277],{},"480s",[177,279,280],{},"OOM(1.4GB에서 크래시)",[156,282,283,286,289,292],{},[177,284,285],{},"FFmpeg WASM 멀티스레드",[177,287,288],{},"115s",[177,290,291],{},"145s",[177,293,294],{},"OOM(1.8GB에서 크래시)",[11,296,297,299],{},[22,298,233],{}," 4K 리먹스는 싱글스레드 FFmpeg WASM이 무너지는 경계점. 미드레인지 하드웨어(8GB)는 메모리 압력으로 크래시——WASM의 단일 인스턴스 메모리 상한이 2-4GB, 세그먼트 버퍼 + 디코딩 상태를 더하면 초과. 멀티스레드는 하이엔드 하드웨어에서 4K 처리 가능, 단 네이티브보다 2-3배 느리다.",[11,301,302,303,306],{},"미드레인지에서의 크래시가 가장 볼 만한 부분. 청크 처리(한 번에 N 세그먼트, OPFS에 쓰기, 메모리 해제)해도 4K TS 디먹싱은 많은 작업 메모리를 필요. 수정은 ",[87,304,305],{"href":89},"OPFS 스트리밍 모드","——출력 전체를 메모리에 올리지 않는 것.",[15,308,310],{"id":309},"결과-8k-hls-mp4-리먹스10분-영상-4gb","결과: 8K HLS → MP4 리먹스(10분 영상, 4GB)",[150,312,313,325],{},[153,314,315],{},[156,316,317,319,321,323],{},[159,318,161],{},[159,320,164],{},[159,322,167],{},[159,324,170],{},[172,326,327,339,349],{},[156,328,329,331,334,336],{},[177,330,109],{},[177,332,333],{},"42s",[177,335,214],{},[177,337,338],{},"OOM",[156,340,341,343,345,347],{},[177,342,192],{},[177,344,338],{},[177,346,338],{},[177,348,338],{},[156,350,351,353,356,359],{},[177,352,285],{},[177,354,355],{},"OOM(3.1GB에서 크래시)",[177,357,358],{},"OOM(3.4GB에서 크래시)",[177,360,338],{},[11,362,363,365],{},[22,364,233],{}," 2026년 시점에서 FFmpeg WASM은 8K를 처리 못 한다. 4GB의 단일 인스턴스 메모리 상한이 하드한 벽. 청크 스트리밍해도 8K HEVC TS 디먹싱은 PTS 재정렬을 위해 여러 100MB+ 세그먼트를 동시에 유지해야.",[11,367,368],{},"이건 알려진 제한. 제안 중인 WASM memory64 사양이 64비트 어드레싱으로 끌어올리지만, 2026년 시점 Chrome의 flag 뒤에 있고, Firefox\u002FSafari에는 없다.",[15,370,372],{"id":371},"결과-dash-리먹스ts-디먹싱-불필요","결과: DASH 리먹스(TS 디먹싱 불필요)",[11,374,375],{},"동일 1080p\u002F4K 콘텐츠이되 DASH 소스(fMP4 세그먼트, 디먹싱 불필요):",[150,377,378,390],{},[153,379,380],{},[156,381,382,384,387],{},[159,383,161],{},[159,385,386],{},"Mac (M2) 1080p",[159,388,389],{},"Mac (M2) 4K",[172,391,392,401,410,420],{},[156,393,394,396,399],{},[177,395,109],{},[177,397,398],{},"4s",[177,400,222],{},[156,402,403,405,407],{},[177,404,192],{},[177,406,184],{},[177,408,409],{},"70s",[156,411,412,414,417],{},[177,413,285],{},[177,415,416],{},"6s",[177,418,419],{},"25s",[156,421,422,425,428],{},[177,423,424],{},"순 JS 결합(FFmpeg 없음)",[177,426,427],{},"2s",[177,429,184],{},[11,431,432,434,435,439],{},[22,433,233],{}," DASH는 디먹싱 단계가 없어 훨씬 빠르다——",[87,436,438],{"href":437},"\u002Fko\u002Fblog\u002Fbrowser-streaming-remux-mp4-isobmff","리먹스 글","에서 이유를 설명. 순 JS 결합(FFmpeg을 완전히 쓰지 않는)은 DASH에서 가능, 메모리 대역폭의 한계 가까이까지 달린다.",[11,441,442],{},"이게 FlowPick의 DASH 경로가 HLS 경로보다 빠른 이유——HLS는 MPEG-TS를 디먹싱해야, DASH는 안 한다.",[15,444,446],{"id":445},"결과-디코딩-프레임-추출30분-1080p-1800프레임","결과: 디코딩 + 프레임 추출(30분 1080p, 1800프레임)",[150,448,449,461],{},[153,450,451],{},[156,452,453,455,457,459],{},[159,454,161],{},[159,456,164],{},[159,458,167],{},[159,460,170],{},[172,462,463,473,484,496,508],{},[156,464,465,467,469,471],{},[177,466,109],{},[177,468,222],{},[177,470,225],{},[177,472,264],{},[156,474,475,477,479,481],{},[177,476,192],{},[177,478,291],{},[177,480,201],{},[177,482,483],{},"320s",[156,485,486,488,490,493],{},[177,487,285],{},[177,489,264],{},[177,491,492],{},"68s",[177,494,495],{},"130s",[156,497,498,500,503,505],{},[177,499,140],{},[177,501,502],{},"31s",[177,504,261],{},[177,506,507],{},"85s",[156,509,510,513,515,518],{},[177,511,512],{},"WebCodecs + Worker 풀(4 worker)",[177,514,184],{},[177,516,517],{},"16s",[177,519,520],{},"35s",[11,522,523,525],{},[22,524,233],{}," WebCodecs + worker 풀이 브라우저에서 가장 빠른 선택——하이엔드 하드웨어에서 네이티브의 2배 이내. 하드웨어 가속이 진짜 효과. 미드레인지 하드웨어에서는 FFmpeg WASM 멀티스레드가 WebCodecs 싱글 worker와 동등——Ryzen 5 5500U의 GPU가 약해서.",[11,527,528],{},"worker 풀의 스케일링이 중요:4 worker는 1 worker보다 약 2.5배 빠르다(GPU 경합으로 서브리니어). 8 worker는 큰 도움 안 됨——GPU는 4-6개의 동시 디코딩에서 포화.",[15,530,532],{"id":531},"결과-브라우저-비교mac-m2-1080p-리먹스","결과: 브라우저 비교(Mac M2, 1080p 리먹스)",[150,534,535,549],{},[153,536,537],{},[156,538,539,542,544,546],{},[159,540,541],{},"브라우저",[159,543,192],{},[159,545,285],{},[159,547,548],{},"WebCodecs",[172,550,551,561,574],{},[156,552,553,555,557,559],{},[177,554,47],{},[177,556,195],{},[177,558,187],{},[177,560,502],{},[156,562,563,565,568,571],{},[177,564,50],{},[177,566,567],{},"92s",[177,569,570],{},"n\u002Fa(pthreads 없음)",[177,572,573],{},"n\u002Fa(WebCodecs 없음)",[156,575,576,578,581,583],{},[177,577,53],{},[177,579,580],{},"88s",[177,582,570],{},[177,584,585],{},"35s(codec 지원 제한)",[11,587,588,590],{},[22,589,233],{}," Chrome이 모든 선택을 달릴 수 있는 유일한 브라우저. Firefox는 WASM pthreads와 WebCodecs 모두 부족(2026년 중반에 WebCodecs는 여전히 flag 뒤). Safari는 WebCodecs를 갖되 codec 지원 제한(AV1 없음, VP9 제한).",[11,592,593,594,598],{},"이게 FlowPick이 Chrome을 권장하는 이유——",[87,595,597],{"href":596},"\u002Fko\u002Fblog\u002Fflowpick-v1-0-0-first-public-release","v1.0.0 릴리스 노트"," 참고.",[15,600,602],{"id":601},"메모리-사용","메모리 사용",[11,604,605],{},"피크 메모리(Chrome 127, Mac M2, 1080p 리먹스):",[150,607,608,620],{},[153,609,610],{},[156,611,612,614,617],{},[159,613,161],{},[159,615,616],{},"피크 메모리",[159,618,619],{},"비고",[172,621,622,632,642,652],{},[156,623,624,626,629],{},[177,625,109],{},[177,627,628],{},"80MB",[177,630,631],{},"베이스라인",[156,633,634,636,639],{},[177,635,192],{},[177,637,638],{},"220MB",[177,640,641],{},"WASM 오버헤드 + 세그먼트 버퍼",[156,643,644,646,649],{},[177,645,206],{},[177,647,648],{},"280MB",[177,650,651],{},"+ 8개의 worker 컨텍스트",[156,653,654,656,659],{},[177,655,140],{},[177,657,658],{},"95MB",[177,660,661],{},"하드웨어 가속이 GPU 메모리 사용, 메인 메모리 소비 안 함",[11,663,664],{},"4K 리먹스의 피크 메모리는 약 2배인 500MB(FFmpeg WASM 멀티스레드)——브라우저 탭의 2GB 소프트 상한 내이지만, 가까우니 다른 탭을 닫아야 할 수도.",[11,666,667],{},"메모리 프로필은 UX에 영향. 4K 리먹스가 8GB 머신에서 탭을 크래시시키는 건 최악의 경험. FlowPick의 청크 처리(한 번에 50세그먼트, OPFS에 쓰기, 메모리 해제)는 4K의 피크 메모리도 300MB 이내로 유지.",[15,669,671],{"id":670},"스트리밍-다운로드-벤치마크","스트리밍 다운로드 벤치마크",[11,673,674],{},"세그먼트 자체를 얼마나 빨리 다운로드할 수 있는가? 이건 네트워크가 병목인 부분.",[11,676,677],{},"테스트:300 세그먼트, 각 약 1.7MB, 총 500MB, CloudFront CDN에서.",[150,679,680,693],{},[153,681,682],{},[156,683,684,687,690],{},[159,685,686],{},"병렬 수",[159,688,689],{},"실측 시간",[159,691,692],{},"실효 대역폭",[172,694,695,705,715,726,736,747],{},[156,696,697,700,702],{},[177,698,699],{},"1",[177,701,291],{},[177,703,704],{},"3.4 MB\u002Fs",[156,706,707,710,712],{},[177,708,709],{},"4",[177,711,261],{},[177,713,714],{},"13.2 MB\u002Fs",[156,716,717,720,723],{},[177,718,719],{},"6",[177,721,722],{},"26s",[177,724,725],{},"19.2 MB\u002Fs",[156,727,728,731,733],{},[177,729,730],{},"8",[177,732,187],{},[177,734,735],{},"22.7 MB\u002Fs",[156,737,738,741,744],{},[177,739,740],{},"12",[177,742,743],{},"21s",[177,745,746],{},"23.8 MB\u002Fs",[156,748,749,752,754],{},[177,750,751],{},"16",[177,753,225],{},[177,755,756],{},"20.8 MB\u002Fs(느림——레이트 리미트)",[11,758,759,761],{},[22,760,233],{}," 6-8개 병렬 연결이 스위트스팟. 그 이상은 CDN이 IP당 레이트 리미트를 시작. FlowPick은 기본 6.",[11,763,764],{},"\"실효 대역폭\"은 CDN에서 제한, 브라우저에서 제한 안 됨. 병렬을 무한히 늘려도 CDN이 허용하는 상한을 넘을 수 없다.",[15,766,768],{"id":767},"방법론의-세부","방법론의 세부",[11,770,771,774],{},[22,772,773],{},"워밍업:"," 각 테스트는 2회 실행, 첫 번째는 폐기(WASM 컴파일, JIT 워밍업 등).",[11,776,777,780],{},[22,778,779],{},"전원:"," 랩탭은 전원 연결, 성능 모드. 배터리 모드에서는 Mac이 약 30%, Windows가 약 50% 클럭 다운.",[11,782,783,786],{},[22,784,785],{},"다른 탭:"," 없음. 백그라운드 탭은 CPU\u002F메모리를 경합.",[11,788,789,792],{},[22,790,791],{},"열:"," 모든 랩탭은 쿨링 패드 위. 열 스로틀은 실재——능동 쿨링 없이 4K 리먹스를 5분 연속하면 15-20% 떨어짐.",[11,794,795,798,799,802],{},[22,796,797],{},"FFmpeg 파라미터:"," ",[112,800,801],{},"-c copy -f mp4 -movflags +faststart","로 리먹스. 필터 없음, 트랜스코딩 없음.",[11,804,805,798,808,811,812,814],{},[22,806,807],{},"WASM 버전:",[112,809,810],{},"@ffmpeg\u002Fcore"," 0.12.10, 멀티스레드 버전은 ",[112,813,135],{},". SharedArrayBuffer 지원을 위한 COEP\u002FCOOP 헤더 올바르게 설정.",[15,816,818],{"id":817},"이-숫자들이-의미하는-것","이 숫자들이 의미하는 것",[11,820,821,824],{},[22,822,823],{},"1080p 콘텐츠(가장 일반적):"," 브라우저가 처리 가능. FFmpeg WASM 멀티스레드는 30분 1080p를 22-65초, 하드웨어에 따라. WebCodecs를 쓸 수 있으면 더 빠르다. 네이티브는 2-3배 빠르지만 설치 필요.",[11,826,827,830],{},[22,828,829],{},"4K 콘텐츠:"," 하이엔드 하드웨어(16GB+ RAM, 최신 CPU)에서 브라우저가 처리 가능. 미드레인지 하드웨어는 고전. 청크 처리가 필수.",[11,832,833,836],{},[22,834,835],{},"8K 콘텐츠:"," 2026년의 브라우저는 처리 불가. memory64 WASM을 기다리거나, 네이티브를 쓴다.",[11,838,839,842],{},[22,840,841],{},"디코딩 집약(프레임 추출, 분석):"," WebCodecs + worker 풀이 명확한 승자. 좋은 하드웨어에서 네이티브의 2배 이내.",[11,844,845,848],{},[22,846,847],{},"광범위 codec 지원:"," FFmpeg WASM. WebCodecs는 브라우저가 지원하는 codec으로 제한(H.264, H.265, VP9, AV1——브라우저마다 주의점 있음).",[15,850,852],{"id":851},"내-견해-브라우저는-90-시나리오에서-충분","내 견해: 브라우저는 90% 시나리오에서 충분",[11,854,855],{},"\"브라우저는 진짜 비디오 처리를 못 한다\"는 말은 시대에 뒤떨어진 것. 1080p 리먹스와 디코딩——실제 사용의 대부분——은 현대 하드웨어에서 Chrome이 네이티브의 2-3배 이내. 충분히 빠르다. 수초의 지연 차이(30분 영상에서 몇 초 더 기다리는)는, 워크플로의 차이(설치 불필요, PATH 설정 불필요, FFmpeg 설치 불필요)에 비하면 중요하지 않다.",[11,857,858],{},"나머지 10%——미드레인지 하드웨어에서의 4K, 어디서든 8K, 희귀 codec——은 여전히 네이티브가 필요. 그리고 그건 괜찮다. 도구는 일에 맞춰.",[11,860,861,862,866],{},"FlowPick의 베팅:브라우저에서 90% 시나리오를 최적화, 나머지 10%에는 \"yt-dlp를 써라\"라고 제안. ",[87,863,865],{"href":864},"\u002Fko\u002Fblog\u002Fflowpick-vs-yt-dlp","FlowPick vs. yt-dlp 비교","에서 언제 어느 쪽을 쓸지 설명.",[15,868,870],{"id":869},"참고-자료","참고 자료",[26,872,873,882,890],{},[29,874,875,881],{},[87,876,880],{"href":877,"rel":878},"https:\u002F\u002Fffmpegwasm.netlify.app\u002F",[879],"nofollow","FFmpeg WASM 문서","——설정과 스레딩",[29,883,884,889],{},[87,885,888],{"href":886,"rel":887},"https:\u002F\u002Fcaniuse.com\u002Fwebcodecs",[879],"WebCodecs 브라우저 지원","——호환성 표",[29,891,892,897],{},[87,893,896],{"href":894,"rel":895},"https:\u002F\u002Fgithub.com\u002FWebAssembly\u002Fmemory64",[879],"Memory64 제안","——WASM의 4GB 메모리 상한을 끌어올리는 제안",[15,899,900],{"id":900},"마치며",[11,902,903],{},"브라우저 비디오 처리는 1080p 워크로드에서 현대 하드웨어로 실행 가능, 4K는 하이엔드 하드웨어에서 실행 가능. 8K는 WASM이 memory64를 내놓을 때까지 불가. FFmpeg WASM 멀티스레드가 가장 좋은 범용 도구. WebCodecs + worker는 디코딩 집약 작업에서 더 빠르지만 codec 제한 있음.",[11,905,906],{},"여기의 방법론은 재현 가능——테스트 파일은 참고 자료에 링크, FFmpeg 파라미터는 기재, 하드웨어는 명시. 다른 워크로드라면, 같은 패턴으로 자신의 테스트를.",[11,908,909,910,912,913,915,916,920],{},"이 숫자를 뒷받침하는 구현 패턴은, ",[87,911,90],{"href":89},"과 ",[87,914,438],{"href":437},"에서. 무엇을 처리할 수 있는지의 법적 고려는, ",[87,917,919],{"href":918},"\u002Fko\u002Fblog\u002Fis-it-legal-to-download-streaming-video","스트리밍 다운로드 합법성 가이드","에서.",[922,923],"hr",{},[15,925,927],{"id":926},"추천-글","추천 글",[26,929,930,938,946,955,963,972],{},[29,931,932,937],{},[22,933,934],{},[87,935,936],{"href":89},"WebCodecs + Web Workers + OPFS: 브라우저 비디오 처리 실전","——여기서 테스트한 구현 패턴",[29,939,940,945],{},[22,941,942],{},[87,943,944],{"href":437},"브라우저에서 비디오 리먹스: fMP4, ISOBMFF, 트랜스코딩하지 않는 이유","——리먹스가 왜 빠르고 트랜스코딩이 왜 빠르지 않은지",[29,947,948,954],{},[22,949,950],{},[87,951,953],{"href":952},"\u002Fko\u002Fblog\u002Fhow-flowpick-merges-video-segments-in-browser","FlowPick은 어떻게 브라우저에서 수백 개의 비디오 세그먼트를 하나의 MP4로 합치는가","——FlowPick의 구체적 구현",[29,956,957,962],{},[22,958,959],{},[87,960,961],{"href":864},"FlowPick vs. yt-dlp","——브라우저 vs 네이티브의 선택 시기",[29,964,965,971],{},[22,966,967],{},[87,968,970],{"href":969},"\u002Fko\u002Fblog\u002Fhls-m3u8-deep-dive-encryption-multitrack","HLS 딥: 암호화, 멀티트랙, 기억해야 할 EXT-X 태그","——여기서 벤치마크한 HLS 포맷",[29,973,974,980],{},[22,975,976],{},[87,977,979],{"href":978},"\u002Fko\u002Fblog\u002Fflowpick-v1-1-0-smarter-media-detection","FlowPick v1.1.0: 더 똑똑한 미디어 감지","——큰 파일의 청크 처리를 추가한 버전",{"title":982,"searchDepth":983,"depth":983,"links":984},"",2,[985,986,987,988,989,990,991,992,993,994,995,996,997,998,999],{"id":17,"depth":983,"text":18},{"id":147,"depth":983,"text":148},{"id":237,"depth":983,"text":238},{"id":309,"depth":983,"text":310},{"id":371,"depth":983,"text":372},{"id":445,"depth":983,"text":446},{"id":531,"depth":983,"text":532},{"id":601,"depth":983,"text":602},{"id":670,"depth":983,"text":671},{"id":767,"depth":983,"text":768},{"id":817,"depth":983,"text":818},{"id":851,"depth":983,"text":852},{"id":869,"depth":983,"text":870},{"id":900,"depth":983,"text":900},{"id":926,"depth":983,"text":927},"tips","2026-08-04","실제 하드웨어에서의 실제 데이터——1080p\u002F4K\u002F8K 리먹스와 디코딩 벤치마크. FFmpeg WASM, WebCodecs, 네이티브 FFmpeg을 횡단. 방법론, 생 데이터, 숫자가 의미하는 바 포함.","md","\u002Fscreenshots\u002Fformat-conversion.png",{},true,"\u002Fko\u002Fblog\u002Fbrowser-video-processing-performance-benchmarks",13,{"title":5,"description":1002},"ko\u002Fblog\u002Fbrowser-video-processing-performance-benchmarks",[1012,1013,1014,1015,1016,1017],"성능","벤치마크","wasm","webcodecs","ffmpeg","딥","5MmUfVL3GCJa21cPpTp6leLbb7AcY3Fjc44bzBwaV50",[1020,1024],{"title":1021,"path":437,"stem":1022,"description":1023,"date":1001,"category":1000,"children":-1},"브라우저에서 비디오 리먹스: fMP4, ISOBMFF, 그리고 트랜스코딩하지 않는 이유","ko\u002Fblog\u002Fbrowser-streaming-remux-mp4-isobmff","비디오 리먹스와 트랜스코딩의 차이, 왜 fMP4 세그먼트를 그냥 붙이면 되는지, ISOBMFF 박스 구조를 살피고 브라우저에서 FFmpeg WASM을 언제 쓸지 판단.",{"title":1025,"path":1026,"stem":1027,"description":1028,"date":1001,"category":1000,"children":-1},"DASH 딥: SegmentTemplate, ContentProtection, 시점 전환 MPD 구조","\u002Fko\u002Fblog\u002Fdash-mpd-deep-dive-segmenttemplate-contentprotection","ko\u002Fblog\u002Fdash-mpd-deep-dive-segmenttemplate-contentprotection","MPD 입문의 그 다음——SegmentTemplate vs SegmentTimeline, $Number$ vs $Time$, ContentProtection 시그널링, 그리고 DASH가 HLS보다 파싱은 어려운데 다운로드는 쉬운 구조적 이유.",1787670592962]