Комментарии 26
Немного offtopic, но когда в вашем виджете появится возможность выбора не только микрофона, но и устройства воспроизведения?
P.S. На большинстве сайтов использующих Zingaya загружается WebRTC версия, исключение встретилось только одно — ИБ ТКС Банка, всё ещё используется flash версия.
P.S. На большинстве сайтов использующих Zingaya загружается WebRTC версия, исключение встретилось только одно — ИБ ТКС Банка, всё ещё используется flash версия.
Выбор устройства воспроизведения не поддерживается пока ни в WebRTC, ни во Flash. Используется устройство, которое выбрано как устройство по умолчанию в системе.
С другой стороны чрезмерная «хитрость» софта вредит — пример тому Скайп для Mac OSX. ОС и железо поддерживает телефонные гарнитуры а Скайп настаивает на выборе конкретного устройства о котором «он знает» из кое-как полученного списка звукозаписывающих устройств от ОС. При включении проводной гарнитуры (от телефона, с микрофоном) невозможно использовать ни встроенный микрофон ноутбука ни микрофон гарнитуры — собеседники ничего не слышат.
Работа над стандартом в самом разгаре, и до некой законченной версии еще далеко
Согласно их расписанию рекомендации должны быть готовы в Q1 2013.
Последнее серьёзное изменение было в августе, после этого они устаканивают детали.
На WebRTC Expo сказали, что рекомендация будет ближе к концу 2013 года
Я так понимаю это связано с тем, что есть зависимости от других рабочих груп (например IETF CODEC group, Device APIs & Policy Working Grou, кому интересно все зависимости можно посмотреть тут), и некоторые из них задерживаются. Судя по доступной открытой переписке, глобальных изменений вближайшее время нас не ждет.
Если у вас есть какие-то другие сведения, было бы интересно о них узнать.
Если у вас есть какие-то другие сведения, было бы интересно о них узнать.
Как минимум, нет определенности с видео кодеками, со стороны W3C измнения скорее всего будут минимальными, но все равно будут — не хватает ряда методов API нужных для реализации работы со списком доступных устройств, еще не до конца определено как будут работать некоторые уже описанные методы (синхронно/асинхронно) и т.д. поэтому рекомендацию обещали к Q4
Кодеки и работа со списком доступных устройств — этим занимаются две другие группы. Изменения в кодеках вообще не должно коснуться public API, исключительно внутренняя реализация поддержки утвержденных кодеков, подождем обновления браузеров и ок :). Что касается работы со списком доступных устройств, то есть подозрения что это тоже не особо коснется WebRTC, все останется на уровне удаления-добавления новых медиа потоков.
А что еще осталось синхронного, что может приехать на асинхронный вызов?
А что еще осталось синхронного, что может приехать на асинхронный вызов?
Например, в Chrome 24 beta есть возможность выбора разрешения захвата с камеры и некоторых других параметров а-ля фреймрейт, а в Chrome 23 нет, так что public API может много что еще коснуться. Про синхронное/асинхронное, например, про метод getUserMedia еще до сих пор идет обсуждение.
А не подскажите, где почитать про эти фишки (разрешение захвата и т.д.)?
Где-то в Google Groups видел, попробую найти ссылку
Расширение захвата называется GetUserMedia, работает в последнем Chrome на всех настольных платформах.
Примеры реализаций: раз, два, три.
Примеры реализаций: раз, два, три.
Вы видимо меня не поняли, меня интересует не как получить доступ к камере, этому уже сто лет в обед, а как управлять разрешением потока.
Ссылку так и не нашел, но код выглядит так:
navigator.webkitGetUserMedia({ audio: true, video: {
mandatory: { maxWidth: 320, maxHeight: 240, maxFrameRate: 15 }
}, ....
2012 год, додумались дать возможность указать разрешение. Круто!
Ждем конструкций вида:
ffmpeg -i input.mpg -f mpegts -acodec copy -vcodec libx264 -level 41 -crf $CRF -bufsize 20000k -maxrate 25000k -g 250 -coder 1 -flags +loop -cmp +chroma -partitions +parti8x8+parti4x4+partp8x8+partb8x8 -flags2 +brdo+dct8x8+bpyramid -me umh -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq «blurCplx^(1-qComp)» output.mpg
А то вот сейчас, к примеру, во флеше можно кодировать звук, но сделать с ним ничего нельзя. Или, можно его поправить, но и кодировать тогда тоже самому. Аналогично во флеше и с камерой — ничего нельзя настроить, кроме битрейта или абстрактного «качества».
Ждем конструкций вида:
ffmpeg -i input.mpg -f mpegts -acodec copy -vcodec libx264 -level 41 -crf $CRF -bufsize 20000k -maxrate 25000k -g 250 -coder 1 -flags +loop -cmp +chroma -partitions +parti8x8+parti4x4+partp8x8+partb8x8 -flags2 +brdo+dct8x8+bpyramid -me umh -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq «blurCplx^(1-qComp)» output.mpg
А то вот сейчас, к примеру, во флеше можно кодировать звук, но сделать с ним ничего нельзя. Или, можно его поправить, но и кодировать тогда тоже самому. Аналогично во флеше и с камерой — ничего нельзя настроить, кроме битрейта или абстрактного «качества».
Во флэше всю жизнь разрешение камеры настраивалось, непонятно о чем вы
Ну настройка разрешения — это и так само собой, можно даже задать кейфреймы. И все
cam.setMode(320,240,25);
cam.setKeyFrameInterval(5);
cam.setLoopback(true);
cam.setQuality(0,70);
И больше ничего.
А посмотрите на опции кодирования видео в ffmpeg (libavcodec), лично мне богатство опций всегда нравилось, а кодек, завернутый в какой-то абстрактный веб-интерфейс, обычно лишен тонкой настройки и теряет ряд преимуществ. Вот это неприятно.
cam.setMode(320,240,25);
cam.setKeyFrameInterval(5);
cam.setLoopback(true);
cam.setQuality(0,70);
И больше ничего.
А посмотрите на опции кодирования видео в ffmpeg (libavcodec), лично мне богатство опций всегда нравилось, а кодек, завернутый в какой-то абстрактный веб-интерфейс, обычно лишен тонкой настройки и теряет ряд преимуществ. Вот это неприятно.
Не знаю, а по мне все это какие-то пляски трупов.
«Здравствуй дорогой пользователь, у нас есть инновационная WebRTC, но работать оно будет в 0.5 браузеров»
В случае флеша, который как известно не нужен, количество обслуживаемых пользователей несколько выше.
«ой, какая у нас клевая полосочка для подтверждения доступа, а не этот мерзкий попап флеша!» — мне честно говоря смешно читать такое, равно как и записывать это в преимущества. Если у вас такие преимущества — какие же недостатки? Завтра покрасите кнопки в красненький/зелененький и это тоже будет прорывом и инновацией?
AGC не включили, какая плохая эта ваша адоба. А то, что многие микрофоны шумят как советский радиоприемник, порой работая как простенькое радио — с этим вы наверное не сталкивались. Ну пропустите такой сигнал через компрессор, заслушайте. Приятно? Зато сраный адоб позволяет получить доступ к семплам звука, а полученные данные скормить модулю на сишке, который сможет и пофильтровать, и сделать усиление, и даже упаковать в ЛЮБОЙ кодек. Конечно, усе это работает внутри AVM2, что скорости не прибавляет, но вполне съедобно, говорю как автор одной такой реализации.
Лет через 15 захват семплов будет тоже работать в любом браузере, а не как сейчас в 1.5, а мощностей хватит на кодирование звука js-кодировщиком. Но это дело далекого будущего. Как и нормальная поддержка RTP, как и поддержка всех кодеков, в зависимости от их наличия в системе.
В общем, мой выбор — говнофлеш + RTMP (которые, как известно, не нужны) для веба. Говно, но вкуснее ничего нет. А когда надо что-то стабильное — ставь милый пользователь СИП-клиент и не выпендривайся. Я правда выпендриваюсь и еще все хочу добавить поддержку мамбла, уж больно он удобен для некоторых целей, использует CELT + speex, а на входе микрофона есть достаточно клевый фильтр шума.
«Здравствуй дорогой пользователь, у нас есть инновационная WebRTC, но работать оно будет в 0.5 браузеров»
В случае флеша, который как известно не нужен, количество обслуживаемых пользователей несколько выше.
«ой, какая у нас клевая полосочка для подтверждения доступа, а не этот мерзкий попап флеша!» — мне честно говоря смешно читать такое, равно как и записывать это в преимущества. Если у вас такие преимущества — какие же недостатки? Завтра покрасите кнопки в красненький/зелененький и это тоже будет прорывом и инновацией?
AGC не включили, какая плохая эта ваша адоба. А то, что многие микрофоны шумят как советский радиоприемник, порой работая как простенькое радио — с этим вы наверное не сталкивались. Ну пропустите такой сигнал через компрессор, заслушайте. Приятно? Зато сраный адоб позволяет получить доступ к семплам звука, а полученные данные скормить модулю на сишке, который сможет и пофильтровать, и сделать усиление, и даже упаковать в ЛЮБОЙ кодек. Конечно, усе это работает внутри AVM2, что скорости не прибавляет, но вполне съедобно, говорю как автор одной такой реализации.
Лет через 15 захват семплов будет тоже работать в любом браузере, а не как сейчас в 1.5, а мощностей хватит на кодирование звука js-кодировщиком. Но это дело далекого будущего. Как и нормальная поддержка RTP, как и поддержка всех кодеков, в зависимости от их наличия в системе.
В общем, мой выбор — говнофлеш + RTMP (которые, как известно, не нужны) для веба. Говно, но вкуснее ничего нет. А когда надо что-то стабильное — ставь милый пользователь СИП-клиент и не выпендривайся. Я правда выпендриваюсь и еще все хочу добавить поддержку мамбла, уж больно он удобен для некоторых целей, использует CELT + speex, а на входе микрофона есть достаточно клевый фильтр шума.
Chrome установлен на 35% компьютеров, скоро подтянется Firefox и станет более 50%, так что это просто вопрос времени. По поводу доступа к сэмплам и упаковке — для реалтайма это не работает. Если ваш выбор говнофлеш+RTMP, то это ваше личное дело, для нормальных реалтайм сервисов коммуникаций такая связка работает не лучшим образом.
Я извиняюсь, а что вообще работает? Мне нужно отправить звук на сервер, как можно ближе к реалтайму. Как это сделать? Я могу хватать семплы, самостоятельно паковать и отправлять на сервер. В случае флеша, мне доступно только TCP. Не реалтайм, но близко и без заиканий. А могу эту работу поручить самому флешу, дабы он там все сам сделал. Недостатком такого решения являются встроенные кодеки флеша — это спикс с отвратительным качеством или неллимосер, который хоть еще большее говно, зато хоть умеет честные 44 килогерца. Поэтому если брать флеш — лучше ничего не выйдет.
Да, флеш должен сдохнуть. Да, он не нужен. Я верю, в будущем все будет хорошо. Но СЕГОДНЯ кроме флеша альтернатив в общем-то и нет. Я правда видел уже чатики на вебсокетах, js и g711, но слушать это было несколько неприятно, да и работало это как технодемка с привязкой к конкретным браузерам (и их билдам)
Да, флеш должен сдохнуть. Да, он не нужен. Я верю, в будущем все будет хорошо. Но СЕГОДНЯ кроме флеша альтернатив в общем-то и нет. Я правда видел уже чатики на вебсокетах, js и g711, но слушать это было несколько неприятно, да и работало это как технодемка с привязкой к конкретным браузерам (и их билдам)
Во Flash есть UDP-протокол, называется RTMFP. Работа с сэмплами напрямую на уровне виртуальных машин — это извращение, по крайней мере на текущем этапе развития таких реализаций. Для нормального реал-тайма код должен быть написан на более низком уровне и взаимодействовать с железом напрямую. Во Flash кроме Speex и Nellymoser есть G.711
вы забыли упомянуть, что в некоторых случаях происходит фоллбек обратно на ртмп, а там с реалтамом все хуже. Далее, не любой кодек выдержит потерю ракетов, кроме пожалуй г711 и некоторых специально заточенных под это дело. Выходит, нам все равно надо как-то восстанавливать стрим.
Работа же с семплами хоть и извращение, но по моему опыту очень даже неплохо, я даже по началу хотел сделать работу по микшированию звука на сишке и упаковать в алчеми, однако выяснилось что это не нужно и в алчеми отправился только енкодер, а микшер так и остался на ас3. Все работает, все всем вещается.
и да, а где вы увидели поддержку г711?
Работа же с семплами хоть и извращение, но по моему опыту очень даже неплохо, я даже по началу хотел сделать работу по микшированию звука на сишке и упаковать в алчеми, однако выяснилось что это не нужно и в алчеми отправился только енкодер, а микшер так и остался на ас3. Все работает, все всем вещается.
и да, а где вы увидели поддержку г711?
Так а каковы подводные камни-то? А то прямо одна радость сплошная.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Из первых рук: подводные камни на пути к поддержке WebRTC