Ekran Paylaşımında A/V Sync Bozuldu: Ses Video Neden Desenkron Olur, Nasıl Düzeltilir?

Görüntülü sohbette ekran paylaşımı açıldığında görüntülü sohbette ekran paylaşımı + ses senkronu (A/V sync) bozulduğunda neden olur, nasıl düzeltilir? sorusu sık sık karşınıza çıkar. Bunun temel nedeni çok basit: Ekranı yakalayan sistem, o görüntüyü kodlayıp (encode) iletirken ses akışıyla aynı zaman çizelgesinde ilerlemek zorunda. Zincirin herhangi bir halkasında küçük bir gecikme bile “ses daha önde/arkada kaldı” hissini oluşturabiliyor.

Bu yazıda, A/V sync bozulmasını önce “donma mı gecikme mi?” ayrımıyla netleştireceğiz. Ardından ekran paylaşımının uçtan uca işleyişini (yakala → encode → ağ → decode → render) birlikte düşünerek; daha sonra da kök nedenleri (jitter/buffer, paket kaybı, drift, codec/FPS uyumsuzluğu, CPU/GPU yükü vb.) adım adım ele alacağız. Hedefimiz şu: Ses mi video mu kayıyor, bu kayma zamanla artıyor mu? Buna göre uygulanabilir bir düzeltme sırası belirlemek.

Kısa özet: A/V sync bozulması nasıl anlaşılır?

A/V sync bozulduğunda genellikle şu belirtiler kendini gösterir:

Ses önde geliyorsa, konuşmaya ait görüntü henüz “ağzın hareketini” yakalayamadan ses duyulur ya da görüntü bir süre geriden takip eder. Ses arkada kaldığında ise görüntü gelir ama ses bir an sonra yetişir.

Bir de “ani kayma” ile “zamanla artan kayma” farkı önemli. Ani bozulmalar çoğu zaman ekran paylaşımının başladığı anda yaşanan pipeline değişimiyle (kodlayıcı/çözünürlük/FPS geçişi, yeniden senkron) ilişkilidir. Drift ise (1-2 dakika içinde farkın büyümesi) clock zaman damgasının yeniden hizalanmaması, buffer büyümesi ya da adaptif bitrate/FPS uyumsuzluğu gibi daha sistemik sebepleri düşündürür.

Freeze vs Latency vs A/V sync drift: belirtilerle ayırma (mini karar ağacı)

İlk iş “aynı şey sanılan” üç farklı durumu ayırmak. Çünkü çözüm yaklaşımı doğrudan değişiyor.

• Freeze (donma): Video/ekran görüntüsü “takılır”. Ses akmaya devam eder; ya da ses de gecikerek gelmeye başlar. Asıl his süreklilik kaybıdır.
• Latency (gecikme): Ses ve video birlikte daha geç gelir; fakat aralarındaki fark genellikle sabit kalır. Örneğin ikisi de 300-600 ms gecikir ama ses video ile birlikte “aynı şekilde” ilerliyordur.
• Drift (desenkron büyümesi): Ses-video arasındaki fark zamanla büyür. İlk 10-20 saniye “idare eder” gibi görünse bile sonra fark giderek belirginleşir.

Karar ağacı: Ekran paylaşımı açılınca “bir anda” ses-video farkı değişiyorsa, zaman damgası yeniden hizalama ya da encode pipeline geçişi ihtimali artar. 1-2 dakika içinde fark büyüyorsa; buffer/jitter birikimi, clock drift ve adaptif kodlama uyumsuzluğu daha olasıdır. Görüntü “donuyor” ama ses akıyor ya da kopukluklar aynı anda geliyorsa; bu durumda freeze kaynaklı CPU/GPU yükü veya paket kaybı daha güçlü bir ihtimal olur.

Ekran paylaşımı A/V sync’i nasıl etkiler?

Ekran paylaşımı sadece “ekranı göstermek” değildir; sisteme uçtan uca yeni bir video pipeline ekler. Tipik zincir şöyle ilerler:

Ekran yakalama → (yakalanan kareler buffer’da) → encode (codec/bitrate/FPS) → ağ üzerinden gönderim → decode → render/kompozit. Ses akışı çoğu zaman ayrı bir yolla yürür; ancak uygulamanın bunu yine de aynı “zaman çizgisi”ne oturtması gerekir.

Ekran yakalamada oluşan gecikme ya da encode süresi (özellikle CPU/GPU boğulması) arttığında video pipeline geride kalır. Bu gerilik tek seferlikse yeniden senkron mümkün olabilir; sürekli oluyorsa buffer büyür ve drift başlar. Ağ tarafında jitter artarsa video paketleri düzensiz gelmeye başlar; bazı paketler geç kaldığında sistem ya bekleme yapar ya da zaman çizgisine yeniden oturtmak için yeniden hizalama girişimlerine girer. İşte bu adımlar ses-video farkını artırabilir.

Kök nedenler (neden-sonuç eşleştirmesi)

Şimdi A/V sync bozulmasının en sık kök nedenlerini “neden → sonuç” şeklinde eşleştirelim. Böylece teşhis çok daha hızlı ilerler.

1) CPU/GPU yükü (ekran yakalama + encode): Ekran paylaşımı başladığında encoder, görüntüyü yakalama, dönüştürme, ölçekleme ve sıkıştırma gibi ek adımlar yapar. CPU/GPU meşgulse encode süresi uzar. Sonuç: Video zamanında yetişemez; ses daha “erken” kalır.

2) FPS düşüşü veya adaptif FPS geçişi: Sistem sabit bir FPS hedefiyle çalışırken yük artınca FPS düşebilir ya da dalgalanabilir. Sonuç: Kare üretim ritmi bozulur; uygulama yeni zaman damgası üretimi/yeniden hizalama davranışına geçebilir. Bu da anlık bozulmaya veya drift’e neden olabilir.

3) Bant genişliği doygunluğu: Wi‑Fi, VPN ya da aynı ağda başka trafik varsa bant genişliği doygunlaşabilir. Sonuç: Video bitrate kontrolü/yeniden kodlama devreye girer, jitter ve buffer artar. Ses tarafı daha stabil kalıyorsa A/V farkı büyür.

4) Jitter ve buffer büyümesi: Paketlerin geliş zamanı düzensizleşir. Alıcı taraf “oynama”yı azaltmak için buffer’a ek paket bekleyebilir. Sonuç: Zaman çizelgesi değişir; ses-video senkronu kayar.

5) Paket kaybı: Video paketleri kaybolduğunda, kayıp kareler telafi edilmeye çalışılabilir. Sonuç: Decode/render gecikmesi artar; drift ya da ani bozulma görülebilir.

6) Zaman damgası (timestamp) ve drift: Her akış (ses/video) kendi clock’ına dayanır. Uygulamanın senkronizasyon stratejisi (örn. “render-time alignment”) yetersiz kalırsa ya da yeniden hizalama tetiklenmezse drift olur. Sonuç: 1-2 dakika içinde fark büyür.

7) Asimetrik encoder/decoder gecikmesi: Bazı cihazlarda ekran yakalama hızlı, encode tarafında yavaş olabilir; karşı cihazın decode tarafı zorlanabilir. Sonuç: Tek yönlü bir “eksen kayması” gibi algılanır.

8) Değişken çözünürlük/codec adaptasyonu: Uygulama ağ kalitesine göre çözünürlüğü veya codec parametrelerini anlık değiştirebilir. Sonuç: Video pipeline “yeni mod”a geçerken senkron anlık kayabilir.

9) Arka plan süreçleri: Tarayıcı sekmesi senkronu, ekran paylaşımını tetikleyen donanım hızlandırma, arka planda indirme/yükleme, antivirüs taraması gibi işlemler CPU’yu etkileyebilir. Sonuç: Encode veya render gecikmesi artar; drift ya da ani bozulma oluşur.

Hızlı teşhis: 5 dakikada hangi bileşen suçlu? (kontrol soruları + gözlem)

Hızlı teşhis, “her şeyi kurcalamak” yerine önce gözlemle daraltmayı hedefler. Şu soruları sırayla yanıtlayın:

1. Sorun ekran paylaşımı açılınca mı başlıyor? Evetse ilk şüpheli: ekran yakalama/encode yükü ve ekran paylaşımı mod geçişleri.
2. Ses-video farkı anlık mı, zamanla mı artıyor? Anlık → pipeline geçişi / yeniden hizalama. Zamanla artan → jitter/buffer birikimi veya clock drift.
3. Her iki tarafta mı aynı? Sadece bir katılımcıda ise o tarafın cihaz/OS yükü, ekran yakalama ayarları ya da ağ rotası daha olasıdır.
4. Wi‑Fi’de mi, Ethernet’te mi? Wi‑Fi’de belirginleşiyorsa bant genişliği/jitter/buffer kaynaklı ihtimaller yükselir.
5. Tarayıcı sekmesi paylaşımı mı, tam ekran mı? İçerik türüne göre yakalama gecikmesi ve yeniden ölçekleme artabilir.
6. Paylaşım FPS/çözünürlük değişince düzeliyor mu? Düzeliyorsa encode ve bitrate kontrolü çözümün anahtarı olabilir.

Burada amaç “tek hamlede bitirmek” değil; bir sonraki başlıkta vereceğimiz ölçülebilir adımlara geçmeden önce doğru hipotezi seçmek.

Nasıl kontrol edilir? (log/istatistik bakma yaklaşımı)

Çoğu görüntülü sohbet uygulaması “bağlantı kalitesi” ve “medya istatistikleri” gibi veriler sunar. Ancak uygulamalar bu verileri farklı isimlerle gösterir. Yine de bakacağınız başlıklar genelde benzer olur.

Adım adım doğrulama:

1. Ses ve video gecikmesi/toplam gecikme ölçümlerini (varsa “round-trip time”, “media latency”, “jitter” gibi metrikleri) paylaşım başlamadan önce ve sonra karşılaştırın.
2. Video FPS ve gönderilen/boşta kalan bitrate değerlerini izleyin. Paylaşım açılınca FPS düşüyor ya da bitrate dalgalanıyorsa encode/bant genişliği etkisi güçlüdür.
3. Paket kaybı (packet loss) ve jitter artıyorsa ağ (özellikle Wi‑Fi/VPN) ya da bant genişliği doygunluğu ilk sıraya çıkar.
4. CPU/GPU kullanımını (Görev Yöneticisi / Activity Monitor) kontrol edin. Ekran paylaşımı anında encode kullanımı sıçrıyorsa, kök neden cihazın kendisine kadar inmiş demektir.

Eğer metrikler “ses-video gecikmesi farkının” arttığını gösteriyorsa, bu A/V sync drift lehine bir işarettir. Sadece genel gecikme artıyorsa; daha çok latency kaynaklı bir senaryo ile karşı karşıyasınız demektir.

Çözüm adımları (öncelik sırasına göre)

Aşağıdaki sırayı izleyin. Çoğu ortamda en hızlı sonuç veren hamleler, önce ekran paylaşımının bindirdiği yükü azaltanlar olur; sonra cihaz performansı, ardından ağ stabilitesi ve en son uygulama/sohbet ayarları gelir.

1. Ekran paylaşımı ayarları (FPS/çözünürlük): Paylaşımı 30 FPS yerine 15-24 FPS aralığına çekin. Çözünürlüğü 1080p’den 720p’ye düşürmek çoğu zaman hızlı sonuç verir.
2. Cihaz performansı (donanım hızlandırma, arka plan): Ekran yakalama sırasında ağır arka plan uygulamalarını kapatın. Uygulama içindeki donanım hızlandırma ayarlarını kontrol edin.
3. Ağ (Wi‑Fi vs Ethernet, bant genişliği, QoS): Mümkünse Ethernet’e geçin. Wi‑Fi kullanıyorsanız 5 GHz’i tercih edin ve yönlendiriciye yaklaşarak test edin. VPN/VPS yükünü azaltın ya da test için kapatın.
4. Uygulama/sohbet ayarları (codec/bitrate/latency modu): “Düşük gecikme” veya “performans” gibi modlar her zaman aynı sonucu vermez. Bazı uygulamalarda jitter buffer’ını artırıp stabiliteyi iyileştirmek drift’i azaltabilir; bazılarında ise daha keskin gecikme yaratıp farkı büyütebilir.

Bu adımlar, ekran paylaşımı pipeline’ında hem encode süresini hem de iletim/jitter etkisini azaltmayı hedefler. Böylece video zaman çizgisi daha düzenli gelir; senkron farkı azalır ya da drift durur.

Ses-video farkı durumuna göre “eşleştirilmiş” düzeltmeler

Sorunu doğru şekilde çözmek için önce “ses önde mi, ses arkada mı?” ayrımını yapın. Ardından uygulayacağınız ayarlar daha isabetli olur.

Ses önde (video geriden yetişiyor) senaryosu: Çoğunlukla video encode/decode gecikmesi veya ağda video paketlerinin düzensiz gelmesi söz konusudur. Ekran paylaşımı FPS/çözünürlük düşürün, donanım hızlandırmayı gözden geçirin, arka plan CPU yükünü azaltın. Wi‑Fi kullanıyorsanız bant genişliği doygunluğu/jitter ihtimali için Ethernet’e geçmeyi deneyin.

Ses arkada (video daha “hızlı”, ses geriden yetişiyor) senaryosu: Bazı durumlarda ses tarafındaki gürültü temizleme, otomatik kazanç kontrolü (AGC), echo cancellation gibi işlemler ek gecikme ekleyebilir ya da ses bitrate/adaptasyon dengesizleşebilir. Uygulama içinde varsa “ses işleme” seçeneklerini düşük gecikmeye uygun moda alın; gürültü temizleme etkisini test edin. Ayrıca ekran paylaşımı açılınca ses tarafı yeniden senkron tetikliyorsa kısa süreli anlık kayma normal olabilir. Ancak drift artıyorsa, genel A/V senkron stratejisi etkileniyor demektir.

Drift artıyorsa (1-2 dk içinde fark büyüyor): En sık jitter/buffer birikimi veya clock drift + adaptif bitrate/FPS uyumsuzluğu görülür. Bu durumda video parametrelerini daha “stabil” hale çekmek (sabit hedef FPS, aşırı yüksek çözünürlük yerine orta değerler) drift’i kesmeye yardımcı olur.

Sık görülen senaryolar

Birçok A/V sync problemi, aynı birkaç “gerçek hayat” koşulundan çıkıyor. Aşağıdaki senaryolar sizde de var mı diye hızlıca kontrol edin.

Çok monitör / farklı DPI: Ekran yakalama alanı sürekli dönüştürülürse encode maliyeti artabilir. Üstüne bir de ölçekleme (Windows Display Scaling gibi) ek gecikme ve kare zamanlaması dalgalanması yaratabilir.

Tarayıcı sekmesi paylaşımı vs tam ekran: Sekme paylaşımında içerik yeniden çizim ve pencere yakalama pipeline’ına göre farklı gecikmeler üretebilir. Tam ekran çoğu zaman daha stabil olur; bazen tam tersi de görülebilir.

Arka planda indirme/yükleme: Ağda jitter artar. Ekran paylaşımı video olduğu için bant genişliği çekişmesi video paketlerini daha sık etkiler; ses ise ayrı akış olarak daha stabil kalabilir.

VPN kullanımı: Ek gecikme ve jitter; bazı rota değişimleri A/V drift’i tetikleyebilir. Test için VPN’i kapatmak “teşhis aracı” gibi kullanışlıdır.

Kaynak cihazda yüksek CPU: Ekran paylaşımı başladığı anda CPU/GPU kullanımı sıçrıyorsa, encode gecikmesi video tarafında desenkronun ana sebebi olabilir.

Örnekler (gerçek teşhis senaryoları)

Örnek 1: Wi‑Fi’de ekran paylaşımı açılınca ses geriye düşüyor — Bant genişliği doygunluğu ve jitter kaynaklı buffer büyümesi senaryosu. Video paketleri düzensiz geldiği için alıcı video tarafında daha uzun beklemeye alır; ses daha “erken” kalır. Ethernet’e geçince veya çözünürlük/FPS düşürülünce senkron düzeliyorsa kök neden ağ stabilitesidir.

Örnek 2: Ekran paylaşımı başlangıcında senkron anlık bozuluyor, sonra düzeliyorsa — Zaman damgası yeniden hizalama/encoder pipeline geçişi olasılığı yükselir. Uygulama paylaşım başladığında codec/çözünürlük/FPS ayarlarını günceller; ilk kareler ya da ilk GOP yapıları zamanlamada farklılık yaratabilir. Birkaç saniye içinde toparlıyorsa panik yerine parametre stabilizasyonu (çok agresif adaptif ayarlardan kaçınma) yeterli olabilir.

Örnek 3: Drift zamanla artıyor (1-2 dk içinde fark büyüyor) — Buffer/clock drift ve adaptif bitrate/FPS uyumsuzluğu ihtimali. Jitter az görünse bile uzun süre boyunca buffer “yürüyebilir”. Bu durumda sabit hedefe daha yakın ama çok uç olmayan FPS/bitrate tercih etmek ve video çözünürlüğünü makul seviyeye çekmek farkı yavaşlatır ya da durdurur.

Uzman önerileri: Stabilite için hedef parametreler

A/V sync için tek bir “sihirli değer” yok; ama pratik hedefler var. Buradaki mantık şu: Video akışının zamanlamasını mümkün olduğunca düzenli ve tahmin edilebilir kılmak.

Hedef alan	Neye bakılır?	Pratik hedef / öneri
Video zamanlaması	FPS dalgalanması, encode süresi	Paylaşım açınca FPS’te ani düşüş/zigzag olmasın; 15-24 FPS çoğu senaryoda stabil olur
Ağ stabilitesi	Jitter, packet loss, RTT	Jitter yükseliyorsa video çözünürlüğü/FPS düşürün; mümkünse Ethernet ve ağ önceliklendirme kullanın
Bitrate adaptasyonu	Bitrate dalgalanması ve codec geçişleri	Aşırı adaptasyon drift’i artırabilir; mümkünse sabit veya sınırlı bitrate modunu test edin

Bu hedefleri uyguladığınızda “ses-video birbirinden kopuyor mu?” sorusu daha ölçülebilir hale gelir. Ayrıca ekip olarak düzenli kullanımda benzer toplantı tipleri için aynı ayar profillerini korumak, hatanın kalıcı şekilde azalmasına yardım eder.

Yaygın hatalar

En sık yapılan hatalar, sorunun kök nedenini bulmayı zorlaştırır. Şunlardan özellikle kaçının:

1) Sadece sesi/konuşma ayarlarını kurcalamak: Ekran paylaşımı A/V sync’i bozuyorsa asıl değişken video pipeline’dır. Ses işleme seçeneklerini değiştirmek bazen yardımcı olur; ama ilk adım çoğu zaman ekran paylaşımı FPS/çözünürlük ve cihaz performansıdır.

2) Wi‑Fi’yi “az etkileniyor” sanmak: A/V drift genellikle bant genişliği doygunluğu + jitter kaynaklıdır ve kullanıcılar bunu tek bir kopma gibi görmeyebilir. Yine de yalnızca genel bağlantı stabil görünüyor olsa bile jitter buffer büyüyebilir.

3) Çok agresif çözünürlük/FPS istemek: 1080p 60 FPS gibi hedefler özellikle dizüstü ve çoklu monitörde encode maliyetini yükseltebilir. Sonuç: Freeze ile A/V sync drift arasında gidip gelen bir tablo oluşabilir.

4) VPN’i düşünmeden açık bırakmak: Rotanın değişmesi ve ek gecikme jitter’i artırarak senkronu bozabilir. Sorun teşhisinde VPN’i kapatıp testi karşılaştırmak pratik bir yöntemdir.

Sık sorulan sorular (SSS)

Ses önde mi, video önde mi olduğuna nasıl karar verilir?

En net yöntem, konuşan kişinin ağız hareketlerini ve ses başlangıcını aynı anda izlemektir. Ses başlıyor ama ağız hareketi gecikiyorsa ses öndedir; ağız hareketi başlıyor ama ses gelmiyorsa ses arkadadır. Mümkünse ekran paylaşımı sırasında birkaç belirgin hece/kelimeyle “başlangıç anını” gözünüzde canlandırın.

A/V sync bozulması donma (freeze) ile aynı şey mi?

Hayır. Freeze görüntünün takılmasıdır; latency gecikmenin artmasıdır; drift ise ses-video arasındaki farkın zamanla büyümesidir. Freeze bazen aynı anda görünse de çözüm yaklaşımı farklı olabilir.

VPN kullanmak senkronu bozar mı?

Evet, özellikle jitter ve RTT’yi artırıyorsa. VPN rota değişimleri paketlerin geliş zamanlarını düzensizleştirerek video buffer’ının büyümesine ve drift’e yol açabilir. Test için kısa süreli VPN kapatma karşılaştırması yapın.

Wi‑Fi yerine kabloya geçince düzelmezse bir sonraki adım ne?

Kabloya geçtiğinizde sorun düzelmediyse önce cihaz tarafını inceleyin: ekran paylaşımı FPS/çözünürlük düşürme, donanım hızlandırma kontrolü, arka plan CPU/GPU yükünü azaltma. Ayrıca uygulama içi düşük gecikme/performans modlarını denemek (sonra metriklerle karşılaştırmak) iyi bir sonraki adımdır.

Ekran paylaşımı FPS/çözünürlük ayarını düşürmek neden işe yarar?

Encode süresini ve gönderilen veri miktarını azaltır. Böylece video pipeline “yetişme” zorluğu yaşamaz; jitter buffer’a daha az ihtiyaç duyulur. Sonuç: ses-video arasındaki zaman çizgisi daha stabil olur.

Donanım hızlandırmayı kapatmak mı açmak mı daha doğru?

Çoğu zaman donanım hızlandırma yardımcı olur; ancak bazı sürücü/cihaz kombinasyonlarında encode tarafında sorun çıkarabilir. En doğrusu: açık/kapalı testi kısa süreli yapıp FPS, encode gecikmesi ve A/V farkını gözlemlemektir.

Uygulama içi “düşük gecikme”/“performans” modu senkronu artırır mı?

Her zaman. Düşük gecikme modları buffer’ı kısaltıp drift riskini artırabilir ya da ağ stabil ise senkronu iyileştirebilir. Bu yüzden modu değiştirip metriklerle (jitter, FPS dalgalanması, A/V farkı) kısa test yapın.

Sadece bir katılımcıda mı oluyor? O zaman nasıl analiz edilir?

O katılımcının cihaz performansı (CPU/GPU), ekran paylaşımı yakalama ayarları ve ağ yolu öne çıkar. Uygun test: aynı toplantıda diğer kullanıcılar aynı video paylaşımını açsın, ardından birinizde mi birinizde mi olduğunu doğrulayın. Metin/ekran yerine “sabit bir uygulama penceresi” paylaşımıyla kıyas yapmak da yardımcı olur.

Özet + kısa kontrol listesi

A/V sync bozulduğunda ekran paylaşımı “ek bir video pipeline” eklediği için sorun çoğu zaman encode/ekran yakalama yükü veya ağ jitter/buffer birikiminden kaynaklanır. Anahtar soru şu: Ses mi önde/arkada? Anlık mı, zamanla büyüyen drift mi? Bu ayrım, doğru çözüm sıralamasını belirler.

Kontrol listesi:

• Ekran paylaşımı açılmadan önce/sonra FPS, jitter, packet loss farkına bak.
• FPS/çözünürlüğü düşürerek encode ve bant genişliği yükünü azalt.
• Wi‑Fi yerine Ethernet test et; düzeliyorsa ağ stabilitesi ana neden olabilir.
• Cihazda arka plan yükünü kapat, donanım hızlandırmayı açık/kapalı test et.
• Anlık bozulma → yeniden hizalama/pipeline geçişi; drift artışı → buffer/clock drift ve adaptif uyumsuzluk şüphesi.

Ek bir performans yaklaşımı isterseniz şu rehberler de işinize yarayabilir: düşük gecikmeli sohbet nasıl kurulur ve ekranda akış kalitesini etkileyen sistemsel bağlantı konuları için NAT Traversal (STUN/TURN/ICE) gecikme ve kopmalar: gerçek nedenler ve optimizasyonlar.