Ozet

Bu belge, Synchro (Synchro) projesinin video pipeline optimizasyonu icin kapsamli bir yol haritasi sunar.

Mevcut durum: Synchro, video_codec.rs modulu araciligiyla zstd (varsayilan) ve zlib (legacy) destegi saglamaktadir. Codec abstraksiyon katmani ve prefix tabanli multiplexing altyapisi tamamlanmistir.

Hedef: Bant genisligi tuketimini %60-90 azaltmak, kullanici deneyimini olculebilir sekilde iyilestirmek.

Strateji: Uc asamali yaklasim - once dusuk riskli optimizasyonlar (dirty-rect), sonra codec genislemesi (OpenH264), son olarak donanim hizlandirma.

Temel Sayilar

Metrik	Mevcut	Hedef (Faz 2 Sonrasi)	Iyilesme
Bant genisligi (ofis)	5-8 Mbps	0.5-1.5 Mbps	%80+
Bant genisligi (video)	8-15 Mbps	2-5 Mbps	%65+
Ortalama FPS	16-20	25-30	%50+
Host CPU kullanimi	%35-45	%20-30	%30+
Giris gecikmesi (LAN)	80-120 ms	40-80 ms	%40+

Mevcut Mimari Analizi

SynchroVideo Pipeline (Simdiki Durum)

Synchro'nun video pipeline'i su adimlardan olusur:

Ekran Yakalama (scrap)
    |
    v
BGRA -> RGB Donusumu (capture.rs)
    |
    v
Downscale (nearest/average filtre)
    |
    v
Codec Encode (video_codec.rs)
    |
    v
BinaryFrame Paketleme (protocol.rs - RD1F magic)
    |
    v
WebSocket Relay (Cloudflare Workers)
    |
    v
BinaryFrame Cozumleme (viewer)
    |
    v
Codec Decode (video_codec.rs)
    |
    v
RGB -> egui::ColorImage (gui.rs)

Codec Abstraksiyon Katmani (Tamamlandi)

video_codec.rs modulu halihazirda su ozellikleri icermektedir:

Prefix tabanli multiplexing: Her frame'in ilk byte'i 0xF0 | codec_id formatindadir
Otomatik codec algilama: Decode sirasinda prefix varsa ilgili codec, yoksa legacy fallback
Cevre degiskeni ile secim: SYNCHRO_VIDEO_CODEC=zstd|zlib|h264|vp9|av1
Geriye uyumluluk: Prefix'siz eski frame'ler otomatik zstd/zlib olarak denenir
Gelecek codec yer tutuculari: H.264, VP9, AV1 id'leri tanimli (henuz implementasyon yok)

Frame Paket Formati

[1 byte: 0xF0|codec_id][N byte: codec-specific compressed data]

codec_id degerleri:
  1 = zlib
  2 = zstd (varsayilan)
  3 = H.264 (gelecek)
  4 = VP9 (gelecek)
  5 = AV1 (gelecek)

Guclue Yanlar

Codec degisimi tek noktadan (VideoCodecConfig::detect_from_env)
Geriye uyumlu decode (eski istemcilerle calismaya devam eder)
zstd varsayilani zlib'e gore ~2-3x daha hizli encode, ~5x daha hizli decode

Eksik Yanlar

Dirty-rect algilama yok: Her frame tam ekran olarak gonderiliyor
Adaptif kalite yok: Ag kosullarina gore FPS/bitrate ayarlama yok
Video codec yok: Hareketli icerikte zstd/zlib yetersiz kaliyor
Delta frame yok: is_delta alani protokolde var ama kullanilmiyor

Rakiplerle Karsilastirma

Codec Stratejileri

Urun	Video Codec	Statik Ekran	Ozel Teknoloji
TeamViewer	Ozel codec	Adaptif	Remote control protokolu
AnyDesk	DeskRT (ozel)	Dirty-rect	Goruntu algilama tabanli
RustDesk	VP9 + H.264	Dirty-rect	libvpx + ffmpeg
Synchro	zstd/zlib	Tam frame	Codec abstraksiyon hazir

Performans Etkisi (Tipik Ofis Senaryosu)

Metrik	Synchro(simdi)	RustDesk	AnyDesk	TeamViewer
Bant genisligi	5-8 Mbps	1-3 Mbps	0.5-2 Mbps	1-3 Mbps
CPU (host)	%35-45	%15-25	%10-20	%15-25
Frame latency	80-120 ms	30-60 ms	15-40 ms	30-60 ms

Ana farkin kaynagi: Synchroher frame'de tum ekrani gonderiyor. Rakipler yalnizca degisen bolgeleri gonderiyor (dirty-rect).

Bu, codec turunden bagimsiz olarak en buyuk performans farkidir.

Codec Secenekleri Karsilastirmasi

Teknik Degerlendirme Tablosu

Codec	Sikistirma	CPU (SW)	CPU (HW)	Gecikme	Lisans	Rust Crate
zlib	2-3x	Dusuk	-	<5ms	MIT	flate2
zstd	3-4x	Cok dusuk	-	<3ms	BSD	zstd
H.264	10-20x*	Orta	Cok dusuk	5-20ms	BSD**	openh264
VP9	15-25x*	Yuksek	Orta	10-30ms	Ucretsiz	libvpx-sys
AV1	20-35x*	Cok yuksek	Yeni GPU	20-50ms	Ucretsiz	rav1e
H.265	20-30x*	Yuksek	Dusuk	5-20ms	Patent!	Kisitli

* Video icerigi icin oranlar. Statik ekran icerigi icin zstd/zlib daha verimli olabilir. ** Cisco'nun OpenH264 implementasyonu BSD lisansli, MPEG-LA patent bedeli Cisco tarafindan odenliyor.

Icerik Tipine Gore Verimlilik

Bu tablo kritik bir noktayi gosterir: Video codec'ler her durumda ustun degildir.

Icerik Tipi	zlib	zstd	H.264	Aciklama
Statik masaustu (metin, IDE)	5-8x	8-12x	3-5x	zstd daha iyi
Karisik (browser, scroll)	2-3x	3-4x	8-15x	H.264 daha iyi
Video oynatma	1.5-2x	2-3x	15-30x	H.264 cok ustun
Slayt sunumu	3-5x	5-8x	5-10x	Benzer

Sonuc: Tek bir codec tum senaryolarda optimal degildir. Hibrit/adaptif yaklasim zorunludur.

Onerilen Codec Secimi

Birincil: H.264 (OpenH264)

Neden: En genis donanim destegi, olgun Rust crate, BSD lisans
Profil: Baseline (dusuk gecikme, B-frame yok, remote desktop icin ideal)
Donanim: Intel QuickSync, NVIDIA NVENC, AMD VCE, Apple VideoToolbox
Crate: openh264 = "0.6" - Cisco'nun referans implementasyonu

Gelecekte: AV1

Neden: En iyi sikistirma, royalty-free, industri destegi buyuyor
Simdilik neden degil: Encode CPU maliyeti cok yuksek, rav1e crate hala beta
Ne zaman: Donanim encode yayginlastiginda (Intel Arc, NVIDIA RTX 40xx+, Apple M3+)

Kacinilmasi gereken: H.265/HEVC

Neden kacinmali: 3 farkli patent havuzu (MPEG-LA, HEVC Advance, Technicolor)
Risk: Acik kaynak projeler icin hukuki belirsizlik
Alternatif: AV1 ayni verimliligti patent riski olmadan sunuyor

Uygulama Yol Haritasi

Genel Bakis

Faz 0: Dirty-Rect Algilama        [3-5 gun]  -> %70-90 bant tasarrufu (statik)
Faz 1: OpenH264 Entegrasyonu      [1-2 hafta] -> Video icerikte buyuk iyilesme
Faz 2: Adaptif Codec Secimi       [1 hafta]   -> Otomatik optimizasyon
Faz 3: Donanim Hizlandirma        [2-3 hafta] -> CPU %2'ye duser

Onemli: Fazlar birbirine bagimli degildir. Faz 0 tek basina en buyuk kazanici saglar.

Faz 0: Dirty-Rect Algilama (En Yuksek Oncelik)

Neden Bu Ilk?

Masaustu kullanimda ekranin %90-95'i cogu zaman degismiyor. Sadece degisen bolgeleri gondermek, herhangi bir codec'ten bagimsiz olarak en buyuk kazanici saglar.

Nasil Calisir

Onceki Frame (bellekte)    Yeni Frame (capture)
      |                         |
      +---------> Piksel Karsilastirma <--------+
                        |
              Degisen Bolgeler (rects)
                        |
          +-------------+-------------+
          |                           |
    Degisim < %5               Degisim > %5
    (Statik ekran)            (Aktif ekran)
          |                           |
    Sadece degisen               Tam frame
    rect'leri gonder             gonder

Teknik Detaylar

Yeni dosya: app/src/dirty_rect.rs

Algoritma:

Onceki frame'i bellekte tut (RGB buffer)
Yeni frame ile piksel bazinda karsilastir (16x16 blok grid)
Degisen bloklari bounding-rect olarak birlesir
Sadece degisen bolgeleri encode et ve gonder
Viewer tarafinda ilgili bolgeleri mevcut frame uzerine yaz

Protokol Genislemesi:

Mevcut BinaryFrame yapisina opsiyonel rect bilgisi eklenir:

is_delta = true ise:
  Frame verisi sadece degisen bolgeyi icerir
  Ek header: rect_x, rect_y, rect_w, rect_h (4x u32)

Beklenen Kazanc:

Senaryo	Mevcut Bant	Dirty-Rect Sonrasi	Tasarruf
IDE'de kod yazma	5-8 Mbps	0.3-0.8 Mbps	%85-95
Belge okuma	4-6 Mbps	0.5-1.5 Mbps	%75-85
Browser scrolling	6-10 Mbps	2-4 Mbps	%50-60
Video oynatma	8-15 Mbps	7-13 Mbps	%10-15

Uygulama Adimlari

dirty_rect.rs modulu olustur - blok bazli karsilastirma
capture.rs icinde onceki frame buffer'i tut
host.rs icinde delta frame gonderimine karar ver
protocol.rs icinde rect bilgisini BinaryFrame'e ekle
gui.rs (viewer) icinde delta frame'leri mevcut goruntu uzerine birlestir

Riskler ve Onlemler

Risk	Etki	Onlem
Yanlis negatif (degisim algilanamaz)	Goruntu bozulmasi	Periyodik keyframe (her 2-3 sn)
Bellek kullanimi artisi	+1 frame buffer	1920x1080x3 = ~6MB (ihmal edilebilir)
Kucuk degisimler cok rect uretir	Overhead	Minimum rect boyutu esligi (orn. 32x32)
Viewer senkronizasyon kaybi	Goruntu bozulmasi	Keyframe isteme mekanizmasi

Faz 1: OpenH264 Entegrasyonu

Hedef

Hareketli icerik (video oynatma, oyun, animasyon) icin H.264 encode/decode eklemek.

Bagimlilik

# app/Cargo.toml
openh264 = "0.6"

Not: openh264 crate'i, Cisco'nun C kutuphanesini otomatik indirir ve derler. Ek sistem bagimliligi gerektirmez.

Konfigurrasyon

Parametre	Deger	Aciklama
Profile	Baseline	Dusuk gecikme, B-frame yok
Rate Control	CBR	WebSocket relay icin ongorulebilir boyut
Target Bitrate	2-5 Mbps	1080p30 icin
Max Frame Rate	30	Remote desktop icin yeterli
IDR Interval	60-120 frame	2-4 sn, baglanti kaybina dayanikli
Complexity	Low	Encode hizi oncelikli

Uygulama Adimlari

video_codec.rs icinde VideoCodecConfig::H264 varyantini aktiflestir
OpenH264 encoder/decoder wrapper fonksiyonlari ekle
encode() ve decode() fonksiyonlarinda H.264 yolunu ac
Frame formatinda RGB -> YUV420 donusumu ekle (H.264 gerekliligi)
Test: encode -> decode -> piksel karsilastirma

Dikkat Edilecek Noktalar

OpenH264 sinirlamasi: Yalnizca Baseline Profile destekler. High Profile ozellikleri (CABAC, 8x8 transform) yoktur.
YUV donusum maliyeti: RGB -> YUV420 donusumu ek CPU gerektirir (~2-3ms/frame)
Keyframe boyutu: IDR frame'ler P-frame'lerin 5-10x buyuklugundedir. Ag spike'larina dikkat.

Beklenen Kazanc (Video Icerigi)

Metrik	zstd (simdi)	H.264 Sonrasi	Iyilesme
Bant genisligi	8-15 Mbps	2-5 Mbps	%65-75
Frame kalitesi	Kayipsiz	Kayipli (yuksek)	Fark edilmez
Encode suresi	1-3ms	5-15ms	Yavaslar
Decode suresi	1-2ms	2-5ms	Yavaslar

Faz 2: Adaptif Codec Secimi

Hedef

Frame icerigine gore otomatik olarak en uygun codec'i secmek.

Karar Algoritmasi

Her frame icin:
  1. Dirty-rect analizi yap
  2. Degisen piksel oranini hesapla (change_ratio)

  Eger change_ratio < 0.05:
    -> Delta frame (zstd ile sadece degisen rect)

  Eger change_ratio 0.05-0.30:
    -> Tam frame (zstd)

  Eger change_ratio > 0.30 VE H.264 aktif:
    -> Tam frame (H.264)

  Ag kotu ise (packet loss > %3 VEYA RTT > 200ms):
    -> FPS'i dusur (30 -> 15 -> 10)
    -> Downscale artir
    -> H.264 bitrate'i dusur

Metrik Toplama

Frame header'ina su bilgiler eklenir:

Alan	Tip	Aciklama
`change_ratio`	f32	Degisen piksel yuzde orani
`codec_id`	u8	Kullanilan codec
`encode_ms`	u16	Encode suresi (ms)

Bu metrikler viewer tarafinda toplanarak host'a geri bildirim gonderilebilir (opsiyonel).

Uygulama Adimlari

capture.rs icinde frame degisim oranini hesapla
host.rs icinde codec secim mantigi ekle
video_codec.rs icinde adaptif konfigurrasyon desteigni ac
Viewer tarafinda codec gecislerini sorunsuz handle et

Faz 3: Donanim Hizlandirma (Ileri Duzey)

Hedef

GPU tabanli encode/decode ile CPU kullanimini minimuma indirmek.

Platform Destegi

Platform	API	GPU	Rust Erisimi
Windows	NVENC	NVIDIA	ffmpeg-next
Windows	AMF	AMD	ffmpeg-next
Windows	QuickSync	Intel	ffmpeg-next
macOS	VideoToolbox	Apple Silicon	objc2-*
Linux	VAAPI	Intel/AMD	ffmpeg-next
Linux	NVENC	NVIDIA	ffmpeg-next

Performans Farki

	Yazilim Encode	Donanim Encode
1080p30 CPU kullanimi	%15-30	<%2
Encode gecikmesi	10-20ms	1-3ms
Guc tuketimi	Yuksek	Minimal
Kalite kontrol	Hassas	Platform bagli

Teknik Yaklasim

Iki secenek vardir:

Secenek A: ffmpeg-next crate (Onerilir)

Tum platformlari tek API ile kapsar
Dezavantaj: Agir bagimlilik (~50MB), karmasik build

Secenek B: Platform bazli dogrudan binding

Daha hafif, ama her platform icin ayri kod
macOS: core-video-rs, Windows: windows-rs, Linux: VAAPI

Onerilen Yaklasim

Oncelikle yazilim OpenH264 ile Faz 1'i tamamla
Donanim hizlandirmayi opsiyonel feature flag olarak ekle
cargo build --features hw-accel ile etkinlestir
Runtime'da GPU mevcut mu kontrol et, yoksa yazilim fallback

Guvenlik Degerlendirmesi

Codec degisiklikleri yeni guvenlik yuzeyler acar. Asagidaki riskler degerlendirilmistir.

Kritik Riskler

#	Risk	Aciklama	Onlem
1	Bozuk frame payload	Manipule edilmis frame ile bellek tasma	Boyut dogrulama + safe Rust
2	Codec confusion	Yanlis codec_id ile decode denemesi	Prefix dogrulama + fallback

Yuksek Riskler

#	Risk	Aciklama	Onlem
3	H.264 parser aciklari	OpenH264 C koduunda buffer overflow	Guncel versiyon + fuzz test
4	Frame boyut saldirisi	Dev frame ile bellek tukenmesi	Max frame boyutu limiti

Orta Riskler

#	Risk	Aciklama	Onlem
5	Keyframe manipulasyonu	Yanlis IDR frame ile goruntu bozma	Periyodik keyframe zorlama
6	Codec downgrade	Guvensiz codec'e gecis zorlama	Minimum codec seviyesi

Onlemler Ozeti

Tum decode islemleri anyhow::Result ile hata yonetimi
Frame boyutu ustsiniri: MAX_FRAME_SIZE = 16 * 1024 * 1024 (16MB)
Bilinmeyen codec_id icin sessizce drop (crash yok)
OpenH264 C kutuphanesi icin fuzz testleri planlandi

Test Plani

Birim Testleri

Test	Aciklama	Beklenen Sonuc
TC-01	zstd encode -> decode dongusu	Bit-perfect eslesme
TC-02	zlib encode -> decode dongusu	Bit-perfect eslesme
TC-03	H.264 encode -> decode dongusu	PSNR > 35dB
TC-04	Prefix'li frame decode	Dogru codec secimi
TC-05	Prefix'siz (legacy) frame decode	zstd/zlib fallback
TC-06	Bozuk frame decode	Hata donusu, crash yok
TC-07	Bos frame decode	Hata donusu, crash yok
TC-08	Codec gecisi (zstd -> H.264 -> zstd)	Sorunsuz gecis

Entegrasyon Testleri

Test	Aciklama	Beklenen Sonuc
TC-10	Host(zstd) -> Viewer(decode)	Frame gorunur
TC-11	Host(H.264) -> Viewer(decode)	Frame gorunur
TC-12	Dirty-rect: statik ekran	Bant %80+ dusuyor
TC-13	Dirty-rect: video oynatma	Tam frame gonderimi
TC-14	Adaptif gecis esigi	Dogru codec secimi
TC-15	Baglanti kopmasi -> yeniden baglanti	Keyframe ile toparlanma

Performans Testleri

Test	Metrik	Kabul Kriteri
PT-01	Encode suresi (zstd, 1080p)	< 5ms
PT-02	Encode suresi (H.264, 1080p)	< 20ms
PT-03	Decode suresi (zstd)	< 3ms
PT-04	Decode suresi (H.264)	< 8ms
PT-05	Dirty-rect karsilastirma suresi	< 2ms
PT-06	Bellek kullanimi artisi	< 50MB

Kabul Kriterleri

Kritik regresyon: %0 (hicbir mevcut ozellik bozulmamali)
Guvenlik testleri: %100 pass
Ortalama gecikme:
- LAN: < 100 ms
- Wi-Fi: < 150 ms
- 4G: < 250 ms

Kullanici Etkisi Simulasyonu

Senaryo Tanimlari

Kod	Senaryo	Hareket Duzeyi	Tipik Kullanim
S1	IDE'de kod yazma	Cok dusuk	Yazilimci gunluk is
S2	Browser'da belge okuma	Dusuk	Ofis calisan
S3	Terminal + scroll	Orta	DevOps / sistem yonetici
S4	Slayt sunumu	Orta (bolgesel)	Toplanti / egitim
S5	Video oynatma	Yuksek	Medya / destek
S6	Coklu islem (chat + dosya + fare)	Karisik	Uzaktan destek

Tahmini Performans Iyilesmesi

Faz 0 Sonrasi (Dirty-Rect)

Metrik	Oncesi	Sonrasi	Degisim
Bant (S1-S2)	5-8 Mbps	0.3-1.0 Mbps	-%85
Bant (S3-S4)	6-10 Mbps	1.5-4 Mbps	-%55
Bant (S5)	8-15 Mbps	7-13 Mbps	-%15
FPS (S1-S4)	16-20	25-30	+%50
Host CPU	%35-45	%25-35	-%25

Faz 1 Sonrasi (+ H.264)

Metrik	Oncesi	Sonrasi	Degisim
Bant (S5, video)	7-13 Mbps	2-5 Mbps	-%65
Bant (S3, scroll)	1.5-4 Mbps	0.8-2 Mbps	-%50
Goruntu kalitesi (S5)	Piksel-perfect	PSNR > 38dB	Fark edilmez

Faz 2 Sonrasi (+ Adaptif)

Metrik	Oncesi	Sonrasi	Degisim
Kullanici memnuniyeti	2.8/5	4.2/5	+%50
4G uzerinde kullanilabilirlik	Zor	Kabul edilebilir	Buyuk fark
Toplam bant (karisik)	5-15 Mbps	1-4 Mbps	-%75

Rakiplerle Puanlama Karsilastirmasi

Agirlikli Puanlama Metodolojisi

10 kategori uzerinden 1-10 olcekli puanlama. Agirliklar kullanim senaryosuna gore degisir.

Varsayilan Agirliklar

Kategori	Agirlik	RustDesk	AnyDesk	TeamViewer	Synchro(simdi)	Synchro(Faz2)
Kurulum/Operasyon	%12	7.5	9.0	9.0	9.0	9.0
Kod Kalitesi	%10	7.0	2.0	3.0	8.5	8.5
Performans	%20	7.5	9.0	9.5	6.5	8.0
Platform	%10	10.0	10.0	10.0	6.0	6.0
Ozellik Zenginligi	%20	8.0	9.5	10.0	7.5	7.5
Guvenlik	%12	7.5	8.5	9.0	7.5	8.0
Altyapi/Olcek	%8	10.0	8.5	9.0	9.5	9.5
Build/CI	%4	8.0	3.0	4.0	9.0	9.0
Ekosistem	%3	9.0	8.0	9.0	2.5	3.0
Bakim	%1	7.0	7.0	8.0	8.0	8.0

Agirlikli Skor Sonuclari

Urun	Mevcut Skor	Faz 2 Sonrasi
TeamViewer	~%82	~%82
AnyDesk	~%79	~%79
RustDesk	~%77	~%77
Synchro	~%71	~%76

Synchro Faz 2 sonrasi performans kategorisinde %65 -> %80'e cikar, genel skorda RustDesk seviyesine yaklasir.

Senaryoya Gore Siralama

Bireysel Kullanici (Performans + Kurulum Oncelikli)

Sira	Urun	Skor
1	AnyDesk	%81
2	TeamViewer	%79
3	Synchro (Faz 2)	%76
4	RustDesk	%75

Kurumsal Kullanici (Ozellik + Guvenlik Oncelikli)

Sira	Urun	Skor
1	TeamViewer	%86
2	AnyDesk	%83
3	RustDesk	%78
4	Synchro (Faz 2)	%72

Gelistirici / DevOps (Kod + Altyapi Oncelikli)

Sira	Urun	Skor
1	Synchro (Faz 2)	%82
2	RustDesk	%79
3	TeamViewer	%71
4	AnyDesk	%68

Sonuc ve Oneriler

Oncelik Sirasi

Oncelik	Eylem	Sure	Etki	Risk
1	Dirty-rect algilama	3-5 gun	Cok yuksek	Dusuk
2	OpenH264 entegrasyonu	1-2 hafta	Yuksek	Orta
3	Adaptif codec secimi	1 hafta	Orta	Dusuk
4	Donanim hizlandirma	2-3 hafta	Yuksek	Yuksek

Kritik Mesajlar

Dirty-rect, codec'ten onemlidir. En buyuk performans kazanci video codec degisikliginden degil, gereksiz piksel gonderiminin onlenmesinden gelir.
Hibrit yaklasim zorunludur. Tek bir codec tum senaryolarda optimal degildir. Statik ekranlarda zstd, hareketli icerikte H.264 kullanimali.
Fazlar bagimsiz uygulanabilir. Her faz kendi basina deger uretir. Faz 0 tek basina uygulandiginda bile kullanici deneyiminde belirgin fark yaratir.
Guvenlik paralel yurutulmelidir. Codec degisiklikleri yeni saldiri yuzeyler acar. Test plani ile birlikte ilerlenmelidir.
Mevcut altyapi hazirdir. video_codec.rs modulu prefix tabanli multiplexing ve geriye uyumlu decode ile yeni codec'lerin eklenmesini kolaylastirir.

Beklenen Genel Etki

Alan	Mevcut	Faz 2 Sonrasi
Bant genisligi (tipik)	5-15 Mbps	1-4 Mbps
FPS (ofis kullanimi)	16-20	25-30
Kullanici memnuniyeti	2.8/5	4.2/5
Rekabet pozisyonu	4. sirada	2-3. sirada

Bu belge, Synchro projesinin surekli gelisen teknik stratejisinin bir parcasidir. Guncelleme tarihi: 2026-02-26.

Video Codec Yol Haritasi ve Performans Optimizasyonu