네트워크가 나쁠 때 JPEG이 줄어드는 건 UDP 때문이 아니라 TCP 구현 방식 때문임
JPEG은 버퍼링이나 혼잡 제어 문제를 해결하지 않음. 아마도 프레임 전송을 최소화하는 구조로 구현했을 가능성이 큼
h.264는 JPEG보다 부호화 효율이 높음. 동일한 크기라면 h.264 IDR 프레임이 더 좋은 품질을 낼 수 있음
근본적인 문제는 대역폭 추정 부재임. TCP 환경에서도 초기 대역폭 프로브와 전송 지연 감지를 통해 비트레이트를 조정할 수 있음
가능하다면 WebRTC를 쓰는 게 낫고, 방화벽 회피용으로는 WebSocket을 쓰는 게 좋음
기사에 나온 폴링 코드에서는 이전 JPEG 다운로드가 끝나야 다음 요청을 보내는 구조였음. UDP가 없어도 이런 루프는 가능함
아마도 프레임을 완전히 직렬화해서 한 번에 하나씩만 요청하는 구조거나, 매번 새로운 GET 요청으로 새 연결을 여는 방식일 가능성이 큼
흥미로운 점은, 시각적으로 동일한 JPEG이라도 용량이 10~15% 수준으로 줄어들 수 있다는 것임. 2000년대 후반 웹 성능 최적화 작업을 하며 이런 효율 개선이 매우 보람찼음
글의 형식 문제나 LLM 스타일을 제쳐두더라도, 내용 전반이 잘못된 부분이 많음
10Mbps면 정적인 화면에는 충분해야 함. 문제는 인코딩 설정이 잘못됐거나 인코더 품질이 낮은 것임
“키프레임만 보내자”는 접근은 비효율적이며, 대신 짧은 keyframe 간격을 설정하면 됨
결국 문제는 TCP 단일 연결로 전체 스트림을 밀어 넣는 구조임. 이런 상황에 맞춘 DASH 같은 솔루션이 이미 존재함
AI가 쓴 글이 왜 상단에 오르는지 이해가 안 됨. 정성 없이 쓴 글을 읽는 건 시간 낭비라는 생각임
Apple에서는 DASH가 지원되지 않음. HLS가 대안이 될 수 있지만, ffmpeg가 없으면 구현이 매우 힘듦
이 글은 오히려 LLM 스타일이 거의 느껴지지 않음. 근거 없는 비판은 설득력이 없음
기존 도구를 익히는 데 드는 시간과 비용이 크기 때문에, “잘못된 재발명”이라도 상황에 따라 더 효율적일 수 있음
VNC가 1998년부터 해온 방식을 참고하면 좋을 것 같음
클라이언트 풀 모델을 유지하면서 프레임버퍼를 타일 단위로 나누고, 변경된 부분만 전송하는 구조임
정적인 코딩 화면에서는 대역폭을 크게 줄일 수 있음. 스크롤 감지도 추가하면 더 효율적일 것임
여러 제안 중 이게 가장 현실적인 출발점 같음. 40Mbps를 기본으로 잡은 건 문제 접근 자체가 잘못된 것 같음
글에서 미숙함이 느껴졌음. 이런 접근이 오픈소스로도 가능한지 궁금함
neko 프로젝트를 먼저 살펴보길 권함. VNC보다 연결 지연과 백프레셔 문제를 훨씬 잘 처리함
VNC 방식을 복제하는 게 가장 자연스러운 첫 시도일 것 같음. Moonlight처럼 게임용 저지연 솔루션을 쓰는 건 오히려 부적절함
예전에 비디오 인코딩을 다뤄봤는데, 40Mbps는 블루레이급 품질임
단순한 텍스트 스트리밍에는 과도함. Claude와 대화해본 결과, 30FPS, GOP 2초, 평균 1Mbps 정도면 충분하다는 결론이 나왔음
최악의 경우에도 1.2Mbps면 충분히 안정적인 품질을 유지할 수 있음
이 글의 핵심 문제는 h.264 최소 대역폭을 너무 높게 설정한 것임
H.264는 JPEG보다 훨씬 효율적임. 1Mbps부터 시작해 조정했어야 함
키프레임만 쓰는 건 오히려 비효율적임
글에서 “10Mbps로 낮췄더니 30초 지연이 생겼다”고 했지만, 이는 인코딩 설정 문제일 가능성이 큼
JPEG도 버퍼링을 통해 재생 대기열을 만들면 끊김 문제를 완화할 수 있음. 요즘 플레이어는 네트워크 품질을 실시간으로 감시함
나였다면 완전히 다르게 접근했을 것임
10Mbps는 과도하고, YouTube의 코딩 영상은 1080p에서도 0.6Mbps 수준임. 충분히 선명함
차라리 1fps로 줄이거나 keyframe 간격을 조정하는 게 낫다고 생각함
글의 문체와 논리 전개가 LLM 냄새가 남. 코드도 비슷한 수준일 듯함
1fps로는 부족할 수 있음. 모든 프레임을 keyframe으로 만드는 설정이 필요함
하지만 어떤 사람에게는 YouTube 화질도 참을 수 없을 정도로 거슬릴 수 있음
브라우저로 실시간 비디오를 스트리밍하는 건 정말 고통스러운 일임
JPEG 스크린샷이 잘 작동한다면 그대로 두는 게 나음
gstreamer나 Moonlight 같은 스택은 백프레셔와 오류 전파를 이해하지 못하면 디버깅이 지옥임
NVIDIA Video Codec SDK + WebSocket + MediaSource Extensions 조합이 현실적인 대안임
하지만 글이 LLM 생성물이라면, 저자는 이런 내부 구조를 이해할 의지가 없을 것 같음
이런 복잡한 시스템을 단일 목적으로 다뤄야 할 때는 오히려 LLM이 유용하게 쓰일 수 있음
예전에 5초마다 스크린샷을 찍는 프로그램을 썼는데, 하드디스크가 금방 가득 찼음
이미지 대부분이 동일하다는 걸 깨닫고, 변경된 부분만 저장하는 알고리즘을 고민하다가
결국 내가 비디오 압축을 재발명하고 있었다는 걸 깨달음
ffmpeg 한 줄로 해결했고, 저장 공간을 98% 절약했음
LLM이 타이핑하는 영상을 40Mbps로 스트리밍한다는 게 비정상적으로 과도한 대역폭임
게다가 60fps로 “컴퓨터가 타이핑하는 장면”을 본다는 것도 이상함. 문제 도메인을 전혀 이해하지 못한 접근 같음
HN에서 좋은 답변을 얻는 유일한 방법은 틀린 글을 올리는 것임
틀렸지만 흥미로운 글이야말로 토론을 이끌어내는 완벽한 균형을 맞춘 사례라고 생각함
Hacker News 의견들
네트워크가 나쁠 때 JPEG이 줄어드는 건 UDP 때문이 아니라 TCP 구현 방식 때문임
JPEG은 버퍼링이나 혼잡 제어 문제를 해결하지 않음. 아마도 프레임 전송을 최소화하는 구조로 구현했을 가능성이 큼
h.264는 JPEG보다 부호화 효율이 높음. 동일한 크기라면 h.264 IDR 프레임이 더 좋은 품질을 낼 수 있음
근본적인 문제는 대역폭 추정 부재임. TCP 환경에서도 초기 대역폭 프로브와 전송 지연 감지를 통해 비트레이트를 조정할 수 있음
가능하다면 WebRTC를 쓰는 게 낫고, 방화벽 회피용으로는 WebSocket을 쓰는 게 좋음
글의 형식 문제나 LLM 스타일을 제쳐두더라도, 내용 전반이 잘못된 부분이 많음
10Mbps면 정적인 화면에는 충분해야 함. 문제는 인코딩 설정이 잘못됐거나 인코더 품질이 낮은 것임
“키프레임만 보내자”는 접근은 비효율적이며, 대신 짧은 keyframe 간격을 설정하면 됨
결국 문제는 TCP 단일 연결로 전체 스트림을 밀어 넣는 구조임. 이런 상황에 맞춘 DASH 같은 솔루션이 이미 존재함
VNC가 1998년부터 해온 방식을 참고하면 좋을 것 같음
클라이언트 풀 모델을 유지하면서 프레임버퍼를 타일 단위로 나누고, 변경된 부분만 전송하는 구조임
정적인 코딩 화면에서는 대역폭을 크게 줄일 수 있음. 스크롤 감지도 추가하면 더 효율적일 것임
예전에 비디오 인코딩을 다뤄봤는데, 40Mbps는 블루레이급 품질임
단순한 텍스트 스트리밍에는 과도함. Claude와 대화해본 결과, 30FPS, GOP 2초, 평균 1Mbps 정도면 충분하다는 결론이 나왔음
최악의 경우에도 1.2Mbps면 충분히 안정적인 품질을 유지할 수 있음
이 글의 핵심 문제는 h.264 최소 대역폭을 너무 높게 설정한 것임
H.264는 JPEG보다 훨씬 효율적임. 1Mbps부터 시작해 조정했어야 함
키프레임만 쓰는 건 오히려 비효율적임
나였다면 완전히 다르게 접근했을 것임
10Mbps는 과도하고, YouTube의 코딩 영상은 1080p에서도 0.6Mbps 수준임. 충분히 선명함
차라리 1fps로 줄이거나 keyframe 간격을 조정하는 게 낫다고 생각함
브라우저로 실시간 비디오를 스트리밍하는 건 정말 고통스러운 일임
JPEG 스크린샷이 잘 작동한다면 그대로 두는 게 나음
gstreamer나 Moonlight 같은 스택은 백프레셔와 오류 전파를 이해하지 못하면 디버깅이 지옥임
NVIDIA Video Codec SDK + WebSocket + MediaSource Extensions 조합이 현실적인 대안임
하지만 글이 LLM 생성물이라면, 저자는 이런 내부 구조를 이해할 의지가 없을 것 같음
예전에 5초마다 스크린샷을 찍는 프로그램을 썼는데, 하드디스크가 금방 가득 찼음
이미지 대부분이 동일하다는 걸 깨닫고, 변경된 부분만 저장하는 알고리즘을 고민하다가
결국 내가 비디오 압축을 재발명하고 있었다는 걸 깨달음
ffmpeg 한 줄로 해결했고, 저장 공간을 98% 절약했음
LLM이 타이핑하는 영상을 40Mbps로 스트리밍한다는 게 비정상적으로 과도한 대역폭임
HN에서 좋은 답변을 얻는 유일한 방법은 틀린 글을 올리는 것임
틀렸지만 흥미로운 글이야말로 토론을 이끌어내는 완벽한 균형을 맞춘 사례라고 생각함