Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- github 100mb
- ELECTRON
- electron-packager
- 이미지 데이터 타입
- react-native-dotenv
- adb pair
- custom printing
- Git
- camera access
- react-native
- Can't resolve
- github pdf
- rolldown
- vercel git lfs
- augmentedDevice
- 티스토리 성능
- Failed to compiled
- dvh
- device in use
- Each child in a list should have a unique "key" prop.
- ffi-napi
- github lfs
- npm package
- nextjs
- adb connect
- Recoil
- animation
- silent printing
- camera permission
- html
Archives
- Today
- Total
목록2026/07/03 (1)
Bleeding edge
RRD Viewer 로딩 줄이기: HTTP Range, Segment Manifest, 그리고 현실적인 한계
Rerun 기반의 RRD viewer를 웹에서 사용하다 보면, 가장 먼저 체감되는 문제는 “데이터를 어떻게 그릴 것인가”보다 “첫 화면이 언제 뜨는가”였다.기능 자체는 동작하고 있었다. 서버는 .rrd 파일을 만들고, 프론트는 그 파일을 받아 decode한 뒤 canvas에 그렸다. 하지만 세션 데이터가 커질수록 첫 로딩이 길어졌다. 사용자는 특정 구간만 보고 싶은데, viewer는 꽤 큰 RRD 데이터를 받은 뒤 decode해야 했다.처음 떠올린 비교 대상은 MP4였다.브라우저에서 MP4를 재생할 때는 전체 영상을 모두 다운로드한 뒤 재생하지 않는다. 브라우저는 필요한 byte 구간을 Range 요청으로 가져오고, 서버는 206 Partial Content로 일부 데이터만 내려준다. 그래서 큰 영상 파..
CS
2026. 7. 3. 17:18