Кодек не поддерживается h 264 avc андроид
Обновлено: 06.07.2024
Что такое Кодек?
Кодеком называют метод кодирования и расшифровки данных в сжатом формате. При помощи этого метода устройство без потерь сжимает и сохраняет видеофайл для его воспроизведения на дисплее. Сжатый таким образом компонент визуально и на слух не теряет качество, поэтому таким образом на телефоне с относительно небольших объемом оперативной памяти можно запускать ролики высокого качества
Что такое Контейнер «формат файла»?
Контейнером называют “упаковку” файла, его формат. Он отвечает за сжатие файла в необходимом расширении, транспортировку и открытие элемента, его “считывание” определенными программами. Также обеспечивают синхронное воспроизведение аудио и видео в одном документе. Например, в файле sing.mp3 часть MP3 является контейнером. Именно по нему плеер распознает обїект. Кстати, контейнеры можно менять при помощи специальный программ для перезаписи.
Почему не поддерживается видеокодак на Андроиде Самсунг
Что делать если видеокодак занят другими приложениями
В таком случае необходимо закрыть все программы, использующие видеоролики, звуковые или визуальные эффекты. Необходимо открыть диспетчер задач и деактивировать все эти приложения, даже работающие в фоновом режиме. После окончания процесса попробуйте снова запустить плеер и открыть необходимый элемент.
Аналоги для воспроизведения аудио и видеофайлов
Если приведенные выше способы не подействовали, попробуйте для просмотра видео одну из следующих программ.
Программа VLC часто используется для ПК, как один из самых универсальных и удобных медиаплееров. Имеется также бесплатное приложение для Android, включающее в себя все необходимые кодеки и поддерживающее все известные видеоформаты. При помощи этого приложения можно вопроизводить фильмы с многодорожечным звуком и субтитрами.
MX Player
Еще один легкий и удобный сервис для воспроизведения контента на Андроиде. Воспроизводит большую часть известных видеоформатов и поддерживает субтитры. Имеется платная и бесплатная версия, последняя имеет небольшое количество рекламных блоков. Платная версия без рекламы можно купить за 5,99 доллара.
Для видеозвонков в Badoo мы используем стандарт WebRTC и кодек H.264. Если верить документации, этот кодек должен без проблем работать на любых устройствах Android начиная с Android 5.0. Но на практике всё оказалось не совсем так. В этой статье я расскажу про особенности реализации аппаратного кодирования для кодека H.264 в WebRTC и о том, как заставить его работать на большем количестве устройств.
Почему именно H.264?
При соединении по WebRTC все устройства, участвующие в сеансе, передают различные параметры связи, в том числе видео- и аудиокодеки. Если устройства поддерживают несколько кодеков (например, VP8 и H.264), приоритетные для платформы кодеки указываются первыми. Эти данные используются на этапе согласования в WebRTC, после которого остаются только кодеки, поддерживаемые всеми устройствами. Пример таких данных с расшифровкой можно увидеть в этом документе.
В случае с видеозвонками при отсутствии на одном из устройств поддержки кодека H.264 оба устройства могут перейти, например, на кодек VP8, который не зависит от аппаратной реализации на устройстве. Но наше приложение доступно на самых разных гаджетах, в том числе на смартфонах предыдущих поколений. Поэтому для видеосвязи мы хотели по возможности использовать аппаратное кодирование: оно снижает нагрузку на процессор и не так сильно ест батарею, что критично для устаревших гаджетов. Поддержка аппаратного кодирования H.264 реализована на большом количестве устройств, в отличие от того же VP8.
Поддержка H.264 на Android
Если верить описанию поддержки форматов мультимедиа, декодирование H.264 Baseline Profile должно работать на всех Android-устройствах, а кодирование — начиная с Android 3.0. В Badoo мы поддерживаем устройства начиная с Android 5.0, так что у нас не должно было возникнуть проблем. Но всё оказалось не так просто: даже в гаджетах с пятой версией мы обнаружили большое количество особенностей.
С чем это может быть связано?
Нас в этом наборе тестов интересуют мультимедиа-тесты, а конкретнее — тесты на кодирование и декодирование видео. Я решил остановиться на тестах EncodeDecodeTest, MediaCodecTest, DecoderTest и EncoderTest, так как они присутствуют на всех версиях Android начиная с 4.3. График количества строк кода в этих тестах выглядит так:
До версии 4.3 большинства из этих тестов просто не существовало, и значительный их прирост пришёлся на версии 5 и 7. Поэтому можно говорить о том, что до версии Android 4.3 Google никак не проверяла соответствие устройств своей спецификации по кодированию и декодированию видео, а в версии 5.0 значительно улучшила эту проверку.
Казалось бы, это указывает на то, что начиная с версии 5.0 с кодированием всё должно быть в порядке. Но, учитывая предыдущий мой опыт работы с декодированием потокового видео на Android, я был уверен, что это не так. Достаточно было посмотреть на количество топиков про кодирование в Google-группе discuss-webrtc.
Искать подводные камни нам помогали исходные файлы WebRTC, которые находятся в свободном доступе. Рассмотрим их подробнее.
Поддержка H.264 в WebRTC
Тут есть метод с говорящим названием isHardwareSupportedInCurrentSdkH264:
Как мы видим, поддержка аппаратного кодирования на Android реализована только для чипсетов Qualcomm и Exynos. Почему же в стандартной реализации WebRTC нет поддержки других чипсетов? Вероятнее всего, это связано с особенностями реализации аппаратных кодеков производителей. И выявить эти особенности часто можно только на продакшене, поскольку найти те или иные устройства не всегда представляется возможным.
Все описания кодеков на устройстве хранятся в файле media_codecs.xml. Вот, например, этот файл для Pixel XL и для HUAWEI P8 lite. При получении списка кодеков с помощью метода getCodecInfos() объекта MediaCodecList этот файл парсится — и возвращаются кодеки, хранящиеся в нём. Эта операция и правильность заполнения этого файла производителем покрываются в CTS тестом MediaCodecListTest, который также увеличился со 160 строк кода в Android 4.3 до 740 строк в Android 10.
В Badoo мы поменяли код метода isHardwareSupportedInCurrentSdkH264, отказавшись от «белого» списка кодеков и заменив его «чёрным» списком префиксов программных кодеков, которые перечислены в WebRTC:
Но нельзя просто так взять и реализовать поддержку всех кодеков, не обращая внимания на особенности производителей. Из названий топиков, посвящённых аппаратному кодированию на Android в группе discuss-webrtc, можно понять, что в этом случае у нас точно возникнут ошибки. В основном они появляются на этапе конфигурации кодека.
Параметры конфигурации кодека
Инициализация кодека для кодирования выглядит так:
В некоторых из этих параметров легко допустить ошибку, что вызовет исключение при конфигурации кодека и нарушит работу приложения. Также при работе с кодеком может понадобиться регулировать его битрейт в зависимости от различных факторов, так как сам кодек делает это неправильно. За это в WebRTC отвечает класс BaseBitrateAdjuster, у которого есть два наследника:
-
— регулирует битрейт в зависимости от объёма данных, — регулирует битрейт в зависимости от частоты кадров.
Разрешение потока
После получения для кодека объекта MediaCodecInfo можно изучить кодек подробнее, получив его возможности в классе CodecCapabilities. Из них можно узнать, поддерживает ли кодек выбранные разрешение и частоту кадров. Если он поддерживает эти параметры, их можно устанавливать безопасно.
Однако иногда это правило не работает. Мы столкнулись с тем, что кодеки с префиксом “OMX.MARVELL.” кодировали неправильно, показывая зелёные полосы по краям экрана, если разрешение потока отличалось от 4:3. При этом сам кодек утверждал, что выбранные разрешение и частота кадров поддерживаются.
Режим битрейта
Стандартный режим для всех видеокодеков — постоянный битрейт. Однако однажды нам пришлось использовать переменный битрейт:
Произошло это на устройстве Lenovo A1000 с чипсетом компании Spreadtrum (теперь Unisoc), начинающимся с префикса “OMX.sprd.”. Поиск в Интернете привёл нас к посту шестилетней давности о Firefox OS, описывающему эту проблему и способ её решения.
Цветовой формат
При использовании кодека в режиме байт-буферов необходимо выбрать правильный формат. Обычно это делается с помощью функции следующего вида:
Грубо говоря, всегда выбирается первый из поддерживаемых цветовых форматов.
Однако в случае с кодеками HUAWEI, начинающимися с префиксов «OMX.IMG.TOPAZ.», «OMX.hisi.» и «OMX.k3.», это не работало, и после долгих поисков мы нашли решение: вне зависимости от того, какой формат возвращают эти кодеки, необходимо использовать формат COLOR_FormatYUV420SemiPlanar. Разобраться в этом нам помог тред на одном китайском форуме.
Регулировка битрейта
Стандартный код WebRTC содержит следующее:
Как видно из этого кода, для всех чипсетов, кроме Exynos, регулировка битрейта выключена. Но это относится только к Qualcomm, так как в стандартном коде поддерживаются только Exynos и Qualcomm. Поэкспериментировав с различными значениями этой настройки, а также поискав в Интернете, мы выяснили, что для кодеков с префиксами «OMX.MTK.» её тоже нужно включить. Также необходимо сделать это для кодеков HUAWEI, начинающихся с префикса «OMX.IMG.TOPAZ.», «OMX.hisi.» или «OMX.k3.». Это связано с тем, что эти кодеки не используют временные метки кадров для регулировки битрейта, считая, что все кадры приходят с одинаковой частотой, установленной при конфигурации кодека.
В завершение приведу список кодеков, которые мы получили для устройств на Android 5.0 и 5.1. Они были нам интересны в первую очередь потому, что на более новых версиях Android ситуация улучшается и нестандартных кодеков становится всё меньше.
Это видно на графике ниже. Шкала логарифмическая, чтобы лучше показать редкие случаи.
Как мы видим, у большинства устройств были чипсеты Spreadtrum, MediaTek, HUAWEI и MARVELL — поэтому наши изменения помогли включить аппаратное кодирование на этих гаджетах.
Результат
Хотя мы и предполагали, что на некоторых устройствах при работе с H.264 будут возникать проблемы, Android опять смог нас удивить. Как мы видим из статистики пользователей Badoo, на руках у пользователей ещё достаточно много устройств 2014–2016 года выпуска, которые они не хотят или не могут обновлять. И хотя ситуация с выходом обновлений Android для новых устройств уже гораздо лучше, чем несколько лет назад, доля гаджетов предыдущего поколения сокращается довольно медленно и поддерживать их придётся ещё достаточно долго.
Сейчас WebRTC активно развивается Google из-за его использования в проекте Stadia (вот видео с подробностями на эту тему), поэтому он будет становиться всё лучше и лучше и, скорее всего, станет стандартом для реализации видеосвязи. Надеюсь, что эта статья поможет вам понять особенности работы с H.264 в WebRTC и использовать это в своих проектах.
H.264 — стандарт сжатия видео. И он вездесущ, его используют для сжатия видео в интернете, на Blu-ray, телефонах, камерах наблюдения, дронах, везде. Все сейчас используют H.264.
Нельзя не отметить технологичность H.264. Он появился в результате 30-ти с лишним лет работы с одной единственной целью: уменьшение необходимой пропускной способности канала для передачи качественного видео.
С технической точки зрения это очень интересно. В статье будут поверхностно описаны подробности работы некоторых механизмов сжатия, я постараюсь не наскучить с деталями. К тому же, стоит отметить, что большинство изложенных ниже технологий справедливы для сжатия видео в целом, а не только для H.264.
Видео в несжатом виде это последовательность двумерных массивов, содержащих информацию о пикселях каждого кадра. Таким образом это трёхмерный (2 пространственных измерения и 1 временной) массив байтов. Каждый пиксель кодируется тремя байтами — один для каждого из трёх основных цветов (красный, зелёный и синий).
1080p @ 60 Hz = 1920x1080x60x3 =>
370 Мб/с данных.
Этим практически невозможно было бы пользоваться. Blu-ray диск на 50Гб мог бы вмещать всего около 2 мин. видео. С копированием так же будет не легко. Даже у SSD возникнут проблемы с записью из памяти на диск.
Поэтому да, сжатие необходимо.
Обязательно отвечу на этот вопрос. Но сперва я покажу кое-что. Взгляните на главную страницу Apple:
Я сохранил изображение и приведу в пример 2 файла:
Нет, с размерами всё в порядке. Видео H.264 с 300 кадрами весит 175 Кб. Один единственный кадр из видео в PNG — 1015 Кб.
Кажется, мы храним в 300 раз больше данных в видео, но получаем файл весом в 5 раз меньше. Получается H.264 эффективнее PNG в 1500 раз.
А приёмов очень много! H.264 использует все приёмы о которых вы догадываетесь (и уйму о которых нет). Давайте пройдёмся по основным.
Представьте, что вы готовите машину к гонкам и вам нужно её ускорить. Что вы сделаете в первую очередь? Вы избавитесь от лишнего веса. Допустим, машина весит одну тонну. Вы начинаете выбрасывать ненужные детали… Заднее кресло? Пфф… выбрасываем. Сабвуфер? Обойдёмся и без музыки. Кондиционер? Не нужен. Коробка передач? В мусо… стойте, она еще пригодится.
Таким образом вы избавитесь от всего, кроме необходимого.
Этот метод отбрасывания ненужных участков называется сжатием данных с потерями. H.264 кодирует с потерями, отбрасывая менее значимые части и сохраняя при этом важные.
PNG кодирует без потерь. Это означает, что вся информация сохраняется, пиксель в пиксель, и поэтому оригинал изображения можно воссоздать из файла, закодированного в PNG.
Важные части? Как алгоритм может определять их важность в кадре?
Существует несколько очевидных способов урезания изображения. Возможно, верхняя правая четверть картинки бесполезна, тогда можно удалить этот угол и мы уместимся в ¾ исходного веса. Теперь машина весит 750 кг. Либо можно вырезать кромку определенной ширины по всему периметру, важная информацию всегда ведь по середине. Да, возможно, но H.264 всего этого не делает.
H.264, как и все алгоритмы сжатия с потерями, уменьшает детализацию. Ниже, сравнение изображений до и после избавления от деталей.
Видите как на сжатом изображении исчезли отверстия в решётке динамика у MacBook Pro? Если не приближать, то можно и не заметить. Изображение справа весит всего 7% от исходного и это при том, что сжатия в традиционном смысле не было. Представьте машину весом всего лишь 70 кг!
Для начала немного математики.
Мы подходим к самому интересному! Если вы посещали теорию информатики, то возможно вспомните про понятие информационной энтропии. Информационная энтропия это количество единиц для представления некоторых данных. Заметьте, что это вовсе не размер самих данных. Это минимальное количество единиц, которое нужно использовать, чтобы представить все элементы данных.
Например, если в виде данных взять один бросок монеты, то энтропия получится 1 единица. Если же бросков монетки 2, то понадобятся 2 единицы.
Предположим, что монета весьма странная — её подбросили 10 раз и каждый раз выпадал орёл. Как бы вы кому нибудь рассказали об этом? Вряд ли как-то вроде ОООООООООО, вы бы сказали «10 бросков, все орлы» — бум! Вы только что сжали информацию! Легко. Я вас спас от многочасовой утомительной лекции. Это, конечно же, огромное упрощение, но вы преобразовали данные в некое короткое представление с той же информативностью. То есть уменьшили избыточность. Информационная энтропия данных не пострадала — вы только преобразовали представление. Такой способ называется энтропийным кодированием, который подходит для кодирования любого вида данных.
Теперь, когда мы разобрались с информационной энтропией, перейдем к преобразованию самих данных. Можно представить данные в фундаментальных системах. Например, если использовать двоичный код, будут 0 и 1. Если же использовать шестнадцатеричную систему, то алфавит будет состоять из 16 символов. Между вышеупомянутыми системами существует взаимно однозначная связь, поэтому можно легко преобразовывать одно в другое. Пока всё понятно? Идём дальше.
А представьте, что можно представить данные, которые изменяются в пространстве или времени, в совершенно иной системе координат. Например, яркость изображения, а вместо системы координат с x и y, возьмём частотную систему. Таким образом, на осях будут частоты freqX и freqY, такое представление называется частотным пространством[Frequency domain representation]. И существует теорема, что любые данные можно без потерь представить в такой системе при достаточно высоких freqX и freqY.
freqX и freqY всего лишь другой базис в системе координат. Так же как можно перейти из двоичной системы в шестнадцатеричную, можно перейти из X-Y в freqX и freqY. Ниже изображён переход из одной системы в другую.
Мелкая решётка MacBook Pro содержит высокочастотную информацию и находится в области с высокими частотами. Таким образом мелкие детали имеют высокую частоту, а плавные изменения, такие как цвет и яркость низкую. Всё, что между, остаётся между.
В таком представлении, низкочастотные детали находятся ближе к центру изображения, а высокочастотные в углах.
Потому что теперь, можно взять изображение, представленное в частотных интервалах, и обрезать углы, иными словами применить маску, понизив тем самым детальность. А если преобразовать изображение обратно в привычное, можно будет заметить, что оно осталось похожим на исходное, но с меньшей детализацией. В результате такой манипуляции, мы сэкономим место. Путём выбора нужной маски, можно контролировать детализацию изображения.
Ниже знакомый нам ноутбук, но теперь уже с, применёнными к ней, круговыми масками.
В процентах указана информационная энтропия относительно исходного изображения. Если не приближать, то разница не заметна и при 2%! — машина теперь весит 20 кг!
Именно таким образом нужно избавляться от веса. Такой процесс сжатия с потерями называется Квантованием.
Человеческий глаз не особо хорошо различает близкие оттенки цвета. Можно легко распознавать наименьшие различия в яркости, но не цвета. Поэтому должен существовать способ избавления от лишней информации о цвете и сэкономить ещё больше места.
В телевизорах, цвета RGB преобразуются в YCbCr, где Y это компонента яркости (по сути яркость черно-белого изображения), а Cb и Cr компоненты цвета. RGB и YCbCr эквиваленты в плане информационной энтропии.
Во времена чёрно-белых телевизоров, была только компонента Y. А с началом появления цветных телевизоров у инженеров встала задача о передаче цветного RGB изображения вместе с чёрно-белым. Поэтому вместо двух каналов для передачи, было решено кодировать цвет в компоненты Cb и Cr и передавать их вместе с Y, а цветные телевизоры уже сами будут преобразовывать компоненты цвета и яркости в привычный им RGB.
Но вот в чём хитрость: компонента яркости кодируется в полном разрешении, а компоненты цвета лишь в четверть. И этим можно пренебречь, т.к. глаз/мозг плохо различает оттенки. Таким образом можно уменьшить размер изображения в половину и с минимальными отличиями. В 2 раза! Машина будет весить 10 кг!
Данная технология кодирования изображения со снижением цветового разрешения называется цветовой субдискретизацией. Она используется повсеместно уже давно и относится не только к H.264.
Это самые значительные технологии в уменьшении размера при сжатии с потерями. Нам удалось избавиться от большинства детализации и сократить информацию о цвете в 2 раза.
Да. Обрезание картинки это лишь первый шаг. До этого момента мы разбирали отдельно взятый кадр. Пришло время взглянуть на сжатии во времени, где нам предстоит работать с группой кадров.
H.264 стандарт, который позволяет компенсировать движения.
Представьте, что вы смотрите теннисный матч. Камера зафиксирована и снимает с определенного угла и единственное что движется это мячик. Как бы вы закодировали это? Вы бы сделали что и обычно, да? Трёхмерный массив пикселей, две координаты в пространстве и один кадр за раз, так?
Но зачем? Большая часть изображения одинакова. Поле, сетка, зрители не меняются, единственное что движется это мячик. Что если определить единственное изображение фона и одно изображение мячика, движущегося по нему. Не сэкономило бы это значительно места? Вы видите к чему я клоню, не так ли? Компенсация движения?
И это именно то, что H.264 делает. H.264 разбивает изображение на макроблоки, обычно 16х16, которые используются для расчёта движения. Один кадр остаётся статичным, обычно его называют I-кадр [Intra frame], и содержит всё. Последующие кадры могут быть либо P-кадры [predicted], либо B-кадры [bi-directionally predicted]. В P-кадрах вектор движения кодируется для каждого макроблока на основе предыдущих кадров, таким образом декодер должен использовать предыдущие кадры, взяв последний из I-кадров видео и постепенно добавляя изменения последующих кадров пока не дойдёт до текущего.
Ещё интереснее обстоят дела с B-кадрами, в которых расчёт производится в обоих направлениях, на основании кадров идущих до и после них. Теперь вы понимаете почему видео в начале статьи весит так мало, это всего лишь 3 I-кадра, в которых мечутся макроблоки.
При такой технологии кодируется только различия векторов движения, тем самым обеспечивая высокую степень сжатия любого видео с перемещениями.
Мы рассмотрели статическое и временное сжатия. С помощью квантования мы во много раз уменьшили размер данных, затем с помощью цветовой субдискретизации ещё вдвое сократили полученное, а теперь еще компенсацией движения добились хранения лишь 3х кадров из 300, которые были первоначально в рассматриваемом видео.
Теперь мы подведём черту, используя традиционное энтропийное кодирование без потерь. Почему нет?
После этапов сжатия с потерями, I-кадры содержат избыточные данные. В векторах движения каждого из макроблоков в P-кадрах и B-кадрах много одинаковой информации, так как зачастую они двигаются идентично, как это можно наблюдать в начальном видео.
От такой избыточности можно избавиться энтропийным кодированием. И можно не переживать за сами данные, так как это стандартная технология сжатия без потерь, а значит всё можно восстановить.
Вот теперь всё! В основе H.264 лежат вышеупомянутые технологии. В этом и заключаются приёмы стандарта.
Отлично! Но меня разбирает любопытство узнать, сколько же весит теперь наша машина.
Исходное видео было снято в нестандартном разрешении 1232x1154. Если посчитать, то получится:
5 сек. @ 60 fps = 1232x1154x60x3x5 => 1.2 Гб
Сжатое видео => 175 Кб
Если соотнести результат с оговорённой массой машины в одну тонну, то получится вес равный 0.14 кг. 140 граммов!
Да, это магия!
Конечно же я в очень упрощённом виде изложил результат десятилетних исследований в этой сфере. Если захотите узнать больше, то страница в википедии вполне познавательна.
Привет. Скачал фильм HEVC, и не могу посмотреть на смартфоне (прости меня Дэвид Линч). Фильм лагает, и смотреть невозможно. Есть ли какой-то способ посмотреть его?
На данный момент хорошего интернета у меня нет. Устройство сравнительно мощное, snapdragon 821. Я нарыл в интернете, что аппаратной поддержки HEVC у смартфона нет, а программная че-то не справляется. На помощь, народ!
Комментарий удален по просьбе пользователя
Ага. Кто только его до слез не довёл. То Файги, то смартфоны
Максимум что смотрел на телефоне это 720p, оптимальный вариант если есть место. А вообще 480p за глаза, аватара на телефонах никто не смотрит -_-
480р даже на смартфоне мыло. 1080р оптимально.
Смотря какой смартфон. Если смартфон старый с разрешением 1280х720, то норм. У меня вообще в фуллхд видосы на ютубе тормозят. Там какой-то кодек неоптимизированный, потому что через MX Player все в фуллхд проигрывается нормально.
Ну блин, сейчас даже бюджетки с 1080р экраном.
То же самое хотел написать.
Забавно читать про 720р. Это же вообще не Ретина :)
Highscreen PowerFive Pro. Брал за 16к в 16-м году. И менять до внедрения 5G в своем городе не собираюсь, так как более чем устраивает. Там уже 5G смартфон какой-нибудь возьму.
Ну, кому-то и кнопочных звонилок достаточно)
Ну а что тут нет такого нет, без чего никак нельзя? Безлимитный 4G на второй симке работает без перерыва, по беспроводным наушникам слушаю подкасты из интернета, онлайн-радио, свою музыку, смотрю ютуб. При самом активном использовании мне его до сих пор хватает минимум на двое суток. А при неактивном (чисто разговаривал по телефону и все, но 4G не вырубал) рекорд был 12 дней.
Ты же понимаешь, что твой случай использования - всего лишь твой?
Я понимаю, что мой случай использования идентичен еще миллионам случаев использования во всем мире. А вы продолжайте переплачивать за кучу не нужных фич, излишних мощностей, дохлый аккумулятор и понтов во имя потреблятельского общества и дальнейшего обогащения богачей.
Если не пользуешься старым говнофоном - то ты понтовщик, ясно понятно.
Утрируете. Есть малый процент пользователей, которым реально нужен мощный крутой телефон. К примеру жирный издавна снимает на айфоны 4к контент и картинка весьма неплохая была. Некоторым реально нужны все эти 5 камер, но это крайне небольшое количество людей. Кто-то графодрочит на смартфонные дрочильни. Ну это заболевание мне не понять. Наверное есть небольшой процент проф. фотографов, использующих смартфоны вместо зеркалок. Но, в большинстве случаев, по моему мнению, это голимые понты. Когда смартфоны по 100к дарят людям, которые не в силах использовать даже 20% функций такого аппарата. Когда себе покупают исключительно как имиджевое устройство. Когда берут кредит на это. Когда покупают подделку под такое устройство или вообще даже коробку от него))) ред.
Ты мыслишь категориями чёрное/белое.
Ясно-понятно. Я похоже с ботом общаюсь, который отвечает короткими односложными универсальными фразами, не приводит ни одного аргумента и ответом на развернутую аргументацию, уже через пару секунд после ее появления, кидает упомянутую односложную универсальную банальную ничего не значащую фразу. А по сути то сказать видимо и нечего.
Мне лень писать тебе аргументы, чел. Я много общался с такими, как ты, и мне просто надоело.
Не проще ли в таком случае просто не отвечать, коль не склонен к дискуссии?))
Да просто брать видео под разрешение экрана и все.
Аватар, может, и не нужен, но я хочу знать, что даже если я буду вглядываться — всё будет чётким.
Читайте также: