Разработчики dash.js говорили, что в некоторых случаях нужен был (на тот момент еще) не стабильный.
Ну и мобильный хром — это, в общем, совсем другой браузер. По крайней мере проигрывание fragmented mp4 там происходит совсем не так, как в обычном хроме.
На самом деле работают, но не все. Это я (автор — это я) поторопился написать. С одним из файлов была такая проблема, но с другими не в baseline ее уже не было.
Однако baseline — все равно вариант предпочтительный, лучше всего поддержан.
Вы не поняли. Я сказал «перейти на эту модель», что также включает high=a.length, while (low < high) {...} заметьте, кода стало меньше, это почти всегда хороший знак для программиста.
Этот случай красноречиво показывает, что если вам надо, чтобы индекс был отрицательным, значит в алгоритме есть проблема, его, как минимум, можно упростить.
Что касается приведенного вами алгоритма, то общепринятым является работа с полуоткрытым диапазоном — слева включающий, а справа исключающий (как итераторы в STL — begin() принадлежит контейнеру, а end() — нет). Так вот, если перейти на эту модель, то приведенный код упрощается, а проблема исчезает т.к. high = mid — 1 превращается в high = mid.
По поводу возвращения -1, то да, есть такая проблема. Но это значит, что надо использовать знаковые числа именно в этих случаях, а не в всех. Например, сискол read() в линукс принимает size_t (беззнаковый) на вход, но возвращаетс ssize_t (знаковый) именно из-за необходимости иногда возвращать -1.
Ну и вообще знаковым число должно быть ровно тогда, когда знак имеет смысл в вашей задаче.
Кроме того, немногие знают, что переполнение знаковых числел в С (а значит и в нативной арифметике некоторых процов) приводит к непредсказуемым результатам, в отличие от беззнаковых.
Оператор деления на 2 (в случае беззнаковых чисел) делает ровно то же самое. А вообще проблема высосана из пальца и в основном связана с тем, что в Java нет беззнаковых чисел. Индексировать массив знаковым числом — это глупость, которая приводит к описанным здесь результатам.
Raspberry Pi + cam module + ffmpeg и вещать через 3G/4G usb-модем на сервак.
Самое сложное в этой системе (на мой программистский взгляд) — источник питания.
Где-то в доках осталось описание старого поведения?
из десктопных браузеров только Safari поддерживает HLS.
Ну и мобильный хром — это, в общем, совсем другой браузер. По крайней мере проигрывание fragmented mp4 там происходит совсем не так, как в обычном хроме.
Однако baseline — все равно вариант предпочтительный, лучше всего поддержан.
Этот случай красноречиво показывает, что если вам надо, чтобы индекс был отрицательным, значит в алгоритме есть проблема, его, как минимум, можно упростить.
По поводу возвращения -1, то да, есть такая проблема. Но это значит, что надо использовать знаковые числа именно в этих случаях, а не в всех. Например, сискол read() в линукс принимает size_t (беззнаковый) на вход, но возвращаетс ssize_t (знаковый) именно из-за необходимости иногда возвращать -1.
Ну и вообще знаковым число должно быть ровно тогда, когда знак имеет смысл в вашей задаче.
Кроме того, немногие знают, что переполнение знаковых числел в С (а значит и в нативной арифметике некоторых процов) приводит к непредсказуемым результатам, в отличие от беззнаковых.
Raspberry Pi + cam module + ffmpeg и вещать через 3G/4G usb-модем на сервак.
Самое сложное в этой системе (на мой программистский взгляд) — источник питания.
А вообще было бы здорово организовать прямую трансляцию «с орбиты».
На самом деле это прекрасный компромисс.