HTML5 video, контроль качества

«click to report playback problem»

Не, аудитория слишком маленькая. Если один человек из ста отпишется о качестве (а это весьма оптимистично) то у меня будет одно или два сообщение в день, для статистики этого мало.

Элемент video предоставляет нужную информацию,

А какая там инфа предоставляется? вроде, несколько стандартных ошибок и все.

но что-бы делать какие-то выводы её нужно дополнительно обрабатывать и фильтровать. Очень не хочется придумывать и писать всё это самому

А что там писать? Одна функция, вешаешь ее на видео, и все.

<video id="v" src="/video/ppanda.mp4" controls>
<script>
v.onerror=function(err){
  // handle err
}
</script>

А какая там инфа предоставляется? вроде, несколько стандартных ошибок и все.

https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Media_events
http://www.w3.org/2010/05/video/mediaevents.html

А что там писать? Одна функция, вешаешь ее на видео, и все.

error это, как я понял, только по какие-то совсем серьёзные ошибки, вроде отсутствия соурса или его нечитабельности.
Меня интересует не это, меня интересуют косяки вроде «файл не успевает подгружаться и из-за этого видео фризится».

Штука вроде того что написал ты у меня уже есть и работает, только ловит она waiting (это когда «в данный момент я не могу воспроизводить потому-что нужные данные ещё не скачались»), а не error.
При-чём waiting возникает например при первоначальном запуске видео и при перемотке. При-чём по несколько раз.
У меня сейчас есть лог за несколько суток, но делать на его основе какие-то выводы трудно.
Вот смотри. За последние двое суток (плюс-минус) событие waiting возникло 1368 раза. О чём это говорит в плане качества обслуживания? Может просмотров было стотыщь, и эта тыща waiting-ов — капля в море. Может просмотров была сотня и в течении каждого видео нещадно тормозило. 10 прерываний на подгрузку в течении десятисекундного просмотра — неприемлемо (скорее всего просмотр прервётся из-за этих косяков), 10 прерывания в течении десятичасового просмотра — незначительно.

Можно фильтровать waiting-и в начале просмотра и после перемотки (и я это уже даже сделал). Можно отслеживать все просмотры (и это сделано). Можно во время просмотра слать «пинги» что-бы отслеживать продолжительность просмотра. Можно по этой информации восстанавливать картину каждого просмотра. Можно придумать какой-то алгоритм оценивающий насколько просмотр был удачным.
Этого я пока не сделал, потому-что заметил что то что начиналось как примитивный скриптик в три строки разрастается во что-то большое, кривое и велосипедоподобное. Так-что я решил обратиться к коллективному бессознательному ЛОРа, вдруг кто-то уже заморачивался этим больше меня и нашёл/написал что-то хорошее.

контроль качества
видео
в браузере

провалено. ты бы еще в нотном редакторе видео показывал.

Расскажи об этом парням из гугла например.

// handle err

Отвалился коннект — хандл еррор, детка. Может и не прокатить.

Это как-раз не проблема. Видео и приёмник логов находятся на разных серверах (а может-быть и в разных датацентрах), вместе дохнуть не должны. Ну а если соединение отвалилось на стороне пользователя то это уже точно не моей задницы геморрой.

парням из гугла

знатные говноеды, судя по тому, как ютуб порой работает даже на 100Мбит

А в чём проблема смотреть на то, как быстро сервер отдаёт видео с учётом его битрейта?

Смотри мою предыдущую тему. Если кратко — ширина интернетов сервера не гарантирована (гарантированная ширина интернетов стоит дорого). Ну и ещё битрейт видео штука вариабельная.
К тому-же задача стоит — «что-бы у клиентов было хорошо» (точнее не слишком плохо), а это логичнее отслеживать на стороне клиента.

ширина интернетов сервера не гарантирована

А какая разница? У тебя есть известная ширина окна у каждого пакета, в ответ приходит ACK, вот и считай, если уж совсем ничего не остаётся.

Ну и ещё битрейт видео штука вариабельная.

Его можно довольно дёшево прикидывать, демукся контейнер.

логичнее отслеживать на стороне клиента

Логичнее-то безусловно, но HTML.

А какая разница? У тебя есть известная ширина окна у каждого пакета, в ответ приходит ACK, вот и считай, если уж совсем ничего не остаётся.

Разверни мысль

Если «файл не успевает подгружаться и из-за этого видео фризится», юзер не будет его смотреть и будет искать на странице циферки 480, 360, ну или 240 на худой конец

https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Flow_control
Ну, разумеется, это можно считать и из юзерспейса, делая лишь ставку на ядерный буфер.