ויספאָרשן די Mediastreamer2 וואָיפּ מאָטאָר. טייל 6

דער מאַטעריאַל פון דעם אַרטיקל איז גענומען פון מיין זען קאַנאַל.

טראַנסמיטינג אַ אַודיאָ סיגנאַל דורך RTP טייַך

אין דער פאַרגאַנגענהייט אַרטיקל מיר האָבן פארזאמלט אַ ווייַט קאָנטראָל קרייַז פון אַ טאָן גענעראַטאָר און אַ טאָן דעטעקטאָר וואָס אַרבעטן אין דער זעלביקער פּראָגראַם. אין דעם אַרטיקל מיר וועלן לערנען ווי צו נוצן די RTP פּראָטאָקאָל (RFC 3550 - RTP: א טראַנספּאָרט פּראָטאָקאָל פֿאַר פאַקטיש-צייט אַפּלאַקיישאַנז) פֿאַר ריסיווינג / טראַנסמיטינג אַ אַודיאָ סיגנאַל איבער אַן עטהערנעט נעץ.

RTP פּראָטאָקאָל (פאַקטיש צייט פּראָטאָקאָל) איבערגעזעצט מיטל פאַקטיש-צייט פּראָטאָקאָל, עס איז געניצט צו אַריבערפירן אַודיאָ, ווידעא, דאַטן, אַלץ וואָס ריקווייערז טראַנסמיסיע אין פאַקטיש צייט. זאל ס נעמען אַן אַודיאָ סיגנאַל ווי אַ בייַשפּיל. די בייגיקייט פון דעם פּראָטאָקאָל איז אַזוי אַז עס אַלאַוז איר צו אַריבערפירן אַ אַודיאָ סיגנאַל מיט אַ פּרידיטערמינד קוואַליטעט.

די טראַנסמיסיע איז דורכגעקאָכט מיט UDP פּאַקיץ, וואָס מיטל אַז פּאַקאַט אָנווער איז גאַנץ פּאַסיק בעשאַס טראַנסמיסיע. יעדער פּאַקאַט כּולל אַ ספּעציעל RTP כעדער און אַ דאַטן בלאָק פון די טראַנסמיטטעד סיגנאַל. דער כעדער כּולל אַ ראַנדאַמלי אויסגעקליבן סיגנאַל מקור אידענטיפיצירן, אינפֿאָרמאַציע וועגן דעם טיפּ פון סיגנאַל טראַנסמיטטעד, און אַ יינציק פּאַקאַט סיקוואַנס נומער אַזוי אַז די פּאַקיץ קענען זיין עריינדזשד אין די ריכטיק סדר ווען דיקאָודינג, ראַגאַרדלאַס פון די סדר אין וואָס זיי זענען איבערגעגעבן דורך די כעדער. נעץ. דער כעדער קען אויך אַנטהאַלטן נאָך אינפֿאָרמאַציע, די אַזוי גערופענע פאַרלענגערונג, וואָס אַלאַוז די כעדער צו זיין צוגעפאסט צו נוצן אין אַ ספּעציפיש אַפּלאַקיישאַן אַרבעט.

די דאַטן בלאָק כּולל די פּיילאָוד פון די פּאַקאַט. די ינערלעך אָרגאַניזאַציע פון ​​אינהאַלט דעפּענדס אויף דעם טיפּ פון מאַסע, עס קענען זיין סאַמפּאַלז פון אַ מאָנאָ סיגנאַל, אַ סטעריאָו סיגנאַל, אַ ווידעא בילד שורה, עטק.

די מאַסע טיפּ איז ינדאַקייטיד דורך אַ זיבן-ביסל נומער. רעקאָמענדאַציע RFC3551 (RTP פּראָפיל פֿאַר אַודיאָ און ווידעא קאַנפראַנסאַז מיט מינימאַל קאָנטראָל) יסטאַבלישיז עטלעכע טייפּס פון מאַסע; די קאָראַספּאַנדינג טיש גיט אַ באַשרייַבונג פון די טייפּס פון מאַסע און די טייַטש פון די קאָודז דורך וואָס זיי זענען דעזיגנייטיד. עטלעכע קאָודז זענען נישט שטרענג טייד צו קיין טיפּ פון מאַסע; זיי קענען זיין געניצט צו דעזיגנייט אַ אַרביטראַריש מאַסע.

די גרייס פון אַ דאַטן בלאָק איז לימיטעד אויבן דורך די מאַקסימום פּאַקאַט גרייס וואָס קענען זיין טראַנסמיטטעד אויף אַ געגעבן נעץ אָן סעגמאַנטיישאַן (MTU פּאַראַמעטער). אין אַלגעמיין, דאָס איז ניט מער ווי 1500 ביטעס. אזוי, אין סדר צו פאַרגרעסערן די סומע פון ​​דאַטן טראַנסמיטטעד פּער סעקונדע, איר קענען פאַרגרעסערן די פּאַקאַט גרייס אַרויף צו אַ זיכער פונט, און דעמאָלט איר דאַרפֿן צו פאַרגרעסערן די אָפטקייַט פון שיקן פּאַקיץ. אין אַ מידיאַ סטרימער, דאָס איז אַ קאַנפיגיעראַבאַל באַשטעטיקן. דורך פעליקייַט עס איז 50 הז, ד"ה. 50 פּאַקיץ פּער סעקונדע. מיר וועלן רופן די סיקוואַנס פון טראַנסמיטטעד רטפּ פּאַקיץ אַ רטפּ טייַך.

צו אָנהייבן טראַנסמיטינג דאַטן צווישן די מקור און די ופנעמער, עס איז גענוג אַז די טראַנסמיטער ווייסט די IP אַדרעס פון די ופנעמער און די פּאָרט נומער וואָס ער ניצט פֿאַר ריסיווינג. יענע. אָן קיין פּרילימאַנערי פּראָוסידזשערז, דער מקור הייבט צו יבערשיקן דאַטן, און דער ופנעמער, אין קער, איז גרייט צו מיד באַקומען און פּראָצעס עס. לויט דער נאָרמאַל, די פּאָרט נומער געניצט צו אַריבערפירן אָדער באַקומען אַ RTP טייַך מוזן זיין גלייַך.

אין סיטואַטיאָנס ווו עס איז אוממעגלעך צו וויסן די ופנעמער ס אַדרעס אין שטייַגן, סערווערס זענען געניצט ווו ריסיווערז לאָזן זייער אַדרעס, און די טראַנסמיטער קענען בעטן עס דורך ריפערינג צו עטלעכע יינציק נאָמען פון די ופנעמער.

אין קאַסעס ווו די קוואַליטעט פון די קאָמוניקאַציע קאַנאַל אָדער די קייפּאַבילאַטיז פון די ופנעמער זענען אומבאַקאַנט, אַ באַמערקונגען קאַנאַל איז אָרגאַניזירט דורך וואָס די ופנעמער קענען מיטטיילן די טראַנסמיטער וועגן זייַן קייפּאַבילאַטיז, די נומער פון פּאַקיץ עס מיסט, אאז"ו ו. דער קאַנאַל ניצט די RTCP פּראָטאָקאָל. דער פֿאָרמאַט פון פּאַקיץ טראַנסמיטטעד אין דעם קאַנאַל איז דיפיינד אין RFC 3605. לעפיערעך קליין דאַטן זענען טראַנסמיטטעד איבער דעם קאַנאַל, 200..300 ביטעס פּער סעקונדע, אַזוי אין אַלגעמיין, זייַן בייַזייַן איז נישט בערדאַנסאַם. די פּאָרט נומער צו וואָס RTCP פּאַקיץ זענען געשיקט מוזן זיין מאָדנע און איינער גרעסער ווי די פּאָרט נומער פון וואָס די RTP טייַך קומט. אין אונדזער בייַשפּיל, מיר וועלן נישט נוצן דעם קאַנאַל, ווייַל די קייפּאַבילאַטיז פון די ופנעמער און קאַנאַל דאָך יקסיד אונדזער, אַזוי ווייַט באַשיידן, דאַרף.

אין אונדזער פּראָגראַם, די דאַטן טראַנסמיסיע קרייַז, ניט ענלעך דעם פריערדיקן בייַשפּיל, וועט זיין צעטיילט אין צוויי טיילן: אַ טראַנסמיטינג וועג און אַ ריסיווינג וועג. פֿאַר יעדער טייל מיר וועלן מאַכן אונדזער אייגענע זייגער מקור, ווי געוויזן אין די טיטל בילד.

איין-וועג קאָמוניקאַציע צווישן זיי וועט זיין דורכגעקאָכט מיט די RTP פּראָטאָקאָל. אין דעם בייַשפּיל, מיר טאָן ניט דאַרפֿן אַ פונדרויסנדיק נעץ, ווייַל ביידע די טראַנסמיטער און די ופנעמער וועט זיין ליגן אויף דער זעלביקער קאָמפּיוטער - די פּאַקיץ וועט אַרומפאָרן ין עס.

צו פאַרלייגן אַ RTP טייַך, די מידיאַ סטרימער ניצט צוויי פילטערס: MS_RTP_SEND און MS_RTP_RECV. דער ערשטער טראַנסמיטט די רגע און נעמט די RTP טייַך. כּדי די פילטערס זאָל אַרבעטן, זיי דאַרפֿן צו פאָרן אַ טייַטל צו אַ RTP סעסיע כייפעץ, וואָס קענען אָדער גער אַ טייַך פון דאַטן בלאַקס אין אַ טייַך פון RTP פּאַקיץ אָדער טאָן די פאַרקערט. זינט די ינערלעך דאַטן פֿאָרמאַט פון די מעדיע סטרימער שטימען נישט מיט די דאַטן פֿאָרמאַט פון די RTP פּאַקאַט, איידער טראַנספערינג די דאַטן צו MS_RTP_SEND, איר דאַרפֿן צו נוצן אַ ענקאָדער פילטער וואָס קאַנווערץ 16-ביסל אַודיאָ סיגנאַל סאַמפּאַלז אין אַכט-ביסל ענקאָודיד לויט ו-געזעץ (מו-געזעץ). אויף די ריסיווינג זייַט, די דיקאָודער פילטער פּערפאָרמז די פאַרקערט פונקציע.

ונטער איז דער טעקסט פון די פּראָגראַם וואָס ימפּלאַמאַנץ די סכעמע געוויזן אין די פיגור (די # סימבאָלס איידער די ינקלודז דיירעקטיווז זענען אַוועקגענומען, טאָן ניט פאַרגעסן צו אַרייַננעמען זיי):

/* Файл mstest6.c Имитатор пульта управления и приемника. */
#include <mediastreamer2/msfilter.h>
#include <mediastreamer2/msticker.h>
#include <mediastreamer2/dtmfgen.h>
#include <mediastreamer2/mssndcard.h>
#include <mediastreamer2/msvolume.h>
#include <mediastreamer2/mstonedetector.h>
#include <mediastreamer2/msrtp.h>
#include <ortp/rtpsession.h>
#include <ortp/payloadtype.h>
/* Подключаем заголовочный файл с функциями управления событиями
* медиастримера.*/
include <mediastreamer2/mseventqueue.h>
#define PCMU 0
/* Функция обратного вызова, она будет вызвана фильтром, как только он
обнаружит совпадение характеристик входного сигнала с заданными. */
static void tone_detected_cb(void *data, MSFilter *f, unsigned int event_id,
MSToneDetectorEvent *ev)
{
printf("Принята команда: %sn", ev->tone_name);
}
/*----------------------------------------------------------------------------*/
/* Функция регистрации типов полезных нагрузок. */
void register_payloads(void)
{
/*Регистрируем типы нагрузок в таблице профилей. Позднее, по индексу
взятому из заголовка RTP-пакета из этой таблицы будут извлекаться
параметры нагрузки, необходимые для декодирования данных пакета. */
rtp_profile_set_payload (&av_profile, PCMU, &payload_type_pcm8000);
}
/*----------------------------------------------------------------------------*/
/* Эта функция создана из функции create_duplex_rtpsession() в audiostream.c
медиастримера2. */
static RtpSession *
create_rtpsession (int loc_rtp_port, int loc_rtcp_port,
bool_t ipv6, RtpSessionMode mode)
{
RtpSession *rtpr;
rtpr = rtp_session_new ((int) mode);
rtp_session_set_scheduling_mode (rtpr, 0);
rtp_session_set_blocking_mode (rtpr, 0);
rtp_session_enable_adaptive_jitter_compensation (rtpr, TRUE);
rtp_session_set_symmetric_rtp (rtpr, TRUE);
rtp_session_set_local_addr (rtpr, ipv6 ? "::" : "0.0.0.0", loc_rtp_port,
loc_rtcp_port);
rtp_session_signal_connect (rtpr, "timestamp_jump",
(RtpCallback) rtp_session_resync, 0);
rtp_session_signal_connect (rtpr, "ssrc_changed",
(RtpCallback) rtp_session_resync, 0);
rtp_session_set_ssrc_changed_threshold (rtpr, 0);
rtp_session_set_send_payload_type(rtpr, PCMU);
/* По умолчанию выключаем RTCP-сессию, так как наш пульт не будет использовать её. */
rtp_session_enable_rtcp (rtpr, FALSE);
return rtpr;
}
/*----------------------------------------------------------------------------*/
int main()
{
ms_init();
/* Создаем экземпляры фильтров. */
MSFilter *voidsource = ms_filter_new(MS_VOID_SOURCE_ID);
MSFilter *dtmfgen = ms_filter_new(MS_DTMF_GEN_ID);
MSFilter *volume = ms_filter_new(MS_VOLUME_ID);
MSSndCard *card_playback =
ms_snd_card_manager_get_default_card(ms_snd_card_manager_get());
MSFilter *snd_card_write = ms_snd_card_create_writer(card_playback);
MSFilter *detector = ms_filter_new(MS_TONE_DETECTOR_ID);
/* Очищаем массив находящийся внутри детектора тонов, он описывает
* особые приметы разыскиваемых сигналов.*/
ms_filter_call_method(detector, MS_TONE_DETECTOR_CLEAR_SCANS, 0);
/* Подключаем к фильтру функцию обратного вызова. */
ms_filter_set_notify_callback(detector,
(MSFilterNotifyFunc)tone_detected_cb, NULL);
/* Создаем массив, каждый элемент которого описывает характеристику
* одного из тонов, который требуется обнаруживать: Текстовое имя
* данного элемента, частота в герцах, длительность в миллисекундах,
* минимальный уровень относительно 0,775В. */
MSToneDetectorDef scan[6]=
{
{"V+",440, 100, 0.1}, /* Команда "Увеличить громкость". */
{"V-",540, 100, 0.1}, /* Команда "Уменьшить громкость". */
{"C+",640, 100, 0.1}, /* Команда "Увеличить номер канала". */
{"C-",740, 100, 0.1}, /* Команда "Уменьшить номер канала". */
{"ON",840, 100, 0.1}, /* Команда "Включить телевизор". */
{"OFF", 940, 100, 0.1}/* Команда "Выключить телевизор". */
};
/* Передаем "приметы" сигналов детектор тонов. */
int i;
for (i = 0; i < 6; i++)
{
ms_filter_call_method(detector, MS_TONE_DETECTOR_ADD_SCAN,
&scan[i]);
}
/* Создаем фильтры кодера и декодера */
MSFilter *encoder = ms_filter_create_encoder("PCMU");
MSFilter *decoder=ms_filter_create_decoder("PCMU");
/* Регистрируем типы нагрузки. */
register_payloads();
/* Создаем RTP-сессию передатчика. */
RtpSession *tx_rtp_session = create_rtpsession (8010, 8011, FALSE, RTP_SESSION_SENDONLY);
rtp_session_set_remote_addr_and_port(tx_rtp_session,"127.0.0.1", 7010, 7011);
rtp_session_set_send_payload_type(tx_rtp_session, PCMU);
MSFilter *rtpsend = ms_filter_new(MS_RTP_SEND_ID);
ms_filter_call_method(rtpsend, MS_RTP_SEND_SET_SESSION, tx_rtp_session);
/* Создаем RTP-сессию приемника. */
MSFilter *rtprecv = ms_filter_new(MS_RTP_RECV_ID);
RtpSession *rx_rtp_session = create_rtpsession (7010, 7011, FALSE, RTP_SESSION_RECVONLY);
ms_filter_call_method(rtprecv, MS_RTP_RECV_SET_SESSION, rx_rtp_session);
/* Создаем источники тактов - тикеры. */
MSTicker *ticker_tx = ms_ticker_new();
MSTicker *ticker_rx = ms_ticker_new();
/* Соединяем фильтры передатчика. */
ms_filter_link(voidsource, 0, dtmfgen, 0);
ms_filter_link(dtmfgen, 0, volume, 0);
ms_filter_link(volume, 0, encoder, 0);
ms_filter_link(encoder, 0, rtpsend, 0);
/* Соединяем фильтры приёмника. */
ms_filter_link(rtprecv, 0, decoder, 0);
ms_filter_link(decoder, 0, detector, 0);
ms_filter_link(detector, 0, snd_card_write, 0);
/* Подключаем источник тактов. */
ms_ticker_attach(ticker_tx, voidsource);
ms_ticker_attach(ticker_rx, rtprecv);
/* Настраиваем структуру, управляющую выходным сигналом генератора. */
MSDtmfGenCustomTone dtmf_cfg;
dtmf_cfg.tone_name[0] = 0;
dtmf_cfg.duration = 1000;
dtmf_cfg.frequencies[0] = 440;
/* Будем генерировать один тон, частоту второго тона установим в 0. */
dtmf_cfg.frequencies[1] = 0;
dtmf_cfg.amplitude = 1.0;
dtmf_cfg.interval = 0.;
dtmf_cfg.repeat_count = 0.;
/* Организуем цикл сканирования нажатых клавиш. Ввод нуля завершает
* цикл и работу программы. */
char key='9';
printf("Нажмите клавишу команды, затем ввод.n"
"Для завершения программы введите 0.n");
while(key != '0')
{
key = getchar();
if ((key >= 49) && (key <= 54))
{
printf("Отправлена команда: %cn", key);
/* Устанавливаем частоту генератора в соответствии с
* кодом нажатой клавиши. */
dtmf_cfg.frequencies[0] = 440 + 100*(key-49);
/* Включаем звуковой генератор c обновленной частотой. */
ms_filter_call_method(dtmfgen, MS_DTMF_GEN_PLAY_CUSTOM,
(void*)&dtmf_cfg);
}
/* Укладываем тред в спячку на 20мс, чтобы другие треды
* приложения получили время на работу. */
ms_usleep(20000);
}
}

מיר צונויפנעמען און לויפן. דער פּראָגראַם וועט אַרבעטן ווי אין די פריערדיקע בייַשפּיל, אָבער די דאַטן וועט זיין טראַנסמיטטעד דורך אַ RTP טייַך.

אין דער ווייַטער אַרטיקל מיר וועלן טיילן דעם פּראָגראַם אין צוויי פרייַ אַפּלאַקיישאַנז - אַ ופנעמער און אַ טראַנסמיטער און קאַטער זיי אין פאַרשידענע טערמינאַלס. אין דער זעלביקער צייט, מיר וועלן לערנען ווי צו אַנאַלייז RTP פּאַקיץ ניצן די TShark פּראָגראַם.

מקור: www.habr.com