Comments 23
UFO just landed and posted this here
Я вот только начинаю щупать, не подскажите, какие бест-практики для следующего кейса: есть комп дома, на работе и мобильный телефон и хочется со всех их общаться с одного ToxID. Или каждое устройство подразумевает только новый ToxID?
Насколько мне известно, на данный момент такой кейс весьма проблематичен и лучше использовать несколько разных профайлов либо шарить один каким-то образом на все устройства и использовать его только с одно устройства в один момент времени. Обсуждение реализации этой возможности в ядре toxcore происходит тут: https://github.com/irungentoo/toxcore/issues/843
UFO just landed and posted this here
Я разрабатываю windows клиент для этой сети: Isotoxin. По фичам я уже обогнал qTox.
Буквально пару недель назад сделал поддержку видео. Работает сносно, до тех пор, пока ваш канал достаточно широк для видеопотока. Как только канала становится недостаточно, происходит потеря пакетов. В ядре есть два способа послать пакет с данными: т.н. lossless и lossy. В чем отличие? Отличие в том, что lossy пакет просто дропается, если ядро не смогло поставить его в очередь на отправку, а lossless будет отослан в любом случае. lossy пакеты используются для передачи видео и аудио. Казалось бы, все правильно. Нет, не правильно! Звук — еще куда ни шло — там все пакеты независимы. А вот с видео так делать нельзя. Точнее нельзя делать так, как это сделано в ядре tox. Получается, при таком подходе — когда часть пакетов, из которых состоит кадр, не долетает до адресата — на приемнике случается цифровой мусор.
Тикет я им написал, но они его почему-то оставили без внимания. Я хочу сделать свою собственную реализацию передачи видеоданных, чтобы убедиться, что ход моих мыслей верен, а потом предложу эту реализацию ребятам из toxcore-team.
Буквально пару недель назад сделал поддержку видео. Работает сносно, до тех пор, пока ваш канал достаточно широк для видеопотока. Как только канала становится недостаточно, происходит потеря пакетов. В ядре есть два способа послать пакет с данными: т.н. lossless и lossy. В чем отличие? Отличие в том, что lossy пакет просто дропается, если ядро не смогло поставить его в очередь на отправку, а lossless будет отослан в любом случае. lossy пакеты используются для передачи видео и аудио. Казалось бы, все правильно. Нет, не правильно! Звук — еще куда ни шло — там все пакеты независимы. А вот с видео так делать нельзя. Точнее нельзя делать так, как это сделано в ядре tox. Получается, при таком подходе — когда часть пакетов, из которых состоит кадр, не долетает до адресата — на приемнике случается цифровой мусор.
Тикет я им написал, но они его почему-то оставили без внимания. Я хочу сделать свою собственную реализацию передачи видеоданных, чтобы убедиться, что ход моих мыслей верен, а потом предложу эту реализацию ребятам из toxcore-team.
Да, клиент очень интересный! Правда, я так и не понял, как импортировать .tox профиль.
Не хотите написать статью о клиенте?
Не хотите написать статью о клиенте?
А можно ли часть видеопотока отправлять с гарантированной доставкой? Скажем, каждый N-й I-frame слать как lossless. Тогда при потере промежуточных фреймов у декодера все равно будет точка восстановления. Другое дело, что I фреймы гораздо больше чем P и B. Поэтому слать все подряд будет неэффективно.
P.S.: Использовал терминологию MPEG2 вещания. Не знаю, как оно сделано в вашем кодеке.
P.S.: Использовал терминологию MPEG2 вещания. Не знаю, как оно сделано в вашем кодеке.
Это нужно сделать. Вопрос только в том, кто это будет делать. Я не разработчик ядра, но тем не менее в своем клиенте я могу сделать другой способ передачи видео. Понятно, что он будет работать только при звонках на мой-же клиент. Когда я так сделаю, то у меня будет что предложить разработчикам ядра — реально рабочее.
При общении с разработчиками ядра, меня несколько огорчило их отношение к предложениям извне их команды. Я еще могу понять нежелание их мейнтейнера ядра (irungentoo) убрать из кода C99 зависимости (я автор сборки под Visual Studio), но когда я им явно описал место в коде, где можно с'экономить на копировании несжатого видеокадра (а это несколько мегабайт в секунду), и даже исправил код в своем форке toxcore и убедился что фикс работает (сейчас Isotoxin на исправленом коде — все ok), тот факт, что это исправление до сих пор не вошло в основной репозиторий выше моего понимания.
Так что улучшать toxcore я не перестану, но вот войдут ли эти улучшения в другие клиенты — это вопрос.
При общении с разработчиками ядра, меня несколько огорчило их отношение к предложениям извне их команды. Я еще могу понять нежелание их мейнтейнера ядра (irungentoo) убрать из кода C99 зависимости (я автор сборки под Visual Studio), но когда я им явно описал место в коде, где можно с'экономить на копировании несжатого видеокадра (а это несколько мегабайт в секунду), и даже исправил код в своем форке toxcore и убедился что фикс работает (сейчас Isotoxin на исправленом коде — все ok), тот факт, что это исправление до сих пор не вошло в основной репозиторий выше моего понимания.
Так что улучшать toxcore я не перестану, но вот войдут ли эти улучшения в другие клиенты — это вопрос.
В теории, кодек VP8 допускает потерю части пакетов («кадры типа Recovery строятся не на базе непосредственно предшествующих кадров»). Плюс в ядре kf_max_dist установлено в значение 48 — т.е. максимум каждые 48 кадров будет отправляться полный опорный кадр (при частоте кадров в 25 FPS получается изображение восстановится за ~2 секунды максимум после восстановления пропускной способности канала).
Если отсылать пакеты с гарантированной доставкой, то при недостатке полосы она просто забьется совсем. Кажется в этом случае лучшая стратегия — это адаптивно уменьшать битрейт для кодирования видео (следуя рекомендациям toxav_bit_rate_status_cb) или уменьшать на лету размер отсылаемого кадра.
Что касается собственной реализации и экспериментами с ней, то я тут только могу поддержать.
Если отсылать пакеты с гарантированной доставкой, то при недостатке полосы она просто забьется совсем. Кажется в этом случае лучшая стратегия — это адаптивно уменьшать битрейт для кодирования видео (следуя рекомендациям toxav_bit_rate_status_cb) или уменьшать на лету размер отсылаемого кадра.
Что касается собственной реализации и экспериментами с ней, то я тут только могу поддержать.
> изображение восстановится за ~2 секунды максимум
тут проблема в том, что опорные кадры тоже приходят битыми, т.к. часть пакетов, из которых состоит опорный кадр, не долетает до приемника.
Моя идея состоит в том, чтобы:
1. опорные кадры слать lossless
2. остальные кадры слать lossy, но только первый пакет. Если первый пакет неключевого кадра отправлен, остальные пакеты этого кадра слать lossless
Вобщем, идея в том, чтобы кадр либо целиком не дошел, либо целиком дошел. Иначе изображение портится, что сейчас и происходит
тут проблема в том, что опорные кадры тоже приходят битыми, т.к. часть пакетов, из которых состоит опорный кадр, не долетает до приемника.
Моя идея состоит в том, чтобы:
1. опорные кадры слать lossless
2. остальные кадры слать lossy, но только первый пакет. Если первый пакет неключевого кадра отправлен, остальные пакеты этого кадра слать lossless
Вобщем, идея в том, чтобы кадр либо целиком не дошел, либо целиком дошел. Иначе изображение портится, что сейчас и происходит
А что с offline-messaging? ИМХО, необходимая, хоть и труднореализуемая фича.
Можно сделать как в скайпе
Кажется, что в ядре такой фитчи в обозримом будущем не будет и ее оставят на усмотрение клиентского приложения.
Вот тут обсуждение этой возможности: https://github.com/irungentoo/toxcore/issues/870
Ещё неплохо, когда в клиенты более-менее прозрачно интегрируют поддержку существующих ToxDNS серверов. Но ваш вопрос тоже животрепещущий.
UFO just landed and posted this here
Проблема возникает только в личкрафте или в стандартном клиенте тоже? Если первое, то возможная причина deadlock потоков в ядре Tox. Если второе, то только gdb в руки и смотреть чем оба занимаются в это время. Я тестировал с qTox на интервале в несколько часов, но уверен, что тестирование покрыло далеко не все возможные ситуации.
Sign up to leave a comment.
Аудио и видео в мессенджере Tox