Pull to refresh

Comments 16

Спасибо за интересную статью. Проблема не нова и готового решения я тоже не нашёл. Попытался было применить Вашу библиотеку, но отпугнули некоторые Ваши решения в коде. Потому сделал «свой блекджек» ) Но за идею спасибо.
что не так с решениями в коде?
Модуль постоянно обновляется т.к. используется в программе.
1. Механизм кеширования привязан к конкретной реализации плейера. Что если я хочу использовать другой плейер, например ExoPlayer, или использовать механизм кеширования при стриминге аудио?
2. Я настороженно отношусь к коду библиотек без тестов.
3. Код местами объективно ну очень сложен. Чего только стоит метод из ~750 строк
4.… и не без огрехов: пустые catch блоки, смешение логики и представления, копипаст,…
5. Не проверял (и не смог понять из логики выполнения из-за п.3), нормально ли обрабатываются ситуации докачки видео, перехода в произвольную позицию во время стримминга, без которых кеш по сути теряет смысл.

1) Там по моему ясно написано: «1) Based on standart player. Easy to use with different other player, but! Not recommended;»
http запросы от любого плеера парсятся и ответ приходит в таком же (http) формате. Это очень унифицированно и подойдёт для любого http плеера. Наверное вы не правильно поняли. Там есть класс стандартного плеера, но он, как опция.

2) На гитхабе большая часть библиотек без тестов и что теперь? Не использовать их?))

3) Для меня этот код, как детский стих. Ничего там нет сложного, если понимать, что происходит. Я думаю написать можно только так. И если код ещё выносить в сторонние процедуры, то будет только сложнее. Я пишу наиболее сжато, максимально компактно и с использованием минимума быстрейших операторов. Да и чего вам надо? Статью написал, картинки сделал, код опубликовал. Вопросы есть? — задавайте! На русском языке даже отвечу)) О чём ещё можно мечтать???

4) Где пустые catch блоки — значит так надо. Там некоторые ошибки будут специально происходить. Им catch не нужен, но без него нельзя. Что бы говорить об огрехах нужно разобраться сначала. А вы лезете со своим уставом в чужой монастырь. Не надо так.

5) Всё просто. Сначала меняешь класс плеера в моём проекте. Запускаешь, проверяешь. Если всё работает, то меняешь настройки под себя, которые задаются в setPaths. Проверяешь. Если всё работает, то можно переносить код в свою программу.
В моём классе плеера есть пара лишних строчек для демо. О чём там ярко написано в комментариях и эти строчки легко можно найти и удалить. А класс плеера, я очень долго отлаживал. В нём собрано всё лучшее от Exoplayer, Vitamio и других… и пока похожего я не видел ни у кого.
Теоретически с помощью прокси можно даже формат видео преобразовывать налету в телефоне))). Так что простор для творчества такой большой, что вам и не снилось.
1.
Наверное вы не правильно поняли.
Напротив, я всё понял. Я хочу иметь возможность использовать интересное библиотечное решение для других плейеров, но автор библиотеки этого не рекомендует. Что мне остаётся, кроме как 1) допилить авторское решение 2) написать своё. Если сам автор пасует перед этой задачей, то, разумеется, лучше выбрать второй подход.

2.
На гитхабе большая часть библиотек без тестов и что теперь? Не использовать их?))
Я этого не говорил. Но без сомнения отдам предпочтение библиотеке с тестами. А иначе где доказательства того, что она работает корректно? Как вносить изменения в код без уверенности, что чего-то не поломал? И да, я стараюсь не использовать библиотеки без тестов. Не поленился просмотреть зависимости своего последнего проекта и обнаружил, что около 80% используемых библиотек имеют тесты. Отсутствие тестов в Вашей библиотеке — это бесспорный минус Вашей библиотеки, с этим бессмысленно спорить.

3.
Для меня этот код, как детский стих.
Поймёте ли Вы его через 2 года? Поймёт ли его другой программист? Ведь, как известно, 80% программист проводит в чтении своего или чужого кода и только 20% в написании.
Ничего там нет сложного, если понимать, что происходит.
Разумеется: ) Сложность-то как раз в том и заключается, чтобы понять: )
Я думаю написать можно только так
Любой код кроме разве что самых тривиальных случаев можно написать превеликом множеством способов.
Да и чего вам надо? Статью написал, картинки сделал, код опубликовал. Вопросы есть? — задавайте! На русском языке даже отвечу))
Как я говорил выше, к статье-то как раз нету никаких вопросов: всё грамотно и интересно.
О чём ещё можно мечтать???
О прекрасном, чистом, очевидном коде, который не боязно вставить в прадакш проект: ).
И если код ещё выносить в сторонние процедуры, то будет только сложнее.
Есть тысяча и один способ повысить читаемость кода и, да, вынесение в метод — один из них.

4.
Где пустые catch блоки — значит так надо.
Сложно поверить, что в например в HttpGetProxy 18 пустых catch блоков из 23 — это норма. Если есть желание обсудить код, можно это сделать на гитхаб ;)
А вы лезете со своим уставом в чужой монастырь. Не надо так.
Разве в мире opensource это не поощряется?

5.
А класс плеера, я очень долго отлаживал.
Возможно всё-таки стоит использовать тесты? Тогда не придется «очень долго отлаживать».
В нём собрано всё лучшее от Exoplayer, Vitamio
Вы уверены в этом? Ваш плейер поддерживает DASH, SmoothStreaming, DRM, он супер расширяем? Ведь это несомненно самое лучшее, что есть в ExoPlayer.
1) Я рекомендую потому что провёл много тестов плееров. И дело не в том что другие плееры могут подходить хуже к прокси. Дело в скорости их работы и глючности. Я много общался с авторами плееров на гитхабе и даже в личных сообщениях. Они не планируют исправлять что-либо. Если это и будет, то через 1-2 года.

2) Почему-то мне попадается только 1% библиотек с тестами. Возможно мы в разных областях работаем. Взять хотя бы приложение play.google.com/store/apps/details?id=com.desarrollodroide.repos&hl=ru найдите там с тестами проект))). Что-то нету.

3.1) Я пойму свой код через 5 лет, если надо. Достаточно быстро.
3.2) Для этого статья. Читайте и понимайте.
3.4) Я думаю вы не до конца понимаете что это за модуль и вам действительно нужно сделать свой. Этот модуль слишком навороченный. Вам нужно попроще.

4) Да хоть 140 пусть пустых будет! Какая разница, если они должны быть пустыми, значит так и будет. Или вы предлагаете ошибки пользователям отображать??)) Что с ними делать, если никак нельзя страховать ошибку?

5.1) Проблема в том что на программном эмуляторе не отследить ошибок и проблем. Не понятно по какому принципу работает плеер. Только на физическом устройстве можно что-то сделать.
5.2) Я же написал, что можно на лету хоть видео конвертировать. И ваши примочки, особенно DRM — для меня, как дьявол какой-то. Я категорически против любых DRM. Это всё от лукавого.

Что вообще вам надо??? Вы видели моё приложение Media Library?? Как там из пиринговых сетей воспроизводится видео хоть HD, хоть 4К формата прямо на телефоне. У меня скорость интернета на телефоне через 4g 15-30 м\бит… Этого достаточно для того что бы сказать, что все ваши видео примочки не нужны больше. Настало новое время. Достаточно просто http плеера.

И если у кого-то не хватает канала, то пора сказать им что бы увеличивали канал, а не подстраиваться под них.
1.
Я рекомендую потому что провёл много тестов плееров. И дело не в том что другие плееры могут подходить хуже к прокси. Дело в скорости их работы и глючности. Я много общался с авторами плееров на гитхабе и даже в личных сообщениях. Они не планируют исправлять что-либо. Если это и будет, то через 1-2 года.
Когда я говорил о интересном библиотечном решении, я имел в виду ImortalPlayer, а когда говорил, что автор не рекомендует его использовать для других плейеров, имел в виду Ваши же слова «Easy to use with different other player, but! Not recommended». Что собственно и подтверждает мои первоначальные слова «Механизм кеширования привязан к конкретной реализации плейера.»

2.
Почему-то мне попадается только 1% библиотек с тестами. Возможно мы в разных областях работаем. Взять хотя бы приложение play.google.com/store/apps/details?id=com.desarrollodroide.repos&hl=ru найдите там с тестами проект))). Что-то нету.
В этом сборнике в основном UI библиотеки. Тесты для них не так критичны. У вас же библиотека неUIайная (опциональная по вашим же словам реализация TextureView-плейера поверх прокси не в счет). В ней много работы с сетью, сокетами, файлами. Это нуждается в тестах.

3.
Я пойму свой код через 5 лет, если надо. Достаточно быстро.
Завидую Вашему оптимизму.
Для этого статья. Читайте и понимайте.
Объяснить идею обычным привычным языком — легко, очевидно объяснить её кодом — нет.
Я думаю вы не до конца понимаете что это за модуль и вам действительно нужно сделать свой. Этот модуль слишком навороченный. Вам нужно попроще.
Я прекрасно понимаю, «что это за модуль». Просто я хочу донести как можно более обоснованно и деликатно, что реализация его далека от идеала.
Этот модуль слишком навороченный. Вам нужно попроще.
Навореченный? Нет. Избыточно сложный в реализации — да.

4.
Да хоть 140 пусть пустых будет! Какая разница, если они должны быть пустыми, значит так и будет. Или вы предлагаете ошибки пользователям отображать??)) Что с ними делать, если никак нельзя страховать ошибку?
Я ничего не предлагаю. Я просто говорю, что повсеместно глушить ошибки — это плохой «запах» кода. Читайте классиков программирования. Да и далеко не одних catch-ах проблема, это просто пример.

5.
Я же написал, что можно на лету хоть видео конвертировать. И ваши примочки, особенно DRM — для меня, как дьявол какой-то. Я категорически против любых DRM. Это всё от лукавого.
Что вообще вам надо??? Вы видели моё приложение Media Library?? Как там из пиринговых сетей воспроизводится видео хоть HD, хоть 4К формата прямо на телефоне. У меня скорость интернета на телефоне через 4g 15-30 м\бит… Этого достаточно для того что бы сказать, что все ваши видео примочки не нужны больше. Настало новое время. Достаточно просто http плеера.
Очевидно, что Google (создатели DASH), Microsoft (создатели SmoothStreaming) так не считают.
5. Очевидно, что я пишу программы для нормальных людей, а не у которых нет 300 рублей на безлимитный 4g в месяц.
Или рядом нет wi-fi точки доступа с минимум 10-15 м.бит скоростью.
И вообще я считаю, что заострение внимания на этих технологиях только тормозит наш прогресс. Одни люди выпускают игры Mortal Kombat, который в сжатом состоянии весит 30гб… А другие занимаются разработкой плееров на технологиях, которые позволят смотреть видео на скорости 1м.бит. и меньше. Ощущаете, что кто-то из них не прав?))) Так как дистрибутив MK X или GTA 5 на скорости 1м.бит вы будете качать месяц! А третьи ещё разработали новый кодек h265, который сжимает видео ещё эффективнее, чем h264! Теперь 3-4 минуты видео HD качества весит 30-40мб.! Тогда как раньше было 50-60мб…
Так вот вместо того что бы осваивать нудные, не нужные технологии лучше бы добавили совместимость в андроид новых кодеков h265. А то mpc-hc уже давно их играет, а андроид и знать не знает что это такое.

3. Я написал этот код в первую очередь не для вас, а для себя. А вы ещё не видели мой сложный код на много тысяч строк. ImmortalPlayer для меня маленький кодик в который я очень быстро вношу нужные изменения. А вот в свой сложный код (Media Library) уже по несколько дней одна фича. И всё равно мне это кажется нормальным. Так как по сложности для меня это, как копать картошку. Есть, например С или С++ где нужно постоянно открывать новый мир… вот там сложно… а java — легкотня))).
То есть требуя от своих пользователей «толстого» интернет-канала, Вы способствуете прогрессу, а создавая новый протокол, позволяющий просматривать видео youtube на слабом интернет-канале, Google тормозит его?
Вы обманываете себя и ещё и меня пытаетесь обмануть этим предложением. Я не требую толстого канала. Это требуют алгоритмы сжатия файлов и от этого никуда не уйти.
Новый протокол не делает магии. Он не может передавать данные быстрее или сжимать их ещё лучше.
А обрезая качество мы не доносим до конечного пользователя всю информацию.
Вот скажите, если вам сказать, что «Россия запустила ракеты», то вы поймёте что это война или наши запустили новый спутник?
Так же и статический контент. Обрезая качество мы выкидываем слова из песни и в итоге люди не владеют всей информацией.
Это большая ошибка!
Тогда когда придумали обрезать качество опирались на возможность сделать первое массовое распространение видео\аудио.
Цель была достигнута и сейчас скорость распространения мультимедиа изменились в лучшую сторону многократно.
Но забыли о той технологии, которая позволила этот первый толчёк. Это была необходимая жертва.
А сейчас в этой жертве не то что нет необходимости, а она нам даже вредит так как мы не получаем всю информацию.
Разрешение экрана моего телефона 1920×1080. Скорость 4g около 30м\бит… безлимит за 400р. в месяц. Резаное качество видео, даже HD или 4K плохо сжатое с ютуба плохо смотрится на моём телефоне, что говорить о 240, которое предлагает ютуб.
Сейчас ни у кого в городах нет на столько больших проблем с интернетом, что бы не посмотреть видео hd формата. И нужно отказываться от низкого качества.
Винчестером 1тб уже давно никого не удивишь. Хранить видео в hd стало гораздо выгоднее чем 640*480. В этом и есть ваш самообман. Вы думаете занимаетесь разработкой технологий будущего, а на самом деле занимаетесь разработкой технологий прошлого. Разве можно такие простые вещи не понимать???
Обрезая качество мы выкидываем слова из песни и в итоге люди не владеют всей информацией.
Это большая ошибка!
Лучше просмотреть видео в качестве 480p вместо 720р, чем не посмотреть вовсе. Разве нет?

Сейчас ни у кого в городах нет на столько больших проблем с интернетом, что бы не посмотреть видео hd формата.
Ошибаетесь. Например на Украине до недавнего времени 3G вообще не был распостраненен, а на текущий момент один из ведущих операторов Киевстар обещает покрыть областные города только к 2016 году.

Да и вообще, разговор же не про необходимость таких технологий, как адаптивный стриминг. По-моему, кроме Вас никто не ставит под сомнение их необходимость. Разговор про то, что Вы голословно утверждаете, что «в нём собрано всё лучшее от Exoplayer, Vitamio и других». Можете сказать, что именно лучшее вы реализовали в своей либе кроме как кеши? Да и кеш работает кое-как. Глянул сэмпл из маркета. Там ведь не работает кеш при скроле в произвольную позицию! Т.е. для нормальной работы кеша нужно полностью просмотреть видео. Это сводит полезность практически к нулю.
Лучше просмотреть видео в качестве 480p вместо 720р, чем не посмотреть вовсе. Разве нет?

Нет! Сколько уже можно писать об этом! 720р — это как раз то минимальное качество, которое нужно использовать сейчас. А вообще нужно забыть об этих технологиях и развивать технологии передачи данных, кеширования и распространять контент в формате без потерь! Но этому мешает бюрократия и авторские права, патенты, блокировки сайтов. В общем вся негативная чушь, которую человек придумал якобы во благо.
Выход из этого болота один — новые технологии. Технологиями можно обойти любое авторское право, патенты или блокировки сайтов. На самом деле те люди, которые это придумали, просто не понимают, как устроена сеть и компьютеры.

То что кроме меня никто не ставит под сомнение, не говорит о том что все правы.

В моей либе кеш работает при скролах в любую позицию. Там есть память какие части файла были скачены и проверка на то, были ли скачены все части. Если были, то файл сохраняется.
Да что я вам объясняю!!! Идите и посмотрите как все работает сами! Там в коде не сложно разобраться. И вообще там кроме кеша уже другие более гибкие и удобные технологии.
Вот программа-то: play.google.com/store/apps/details?id=com.medialibrary.mycollection
Не думаю, что ваша библиотека актуальна более. Ну или вам надо её серьёзно переписывать под многопоточность.
Моя текущая разработка обеспечивает многопоточный доступ в сторону интернета и в сторону плеера, причём кардинально разделяя эти процессы. Алгоритм одинаково отлично справляется с 4к. фильмами размером 60-100гб. и мп3. Совместим со всеми известными плеерами. И много чего ещё… но он настолько сложный и быстрый, что врятли я буду его публиковать в ближайшее время. Можете проверить его в моём приложении.
Sign up to leave a comment.

Articles