Ну, политика такая... Ручками можно любой, практически, кодек прикрутить

кстати, я читал, что в Duo сам гугл тестил HEVC, не знаю, выкатили ли в итоге

пишут, что поддерживают - https://support.google.com/duo/thread/737807?hl=en

но больше ничего не гуглится, кроме тестирования  hevc в Duo...

исходники?

он же не опенсорсный

Оказывается, для webRTC поддержка HEVC в Android [1, 2] есть в форке Open WebRTC Toolkit (OWT) [3, 4], кот. был изначально создан (и оптимизирован) для процессоров Intel. Лицензия: Apache-2.0.
Вот выбор HEVC с пом. API OWT для Android [2]:
- owt.p2p.P2PClientConfiguration.addVideoParameters(new VideoEncodingParameters(H265))
- owt.conference.SubscribeOptions.setVideoOption(VideoSubscriptionConstraints.builder().addCodec(new VideoCodecParameters(H265)).build())
- owt.conference.PublishOptions.addVideoParameter(new VideoEncodingParameters(H265))

1. https://software.intel.com/sites/products/documentation/webrtc/android/index.html
2. https://github.com/open-webrtc-toolkit/owt-client-android
3. https://01.org/open-webrtc-toolkit
4. https://software.intel.com/en-us/webrtc-sdk

а AV1 на андроидах разве не из коробки?  hevc чот не взлетает должным образом и уже VVC во всю наступает

Только в 10 завезли, и, как я понимаю, процессоров с хардварным кодеком в природе ещё не существует

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

Это если железо позволяет использовать эти этапы по отдельности. Там же наверняка адская конвейризация

Например, в нексусе 5 в последней официальной прошивке есть программный декодер HEVC, но он полностью программный. Хотя я почти уверен, что можно было переиспользовать какие-нибудь куски из аппаратного H264.

+++

Подскажите, кто знаком с MTProto. Не могу разобрать ответ от сервера. Отправляю серверу запрос auth.sendCode. В ответ получаю вот такой набор данных 016d5cf3 00ec5118c1d63e5e bdbc1522b575729912386434396233343165393463666536633363008642b41f0b9eee8e5fa3ca7aa6bec15e4ef2467b624042ed
016d5cf3 - это у нас хэш TL типа: rpc_result#f35c6d01 req_msg_id:long result:Object = RpcResult;
00ec5118c1d63e5e - req_msg_id
bdbc1522b575729912386434396233343165393463666536633363008642b41f0b9eee8e5fa3ca7aa6bec15e4ef2467b624042ed - а вот с оставшимся result типа Object проблемы. TL тип с хэшем 2215bcbd не смог найти, что здесь может быть? заметил единственное, что следующие 4 байта это boolTrue#997275b5 = Bool;

tl схемы только с этих двух ссылок
https://core.telegram.org/schema/mtproto
https://core.telegram.org/schema
искал только по уже просчитанным хэшам, свои не считал

какую версию схемы используете?

видимо какую-то по умолчанию, явно серверу не сообщал

https://core.telegram.org/api/invoking - раздел layers необходимо реализовать

и Saving Client Info тоже

понял, спасибо!