Mikrofon-sunucu tarafı senteziyle mobil canlı yayının gerçekleştirilmesi
Giriş: Bu makale, Sunucu (UpServer) tarafından gerçekleştirilen ses ve video sentezinin işlem ve ayrıntılarını paylaşan, mikrofon uygulama serisini bağlayan bir mobil canlı yayın serisinin ikincisidir. Daha önce, ses ve video sentezinin birkaç gerçekleştirme fikri ve bağlantıya katılan istemci rolü ve sunucu rolü dahil olmak üzere mobil canlı yayın bağlantısının gerçekleştirilmesinin genel durumunu tanıtmıştık. Ayrıntılar için lütfen "Mobil Canlı Yayın Bağlantısı Uygulama Fikri: Genel" e bakın.
Bu makalenin içeriği UpServer ses ve video sentezini, A çapa ses ve video sentezini, B çapa ses ve video sentezini ve zaman damgası uygulamasına giriş içerir. İlk olarak, daha karmaşık video sentezini analiz edin ve ardından daha kolay ses sentezini açıklayın.
Sunucu (UpServer) ses ve videoyu sentezlemek için kullanıldıktan sonra, UpServer sentezlenmiş veri akışını DeliveryServer kümesine gönderir ve ardından DeliveryServer bunu mobil canlı yayının tüm izleyicilerine dağıtır. DeliveryServer kümesi ve sonraki push çalışması, ses ve video sentezini içermez ve Lianmai ile hiçbir ilgisi yoktur. Bu makalenin kapsamına ait değildir ve açıklanmayacaktır. Yapı şeması yalnızca DeliveryServer'a çekilmiştir. Umarım anlarsınız.
UpServer video sentezi
Video, çözünürlük, kare hızı, renk alanı, görüntü konumu vb. Gibi temel parametrelerle tanımlanır. Bu parametreler, video sentezi işleminden önce belirlenmelidir. UpServer video sentezi işleminin açıklamasını kolaylaştırmak için, mobil canlı yayın bağlantısının mevcut ortak durumuna atıfta bulunarak, video parametreleri aşağıdaki gibi önceden tanımlanmıştır.
-
A ana bilgisayar video verilerinin yüksekliği ve genişliği, tam ekran görüntüleme için alt katmana yerleştirilen 640 * 360 (16: 9) 'dur.
-
B ana bilgisayar video verilerinin yüksekliği ve genişliği hem 160 * 120'dir (4: 3) ve görüntü konumu en üst katmandadır.
-
Birden fazla B bağlantı videosu olduğunda, B1 / B2 / B3 bağlantılarının görüntü konumları, her bağlantı için 1 piksellik ve alt kenarda 100 piksellik bir aralıkla sağda sırayla düzenlenir.
-
Yatay yönde, tüm B tutturucuları boşluk bırakmadan sağda görüntülenir.
-
Gösterim sekansı, alt kısımda B1 veya alt kısımda B3 olabilir, ancak birçok durumda mikrofona bağlı yalnızca bir B çapası vardır, bu nedenle B1 genellikle alt kısımda görüntülenecek şekilde düzenlenir.Alıcı, A çapasının video görüntüsü üzerinde en az etkiye sahip olmasıdır.
-
Bağlantı A ve bağlantı B'nin video kare hızı saniyede 20 karedir ve renk alanı I420'dir.
Yukarıdaki parametrelerin yalnızca UpServer videoları sentezlerken değil, aynı zamanda A ve B bağlantılarının videolarını sentezlerken de kullanılması gerekir.
Çap A ve tutturucu B'nin çözünürlüğü yukarıdaki tanımı karşılamıyorsa, uygun şekilde ölçeklendirilmesi gerekir; renk alanı tutarsızsa, önce dönüştürülmesi gerekir. Video verilerinin yüksekliğinin ve genişliğinin ekranın yüksekliğinden ve genişliğinden farklı olduğuna dikkat edin En boy oranı aynı olduğunda, video görüntüsü OpenGL'nin kendi ölçeklendirmesiyle çizilebilir ve özel ekran çözünürlüklerinin uyarlanması için ekstra bir iş yükü vardır.
Video kare hızı farklıdır.İşlemi basitleştirmek için kare eklemeye gerek yoktur.A ana bilgisayarın video kare hızına göre sentezlenebilir, yani B1 / B2 / B3 videoları A ana bilgisayarın video görüntüsü ile birleştirilir ve A ana bilgisayarın video kare hızı bileşiktir Video kare hızı dolduktan sonra. Birleştirmek için temel harita olarak bir ana makine video görüntüsünü kullanın. Bir ana makinenin video verisi yoksa, sentez duraklatılacaktır. Bir B ana makinesinin yeni video verisi yoksa, önceki kare yine de çoğullanacaktır. Efektten, B ana bilgisayar video kartıdır Yaşamak.
Video görüntüleri bellekte satırlar halinde saklanır ve sol alt köşenin veya sol üst köşenin başlangıç noktası olduğu iki durum vardır, yani karşılaştığınız belirli yapılar olan sol alt yapı ve sol üst yapı. Aynı zamanda, I420 renk uzayındaki YUV'nin birden çok düzlemde depolandığı ve görüntü sentezlendiğinde her düzlemin ayrı ayrı işlenmesi gerektiğine dikkat edilmelidir.Y düzlemi ile UV düzleminin sıra ve sütun sayıları da farklıdır.
Aşağıdaki örneğimizde, video görüntüsü depolama sol üst köşeden (sol üst yapı) başlar, sırasıyla A, B1, B2 ve B3 ile temsil edilen görüntü ara bellek çoğullama rolü tanımlanır ve sentezlenen video görüntüsü VideoMixer'da depolanır. UpServer sırasıyla A, B1, B2 ve B3'ün video veri akışlarını aldığında ve her bir görüntü karesinin kodunu çözdüğünde, Şekil 1'de gösterildiği gibi video sentezini başlatabilir.
Şekil 1 Tüm çapa video veri yapısı diyagramının UpServer sentezi
UpServer kompozit videonun temel süreci aşağıda açıklanmıştır.
-
İlk olarak, ses ve video senkronizasyonuna göre, bileşik temel harita olarak A çapasının video verilerini okuyun.İki başarı ve başarısızlık durumu vardır. Okuma başarılıysa, 4. adıma gidin ve başarısız olursa 2. adıma gidin.
-
Bağlantı A'nın video görüntü verilerini okurken başarısız olurken, ses ve video senkronizasyonuna göre bağlantı B'nin tüm video verilerini okumaya devam edin Okuma başarılı olursa, sonraki sentezde çerçevenin kullanılmasının neden olduğu senkronizasyon dışı fenomeni önlemek için video çerçevesinin atılması gerekir. .
-
Tüm B çapa video verileri okunduğunda, bu video sentezi turu başarısızlıkla sonuçlanır. Video sentezi temel görüntüye bağlıdır ve hiçbir A bağlantı videosu sentezlenemez.
-
A görüntüsünün üst kısmındaki 58 satırı VidoeMixer'a kopyalayın. Satır sayısı için hesaplama formülü 640-160 * 3-1 * 2-100 = 58'dir. Lütfen her bir değerin anlamı için parametre tanımına bakın. Bunu anlamış olmalısınız ve ayrı olarak açıklamamalısınız.
-
Sonra sentez için B3 çapasının video verilerini okuyun.İki başarı ve başarısızlık durumu vardır.Adım 7'de başarılı olursanız, iki başarısızlık durumu vardır, biri önceki kare diğeri değildir. Evet ise, 7. adıma ilerleyin; B3 çapası yoksa veya yoksa, 6. adıma bakın.
-
B3 videosunun okunması başarısız olursa ve önceki çerçeve yoksa veya bağlantı mevcut değilse, A'nın video görüntüsünün 161 satırını (160 + 1) VidoeMixer'a doğrudan kopyalayın.
-
B3 video verileri başarılı bir şekilde okunursa veya önceki bir çerçeve varsa, B3 ve A bağlantı video görüntüleri satırlar halinde sentezlenir ve her satırın kopyalanması için 2 bölüme ayrılması gerekir. İlk bölüm A video verilerini VidoeMixer'a kopyalar, kopya sütun sayısı 360'tır -120 = 240; İkinci bölüm B3 video verilerini 120 sütun VidoeMixer'a kopyalar.
-
B3 video verileri başarılı bir şekilde okunursa, sonraki okuma başarısız olduğunda önceki çerçeveyi yeniden kullanmak için B3'ün video verileri sentezden sonra belirtilen konuma yedeklenmelidir; B3 sunucusu mikrofonu bağlamayı bıraktığında veya uzun süre takılı kaldığında, Belirsizliği önlemek için veri önbelleğinin temizlenmesi gerekir.
-
Ardından, B3 ve B2 arasındaki aralığı, yani A'nın video verilerini 1 satır VidoeMixer'e kopyalayın.
-
5-9 adımlık süreci dolaştırın, B2, B2 ve B1 aralığının video verilerini (1 satır A) VidoeMixer'a kopyalayın; tekrar döngü yapın, B1, B1'in (100 A satırı) alt kısmının video verilerini VidoeMixer'a kopyalayın .
-
Yukarıdaki işlemi kullanarak, "A + B1 + B2 + B3" video görüntü sentezi tamamlanır ve sentez sonucu VidoeMixer'da saklanır.
"A + B1 + B2 + B3" video görüntüsünü oluşturduktan sonra, UpServer'ın video veri akışını kodlaması ve paketlemesi ve mobil canlı yayın kullanıcılarının Lianmai videosunu izleyebilmesi için bunu DeliveryServer'a göndermesi gerekir.
Çapa A'nın diğer B çapalarının videolarını da izlemesi gerekir, ancak "A + B1 + B2 + B3" video görüntüsünün kullanılıp kullanılmayacağı tartışılmalıdır. Yöntem karmaşıklık açısından farklıdır ve ayrıntılar, Çapa video sentezi bölümünde açıklanacaktır. Her B çapası aynı zamanda A çapasının ve diğer B çapalarının videolarını da gösterir.Kişisel olarak "A + B1 + B2 + B3" video veri akışı kullanımının talebi karşılayabileceğini düşünüyorum.Özel ayrıntılar B çapa video sentezi bölümünde açıklanmıştır.
Bir sunucu videosu
Bir toplantı sahibinin video verilerini işleme üç bölüme ayrılır: gönderme, alma ve görüntüleme. Gönderme bağlantısı toplama, kodlama, paketleme ve göndermeyi içerir. Alma bağlantısı, alma, zaman damgasına göre senkronizasyon, paket açma ve kod çözmeyi içerir. Görüntüleme bağlantısı yerel video görüntülerini ve Uzak video görüntülerinin sentezi ve gösterimi.
Gönderen kısımda, UpServer videonun birleştirilmesinden sorumlu olduğunda, Anchor A'nın toplanan yerel videoyu kodlaması ve belirtilen kapsülleme formatına göre paketlemesi ve ardından UpServer'a göndermesi gerekmektedir.İşlem yapısı Şekil 1'de gösterilmiştir. Bu bölümün canlı yayın bağlantısıyla çok az ilgisi vardır ve tek bir çapa canlı yayın süreciyle tutarlıdır.
Şekil 2'de gösterildiği gibi, A çapasının alıcı kısmı, ilk önce UpServer tarafından itilen B sabitleyicisinin video verilerini alır ve ardından zaman damgasına göre eşzamanlı olarak okur, paketlerini açar ve kodunu çözer. Bağlantı A için UpServer tarafından itilen video veri içeriği aşağıdaki üç türe sahip olabilir: Veri içeriği farklıysa, bileşik görüntü parçasının işleme akışı da farklıdır.
Şekil 2 UpServer sentezi, Bir ana bilgisayar alan video yapısı diyagramı
-
Birinci tür olan UpServer, sıradan izleyicilere gönderilen videonun aynısı olan, sentezlenmiş tüm video verilerini "A + B1 + B2 + B3" iter;
-
İkinci tür olan B1 / B2 / B3 video veri akışı bağımsız olarak itilir, yani UpServer, her B çapasının videosunu doğrudan A çapasına iletir;
-
Üçüncü türde UpServer, boyut ve görüntü konumuna göre B1 / B2 / B3 videoyu bir video veri akışında birleştirir ve video veri akışını bir ana bilgisayara iletir.
Yukarıda bahsedilen Çapa A tarafından alınan üç video veri akışı formatını birleştiren Çapa A'nın bileşik ekran bölümünü paylaşalım ve artılarını ve eksilerini açıklayıp karşılaştıralım.
Öncelikle önermediğim formu kısaca tanıtacağım UpServer, birden fazla B çapanın videosunu video boyutuna ve görüntü konumuna göre tek bir video akışında birleştiriyor.Bu yöntemin dezavantajı, UpServer üzerindeki baskının önemli ölçüde artmasıdır. UpServer, her Lianmai için video sentezi çalışması yapmış ve ardından A çapası için başka bir kanal sentezlemiştir. Video sentezi ve kodlama ve gönderme açısından daha fazla baskı altına girmiştir.Sunucunun sentezindeki en büyük darboğaz, UpServer sunucusunun işlem kapasitesidir. Bu nedenle, yükünü artıran herhangi bir davranış göz ardı edilmelidir. Aynı zamanda bu modda Çapa A'nın kod çözme ve sentez sürecinde herhangi bir değişiklik olmaz ve CPU kullanımı temelde azaltılmaz, bu nedenle tavsiye edilmez.
Daha sonra, UpServer'ın sentezlenmiş tüm videoları "A + B1 + B2 + B3" bir çapaya ittiği formatı tanıtacağız. Şu anda, UpServer daha fazla tüketim olmadan yalnızca bir veri akışı aktarımı ekliyor, bu da kabul edilebilir bir yoldur. Ancak bu yöntem, bir toplantı sahibinin görüntü sentezine çok fazla baskı uygular. Yerel videonun gerçek zamanlı performansını sağlamak için, temel haritanın A video görüntüsünün toplanması gerekir, bu nedenle görüntüyü sentezlemeden önce görüntüyü kesmeniz gerekir. Belirli adımlar aşağıdaki gibidir:
-
B1, B2 ve B3'ün 3 bağımsız videosunu elde etmek için "A + B1 + B2 + B3" deki A'yı çıkarın; videolar satırlar halinde depolandığından, bağımsız videolar elde etme süreci yalnızca her satırda döngü halinde olabilir , Gerekli video verilerini alın.
-
En son yakalanan Anchor videoyu kullanın, yukarıda elde edilen B1, B2 ve B3 videoları birleştirin ve ilk bölümde açıklanan video görüntülerini tekrar birleştirerek "Yeni A + B1 + B2 + B3" elde edin. Bu şekilde, sonraki görüntüleme işleminde çok az fark vardır, OpenGL aracılığıyla UI'ye "yeni A + B1 + B2 + B3" çizmeniz yeterlidir.
Son olarak, UpServer her B çapanın videosunu doğrudan A çapasına iletir.Bu yöntemle ilgili sorun, üç yönlü veri akışı itildiğinde, A çapanın ağ paketi kaybı (paket kaybı alma) ve zaman damgası senkronizasyon kontrolünün daha zahmetli olmasına karşın, kod çözme ve sentezde daha zahmetli olmasıdır. Öte yandan, sorun büyük değil ve UpServer sunucusu üzerindeki baskı da çok az. Spesifik uygulama süreci, birinci bölümde video görüntü sentezinin girişine atıfta bulunabilir.
Özetle, UpServer B çapa video verilerini ittiğinde, karşılaştırmadan sonra birinci veya ikinci yöntemi, özellikle de UpServer'ın her B çapa videosunu doğrudan A çapasına ilettiği yöntemi (ikinci yöntem) seçmeniz önerilir, çünkü ilk itme Çapa A için tüm sentezlenmiş videolar "A + B1 + B2 + B3" biçiminde bir kusur vardır. Örneğin, B2 çapası bir sürekli buğday bağlantısından sonra durursa, UpServer ve A çapasının mesajı aldığı zaman farklıdır. İki durum olacaktır:
-
UpServer, B2 videosunu sentezlemeyi durdurur, ancak Bağlantı A yine de sentezler ve görüntüler; Bağlantı A, B2 videosunu çektiğinde, A'nın görüntüsünü alır, bu nedenle Bağlantı A, B2 alanını sentezlediğinde, A'nın kendi tarihsel görüntüsünü kullanır.
-
UpServer B2 videosu çizmeyi durdurmaz, ancak Çapa A artık çizim yapmaz, Çapa A B2 videonun son birkaç karesini görmez.
Yukarıdaki iki durum, mesaj alma ve işleme süresindeki farklılıktan kaynaklanmaktadır, bu nedenle bunlar çok kısa ömürlü olacak ve yalnızca kusurlara ait olacaktır. Her bir B çapasının videosunu doğrudan A çapasına iletmek için UpServer'ı kullanmak, çünkü her veri akışı bağımsızdır, böyle bir kusur yoktur.
B bağlantı videosu
B çapa videosunun işleme süreci temelde iki bölümün gönderilmesi, alınması ve görüntülenmesi olarak ikiye ayrılır. Gönderen kısım da toplanır, kodlanır, paketlenir ve gönderilir, bu da A ana bilgisayar işlemiyle tutarlıdır. Alım ve görüntüleme açısından Çapa A ile karşılaştırıldığında, Çapa B'nin videosu tüm sentezlenmiş videoların üstünde görüntülenir, bu nedenle işleme süreci nispeten basittir. Örneğin B1 çapasını ele alırsak, iki yol vardır:
-
Birincisi, UpServer'ın Şekil 3'te gösterildiği gibi sıradan izleyicilere gönderilen video akışıyla aynı olan sentezlenmiş tüm videoları "A + B1 + B2 + B3" i itmesidir;
Şekil 3 UpServer sentezi, B1 çapası alma video yapısı diyagramı
-
İkinci tür olan Çapa A, B2, B3 bağlantı video veri akışları bağımsız olarak itilir, yani UpServer diğer bağlantıların videolarını doğrudan B1 bağlantılarına iletir.
Eliminasyon yöntemi hakkında konuşmama izin verin. Çapa A, B2, B3 çapaları video veri akışlarını bağımsız olarak itiyor.Bu yöntemin belirgin bir avantajı yoktur.Ses de bağımsız olarak gönderiliyorsa, ses ve video senkronizasyonu biraz daha iyi olabilir; dezavantaj B1 çapasının 3 kanal video verisi alması gerektiğidir. Verileri yayınlayın ve okuyun, görüntüleri zaman damgasına göre eşzamanlı olarak çözün ve sentezleyin, böylece B1 çapası daha fazla CPU tüketir.
İkinci olarak, UpServer sentezlenmiş tüm videoları "A + B1 + B2 + B3" yöntemine B1 iter. Bu yöntemde, B1 sunucusunun yalnızca bir veri kanalını okuması ve kodunu çözmesi gerekir ve ardından veri sentezi yalnızca B1'deki uzak videonun yerini alır. Yerel toplama için işlem basit ve kolaydır; bu yöntemde, sentezlenen videonun ses ve video senkronizasyonu, Çapa sesine başvurarak tamamlanabilir.Ayrıntılar için sonraki bölümlere bakın.
Özet olarak, UpServer'ın tüm sentezlenmiş video veri akışlarını B1 bağlantılarına iten yöntemini seçmeniz önerilir, böylece B1 diğer Lianmai bağlantı videolarını izleyebilir. B2 ve B3 çapalarının uygulanması, B1 çapalarınınki ile aynıdır.
UpServer ses sentezi
Ses ayrıca örnekleme frekansı, örnekleme noktalarının sayısı, kanal sayısı, her çerçevenin uzunluğu gibi bazı temel parametrelerle tanımlanır. UpServer ses sentezi işleminin açıklamasını kolaylaştırmak için, yukarıdaki parametreleri tanımlamak için mobil canlı yayın bağlantısının genel durumuna bakın: örnekleme frekansı 48KHz, örnekleme noktalarının sayısı 16 bit (2 bayt) ve kanal sayısı 2'dir (stereo). Her çerçevenin uzunluğu 8192 bayttır (kodlama için) ve saklama sırası sol ve sağ kanallar için örnekleme noktaları ile taranır.
Ses veri akışı sentezleme süreci videodan daha basittir, çapa türleri arasında ayrım yapmaz ve yukarıdaki parametrelere göre toplar, sentezler ve oynatır, yani tüm çapalar tutarlıdır.
Ses sentezinden önce, ilk olarak çok kişili konuşma veri sentezi algoritmasını tanıtın.Herkes, doğrudan toplama, maksimum değeri alma, doğrusal üst üste binme sonrası ortalama alma, normalleştirilmiş karıştırma (uyarlamalı ağırlıklı karıştırma algoritması) vb. Gibi birçok ses sentezi algoritması olduğunu bilir. , Farklı algoritmaların karmaşıklığı ve özellikleri farklıdır ve uygulanabilir senaryolar da çok farklıdır. Burada sadece daha basit ses sentez algoritmaları tanıtılmaktadır: doğrudan toplama algoritması ve maksimum değer algoritması Diğer algoritmaların tanıtımı bu makalenin kapsamı dışındadır, lütfen kendiniz öğrenin.
Doğrudan ekleme, adından da anlaşılacağı gibi, doğrudan iki ses verisi kanalını birbirine eklemektir.İki veri kanalının örnekleme noktalarının her ikisi de 16 bit olduğundan, sonuç da 16 bittir, bu nedenle ekleme verileri aşabilir.Koruma yöntemi verileri yargılamaktır. Taşma, sonucu maksimum değere ayarlar. Bu algoritmanın dezavantajı popülasyonunun kolay olmasıdır.Avantajı, algoritmanın basit olması ve her kanalın veri sentezinden dolayı ses kaybının çok az olmasıdır.
Maksimum değeri alın İki veri kanalı sentezlendiğinde, maksimum değer noktaları örnekleme ile elde edilir ve sentez sonucuna kaydedilir. Daha küçük değerlere sahip örnekleme noktaları atıldığı için bu algoritmanın dezavantajı ses verilerinin daha bozuk olmasıdır; avantajı ise algoritmanın basit olması ve patlamanın neden olduğu taşma olmamasıdır.
Yukarıdaki iki algoritma sadece iki kanallı ses sentezi için değil, aynı zamanda çok kanallı ses sentezi için de uygundur. Aşağıdaki ses verilerini sentezlerken, varsayılan olarak doğrudan toplama algoritmasını kullanırız.
Her bir çapa ses arabellek çoğullamasının rol tanımı A, B1, B2 ve B3 ile temsil edilir ve sentezlenen ses verileri AudioMixer'da depolanır. UpServer, A, B1, B2 ve B3'ün ses veri akışlarını aldıktan ve her veri çerçevesinin kodunu çözdükten sonra, Şekil 4'te gösterildiği gibi ses sentezini gerçekleştirebilir. Ses sentezinin temel akışı aşağıdaki gibidir.
Şekil 4 Tüm çapa ses veri yapısı diyagramının UpServer sentezi
-
Önce sentezlenebilecek ses verilerini bulun, yoksa sentezlemenize gerek yoktur. Yalnızca bir kanal ses verisi varsa, bunları sentez yapmadan doğrudan AudioMixer'a kopyalayın.
-
Ses verisi sentezi için ikiden fazla kanal olmalıdır Genel olarak, A çapası önce B1 çapası için aranır ve bu şekilde, sentezlenebilecek tüm ses verileri bulunana kadar devam eder.
-
Tüm örnekleme noktalarında döngü oluşturarak, her bir çapanın ses verilerini doğrudan ekleyerek ve sonucu AudioMixer'a koyarak, ses verisi sentezi tamamlanmış olur; doğrudan ekleme algoritmasının ses verilerinin taşmasını önlemesi gerekir, bu yüzden dikkatli olun.
Tüm bağlantıların ses verileri varsa UpServer, ses sentezinden sonra "A + B1 + B2 + B3" ses verilerini alır ve ardından mobil canlı yayın kullanıcılarının sesi dinlemesi için ses verilerinin kodlanması, paketlenmesi ve DeliveryServer'a gönderilmesi gerekir. .
Çapa A'nın diğer B çapalarının seslerini de duyması gerekir, ancak kullanıcı deneyimi nedeniyle "A + B1 + B2 + B3" ses verilerini kullanamaz. Çapa A kendi sesini duymak istemez (yankıya benzer), bağlantı B Benzer bir problem de mevcuttur, yani tüm çapalar yukarıda sentezlenen ses verilerini kullanamaz.
Ses sentezlendikten sonra onu çıkarmak son derece zordur, bu nedenle A çapasının sesi "A + B1 + B2 + B3" ses verilerinden çıkarılır ve hiçbir girişim yapılmaz.
Çapa A ve çapa B arasında birbirlerinin sesini dinleme sorununu çözmek için, belirtilen ses veri akışı yöntemini sentezlemek için UpServer'ı kullanabilir veya her çapa bağımsız olarak ses verilerini gönderme ve her çapa tarafından sentezleme yöntemini kullanabilirsiniz.
Çapa sesi
Aşağıda Çapa A'nın ses işleme süreci açıklanmaktadır. Çapa A tarafından toplanan sesin dinlediği uzak uç sesle (B1 / B2 / B3) karıştırılmasına gerek olmadığından işleme süreci videodan çok farklıdır.
Toplama açısından, Anchor Anın ses toplama süreci nispeten basittir, yerel ses toplama, kodlama, paketleme ve mobil canlı yayınla aynı olan UpServer sunucusuna gönderme.
Mobil canlı yayın, kod çözme ve oynatma için gereken ses oynatma kısmı, UpServer tarafından gönderilen veri akışı yöntemine bağlıdır; bunların çoğu sıradan mobil canlı yayın kullanıcıları tarafından kullanılır; yalnızca ses veri sentezi Lianmai'nin özel bağlantısı burada ayrıntılı olarak açıklanmıştır.
A. Çapanın sentezlenmesi gerekip gerekmediği, UpServer tarafından gönderilen veri akışına bağlıdır, bu nedenle önce UpServer'ın ses veri akışını iletmek için olası yollarını tanıtın:
-
Yöntem 1, sentezlenmiş ses verileri, yani UpServer tarafından sentezlenen ve Çapa A'ya gönderilen "B1 + B2 + B3" ses verileri. Bu şekilde, Çapa A'nın doğrudan çalmak için sentezlenmesine gerek yoktur;
-
İkinci yöntem, bağımsız ses veri akışı, UpServer yalnızca B1 / B2 / B3'ün ses verilerini sentez yapmadan iletir Bu anda, Şekil 5'te gösterildiği gibi, A çapasının B1 / B2 / B3'ün ses verilerini çalmadan önce sentezlemesi gerekir.
Şekil 5 UpServer sentezi, Bir ana bilgisayar ses yapısı diyagramını alır
Yöntem 1, mobil canlı yayın kullanıcılarının işlemiyle aynıdır Çapa A'nın işlenmesi çok basittir, ancak UpServer'ın artan kaynak tüketimi nedeniyle önerilmez. Mikrofonlu birden fazla B tutturucu olması durumunda, UpServer A bağlantısı için "B1 + B2 + B3" ses verilerini, B1 bağlantısı için "A + B2 + B3" ses verilerini sentezler ve B2 bağlantısı için "A + B1 +" sentezler B3 "ses verileri, B3 çapası için" A + B1 + B2 "ses verilerini sentezliyor. Birçok kez sentezlenmesi, kodlanması ve paketlenmesi gerekiyor. Karmaşıklık çok arttı.
İkinci yöntem UpServer, yalnızca B1 / B2 / B3'ün ses verilerini şeffaf bir şekilde iletir. Bir ana bilgisayarın, her B ana bilgisayarının ses verilerini sentezlemesi gerekir. Sentez algoritması, önceki bölümde açıklanan doğrudan toplama algoritmasını yeniden kullanır.Sentez işlemi ayrıca, ses verilerini UpServer ile sentezler. İşlem aynı, bu yüzden burada tekrar etmeyeceğim. Bu şekilde, UpServer'ın CPU tüketimi yüksek değildir, ancak ağ bant genişliği daha fazla kullanılmalıdır.Ses veri akışının daha düşük bir ağ trafiği kullandığı düşünüldüğünde, bu eksiklik kabul edilebilir.
Aralarındaki fark, kişisel bir öneri olan sunucunun kaynak kullanımını azaltmak için sunucu tarafındaki sentez çalışmasının ana bilgisayar tarafına aktarılmasıdır.
B bağlantı sesi
Ses açısından, video gösterimine benzer bir ana-köle ilişkisi yoktur.Tüm A çapaları ve B çapaları eşittir.Bu nedenle, B çapalarının ses işleme akışı ve mantığı temelde A çapalarınınkilerle aynıdır. Fark herkesin alması gerektiğidir. Veri akışı farklıdır B1 çapası "A / B2 / B3" ses verilerine ihtiyaç duyar, B2 çapası "A / B1 / B3" ses verilerine ihtiyaç duyar ve B3 çapası "A / B1 / B2" ses verilerine ihtiyaç duyar.
Uygulama ayrıntıları için lütfen önceki bölümdeki Çapa Ses Sentezinin girişine bakın.
Zaman damgası
Alıcı tarafın sesini ve videosunu oynatırken en iyi senkronizasyon efektini sağlamak için, paketleme için ortam veri iletim protokolünü kullanırken, yerel milisaniye zamanını bir zaman damgası (Zaman Damgası) olarak kapsüllemek gerekir.
Zaman damgasının iki yöntemi vardır: göreli zaman ve mutlak zaman. Göreli zaman 4 bayt olarak depolanır. İşaretsiz tür sıfırlanacak ve 50 günden fazla bir süre içinde yeniden biriktirilecektir. Bu noktanın uygulama sırasında korunması gerekir; mutlak süre 8 bayttır Depolama, sıfırlama konusunda endişelenmeyin, ancak biraz daha fazla ağ bant genişliği kullanın. İki yöntem arasında çok az fark vardır ve her ikisi de ses ve video senkronizasyon işlevini gerçekleştirebilir.
Mobil canlı yayının uzaktan ses ve video oynatmasında, zaman damgası aşağıdaki işlevlere sahiptir:
-
Ağ titreşiminin etkisinden kaçınmak için, oynatmadan önce uzak ortam verilerini arabelleğe almak gerekir ve ara belleğe alınan verilerin uzunluğu uzak zaman damgaları arasındaki fark hesaplanarak elde edilebilir.
-
Ses ve videonun oynatılıp oynatılamayacağına ilişkin yargı koşulu Arabelleğe alınan verilerin uzunluğu beklentiye ulaştığında veya yerel saat ile uzak zaman arasındaki fark beklentiye ulaştığında, ses ve video verilerinin oynatılabileceğini gösterir.
-
Kıyaslama olarak ses gibi, ses ve video senkronizasyonu oynatmanın yargı koşulu, ses zaman damgası sapmasını ve sesin oynatılabildiği video zaman damgasını karşılaştırır ve videoyu izin verilen aralıkta oynatma zamanı gelmiştir.
UpServer'ın önce ses ve video verilerini sentezlemesi ve ardından medya aktarım protokolüne göre yeniden paketlemesi gerektiğinden, aynı zamanda tekrar zaman damgası yapması gerekir ve belirli bir zamanı zaman damgası olarak kullanmak biraz karmaşıktır. UpServer için, ana bilgisayar zaman damgasını yeniden kullanmak veya yerel saati kullanmak üzere iki zaman damgası önerisi vardır. Her birinin avantajları ve dezavantajları vardır:
Yerel saat için, zaman damgası olarak doğrudan yerel milisaniye düzeyindeki saati kullanın. Avantajı, uygulanmasının basit olmasıdır. Yerel saati doğrudan edinebilir ve kullanabilirsiniz. İki dezavantaj vardır:
-
Ses ve video veri sentezi, kodlama vb. Video sentezi gibi çok zaman alacaktır, ses sentezi değil, işlem hızındaki farktan dolayı, ses ve videonun alıcı sonunun senkronizasyon dışına çıkmasına neden olabilir.
-
Veri sentezlemeye gerek olmadığında, örneğin ses verilerinin yalnızca iletildiği durumlarda zaman damgasını yeniden değiştirmek de gereklidir; şu anda, ağ titreşimi ve paket kaybı, zaman damgasını değiştirmede ciddi bir etkiye sahip olabilir.
Ana bilgisayar zamanı, ana bilgisayar ortam paketinde kapsüllenen zaman damgasını çoklar. Avantajı, sentez ve kodlama gibi işlemler için harcanan sürenin, alıcının ses ve videonun eşzamanlı oynatılmasını etkilememesidir. Ayrıca iki dezavantaj vardır:
-
Zaman damgası sürekliliği garanti edilemez.Ses sentezlendiğinde, çapa A zaman damgası kullanılıyorsa, ancak çapa A sıkışmışsa veya veri yoksa, sürekli olarak kullanılamaz. Şu anda, diğer B bağının sesleri hala sentezlenmektedir ve sürekli olarak üretilmesi gerekir. Zaman damgası.
-
Aynı çapanın ses ve videosunun bazen verileri sentezlemesi (sentetik video) ve bazen de verileri sentezlemesi (sesi bağımsız olarak göndermesi) gerekmez. Şu anda, sentezlenen video diğer bağlantıların zaman damgalarıyla çoklanır. Zaman damgaları arasında güçlü bir bağımlılık yoktur ve bu, oynatma sırasında eşzamansızlığa neden olabilir.
Yukarıdaki analize göre, ses ve video veri akışlarını sentezlemek için UpServer kullanımı ile birlikte, önerilen ortam veri aktarım içeriği ve zaman damgalarının kullanımı Tablo 1'de gösterildiği gibi sıralanır ve özetlenir.
Tablodaki tablolardan bazıları "A + B1 + B2 + B3" gibi UpServer tarafından sentezlenir ve bazıları "B1 / B2 / B3" gibi UpServer tarafından şeffaf bir şekilde iletilir. Zaman damgası türünün seçilmesinde birçok zorluk vardır. Kapsamlı bir değerlendirmeden sonra, iki türün birlikte kullanılacağı belirlenir. Zaman damgası sütunundaki açıklamaya bakın. Bu seçimin nedenleri aşağıdaki gibidir:
-
Alıcı DeliveryServer olduğunda, her bir çapa kısa bir süre için ses verilerine sahip olmayabilir. Şu anda ses, ses ve video senkronizasyonu için temel olarak kullanılır ve sürekli olarak zaman damgası olmalıdır. UpServer'ın yerel saatini kullanmak en mantıklıdır; ses ve video senkronizasyonu için video da UpServer yerel saatini kullanmalıdır.
-
Alıcı bir ana bilgisayar olduğunda, önerilen biçim, her B ana bilgisayarının ses ve video verilerini doğrudan A'ya göndermektir. Bu durumda, orijinal zaman damgasını yeniden kullanmak en mantıklı ve basittir;
-
Alıcı B çapası olduğunda, önerilen biçim video sentezi ve ses bağımsızlığıdır; ses bağımsızlığı zaman damgasını değiştirmez, ancak video sentezinden sonra, zaman damgası olarak UpServer'ın yerel saati seçilirse, ses ve video yalnızca A bağlantı videosuna güvenebilir. Senkronize edilemiyor, çünkü her B çapası aynı zamanda A çapasının sesini de dinlediğinden, video için A çapasının zaman damgasını kullanmak en uygun yöntemdir.
Yukarıdaki önerilere göre, video bileşik verileri "A + B1 + B2 + B3", farklı terminallere itildiğinde farklı zaman damgaları kullanır. DeliveryServer'ın video verileri, UpServer'ın yerel saatiyle zaman damgasına sahiptir ve her B çapasına itildiğinde yeniden kullanılır. Çapa zaman damgası, bu en mantıklı seçim mi? Derinlemesine çalışabilirsiniz.
postscript
Sunucu tarafı senteziyle ilgili olarak, yazar şahsen bir rezervasyona sahiptir.Lütfen kullanıp kullanmayacağınıza karar verin Bilinen dezavantajlar aşağıda listelenmiştir.
-
Sunucu performansı: UpServer'ın ses ve video kod çözme, sentez ve kodlama uygulaması gerekir, CPU kullanımı artar ve iş uygulama maliyetleri yüksektir.
-
Karmaşıklık: Hem ana bilgisayar hem de kullanıcı tarafında en iyi kullanıcı deneyimini elde etmek için, her terminalin veri akışları için farklı gereksinimleri vardır ve yalnızca her bir terminal türü tek tek uyarlanabilir.Sunucunun ve ana bilgisayarın uygulama karmaşıklığı hem yüksektir.
-
Zaman damgası: Farklı veri akışlarında, ses ve video senkronizasyonunu sağlamak için farklı terminaller farklı zaman damgaları gerektirir.Zaman damgalarının üretimi ve kullanımı dikkatlice değerlendirilmeli ve ayrıntılı olarak test edilmelidir.
-
Ana bilgisayar performansı: Ana bilgisayarın, video görüntülemek ve çok fazla CPU kaynağı alan sesi oynatmak için ses ve videoyu sentezlemesi gerekir; Bir ana bilgisayarın performansı ve karmaşıklığı açısından, A ana bilgisayar sentezine kıyasla küçük bir avantajı vardır.
Yazar hakkında: Gathering Bilim ve Teknoloji Enstitüsü'nün teknik direktörü Zhang Yawei, uzun yıllar boyunca platformlar arası canlı yayın geliştirme deneyimine ve teknoloji birikimine sahiptir. Sorumlu editör: Tu Min, hoş geldiniz teknik gönderimler, gönderimler ve makalelerdeki düzeltmeler, lütfen mobile@csdn.net adresine bir e-posta gönderin.
Mobil geliştirmeyle ilgili en son bilgiler ve teknolojiler için lütfen mobilehub genel WeChat hesabını (ID: mobilehub) takip edin.
