Комментарии 54
Посмотрел демо
Имхо шустро — уж точно шустрее всяких плееров основанных на флеше. качество картинки хорошее (хотя я сравниваю с тытрубой у которых сжатие)
главное — нет сторонних модулей — всё в браузере и я не заметил прожорства ресурсов
кстати почему у подавляющего большинства современных плееров нет кнопки стоп?
вот сижу я с модема и открыл вкладку с часовым видео. начал смотреть и понял что не хочу больше, а страницу закрывать нельзя. в итоге придётся жрать траффик пока не загрузится всё.
Имхо шустро — уж точно шустрее всяких плееров основанных на флеше. качество картинки хорошее (хотя я сравниваю с тытрубой у которых сжатие)
главное — нет сторонних модулей — всё в браузере и я не заметил прожорства ресурсов
кстати почему у подавляющего большинства современных плееров нет кнопки стоп?
вот сижу я с модема и открыл вкладку с часовым видео. начал смотреть и понял что не хочу больше, а страницу закрывать нельзя. в итоге придётся жрать траффик пока не загрузится всё.
В спецификации нет метода stop() вообще. Есть только pause(), которая продолжает буферизацию. К сожалению, ребята не понимают в каком варианте и при каких случаях может потребоваться stop().
Да не только у html5, пока что flash доминирует
из всех что помню, только у uppod есть стоп
нет, я понимаю что у _всех_ давно 100 мегабит до квартиры и LTE безлимитом, но всё же
из всех что помню, только у uppod есть стоп
нет, я понимаю что у _всех_ давно 100 мегабит до квартиры и LTE безлимитом, но всё же
Uppod, FlowPlayer, JW Player
Почти у всех flash плееров стоп была.
Почти у всех flash плееров стоп была.
Ну да, ребята из videojs, например, тоже особо не парятся на тему stop(). С одной стороны, они пытаются использовать лишь HTML 5 Video API/Events, но у них уже неоднократно поднимались вопросы относительно stop() (на том же гитхабе).
ОООчень сильно заблуждаетесь, есть те кто еще сидит с пингом 600+ на каналах в 128кбит и поверьте, таких достаточно много, большая часть северных регионов России.
А стоп и не нужен. Все серьезные плееры и так сами занимаются буфферизацией. Это уже от разработчиков плееров/сайтов зависит. Могут добавить, могут убрать.
Приходится извращаться.
И, на самом деле, нужен. Далеко не у всех 100мб безлимит. Плюс, телефоны.
Не говоря уж о том, что есть сценарии, при которых надо выключать воспроизведение определенных стримов спустя N-время. Пауза не подходит, ибо трафик будет продолжать ходить между сервером и клиентом.
А в стандартных ситуациях (воспроизведение видео с котятами, например), да — стоп нафиг не нужен.
И, на самом деле, нужен. Далеко не у всех 100мб безлимит. Плюс, телефоны.
Не говоря уж о том, что есть сценарии, при которых надо выключать воспроизведение определенных стримов спустя N-время. Пауза не подходит, ибо трафик будет продолжать ходить между сервером и клиентом.
А в стандартных ситуациях (воспроизведение видео с котятами, например), да — стоп нафиг не нужен.
Вы не поняли.
Все серьезные плееры сами скачивают видео кусочками в браузер. А потом эти кусочки закидывают в буфер видео элемента.
Это «воля» разработчиков плеера скачивать видео или нет. И никакая кнопка стоп их не остановит / не решит вопрос.
Все серьезные плееры сами скачивают видео кусочками в браузер. А потом эти кусочки закидывают в буфер видео элемента.
Это «воля» разработчиков плеера скачивать видео или нет. И никакая кнопка стоп их не остановит / не решит вопрос.
Все серьезные плееры сами скачивают видео кусочками в браузер.
С этого момента попродробнее. Не видел ни одного такого серьезного.
Все закачивают поток целиком. Даже Ютуб, а сервер вот отдает кусочками.
Стрим бывает кусочками, и то это было на флеш и f4*.
Если в плеере нажата play, то уже ничего не остановит буфкризацию, только F5 страницы. Ну и stop, если предусмотренна.
Rule of thumb: любой плеер который переключает качество видео/аудио «на лету» скачивает кусочками.
Проверить на «продвинутость» любого сайта/плеера можно в консоли разработчика:
Проверить на «продвинутость» любого сайта/плеера можно в консоли разработчика:
Пример YT
Я специально написал
Ютуб это не показатель. Плеер их этот не поставишь на свой сервер так просто. И отдает кусками сервер, а не плеер принимает.
Ну хорошо. Считаем плеер Ютуба «продвинутым». Следовательно все остальные непродвинутые. Так и запишем.
Все закачивают поток целиком. Даже Ютуб, а сервер вот отдает кусочками.
Ютуб это не показатель. Плеер их этот не поставишь на свой сервер так просто. И отдает кусками сервер, а не плеер принимает.
Ну хорошо. Считаем плеер Ютуба «продвинутым». Следовательно все остальные непродвинутые. Так и запишем.
Да, я прочитал. Сервер не отдает кусками, в той форме в которой вы это описали.
Это бы противоречило протоколу HTTP.
Вот пример самого популярного интернет плеера.
Время подключением на свой сайт, кушая печеньки, минут 5.
В этом примере плеер шлет запрос с помощью HTTP заголовка Range.
Это бы противоречило протоколу HTTP.
Вот пример самого популярного интернет плеера.
Время подключением на свой сайт, кушая печеньки, минут 5.
В этом примере плеер шлет запрос с помощью HTTP заголовка Range.
JW player
Именно Ютуб отдает кусками. Там вообще сложная схема. Зависит от запроса. Можно сломать мозг очень быстро. И думаю его, как пример, надо рассматривать отдельно.
А вот на JWP отдается видео до конца. Разумеется можно начать смотреть с середины, запросить с середины. Но всё равно отдастся до конца.
Скорее всего разногласия из-за причин описанной в вашем диалоге с Fr3nzy. Я пользуюсь FF, поэтому у меня другая сторона медали.
Ютуб
А вот на JWP отдается видео до конца. Разумеется можно начать смотреть с середины, запросить с середины. Но всё равно отдастся до конца.
JWP
Скорее всего разногласия из-за причин описанной в вашем диалоге с Fr3nzy. Я пользуюсь FF, поэтому у меня другая сторона медали.
Нет, там простая схема. Ютуб работает по технологии видеостриминга MPEG-DASH.
Просто вместо того чтобы запрашивать видео кусочками, транскодер подготовил отдельные файлы.
Без разницы или нарезать файлы на байты «по линии сегментов» или запрашивать с помощью range «по линии сегментов».
Результат тот же.
Технология видеостриминга это совокупность: кодека, контейнера, манифеста и способа доставки.
— Кодек жмет видео в поток видеоданных. Это h.264, webm etc.
— Контейнер, он же формат эти данные упорядочивает. mp4, mpeg-ts etc.
— Манифест сообщает метаданные. К примеру данные о структуре сегментов могут быть вписаны как в атомы mp4 (еденица внутренней структуры mp4), так и во внешнем XML файле как в DASH/ M$S
— Способ доставки это порядок взаимодействия при закачке видео. Протокол (в значения правил, а не RFC) по сути.
Популярных технологий несколько: Microsoft Smooth Streaming, Apple HLS, Adobe что-то то там и MPEG-DASH
под которым подписался Netflix+Youtube следовательно все остальные издохнут.
Суть не в том есть ли там поддержка этого stop или нет.
Суть в том что поддержка MSE обязательно появится абсолютно везде уже завтра.
И кнопкой Stop не остановишь кастомный js от закачки видео.
Просто вместо того чтобы запрашивать видео кусочками, транскодер подготовил отдельные файлы.
Без разницы или нарезать файлы на байты «по линии сегментов» или запрашивать с помощью range «по линии сегментов».
Результат тот же.
Технология видеостриминга это совокупность: кодека, контейнера, манифеста и способа доставки.
— Кодек жмет видео в поток видеоданных. Это h.264, webm etc.
— Контейнер, он же формат эти данные упорядочивает. mp4, mpeg-ts etc.
— Манифест сообщает метаданные. К примеру данные о структуре сегментов могут быть вписаны как в атомы mp4 (еденица внутренней структуры mp4), так и во внешнем XML файле как в DASH/ M$S
— Способ доставки это порядок взаимодействия при закачке видео. Протокол (в значения правил, а не RFC) по сути.
Популярных технологий несколько: Microsoft Smooth Streaming, Apple HLS, Adobe что-то то там и MPEG-DASH
под которым подписался Netflix+Youtube следовательно все остальные издохнут.
Суть не в том есть ли там поддержка этого stop или нет.
Суть в том что поддержка MSE обязательно появится абсолютно везде уже завтра.
И кнопкой Stop не остановишь кастомный js от закачки видео.
Да, но на данный момент в HTML/JS буферизацией особо не по управляешь. Если быть точнее, то вообще не по управляешь. Браузер сам занимается буферизацией.
Только в случае с MSE, наверное, у разработчика появляется возможность влиять на буферизацию. Правда, если честно, не изучал документацию по MSE подробно.
Только в случае с MSE, наверное, у разработчика появляется возможность влиять на буферизацию. Правда, если честно, не изучал документацию по MSE подробно.
Посмотрел. Да, в случае с MSE есть возможность контролировать буферизацию. Правда, MSE пока поддерживается только в Chrome и IE11. Причем, в случае с IE11, MSE поддерживается только на Windows 8.
Ну вот через MSE и управляют.
Все браузеры годовой свежести (большинство еще раньше) поддерживают MSE.
Проще всего это понять зайдя на страницу YT.
Все браузеры годовой свежести (большинство еще раньше) поддерживают MSE.
Проще всего это понять зайдя на страницу YT.
Как я уже сказал выше, поддерживает только Chrome и IE 11. Chrome на любой системе, IE11 только на Windows 8. Firefox все еще не имеет поддержки MSE. Планировалось зарелизить базовую поддержку еще в 30 версии, но каждый раз переносят. Safari на данный момент не поддерживает. Но в бете 10.10 определенные намеки на возможную поддержку MSE в Safari есть. Правда, Safari не справился с воспроизведением видео, но, хотя бы, попытался распарсить манифест.
На счет Opera знаю только, что должна была поддерживать с 20 версии, но только в WebM. Насколько хорошо у нее это удается — не проверял.
На счет Opera знаю только, что должна была поддерживать с 20 версии, но только в WebM. Насколько хорошо у нее это удается — не проверял.
Как выше заметили про котят — там стоп не надо, если видео одно. Бывает десятки или сотни видео на странице с котятами — все они в буфере и забуть про ОЗУ.
Также часто надо для больших видео. Например начал смотреть фильм, а он оказался шлаком. Разумеется спасает F5, но опять трафик на обновление страницы.
Отличие паузы от стоп в том, что пауза останавливает воспроизведение, но продолжает буферизацию. А стоп — останавливает буферизацию.
Я думаю, что даже на Ютуб, буферизация кусками реализована по этой причине. Правда криво :)
Также часто надо для больших видео. Например начал смотреть фильм, а он оказался шлаком. Разумеется спасает F5, но опять трафик на обновление страницы.
Отличие паузы от стоп в том, что пауза останавливает воспроизведение, но продолжает буферизацию. А стоп — останавливает буферизацию.
Я думаю, что даже на Ютуб, буферизация кусками реализована по этой причине. Правда криво :)
См. ответ выше.
А при чем тут качество картинки к плееру? 0_о
И на чем вы основываетесь, говоря, что это быстрее «всяких плееров основанных на флеше»? И как может быть качество картинки аргументом, если разработчики плееров вообще не имеют к этому отношения — все зависит от сжатия и кодеков?
Вот мне больше интересно, когда в html5 video можно будет добавлять отдельно видео и аудио, чтобы между разными аудиодорожками переключаться.
Кстати, у разработчиков этого плеера есть нечто подобное в планах. Правда там это опять же в контексте accessibility, чтобы добавлять функцию включения дополнительной звуковой дорожки с audio discription (тифлокомментарием) для слепых, но по сути функциональность близкая, так что можете подождать и допилить под свои нужды, если нет желания писать с нуля. Ну а в родной реализации видео в HTML5, боюсь, это не скоро появится.
www.annodex.net/~silvia/itext/elephant_separate_audesc_dub.html с небольшим рассинхроном
Эммм… Да хоть сейчас. MSE это уже давно позволяет.
Тут есть свои проблемы, как то синхронизация, или, например на iOS можно одним js-действием запустить воспроизвдение(старт буферизации, если точнее) только одного потока аудио или видео. То есть, грубо говоря, нужно будет 2 раза нажимать на плей.
Так сделано, чтобы не грузить ненужное пользователю. Хотя это тоже так себе решение из разряда «чтобы сделать юзеру хорошо», поскольку через
Так сделано, чтобы не грузить ненужное пользователю. Хотя это тоже так себе решение из разряда «чтобы сделать юзеру хорошо», поскольку через
XHR можно загрузить как arraybuffer любое количество файлов, а затем их проигрывать через Web Audio API, правда там с этим свои сложности.
Жаль только, что такое решение не позволит оставить одну копию видео, а не тратить лишние ресурсы на повторное кодирование в web и последующее хранение двух копий видео.
Пока более рациональным с точки зрения сервиса выглядит fallback на флеш, если браузер не поддерживает воспроизведение h264 нативно.
Пока более рациональным с точки зрения сервиса выглядит fallback на флеш, если браузер не поддерживает воспроизведение h264 нативно.
А чем он лучше других? Я так и не понял его больших преимуществ.
Я пользуюсь FlowPlayer. Вот и интересует: почему он (плеер из статьи)?
Преимущества над FlowPlayer, которые я заметил
— Мало кода. Это временно. Дальше будет больше, как у всех.
— Бесплатный. У FlowPlayer это решаемо, генератор ключей есть в сети, а для крупных проектов — цена не такая уж и большая.
— Работает с NoScript и прочим. Это тоже легко решаемо в FlowPlayer, только надо самому это решать.
Зато минусы:
— Нет обратной совместимости (я про FLV)
— Функционал очень маленький. У FlowPlayer и API, и плагины/модули. И много ещё чего вкусного…
Это краткое сравнение с моим любимым плеером. И таких плееров уже десятки.
PS Очень не понравились рывки progressbar'а, каждую секунду рывок, а не плавное увеличение. Могли бы и CSS3 анимацию прикрутить.
Я пользуюсь FlowPlayer. Вот и интересует: почему он (плеер из статьи)?
Преимущества над FlowPlayer, которые я заметил
— Мало кода. Это временно. Дальше будет больше, как у всех.
— Бесплатный. У FlowPlayer это решаемо, генератор ключей есть в сети, а для крупных проектов — цена не такая уж и большая.
— Работает с NoScript и прочим. Это тоже легко решаемо в FlowPlayer, только надо самому это решать.
Зато минусы:
— Нет обратной совместимости (я про FLV)
— Функционал очень маленький. У FlowPlayer и API, и плагины/модули. И много ещё чего вкусного…
Это краткое сравнение с моим любимым плеером. И таких плееров уже десятки.
PS Очень не понравились рывки progressbar'а, каждую секунду рывок, а не плавное увеличение. Могли бы и CSS3 анимацию прикрутить.
Не говоря уж о том, что для стриминг сервисов придется использовать еще плюс дофига JS-кода, ибо только HLS поддерживает из коробки стриминг. А дальше либо MPEG-DASH, либо RTMP. :)
А вы до какого предложения с начала статьи прочитали? Главное преимущества описывается уже в первом абзаце, да и ясно из первого слова названия плеера. Если же термин accessible вам ни о чём не говорит, то не обижайтесь, но надо прокачивать профессиональную эрудицию.
Этот плеер поддерживает только нативные форматы. Окей, перефразирую: статические файлы, псевдо-стриминг, HLS (и то, только на OS X в Safari).
Как бы то ни было:
Хочешь посмотреть стрим с камеры? Нет, это ведь accessible плеер от PayPal, он не умеет.
Как бы то ни было:
Accessibility is the degree to which a product, device, service, or environment is available to as many people as possible
Хочешь посмотреть стрим с камеры? Нет, это ведь accessible плеер от PayPal, он не умеет.
Написали бы, в чем, по вашему мнению, я не прав. Раз уж минусы поставили. В моей голове одни стримы последние несколько месяцев, ибо с ними мы и работаем. Поэтому мой пример связан с ними.
Более удачные примеры привели два человека ниже.
Более удачные примеры привели два человека ниже.
Хочешь посмотреть стрим с камеры? Нет, это ведь accessible плеер от PayPal, он не умеет.
Вы не совсем правильно понимаете саму суть accessibility как свойства продукта. Это не возможность применить некий продукт наибольшим числом способов, а возможность использования его заявленной функциональности наибольшим числом пользователей в условиях различных ограничений, как технологических, так и физических.
Если следовать вашей логике, то никакой продукт нельзя назвать доступным (accessible), потому что в видеоплеере для воспроизведения формата A, я не смогу смотреть формат B, а молоток я не смогу использовать как микроскоп. Но дело в том, что этот плеер и не заявлял воспроизведение формата B, а молоток не вызывался работать микроскопом. То есть accessibility — это возможность использование заявленной функциональности наибольшим числом пользователей.
Никто не говорит, что этот плеер от PayPal самый функциональный или самый красивый. Речь лишь о том, что он представляет собой готовую реализацию, в которой в наибольшей степени решена проблема доступности, которая в других плеерах присутствует в полный рост.
Как я уже сказал, в последние несколько месяцев работал только со стримами, поэтому это первое, что пришло в голову.
Но, ребята взяли просто HTML 5 видео плеер и выложили его на Github. Вот такой же: www.w3schools.com/html/html5_video.asp
По-сути, единственное, что они сделали, это поддержка кастомного интерфейса.
Причем, про:
и пара инструкций из разряда aria-hidden = true.
А дальше встают все те же вопросы относительно кучи форматов, которые необходимы для того, чтобы видео воспроизводилось на всех девайсах и этим уже будет заниматься сервер (если это понадобится).
Ну да ладно, это все разговор ни о чем.
Но, ребята взяли просто HTML 5 видео плеер и выложили его на Github. Вот такой же: www.w3schools.com/html/html5_video.asp
По-сути, единственное, что они сделали, это поддержка кастомного интерфейса.
Причем, про:
Чтобы screenreader'ы видели и корректно распознавали различные контролы, наложена специальная семантическая разметка, описывающая типы и состояния этих элементов в понятной для них форме.можно сказать только то, что там есть класс sr-only, который делает
position: absolute !important;
clip: rect(1px, 1px, 1px, 1px);
padding: 0 !important;
border: 0 !important;
height: 1px !important;
width: 1px !important;
overflow: hidden;
и пара инструкций из разряда aria-hidden = true.
А дальше встают все те же вопросы относительно кучи форматов, которые необходимы для того, чтобы видео воспроизводилось на всех девайсах и этим уже будет заниматься сервер (если это понадобится).
Ну да ладно, это все разговор ни о чем.
Вот такой же: www.w3schools.com/html/html5_video.asp
А куда смотреть?
«HTML Video Example» — здесь недоступно изменение громкости, а элемент перехода по ролику реализован мало доступными для экранных чтецов методами, к тому же некоторые другие управляющие элементы выполнены не оптимально, например, PayPal не случайно делали переключатели звука и субтитров через checkbox, а не button. В общем, тут все проблемы стандартного плеера HTML5.
«Example: Using JavaScript» — здесь вообще всё убого и функциональность просто несопоставима.
По-сути, единственное, что они сделали, это поддержка кастомного интерфейса.
Верно, именно такая задача и стояла — обернуть стандартный контейнер video из HTML5 в более доступную обёртку. Если нужно что-то более сложное, то надо поднапрячься самим на бэкэнде, PayPal сделали работу по обеспечению доступности фронтэнда, чтобы вы не ломали голову над обеспечением accessibility.
можно сказать только то, что там есть класс sr-only
Посмотрите ещё в JS-код. Там есть не очень сложные манипуляции с метками кнопок для программ экранного доступа, где как раз используются возможности WAI-ARIA.
А куда смотреть?
Естественно, я преувеличивал, когда говорил об этом. Видимо, надо говорить все как есть. Окей: они не далеко ушли от обычного HTML 5 плеера.
Посмотрите ещё в JS-код. Там есть не очень сложные манипуляции с метками кнопок для программ экранного доступа, где как раз используются возможности WAI-ARIA.
Именно про них я и сказал
и пара инструкций из разряда aria-hidden = true.
Очень сложные, да. Это же надо поставить aria-label="%label_text%".
Возможно, меня обманывают мои глаза и я чего-то не замечаю? Ролей нигде там не применяется. Из всех WAI-ARIA атрибутов я видел только aria-hidden и aria-label.
В общем исходя из статьи/комментариев — они первые подобное реализовали. Показали, что и как надо делать.Теперь разработчикам плееров надо просто увидеть этот материал и добавить данную поддержку к своим продуктам (в ядро или модулем).
И вот это всё надо было писать в статье. А не в комментариях. Ибо 99% прочитавших мало поняли преимущевства и о чем вообще этот плеер.
И вот это всё надо было писать в статье. А не в комментариях. Ибо 99% прочитавших мало поняли преимущевства и о чем вообще этот плеер.
Я прочитал.
И долго пытался понять, чего же в нем из «accessible». Табом можно добраться до кнопок управления? Замечательно это плюс. А вот горячих клавиш нету — это минус. Api тоже нету. А ведь можно было бы и глобальные клавиши управления посадить.
Поэтому с моей стороны и была просьба, которая успешно проигнорирована, описать преимущевства, кроме красивыфх слова «HTML5» и «accessible».
И долго пытался понять, чего же в нем из «accessible». Табом можно добраться до кнопок управления? Замечательно это плюс. А вот горячих клавиш нету — это минус. Api тоже нету. А ведь можно было бы и глобальные клавиши управления посадить.
Поэтому с моей стороны и была просьба, которая успешно проигнорирована, описать преимущевства, кроме красивыфх слова «HTML5» и «accessible».
Поэтому с моей стороны и была просьба, которая успешно проигнорирована, описать преимущевства, кроме красивыфх слова «HTML5» и «accessible».
Преимущество заключается в том, что интерфейс в максимальной степени доступен. Навигация с клавиатуры — это, конечно, must have, но технически это решается достаточно просто через атрибут tabindex, а основные фишки здесь заключаются в доступности элементов управления для программ экранного доступа. Чтобы screenreader'ы видели и корректно распознавали различные контролы, наложена специальная семантическая разметка, описывающая типы и состояния этих элементов в понятной для них форме. Делается это средствами стандарта WAI-ARIA, который как раз и является подразделом HTML5.
В результате, Accessible HTML5 Video Player позволяет пользователям программ экранного доступа без проблем работать с встроенным в страницу видео, причём количество доступных возможностей по управлению больше, чем у альтернативных решений, где в лучшем случае доступны функции запуска/паузы и перемотки, и то, если повезёт.
к тому же на андроиде интерфейс видеоплеера отличается от интерфейса на ПК, по крайней мере в огнелисе
Во, отлично сделали. В массы нужно.
Нет, нормальной документации — терпимо
Поддерживаются только нативные стриминги — терпимо
А вот то что этот плеер не может нормально воспроизводить рекламу (мид-роллы, пост-роллы ), ставит на это плеере жирный крест.
Поддерживаются только нативные стриминги — терпимо
А вот то что этот плеер не может нормально воспроизводить рекламу (мид-роллы, пост-роллы ), ставит на это плеере жирный крест.
Ну как уже здесь писалось, его можно воспринимать как пример реализации поддержки accessibility-технологий. К тому же есть ниши, в которых он вполне готов к применению уже в существующем виде: без рекламы и прочего. Например, к государственным сайтам предъявляются требования обеспечения доступности, а рекламы и прочего там как раз не нужно, так что на каком-нибудь *.gov.ru он вполне придётся ко двору уже в текущем состоянии. Только вот, к сожалению, с accessibility у государственных сайтов зачастую всё ещё хуже, чем у многих коммерческих. Особенно вгоняет в уныние, когда формально это декларируется, но видно, что занимались этим люди совершенно некомпетентные.
Так а какой поддержке accessability-технологий дает этот плеер? Субтитры на любой платформе? Нет. Хоткеи на любой платформе? Нет. Видео-стриминг? Нет. Кастомазиция дизайна на всех платформах? Нет
Вы можете мне на пальцах объяснить по какой причине я должен выбрать этот плеер, а не скажем video.js или flowplayer? Имхо, они держат такую же функциональность и много более. Вы говорите, что эта библиотека дает возможность бОльшему количеству людей пользовать видеоконтент. Для меня это не очевидно.
Вы можете мне на пальцах объяснить по какой причине я должен выбрать этот плеер, а не скажем video.js или flowplayer? Имхо, они держат такую же функциональность и много более. Вы говорите, что эта библиотека дает возможность бОльшему количеству людей пользовать видеоконтент. Для меня это не очевидно.
Простите: *о какой поддержке accessability-технологий идет разговор?
Ну вот чуть выше это всё обсуждалось.
Я называю этот плеер доступным потому, что в отличии от других готовых решений, по крайней мере, известных мне, он предоставляет возможность в максимальной степени пользоваться всеми его функциями из под программ экранного доступа. Запуск/остановка воспроизведения, перемотка, включение/выключение звука и субтитров, а также школа настройки громкости — всё это доступно для экранных чтецов и выполнено в форме наиболее эргономичных для невизуальной работы контролов. Известные мне альтернативные решения всем этим разом похвастаться не могут: они либо вообще недоступны, либо доступны фрагментарно и часто требуют от пользователя вспомогательных технологий продвинутых навыков, так как взаимодействие с ними хоть и возможно, но достаточно нетривиально и предполагает применение особых лайвхаков, типа отключения виртуального курсора screenreader'а, эмуляцию мыши, попиксельный сдвиг курсора от какого-то ориентира для клика вслепую и прочих.
Если не согласны, то покажите мне готовую реализацию видео плеера, который, на ваш взгляд, сопоставим с плеером PayPal по уровню accessibility. Я буду только рад узнать о чём-то в этом роде.
Если не согласны, то покажите мне готовую реализацию видео плеера, который, на ваш взгляд, сопоставим с плеером PayPal по уровню accessibility. Я буду только рад узнать о чём-то в этом роде.
Сдаётся мне, программы-медиа-проигрыватели скоро начнут отмирать, как жанр. А зачем, спрашивается, качать что-то, потом программу запускать, когда можно прямо с сети смотреть, слушать? Научиться переключаться между дорожками, как сказал vplka; менять параметры яркости-контрастности-цветности, если, конечно, это ещё не возможно — и всё, одним жанром desktop-приложений станет меньше. VLC, GOM, LA останутся уделом тех, у кого сложности с доступом в сеть интернет.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Готовое решение доступного видеоплеера на HTML5