Pull to refresh

Comments 21

Не совсем понял, что именно вы сделали. В вашем репозитории лежат всего лишь скрипты для сборки приложения, точная копия оригинального репозитория компании Pristine (https://github.com/pristineio/webrtc-build-scripts) причём не самой последней версии, ибо у вас в зависимостях на платформе OS X ещё присутствует QTKit, который был удалён в марте.
Можно ссылку на ваши пулл-реквесты в репозиторий webrtc? Интересно было бы посмотреть, вдруг ваши предложения ещё и на Android улучшат ситуацию, у нас тоже не всё гладко.
Из скриптов сборки приложения, если бы Вы их изучили, Вы бы увидели, что сама библиотека так же подтягивается из моего репозитория. В скором времени эта библиотека, которая подтягивается, будет автоматически обновляться из git'а разработки WebRTC. Это было сделано для того, чтобы не скачивать постоянно новую версию WebRTC и не компилировать её снова, а это отнимает около 12 часов (с моим интернетом). Это было основной целью вынесения библиотеки в отдельный репо.
Там гит вообще-то, много выкачивать нужно только один раз.
Я вкурсе как работают эти скрипты, использую их давно, спасибо. Чтобы найти различия между оригинальными и вашими я сделал следующее:
1. Слил репозиторий https://github.com/pristineio/webrtc-build-scripts
2. Слил ваш репозиторий
3. Скопировал все файлы из вашего репозитория в оригинальный.
4. Сделал git diff.
5. Увидел всего два изменения — QTKit и добавленный файл .podspec, который, как я подозреваю, никакого отношения к сборке не имеет.
В связи с этим вопрос — о каком вашем репозитории вы толкуете?
Ссылки на репы, где что нашли можно написать
Решением оказалось не использовать свой сервер для WebRTC. То есть сервер самого приложения только лишь анализировал подключенных к нему пользователей и предлагал им соединиться, после этого приложения начинали работать с сервером самого “AppRTC” и все взаимодействия с передачей пакетов, STUN и TURN серверами проходило там.


Что это должно значить? Вы вместо своего stun/turn-сервера чужой стали использовать и это всё решение?

Был проведен полный рефакторинг кода видео-чата и приложение заработало еще быстрее и стало юзабельнее. В результате оптимизации кода, библиотека была вынесена в отдельный “Pod” сюда.

Ссылочку плз на изменения по сравнению с оригинальной версией.

Было разработано и представлено несколько решений по оптимизации работы самой библиотеки “AppRTC” и они были отправлены разработчикам.

Ссылку можно на отправленные решения?

К слову, у меня так и не получилось использовать h264 для гуглового WebRTC в iOS, ибо всё время приходит RTCI420Frame с NULL вместо данных в переменных yPlane, uPlane и vPlane на принимающей стороне. Как ни странно, VP8 работает. У кого-то такое было?
Что это должно значить? Вы вместо своего stun/turn-сервера чужой стали использовать и это всё решение?


Это значит то, что наш сервер указывал что нужно соединить вот этих двух ребят, затем они сами подключались к Signaling и stun/turn серверам «AppRTC» и взаимодействовали внутри серверов «AppRTC» (appr.tc).

Ссылочку плз на изменения по сравнению с оригинальной версией.


Имелся ввиду рефакторинг кода видео-чата внутри приложения, а не библиотеки, то есть то, как приложение взаимодействовало с библиотекой, а это уже является собственностью заказчика, и я не в праве это разглашать.

Ссылку можно на отправленные решения?


С удовольствием, но сейчас прилетит туча комментариев к логичности или уместности решений, могу сказать только то, что решения были частично внедрены, они касались ARDAppEngineClient.

У кого-то такое было?


У нас такое было до обновления библиотеки до актуальной версии. Сейчас, если я не ошибаюсь, поддержка VP8 медленно вырезается из библиотеки за ненадобностью.
Так же вы могли упустить важную часть после создания session description (peerConnection:didCreateSessionDescription:error:):
// Prefer H264 if available.
RTCSessionDescription *sdpPreferringH264 = sip;
sdpPreferringH264 = [ARDSDPUtils descriptionForDescription:sdpPreferringH264 preferredVideoCodec:@"H264"];        sdpPreferringH264 = [ARDSDPUtils descriptionForDescription:sdpPreferringH264 preferredAudioCodec:@"ILBC"];        [_peerConnection setLocalDescriptionWithDelegate:self sessionDescription:sdpPreferringH264];
ARDSessionDescriptionMessage *message = [[ARDSessionDescriptionMessage alloc] initWithDescription:sdpPreferringH264];
С удовольствием, но сейчас прилетит туча комментариев к логичности или уместности решений, могу сказать только то, что решения были частично внедрены, они касались ARDAppEngineClient.

Какая разница? Думаю, не только мне интересно было бы взглянуть на то, что вы улучшили. Тем более, после написания статьи, но без подробностей толком.

У нас такое было до обновления библиотеки до актуальной версии. Сейчас, если я не ошибаюсь, поддержка VP8 медленно вырезается из библиотеки за ненадобностью.
Так же вы могли упустить важную часть после создания session description (peerConnection:didCreateSessionDescription:error:):

Библиотека была собрана последняя из мастера пару дней назад (так же пробовал ревизию из ветки 52-го релиза хромиума), кодек конечно же приоритетный в SDP, но кадры без этих данных приходят в любом случае. Локально, однако, всё с ними окей. Такое только со стримом видео, который приходит по сети.

А как Вы проверяли, что кодек включился?
У меня при использовании его — просто зеленый фрейм и все, при использовании других кодеков — все норм. Либа последняя использовалась.

К слову, у меня так и не получилось использовать h264 для гуглового WebRTC в iOS, ибо всё время приходит RTCI420Frame с NULL вместо данных в переменных yPlane, uPlane и vPlane на принимающей стороне. Как ни странно, VP8 работает. У кого-то такое было?

А крешей не было в Debug версии библиотеки при использовании данного кодека?

Дебаг-версия слишком много места занимала, поэтому использовал релизную. Креши были, на приёмной стороне, потому что кадры без данных приходят.

Решили проблему с кодеком h264 или использовали другой?
У меня схожая задача возникла.

Ответили в дисскусиях, гугловая либа походу не поддерживает корректно h264.
talk/app/webrtc/objc/public — на основе которого строится либа, описанная в тексте выше — уже не супортится.
Ребята, как я понял, переписывают ее, и в демо под WebRTC используются сорсы с этого пути:webrtc/sdk/objc/Framework/Headers/WebRTC.

В подсах не нашел либы либо фреймворка с нужными заголовками. Сейчас сам компилю фреймворк, нашел инструкции что и как, погляжу что выйдет в итоге.

Да, оно. Я тоже компилил скриптом. Демо пример на этом же апи написано :)
/webrtc/build/ios/build_ios_libs.sh b/webrtc/build/ios/build_ios_libs.sh

Какая разница? Думаю, не только мне интересно было бы взглянуть на то, что вы улучшили. Тем более, после написания статьи, но без подробностей толком.


Учту в следующий раз.
Зайдя в папку, которая мне была симпатична более другой, я обнаружил массу исходных файлов библиотеки и папку “Example”, в которой находился проект под названием “AppRTC”.

Пришла мысль обновить библиотеку полностью. После переделки 80% написанного до обновления кода он все еще не работал, а пример не был обновлен до актуальной версии.

Было разработано и представлено несколько решений по оптимизации работы самой библиотеки “AppRTC” и они были отправлены разработчикам.


Я так и не понял, какую библиотеку вы нашли и что вы переписали? Какая-то лапша без конкретики. AppRTC у вас то пример, то библиотека, ещё 80% какого-то кода вы переписали, но какой, сказать не можете? Какие вы улучшения предложили и куда?
Sign up to leave a comment.

Articles