Обсуждение: динамическая адаптивная потоковая передача по HTTP
Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
WikiProject Computing / Сеть / Веб-сайты (Номинальный B-класс, Низкая важность)
Значок WikiProjectЭта статья находится в рамках WikiProject Computing , совместной работы по расширению охвата компьютеров , вычислений и информационных технологий в Википедии. Если вы хотите принять участие, посетите страницу проекта, где вы можете присоединиться к обсуждению и увидеть список открытых задач.
B-Class article B Эта статья была оценена как B-Class по шкале качества проекта .
 Низкий Эта статья была оценена как Низкая по шкале важности проекта .
Значок рабочей группы
Эта статья поддерживается целевой группой по сетевым технологиям (помечена как " Низкая важность" ).
Значок рабочей группы
Эта статья поддерживается веб-сайтами WikiProject (помеченными как Низкая важность ).
 
WikiProject Интернет (Класс B, средний уровень)
Значок WikiProjectЭта статья находится в рамках WikiProject Internet , совместной работы по расширению охвата Интернета в Википедии. Если вы хотите принять участие, посетите страницу проекта, где вы можете присоединиться к обсуждению и увидеть список открытых задач.
B-Class article B Эта статья была оценена как B-Class по шкале качества проекта .
 Середина Эта статья была оценена как средняя по шкале важности проекта .
 

Уточните формулировку в разделе сервера

В нем говорится: «Обратите внимание, что со стороны сервера не требуется никакой конкретной поддержки для содержимого DASH, за исключением _Live Streaming_», но неясно, что такое «Live Streaming» в этом контексте. Я не смог найти ни одной части протокола HTTP, который в настоящее время определяется как «Прямая трансляция». 172.2.203.49 ( разговорное ) 16:32, 6 мая 2015 (UTC) Рон Дж.

Это термин, характерный для потокового мультимедиа, а не для самого HTTP. Что касается MPEG-DASH, потоковая передача в реальном времени требует генерации сегментов на лету и повторной генерации файла манифеста только из-за характера носителя (это происходит «прямо сейчас», а не предварительно). Обычный веб-сервер не может справиться с этим. Отсюда замечание об исключении прямой трансляции. Возможно, «Live Streaming» не стоит начинать с заглавных букв. Юррик ( разговорное ) 00:40, 8 мая 2015 (UTC)

DASH в заголовке?

Следует ли включать "DASH" как часть имени страницы? BambelB ( разговорное ) 15:54, 9 декабря 2011 (UTC)

Возможно. Я все равно создал перенаправление из MPEG-DASH Седьмой Тейлор ( разговор ) 08:14, 1 мая 2012 (UTC)

Ссылка на потоковую передачу с адаптивным битрейтом

Разве эта ссылка не должна быть на: Адаптивная потоковая передача битрейта ? BambelB ( разговорное ) 15:54, 9 декабря 2011 (UTC)

Я согласен. Готово сейчас. Седьмой Тейлор ( разговор ) 08:14, 1 мая 2012 (UTC)

Ссылка на MPEG

Не следует ли добавить сюда поля навигации {{Форматы сжатия}} и {{Методы сжатия}}? И где в это место должен быть MPEG-DASH? Седьмой Тейлор ( разговор ) 23:58, 12 апреля 2012 (UTC)

DASH 264

Я заметил, что форум индустрии DASH опубликовал стандарт v0.9 для DASH264 [1] . Это то же самое, что и MPEG-DASH, или что-то другое? Седьмой Тейлор ( разговор ) 10:50, 17 января 2013 (UTC)

Я начал читать стандарт для «DASH264» [2] и обнаружил на странице 7, строка 16, что в нем упоминается как отдельный стандарт, стандарт «MPEG-DASH». ( MoreOrLezFun ( обсуждение ) 19:57, 23 января 2013 (UTC))
Я думаю, что стандартная ссылка MPEG-DASH должна быть обновлена ​​до [3] - Предыдущий неподписанный комментарий добавлен 207.253.7.190 ( обсуждение ) 21:38, 4 августа 2014 г. (UTC)

Обременен ли патент DASH?

Было бы хорошо уточнить эту информацию в статье - Бахалтенер ( разговор ) 02:47, 18 декабря 2014 (UTC)

Следует ли упоминать HLS во введении?

Нет необходимости упоминать, что MPEG-DASH похож на Apple HLS. - Предыдущий неподписанный комментарий добавлен Rushikesh90 ( обсуждение • вклад ) 04:56, 11 мая 2016 г. (UTC)

Кроме того, во введении говорится, что «MPEG-DASH - это первое решение потоковой передачи на основе HTTP с адаптивной скоростью передачи данных, которое является международным стандартом. [1]» (введено в 2012 г.). Но HLS стал стандартом Internet Engineering Task Force с мая 2009 года (см. Https://en.wikipedia.org/wiki/HTTP_Live_Streaming ).

Внешние ссылки изменены

Привет, друзья Википедии,

Я только что изменил одну внешнюю ссылку на Dynamic Adaptive Streaming over HTTP . Пожалуйста, найдите время, чтобы просмотреть мою правку . Если у вас есть какие-либо вопросы или вам нужно, чтобы бот игнорировал ссылки или страницу в целом, посетите этот простой FAQ для получения дополнительной информации. Я внес следующие изменения:

  • Добавлен архив https://web.archive.org/web/20130624105147/http://vicky.bitmovin.net:80/mailman/listinfo/libdash-dev в http://vicky.bitmovin.net/mailman/listinfo/ libdash-dev

Когда вы закончите просмотр моих изменений, установите для отмеченного ниже параметра значение true или не сообщите другим (документация по адресу ).{{Sourcecheck}}

Это сообщение было опубликовано до февраля 2018 г. После февраля 2018 г. разделы страницы обсуждения «Изменены внешние ссылки» больше не создаются и не отслеживаются InternetArchiveBot . В отношении этих уведомлений на странице обсуждения не требуется никаких специальных действий, кроме регулярной проверки с использованием приведенных ниже инструкций инструмента архивации. Редакторы имеют разрешение удалить эти разделы «Внешние ссылки изменены» на странице обсуждения, если они хотят убрать беспорядок на страницах обсуждения, но перед массовым систематическим удалением просматривают RfC . Это сообщение динамически обновляется с помощью шаблона (последнее обновление: 15 июля 2018 г.) .{{sourcecheck}}

  • Если вы обнаружили URL-адреса, которые бот ошибочно считал мертвыми, вы можете сообщить о них с помощью этого инструмента .
  • Если вы обнаружили ошибку в каких-либо архивах или самих URL-адресах, вы можете исправить их с помощью этого инструмента .

Ура. - InternetArchiveBot ( Сообщить об ошибке ) 05:26, 18 декабря 2016 г. (UTC)

Неверно утверждать, что СМИ обязательно сегментированы

Во вступлении говорится, что DASH включает «разбиение содержимого на последовательность небольших файловых сегментов на основе HTTP». У меня есть 48-минутный контрпример, на который я смотрю, и каждый битрейт видео имеет один файл (без разбивки по временным сегментам). Может быть, это следует удалить или уточнить.

Плавно

Мне очень не нравится слово «плавно» в начале. Если бы это было правдой. Не так давно я смотрел соревнования по гребле на Таити, используя Chromium / YouTube. Съемочную группу проинструктировали не мешать гонке, оставляя за собой след, который мог повлиять на следующую лодку, поэтому до тех пор, пока не образовалось большое разделение, освещение ограничивалось длинными кадрами с большим сжатием и не так много деталей, которые стоили бы иметь. Но тут женщина на лодке с Таити сделалаполучили огромное разделение, и они решили вернуться к этой лодке каждую секунду - по крайней мере, так казалось, - и произойдет внезапный переход к более близкому кадру, и сложность изображения и доступная детализация резко возрастут. Chromium попал в петлю переключения разрешения, где ему удавалось каждый раз разбрызгиваться. Во время крупных планов, когда вы действительно могли увидеть форму и технику, Chromium давал сбой на сотни миллисекунд за раз во время решающей механики. Он делал это снова и снова, часами. Затем вы вернетесь к большому кадру, где не было много деталей, достойных внимания, и все снова стало бы плавным. Я проиграл гонку и потратил время на то, чтобы разобраться с настройками буфера Chromium, чтобы попытаться решить проблему.

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

Учтите, что ваш интернет-провайдер перегружен и у него есть алгоритм для распределения фиксированной доли каждому клиенту (если вы удвоите ежемесячную плату, они выделят вам долю в десять раз больше, чем у основного клиента, но это уже другая история). Когда 720p переходит от высокого сжатия (скучная, несколько неподвижная сцена) к низкому сжатию (сложная, плавная, детализированная сцена), требования к пропускной способности сети резко возрастают, превышая ограничение вашего провайдера, и ваши пакеты начинают накапливаться в сетевых буферах (задержка буфера) как машины в час пик. Задержка приема постоянно увеличивается, пока пакеты не начнут падать на пол (вы, наконец, исчерпали задержку буфера), и теперь TCP / IP согласовывает повторную передачу (я предполагал, что это все еще было в миксе, но не проверял). Поскольку 5-секундная прямая буферизация Chromium начинает истощаться,Chromium переключается на более низкое разрешение. Но для более низкого разрешения требуется столько же данных для детализированной сцены, сколько для высокого разрешения для статической сцены, и вы все еще работаете в опасной близости от лимита вашего интернет-провайдера, а TCP / IP все еще восстанавливает потерянные пакеты из исходного потока.и новое постановление.

Проблема для Chromium заключалась в том, что уменьшение запроса разрешения не оказывало немедленного влияния на задержку приема, которая требуется его модели для обеспечения непрерывного потока.

Я даже не говорю о том, что ваш интернет-провайдер включает термин адаптивной пакетной полосы пропускания в их расчет ограничения (они дадут вам немного больше, чем ваша доля, вкратце, если вы заработали некоторый «кредит» пропускной способности, не загружая постоянно Wayback Машина).

Слово «цельный» применимо, если бы это была одномерная проблема, но в реальной жизни проблема имеет много сложностей.

Если глупый Хром / YouTube увеличила свою буферизацию браузера от 5 с до 30 с после десятой мульти-второй кабинке через десять минут в точно худшее время, воспроизведение было бы гладко. В конце концов я обманом заставил его сделать это (не могу вспомнить, был ли этот тест Chromium или Firefox), долгое время нажимая "паузу", и когда я вернулся, у меня было много минут предварительно загруженных данных, и в основном DASH больше не было эффект (мое разрешение было эффективно заблокировано в течение коротких периодов времени, если Chromium не хотел пролить несколько минут предварительно загруженных данных на пол).

Я также постоянно вижу это в хоккейных видеороликах на YouTube, где наблюдается безумная активность, и угол камеры меняется сразу после забитого гола, когда интенсивность действий нарастает, кодировщик теряет разрешение от высокочастотных компонентов до шайбы. становится исключительно размытым, если не полностью невидимым, и требуется шесть повторов, чтобы выяснить, какие игроки действительно коснулись шайбы в решающие моменты. У меня был опыт, когда воспроизведение за повтором, вы видите, как защитник загружается для прорыва, затем видео останавливается и заикается, когда угол обзора камеры разбивает лед, и следующее, на что вы можете хорошенько разглядеть, - это Коннор МакДэвид. скользит мимо складки, подняв руки вверх.

Кто-нибудь, пожалуйста, скажите мне, где существует этот «цельный» опыт DASH, чтобы я тоже мог им насладиться. - MaxEnt 17:12, 13 июля 2017 г. (UTC)

Внешние ссылки изменены

Привет, друзья Википедии,

Я только что изменил 3 внешние ссылки на Dynamic Adaptive Streaming over HTTP . Пожалуйста, найдите время, чтобы просмотреть мою правку . Если у вас есть какие-либо вопросы или вам нужно, чтобы бот игнорировал ссылки или страницу в целом, посетите этот простой FAQ для получения дополнительной информации. Я внес следующие изменения:

  • Добавлен архив https://web.archive.org/web/20120820233136/http://mpeg.chiariglione.org/meetings/geneva11-1/geneva_press.htm на http://mpeg.chiariglione.org/meetings/geneva11- 1 / geneva_press.htm
  • Добавлен архив https://web.archive.org/web/20111009063030/http://www.oipf.tv/live/oipf/release_2.html в http://www.oipf.tv/live/oipf/release_2. html
  • Исправлено форматирование / использование http://vicky.bitmovin.net/mailman/listinfo/libdash-dev.

Когда вы закончите просматривать мои изменения, вы можете следовать инструкциям в шаблоне ниже, чтобы исправить любые проблемы с URL-адресами.

Это сообщение было опубликовано до февраля 2018 г. После февраля 2018 г. разделы страницы обсуждения «Изменены внешние ссылки» больше не создаются и не отслеживаются InternetArchiveBot . В отношении этих уведомлений на странице обсуждения не требуется никаких специальных действий, кроме регулярной проверки с использованием приведенных ниже инструкций инструмента архивации. Редакторы имеют разрешение удалить эти разделы «Внешние ссылки изменены» на странице обсуждения, если они хотят убрать беспорядок на страницах обсуждения, но перед массовым систематическим удалением просматривают RfC . Это сообщение динамически обновляется с помощью шаблона (последнее обновление: 15 июля 2018 г.) .{{sourcecheck}}

  • Если вы обнаружили URL-адреса, которые бот ошибочно считал мертвыми, вы можете сообщить о них с помощью этого инструмента .
  • Если вы обнаружили ошибку в каких-либо архивах или самих URL-адресах, вы можете исправить их с помощью этого инструмента .

Ура. - InternetArchiveBot ( Сообщить об ошибке ) 06:57, 15 сентября 2017 г. (UTC)

Добавить VideoJS в список реализаций DASH

  • Информация для добавления или удаления: добавьте VideoJS в список клиентов и в таблицу клиентов
  • Объяснение проблемы: VideoJS - это широко используемый видеопроигрыватель HTML5 (более 23000 звезд на github ), поддерживающий воспроизведение DASH.
  • Ссылки, подтверждающие выпуск:
    • Объявление VideoJS 7
    • демонстрационная страница : поддержку DASH можно проверить с помощью этого тестового потока: https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps.mpd

Обратите внимание: в прошлом я участвовал в проекте VideoJS и работаю в компании ( Brightcove ), которая продолжает вносить свой вклад в этот проект.- Предшествующий неподписанный комментарий, добавленный Dlapalomento ( обсуждение • вклад ) 23:14, 22 января 2019 г. (UTC)

Ответить 22-ЯНВ-2019

  Запрос на изменение отклонен  

  1. Раздел, в который запрос на редактирование COI пытается добавить информацию, содержит шаблон обслуживания, в котором указано, что он содержит « информацию неясной или сомнительной важности или актуальности для предмета статьи ».
  2. Таким образом, редактор COI должен попытаться достичь консенсуса по поводу этого изменения с местным редактором, заинтересованным в теме, прежде чем делать запрос на редактирование.

С уважением,  Spintendo  23:26, 22 января 2019 г. (UTC)

Источник « https://en.wikipedia.org/w/index.php?title=Talk:Dynamic_Adaptive_Streaming_over_HTTP&oldid=879719505 »
Contribute a better translation