Круче будет, когда машина сможет решать обратную задачу — выявив закономерности в порно, сможет синтезировать, к примеру, абстрактные движущиеся узоры, которые по воздействию на мозг будут аналогичны обычному порно.
По мне так подход eSpeak имеет право на жизнь. Я вообще не против robotic voice и считаю, что железка пусть звучит как железка. Но широкому кругу пользователей такая идея не близка. Боюсь что такое качество трудно будет продать.
Насчет псевдоязыков — да, я тоже баловался такими вещами, например моделируя канадский английский на базе американского английского. Радости мало, но порой приходится идти на компромисс.
Sphinx выглядит многообещающе, но уже довольно давно :)
В принципе я верю, что его когда-нибудь допилят до нужной кондиции + добавят большинство распространенных языков. Но процесс идет как-то медленно. А может быть развитие пойдет по другому пути — все будут использовать облачные сервисы вместо встроенных…
Если использовать их только для этого то все ок (как у вас указано — для обслуживания read()) но если добавить что-то еще то возможны варианты.
Я сталкивался со сценариями типа: часть запросов требует интенсивного счета, другая часть — ввода/вывода (т.е. может блокироваться). Если все потоки из пула уже заблокировались, то вроде как имеет смысл добавить новых, для выполнения счетных операций. Но поскольку знать состояние потока мы не можем, то непонятно когда это делать.
Разумеется, пока вы используете пулы потоков только для ожидания — все более-менее ок.
Пулы потоков это хорошо, но проблема еще и в том, что нет возможности узнать чем занимается конкретный поток. Быть может он ждет на блокирующей операции, а процессор в результате простаивает. К сожалению, системного вызова который бы сообщил состояние thread в Linux нет.
А интересно, есть ли иные решения? Ну, типа принудительно сделать минимальную задержку для изменения цены в 1000 ms, или что-то в этом роде. Чтоб уровнять шансы быстрых и «медленных» клиентов.
Да, насколько я понимаю основное применение протокола — удобные презентации.
Что касается клиента — вроде бы тут нет ничего невозможного. Того что вы описали должно хватить. Разве что я не в курсе приличных клиентов для RTSP которые можно было бы доработать. Сам я делал делал back port сервера на Android 4.0.3, не думаю, что «клиент» сложнее.
В одном из инженерных sample этого самого miracast dongle я вообще обнаружил полноценный Android. Т.е. выходит забавно — один Android на телефоне жмет поток в H.264, другой разжимает, и все для того, чтоб показать экран телефона. Думаю если кидать jpeg-и screenshot-ов то вышло бы быстрее и проще.
Касательно нюансов — очень важно чтоб был правильно сформирован Transport Stream. В частности — должен присутствовать корректный PCR и PTS. Без него многие клиенты отказываются отображать что либо. Но если писать клиент, то это не столь важно. Я могу, если интересно, выложить ссылку на полный лог tcpdump-а для успешного соединения и показа маленького ролика.
Касательно перевода — я не против. Думаю, это было бы полезно сообществу.
Я сам удивился, что на xda-developers и Stack Overflow практически нет информации по Miracast. Вроде за год должна бы уж появиться.
С задержкой конечно не ахти. Минимум, которого мне удавалось добиться — 200 ms. Обычно больше — порядка секунды-двух. Плюс еще неслабый jitter. Я пробовал пользоваться Miracast-ом в режиме VNC — выходило не очень. Как я понимаю, основное маркетинговое назначение протокола — показывать друзьям ролики и фотки с телефона на большом экране. Там, понятное дело, latency не так важна, ведь можно и буферизовать.
Китайцы отдают свои изделия такого типа ~ по 20$ (и там даже бывают конфигурации сразу с тремя стандартами — AirPlay, DLNA, Miracast). Искать по контексту «HDMI Miracast dongle». Реализация от NetGear, в некотором роде — референсная — PTV3000 стоит аж 60$.
Софтовая реализация возможна, если имеется аппаратная поддержка кодека для H.264, иначе будет зверски тормозить (на телефоне). Насчет приставок не скажу — не владею предметом. По мне, если уж поддержка классики типа DLNA встроена, то и хорошо. От добра добра не ищут.
Насчет псевдоязыков — да, я тоже баловался такими вещами, например моделируя канадский английский на базе американского английского. Радости мало, но порой приходится идти на компромисс.
В принципе я верю, что его когда-нибудь допилят до нужной кондиции + добавят большинство распространенных языков. Но процесс идет как-то медленно. А может быть развитие пойдет по другому пути — все будут использовать облачные сервисы вместо встроенных…
Просто хочется меньше задумываться над спецификой.
Я сталкивался со сценариями типа: часть запросов требует интенсивного счета, другая часть — ввода/вывода (т.е. может блокироваться). Если все потоки из пула уже заблокировались, то вроде как имеет смысл добавить новых, для выполнения счетных операций. Но поскольку знать состояние потока мы не можем, то непонятно когда это делать.
Разумеется, пока вы используете пулы потоков только для ожидания — все более-менее ок.
Надо было им для сравнения компактности еще добавить ASN.1 PER.
Что касается клиента — вроде бы тут нет ничего невозможного. Того что вы описали должно хватить. Разве что я не в курсе приличных клиентов для RTSP которые можно было бы доработать. Сам я делал делал back port сервера на Android 4.0.3, не думаю, что «клиент» сложнее.
В одном из инженерных sample этого самого miracast dongle я вообще обнаружил полноценный Android. Т.е. выходит забавно — один Android на телефоне жмет поток в H.264, другой разжимает, и все для того, чтоб показать экран телефона. Думаю если кидать jpeg-и screenshot-ов то вышло бы быстрее и проще.
Касательно нюансов — очень важно чтоб был правильно сформирован Transport Stream. В частности — должен присутствовать корректный PCR и PTS. Без него многие клиенты отказываются отображать что либо. Но если писать клиент, то это не столь важно. Я могу, если интересно, выложить ссылку на полный лог tcpdump-а для успешного соединения и показа маленького ролика.
Касательно перевода — я не против. Думаю, это было бы полезно сообществу.
Я сам удивился, что на xda-developers и Stack Overflow практически нет информации по Miracast. Вроде за год должна бы уж появиться.
Софтовая реализация возможна, если имеется аппаратная поддержка кодека для H.264, иначе будет зверски тормозить (на телефоне). Насчет приставок не скажу — не владею предметом. По мне, если уж поддержка классики типа DLNA встроена, то и хорошо. От добра добра не ищут.