Pull to refresh

Comments 41

Антон, а как вообще распределяется нагрузка на пользователя? Вы никогда не задумывались, чтобы ввести, эммм, как бы это сказать… Изменение качества анимаций? Грубо говоря, как на ютубе?
Просто пишу это потому, что с моим 64 кб/с особо не посмотришь 8ми мегабайтных гифок. Вам не кажется, что данный метод был бы весьма удобен?
Мы все же не стримим большие видео-ролики на данный момент. Поэтому, пока что нет особого смысла внедрять «адаптивное качество анимации». Если тяжелая гифка весила 3-4Mb, то ее webm-версия обычно ужимается в 700-900Kb. Такие объемы не напрягают пользователей. По крайней мере, наш саппорт не жалуется)
> Проблему решили, но таким костылём, что до сих пор краснеем от стыда: к конвертируемой GIF добавляем дубликат последнего фрейма.

А почему бы не добавлять прозрачный фрейм?
Да дело не в том, какой фрейм добавлять — его всё равно не увидит никто, а исходную GIF никто не трогает, это только для конвертации в видео.
Стыдно потому, что могли бы правильно решить проблему, не прибегая к костылям — пропатчить libvpx, либо ffmpeg, смотря у кого проблема, но сил и времени пока не хватает на это, к сожалению.
Не думали вместе с роликом передвавать длительность задержки после последнего кадра. А при просмотре внутри приложения ставить паузу указаной длительности? Или это нетривиальная задача, учитывая нестандартность плеера?
Это еще более жёсткий костыль, чем описанный в статье.
А тем кто не умеет webM, например всяким ios, которые гененируют львиную долю мобильного трафика так и остался gif?

В посте же: «собрали libvpx под нужные платформы». Таким образом, ios научился webm.
В рядах мобильных разработчиков в это время царил хардкор: собрали libvpx под нужные платформы, написали обёртку-плеер на Си и вуаля.
Переход с GIF на WebM позволил сократить объемы раздаваемого трафика на 30% и снизить CDN-расходы примерно на $50 000 в месяц.
Сижу с калькулятором и ради забавы рассчитываю варианты сэкономить на CDN. А то в месяц вы тратите около $100 000, что как-то много. Не хватает параметра — сколько занимает места ваш контент и по сколько МБ/ГБ в день его прибавляется?
Траффик намного дороже обходится нежели место.
А я хотел бы посчитать вариант без использования CDN (под CDN, я полагаю, в статье понимается некий сторонний облачный сервис), на обычных железках. И поэтому в этом случае важно знать объемы контента.
Были мы некоторое время на обычных железках для задач по раздаче статики…
Если интересно, то в этом (scribd) выступлении более подробно, с какими проблемами столкнулись и к чему в итоге пришли. Правда, годичной давности, но в плане CDN сейчас ничего не поменялось у нас.

Вкратце — поддерживать столько обычных железок, разбросанных по всему миру, нам на данный момент не под силу своей командой, поэтому пользуемся услугами партнёра
UFO just landed and posted this here
А почему не сделать просто у GIF-ок кнопку play? Ну т.е. в ленте вместо полных GIF-ок идут только картинки с их первыми кадрами, если на какую-то из них нажать — подгрузится вся GIFка и пойдет анимация. Так сделано много где — тот-же 9gag например. По-моему гораздо проще чем кодировать в video.
Или есть статистика что все пользователи всегда все гифки пытаются посмотреть? :-)
Думали и на этот счет, но… Почему гифки стали так популярны сейчас? Видео дольше загружается, часто показывает рекламу, нужно каждый раз нажимать «play» и тд. Для целых больших фильмов это ок, но когда хочется посмотреть десяток-другой коротких роликов за раз — напрягает.
Понял. У нас просто в проекте был такой вариант, как я описал + когда загрузилась картинка первого кадра — идет ожидание и если пользователь не нажал next в течении некоторого короткого промежутка времени (секунды например) — значит ему интересно и тогда оригинальная GIF-ка автоматически начинала подгружаться.
Хотя… это тоже костыль, просто не программерский ) этакий лайфхак )
Похожее поведение на сайт версии, заставлять щелкать лишний раз пользователя на «play» очень не хочется, а ждать когда загрузится gif анимация на 3G достаточно долго. Для слабых устройств отказ от gif в пользу первого кадра это небольшой глоток производительности.
habrahabr.ru/post/87083/ lazy-load?
На мобильных девайсах например показало 50 анимаций, пользователь видит 5. Именно эти 5 анимаций будут загружены. Уменьшение трафика в 10 раз в случае, если пользователь не прокручивает дальше. Также можно сделать так, чтобы перввый кадр был статичен, а дальше при прокрутке загружались анимации.
Там, где нет поддержки webm и приходится отдавать тяжелые гифки (например, в некоторых мобильных браузерах), вариант со статичным первым кадром + дальнейшей подгрузкой GIF неплох. В мобильном приложении проще сделать фоновую подгрузку изображений/webm. Пользователь смотрит конкретный контент и в это время в фоне загружаются несколько «соседних» элементов. Да, он никогда может на них не перейти и мы прогоним этот трафик вхолостую. Но проведя тестирование, мы увидели, что избыточность при таком подходе совсем невысокая. Зато, мы получаем плавность перехода между элементами в «ленте», приложением становится намного приятнее пользоваться.
Если будет приложение, ну очень соверую поставить ручную настройку кэша в настройках. А то часто есть переключатель вкл-выкл, хотя кэш там либо маловат, либо большой слишком. Например у меня есть нексус 4, там 16 гигов памяти, могу для частоиспользуемого приложения кэш хоть гигабайт сделать (хотя тут хватит 100 мегов я так думаю), а есть еще LG Optimus One и там кэш может 1-10 мбайт, не более.
Кстати как вариант при подгрузке, думаю возможно как нибудь загружать одновременно 3 анимации, и например если они длятся 4 секунды, то они успеют в процессе загрузиться. Т.е. загружаем сразу пакетом несколько штук и если они на экране сразу проигрываем недозагруженные, или библиотеки не позволят?
UFO just landed and posted this here
Думаю, этому не быть :)
Спасибо, конечно, за ссылки, но насколько я помню стандарт, ничего не мешает там делать анимированные гифы. В 87-м стандарте только не было величин задержек и расширения для количества повторений (насколько я помню, это вообще не часть стандарта, а расширение браузера Netscape).
Ну из табуретки тоже ничего не мешает сделать колесницу, если прикрутить колёса и лошадь :)
Да-да, ок. Но только GIF87a тоже умеет анимацию.
$100k в месяц раздачи трафика с лихвой окупается рекламой? 4 млн пользователей, даже при CPM 10 (что довольно много) получается всего 4000*10=$40k.
Конечно нескромный, но всем же интересно. Откуда там в картинках может быть большой eCPM, это и есть самое интересное.
Мы упорные. А если серьезно, это тема для отдельной статьи.
UFO just landed and posted this here
Терминатор, тащем-то.
Стыдно классику не знать…
Последний киногерой… очень стыдно не знать классику…
Проблему решили, но таким костылём, что до сих пор краснеем от стыда: к конвертируемой GIF добавляем дубликат последнего фрейма.

Забавное совпадение, но проблема с задержкой на последнем кадре в GIF была, кажется и в ACDSee. Т.е., когда я просматривал в этом вьювере свои гифки (по малолетке увлекался анимацией в аватарках), то задержка в последнем кадре не воспринималась, и кадр проскакивал мгновенно. Давно это было, надеюсь, не ошибся, и это была ACDSee, а не браузер. Может, у вашего конвертера из того же места уши растут.
Отличная идея у вашей программы, пошёл ставить.

Думаю, после этого поста количество русскоязычных пользователей добавится.
Воспользовавшись моментом, задам вопрос, — кто-то может подсказать решение для генерации GIF на сервере из кадров? Желательно JS/Ruby/PHP. Пардон за оффтоп.
Sign up to leave a comment.