Как стать автором
Обновить

Комментарии 23

владельцы Mac с M1 жаловались на быстрый износ новых SSD

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

Там ему присвоили номер FB9112835 и пообещали разобраться с таким расходом памяти.

В следующем обновлении GIF на маке будет deprecated?

Просто добавят платное включение поддержки GIF.

Или лучше: исправят, но на x86 версии, чтобы там тоже отжирало 100500ГБ памяти, а то непорядок

Уберут возможность посмотреть (в том числе и сторонними утилитами), сколько памяти отожрано: "Пользователям это не важно"

Какого хрена несчастная gif даже 360Мб занимает? Там ведь простейший формат, созданный как раз для того, чтобы в реальном времени раскодировать и показывать кадр, ничего не кэшируя, и это не жрало памяти даже на первых пентиумах. Разработчики вообще обленились и перестали считать память?
дело не в том, почему возникла ошибка, а то, что они не протестировали самый популярный юзкейс, что говорит о плохом тестировании.

Это память после декомпресии в 32bpp в редакторе. Как раз около:


400px240px4byte*730frames = 267MB


Ну и по мелочи там служебная информация в редакторе и т.д. до 360МБ

Страшно представить, сколько тогда должен занимать в видеоредакторе двухчасовой фильм в HD.

Видеоредакторы это очень специализированное ПО. Там используют всякие ухищрения чтобы понизить использование памяти. Но все равно, жрут память они очень и очень много.

Потому им и нужны быстрые диски, и raw кадры.

В видеоредакторах нет такой битности цвета. Производителям хватает 12 в основном. Потребителям — 8-10, причем сжатых inter-frame. Кроме того, никто не кеширует целиком фильм в память: видео — большие файлы, которым нужны линейные чтения. С ними и жесткие диски прекрасно справляются, в кеш ложатся только окрестности вашей позиции на таймлайне как правило. Проблемы возникают только при перемотке и использовании кодеков, не предназначенных для монтажа.
Занимает не gif, а программа в которой этот gif редактируют.
Да пофигу, делали криворугие индусы, которые просто не подумали, что будет gif больше 30 кадров. Раскодировать кадр gif занимает долю миллисекунды, это не h264/h265, который опирается на 100 предыдущих кадр (и то который научились быстро seek-ать в видеоредакторах).

А GIF разве не опирается на ВСЕ предыдущие кадры?

В исходном виде да. А когда развернули в редакторе по кадрам, увы уже нет.

Это ерунда! Может, в том редакторе и так, но в GIMP, например, изображение всегда формируется из текущего кадра и всех предшествовавших. Кадры, знаете ли, с прозрачностью бывают.

Там 730 кадров, 400x240px итого 70 080 000 пикселей. Если все открывалось в RGBA, умножить на 4, примерно под 280мб выходит. Конечно 360мб намного больше, но не так уж и сильно. «И так сойдет».
На некоторых (не будем показывать пальцем) развлекательных сайтах, не понимающих видеофайлы, столько порою занимают гифы даже в сжатом виде.
Да почему «утилизирует» если «использует», ну что за калькированный перевод, ну доколе?

Поздно

Ранее в феврале владельцы Mac с M1 жаловались на быстрый износ новых SSD (расход ресурса SSD со скоростью записи 180Гб/час).

На самом деле, две проблемы могут быть связаны.
Открытая в браузере вкладка с ГИФкой вызывает утечку памяти, и заставляет систему очень активно использовать «файл подкачки», что, в свою очередь, вызывает перерасход ресурса SSD.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.