Обычное явление при попытке кодека выравнять качество кадров
Ну тут по любому из-за того, что контент дичь, про это подумал только после того как уже написал коммент. Там же просто шум, видеокодеки такое не вывозят, это надо кодировать только в all-intra.
А вот по нагрузкам ничего по графикам не понял. Выглядит, что декодирование не нагружает проц
В том то и прикол, какой-то странный там hevc, декодируется в пару потоков, я такое первый раз вижу, не понятно чего там накостылили в кодере, там ещё и тайлы используются, картинка разделена на 5 колонок, последняя вообще почему-то в 2 раза меньше остальных.
А all-intra декодируется нормально с близкой к 100% загрузке проца. Все цифры в консоли, там написано 320 мбит - 11 fps (11,376 если точнее), 100 мбит - 17 fps (17,088). Загрузка проца 24 и 18% соответственно. all-intra - 39 fps (39,36). В итоге выходит зависимость примерно такая: в 4 раза больше битрейт = в 2 раза больше ресурсов проца для декодирования.
Для хоть какого-то ориентира, перекодировал 320 мбит в 100 мбит с помощью x265, чтобы посмотреть сколько будет fps при нормальной загрузке проца, было 55 fps, получается 39 fps 320 мбит all-intra против 55 fps 100 мбит, разница по меньше, но и декодировать более качественный hevc сложнее, да и all-intra декодировать вроде как по проще, при прочих равных.
Ещё несколько скринов из анализатора, если что, линия на графике сверху - это квантизатор.
ТайлыТип блоков, красные - intra, синие - inter, хорошо видно, что даже при статичной картинке много intra блоков из-за шума.
Хорошо видно, что даже при статичной картинке много intra блоков из-за шума. У 320 мбит видоса ещё и динамика, там вообще 80-90% блоков intra.
диск HDD
Использую SSD для таких тестов, да и вообще для любых.
Странные файлы, очень странные результаты, первый раз такое вижу, как будто какие-то проблемы с многопоточным декодированием inter кадров.
Даже с такими результатами видно, что 320 мбит больше жрёт, чуть больше нагрузка на проц при меньшей скорости декодирования.
Последние скрины с анализатора видео потоков, видно, что 320 мбит с ключевыми каждые 24, а не 48 и ключевые по размеру меньше не ключевых, кодер к такому явно не готовили (как я понял это с хаком битрейта). 100 мбит +- нормально, ну а all-intra нету в принципе, конечно не так как у меня на helio g90t, где ключевые каждые 1-3 кадра, но всё равно не all-intra.
Конечно, стандартный софтовый декодер ffmpeg именно он используется в большинстве плееров, когда не работает аппаратно.
Скидывайте, я посмотрю через час-полтора, ещё на телефоне посмотрю и завтра на работе. Если будет 24 фпс выдавать, то можно и плееры запускать и смотреть именно загрузку процессора.
К слову, про приложения на Айфонах, ffmpeg там есть хоть в каком-то виде? На Андроиде можно скачать с плей маркета готовый АПК, или же скачать там же АПК гуи и к нему скачать любой билд ffmpeg для Linux arm64.
Конечно, только декодирование. Могу сравнить любые битрейты и кодеки. Если бы всё было как вы пишите, то проблем с воспроизведением больших битрейтов не было бы, и в профилях кодека битрейт бы тоже не указывали, ну или указывали бы в обратную сторону к уменьшению.
Если в zip сжать то, что почти не сжато (видео, например), то распаковка не нагрузит проц вообще
То есть вы считаете, что в зависимости от квантизатора энтропия данных меняется так сильно, что нагрузка на проц может различаться в разы?
Я могу скинуть скриншоты декодирования hevc в ffmpeg, по крайней мере в avc/hevc и vp9/av1 при прочих равных, чем больше битрейт, тем больше загрузка проца, так на всех устройствах, на которых я смотрел видео.
Ну я считаю, что с логикой работы кодека как раз таки не расходится. Если говорить про avc/hevc, там сначала сжатие с потерями и в самом конце энтропийное сжатие, больше битрейт = больший поток проц должен распаковать = больше нагрузка на проц именно от энтропийного сжатия, тоже самое как если распаковывать zip, в 2 раза больше zip, значит распаковка минимум в 2 раза дольше.
почему 4:4:4 не может декодироваться аппаратно
По документации инвидии и АМД - может, по факту два плеера, которые я использую, почему то не могут, в чём проблема я хз, скорее всего в плеерах. Ну и всё равно в железе в первую очередь реализуют 4:2:0 8 бит, потом 10 бит, потом 4:2:2/4:4:4, ну и 12 бит. В телефонах в принципе не реализуют ничего кроме 4:2:0.
Ну при проигрывании у меня всегда больше битрейт = больше загрузка процессора, если конечно речь про один кодек. А hevc с ProRes по загрузке процессора даже не близко, там такая разница, что уже не важно какой там битрейт, ProRes всегда меньше грузит проц. Но я не занимаюсь монтажём, я просто иногда делаю какую-нибудь дичь и когда мне нужен видос для последующего редактирования, то использую AVC со сжатием без потерь и без all-intra. Когда нужно было немного помонтажить для знакомого, использовал avc all-intra с потерями.
Но у меня прекрасно работает HEVC 320Mbps с All-intra
Если тут речь про 4:2:0, то не удивительно, должно декодироваться аппаратно, а это быстрее чем ProRes. Если 4:2:2 или 4:4:4, то значит у вас не слабый проц, моего ryzen 5 5600h не хватает для этого, поэтому для просмотра или hevc 4:2:0 или любой avc.
Т.е. 4:4:4 будет примерно в два раза больше, чем 4:2:0, если мы говорим о YUV без дополнительного сжатия
Но мы говорим о сжатии, поэтому разница не в 2 раза, 4:4:4 может быть всего на 20-30% больше, зависит от контента.
Просто печалит хреновая аппаратная поддержка 4:2:2 и 4:4:4, для конечного видоса приходится использовать 4:2:0, даже если видос чисто для себя.
Какого такого размера? Как бы и AVC и HEVC сжимают лучше чем ProRes, отсюда и сложность декодирования. При равном качестве битрейт у AVC/HEVC будет меньше чем у ProRes, даже в режиме all-intra. А сам all-intra даёт только мгновенный переход на любой кадр.Обычно нельзя сделать одновременно и сильное сжатие и быстрое декодирование. ProRes про быстрое декодирование, а AVC/HEVC про сильное сжатие.
Чем выше битрейт, чем ниже субдискретизация (4:4:4 самая низкая), тем проще декодировать
Ни разу не так, или вы сравниваете скорость декодирования разных битрейтов разных кодеков? Например hevc 150 мбит и ProRes 350 мбит, так сравниваете что-ли? Сравните например ProRes 350 мбит и ProRes 700 мбит и увидите, что больший битрейт сложнее декодировать.
Если эксинос может снять 4к30 8бит с 1 Гбит битрейтом, то это уже местами без потерь, зависит от картинки. Реально мощный кодер у эксиносов, ему бы возможность снимать с постоянным качеством.
Возможно самсунг не верит в кодер снапа, у их эксиносов то свой кодер. И по производительности вы же сами говорите, что снап 160 мбит, тогда как эксинос до гигабита может - это уже говорит о том, что кодеры совсем разные и производительность разная. Так же фпс, битрейт и разрешение - это совсем разные параметры для кодера, а исходя из вашего комментария эксинос производительнее в плане разрешения и сильно производительнее в плане битрейта. Получается у эксиноса большой запас, так что снап вполне может перегреваться как пишет самсунг, а делать для него другое охлаждение они не стали. Да и вроде как последние самсы с эксиносом и в играх греются меньше чем со снапом.
У вас есть самс эксинос и снап? Можно же сравнить их энергопотребление при одинаковых настройках, как в стоке так и в мкпро.
А вы сами пробовали hevc 4:2:2? Я вот чисто из интереса недавно попробовал HEVC 4:4:4 и понял, что ну нахер, максимум AVC можно использовать в этом случае и то лучше без CABAC, даже он будет не хуже чем ProRes по качеству (но это субъективно, кому как короче). В HEVC всё что выше 4:2:0 - это extended профили, которые похоже аппаратно не поддерживаются никем, а значит вам нужен просто нереальный проц чтобы декодировать 4к HEVC с каким нибудь битрейтом 300-500 мбит. ProRes в плане декодирования заметно быстрее чем HEVC, потому-что он сильно проще и больше похож на апнутый JPEG, напрямую я не сравнивал, но разница ощущается как будто в разы. Это просто совсем разные кодеки для совсем разных вариантов использования. ProRes для монтажек, чтобы не нужно было делать кеш файлы для нормального предпросмотра, а просто напрямую декодировать и всё. Но плюс AVC и HEVC в том, что можешь использовать любой битрейт, тогда как в ProRes есть только пресеты (тут могу ошибаться).
Так что отсутствие HEVC 4:2:2 логично, зачем снимать то, что потом хрен посмотришь, ну и для этого производителям SOC нужно реализовывать кодеры, тут уже вендоры вообще ни при чём. У Apple свой SOC, вот они и реализовали что им нужно и что реально смотреть без аппаратной поддержки. В теории то можно реализовать любой all-intra кодек вместо ProRes, но это опять же упирается в большинство, которым оно и даром не нужно.
А самое смешное, что моя rtx 3060 спокойно аппаратно кодирует в HEVC 4:4:4, но при этом по каким-то неведомым мне причинам не может аппаратно декодировать то, что сама закодировала.
А в чём проблема гуглу в своём ютубе дать возможность смотреть любое разрешение видео? Я вышел на vanced только из-за разрешения видео, до этого с рутом менял разрешение в build.prop (а ещё раньше просто смотрел в браузере, там то все разрешения доступны), чтобы сток ютуб показывал все разрешения, а без рута только vanced. Ещё бы выбор кодека добавили в vanced вообще было бы отлично, на ПК я всегда включаю тот кодек в котором видос скорее всего будет лучшего качества, сравниваю по размерам файлов и теоретическому приросту качества от кодека. Сейчас с внедрением av1 выбор аж из трёх вариантов.
Я считаю, что задуматься должен гугл, а не какой-то там вендор, сделать в своих аппаратах эталон и обязать других делать всё по документации. И главное активно эту документацию развивать с каждой новой версией андройда. А сейчас получается гугл даёт какой-то андроид, делайте в нём что хотите, мы сами так же делаем, так что это норма.
В принципе получается как будто дан только какой-то стандарт приложений и ядро системы, а дальше вы уж там сами. В какой-то степени это доказывают разные линуксы на мобилках с возможностью запуска apk и та же гармония от хуавея.
Мне часто задают вопрос: какой аппарат больше подходит для приложения. Т.е. я имею возможность влиять на мысли пользователей в данном вопросе
Печально, когда оптимальный телефон для фото не может в видео и наоборот.
Прикольно, сам гугл помогает вендорам творить дичь, и при этом ещё пытается от этой же дичи избавиться (по крайней мере пытается плане обновления и поддержки устройств).
Вот блочил бы гугл за Reflections абсолютно всех одинаково, тогда думаю было бы меньше костылей со стороны вендоров и больше использования Android API. А так конечно вендорам насрать, делают всё, чтобы пипл хавал их приложения.
Логично же что вендорам нужно продать свой телефон и судя по тому что происходит, дешевле и проще рекламить свой софт (саму прошивку, камеру и некоторые другие проги), чем использовать более дорогие комплектующие (матрицы, оптику, экран, проц, оперативку, память, материалы корпуса) и качественную сборку, и рекламировать именно их. Стандартная фраза же: "ничего личного, только бизнес".
И главное, у Apple нет конкурентов (имею ввиду на той же ОС), поэтому всё открыто для разработчиков. Андроид же используется всеми и конкуренция дикая, делать всё по документации ради 10% пользователей никто не будет, я думаю даже если такой подход поднимет % этих пользователей до 30%, всё равно нет смысла.
Первый, смешно. Хотя глюкам винды я уже не удивляюсь, был случай с одним ноутом, у которого просто не открывался один раздел панели задач (ну он открывался, только через минут 5), ничего не помогало, хоть как винду переставляй, был такой глюк на виндах 10 после определенной версии, на более ранних не было.
У меня такая проблема со сжатием на нескольких ПК, не зависимо от того только что винду поставил или давно, а так же не зависимо от версии винды и железа ПК. Не было ещё такого, чтобы после сжатия системы она не умерла. Любые папки сжимает без проблем, а системную никак и всё тут, поэтому я и не понимаю как так я первый. Единственное я пока что не ставил систему сразу со включенным сжатием, сжимал только из под рабочей, может и так тоже не поставилась бы.
Доступ к командной строке и так есть из среды восстановления, вот только я не пойму как прописать там путь до винды и чтобы он запустил команду. По умолчанию там путь вида: x:\windows\system32, поэтому команду он выполняет в этом пути и просто пытается распаковать среду восстановления. Загрузочная флешка имеется, прямо хоть ставь винду на другой диск и из под неё распаковывай не рабочую.
Может кто-нибудь посоветовать как восстановить винду после сжатия? Отменить это сжатие как нибудь.
Сжал командой compact.exe /CompactOS:always, после перезагрузки показывает "подготовка автоматического восстановления" и не грузится. Такое произошло со всеми ПК на которых я сжал.
Странно что о таких приколах нигде не пишут, много видел статей про это сжатие и ни в одной не пишут, что винда может умереть после этого.
Не в максимальном качестве, а максимум 1080р и то зависит от видео, некоторые даже 1080р только в vp9 кодеке, соответственно с h264ify такое видео будет максимум в 720р.
Ютуб постепенно отказывается от h264, раньше в h264 было и 4к, потом осталось максимум 1440р, а сейчас вот 1080р и всё больше видео только 720р, а более высокие разрешения vp9 и av1.
Интересно, значит тем более делают какую-то дичь.
А вот «пока» скрыто или же навсегда и с последующим выпилом в будущих обновах (как вариант ещё не успели выпилить) — это неизвестно. Но в любом случае танцевать с реестром для настройки интерфейса — это край уже.
Ага, если на релизе будет всё так же, то можно сказать они панель управления из рабочего инструмента превратили в элемент интерфейса.
Странные изменения, возможно они это делают основываясь на телеметрии, ведь обычный пользователь (например тот, кто не может винду поставить) даже не знает, что панель задач можно как-то изменить.
Ну тут по любому из-за того, что контент дичь, про это подумал только после того как уже написал коммент. Там же просто шум, видеокодеки такое не вывозят, это надо кодировать только в all-intra.
В том то и прикол, какой-то странный там hevc, декодируется в пару потоков, я такое первый раз вижу, не понятно чего там накостылили в кодере, там ещё и тайлы используются, картинка разделена на 5 колонок, последняя вообще почему-то в 2 раза меньше остальных.
А all-intra декодируется нормально с близкой к 100% загрузке проца. Все цифры в консоли, там написано 320 мбит - 11 fps (11,376 если точнее), 100 мбит - 17 fps (17,088). Загрузка проца 24 и 18% соответственно. all-intra - 39 fps (39,36). В итоге выходит зависимость примерно такая: в 4 раза больше битрейт = в 2 раза больше ресурсов проца для декодирования.
Для хоть какого-то ориентира, перекодировал 320 мбит в 100 мбит с помощью x265, чтобы посмотреть сколько будет fps при нормальной загрузке проца, было 55 fps, получается 39 fps 320 мбит all-intra против 55 fps 100 мбит, разница по меньше, но и декодировать более качественный hevc сложнее, да и all-intra декодировать вроде как по проще, при прочих равных.
Ещё несколько скринов из анализатора, если что, линия на графике сверху - это квантизатор.
Хорошо видно, что даже при статичной картинке много intra блоков из-за шума. У 320 мбит видоса ещё и динамика, там вообще 80-90% блоков intra.
Использую SSD для таких тестов, да и вообще для любых.
Странные файлы, очень странные результаты, первый раз такое вижу, как будто какие-то проблемы с многопоточным декодированием inter кадров.
Даже с такими результатами видно, что 320 мбит больше жрёт, чуть больше нагрузка на проц при меньшей скорости декодирования.
Последние скрины с анализатора видео потоков, видно, что 320 мбит с ключевыми каждые 24, а не 48 и ключевые по размеру меньше не ключевых, кодер к такому явно не готовили (как я понял это с хаком битрейта). 100 мбит +- нормально, ну а all-intra нету в принципе, конечно не так как у меня на helio g90t, где ключевые каждые 1-3 кадра, но всё равно не all-intra.
Конечно, стандартный софтовый декодер ffmpeg именно он используется в большинстве плееров, когда не работает аппаратно.
Скидывайте, я посмотрю через час-полтора, ещё на телефоне посмотрю и завтра на работе. Если будет 24 фпс выдавать, то можно и плееры запускать и смотреть именно загрузку процессора.
К слову, про приложения на Айфонах, ffmpeg там есть хоть в каком-то виде? На Андроиде можно скачать с плей маркета готовый АПК, или же скачать там же АПК гуи и к нему скачать любой билд ffmpeg для Linux arm64.
Конечно, только декодирование. Могу сравнить любые битрейты и кодеки. Если бы всё было как вы пишите, то проблем с воспроизведением больших битрейтов не было бы, и в профилях кодека битрейт бы тоже не указывали, ну или указывали бы в обратную сторону к уменьшению.
То есть вы считаете, что в зависимости от квантизатора энтропия данных меняется так сильно, что нагрузка на проц может различаться в разы?
Я могу скинуть скриншоты декодирования hevc в ffmpeg, по крайней мере в avc/hevc и vp9/av1 при прочих равных, чем больше битрейт, тем больше загрузка проца, так на всех устройствах, на которых я смотрел видео.
Ну я считаю, что с логикой работы кодека как раз таки не расходится. Если говорить про avc/hevc, там сначала сжатие с потерями и в самом конце энтропийное сжатие, больше битрейт = больший поток проц должен распаковать = больше нагрузка на проц именно от энтропийного сжатия, тоже самое как если распаковывать zip, в 2 раза больше zip, значит распаковка минимум в 2 раза дольше.
По документации инвидии и АМД - может, по факту два плеера, которые я использую, почему то не могут, в чём проблема я хз, скорее всего в плеерах. Ну и всё равно в железе в первую очередь реализуют 4:2:0 8 бит, потом 10 бит, потом 4:2:2/4:4:4, ну и 12 бит. В телефонах в принципе не реализуют ничего кроме 4:2:0.
Ну при проигрывании у меня всегда больше битрейт = больше загрузка процессора, если конечно речь про один кодек. А hevc с ProRes по загрузке процессора даже не близко, там такая разница, что уже не важно какой там битрейт, ProRes всегда меньше грузит проц. Но я не занимаюсь монтажём, я просто иногда делаю какую-нибудь дичь и когда мне нужен видос для последующего редактирования, то использую AVC со сжатием без потерь и без all-intra. Когда нужно было немного помонтажить для знакомого, использовал avc all-intra с потерями.
Если тут речь про 4:2:0, то не удивительно, должно декодироваться аппаратно, а это быстрее чем ProRes. Если 4:2:2 или 4:4:4, то значит у вас не слабый проц, моего ryzen 5 5600h не хватает для этого, поэтому для просмотра или hevc 4:2:0 или любой avc.
Но мы говорим о сжатии, поэтому разница не в 2 раза, 4:4:4 может быть всего на 20-30% больше, зависит от контента.
Просто печалит хреновая аппаратная поддержка 4:2:2 и 4:4:4, для конечного видоса приходится использовать 4:2:0, даже если видос чисто для себя.
Какого такого размера? Как бы и AVC и HEVC сжимают лучше чем ProRes, отсюда и сложность декодирования. При равном качестве битрейт у AVC/HEVC будет меньше чем у ProRes, даже в режиме all-intra. А сам all-intra даёт только мгновенный переход на любой кадр.![]()
![]()
Обычно нельзя сделать одновременно и сильное сжатие и быстрое декодирование. ProRes про быстрое декодирование, а AVC/HEVC про сильное сжатие.
Ни разу не так, или вы сравниваете скорость декодирования разных битрейтов разных кодеков? Например hevc 150 мбит и ProRes 350 мбит, так сравниваете что-ли? Сравните например ProRes 350 мбит и ProRes 700 мбит и увидите, что больший битрейт сложнее декодировать.
Если эксинос может снять 4к30 8бит с 1 Гбит битрейтом, то это уже местами без потерь, зависит от картинки. Реально мощный кодер у эксиносов, ему бы возможность снимать с постоянным качеством.
Возможно самсунг не верит в кодер снапа, у их эксиносов то свой кодер. И по производительности вы же сами говорите, что снап 160 мбит, тогда как эксинос до гигабита может - это уже говорит о том, что кодеры совсем разные и производительность разная. Так же фпс, битрейт и разрешение - это совсем разные параметры для кодера, а исходя из вашего комментария эксинос производительнее в плане разрешения и сильно производительнее в плане битрейта. Получается у эксиноса большой запас, так что снап вполне может перегреваться как пишет самсунг, а делать для него другое охлаждение они не стали. Да и вроде как последние самсы с эксиносом и в играх греются меньше чем со снапом.
У вас есть самс эксинос и снап? Можно же сравнить их энергопотребление при одинаковых настройках, как в стоке так и в мкпро.
А вы сами пробовали hevc 4:2:2? Я вот чисто из интереса недавно попробовал HEVC 4:4:4 и понял, что ну нахер, максимум AVC можно использовать в этом случае и то лучше без CABAC, даже он будет не хуже чем ProRes по качеству (но это субъективно, кому как короче). В HEVC всё что выше 4:2:0 - это extended профили, которые похоже аппаратно не поддерживаются никем, а значит вам нужен просто нереальный проц чтобы декодировать 4к HEVC с каким нибудь битрейтом 300-500 мбит. ProRes в плане декодирования заметно быстрее чем HEVC, потому-что он сильно проще и больше похож на апнутый JPEG, напрямую я не сравнивал, но разница ощущается как будто в разы. Это просто совсем разные кодеки для совсем разных вариантов использования. ProRes для монтажек, чтобы не нужно было делать кеш файлы для нормального предпросмотра, а просто напрямую декодировать и всё. Но плюс AVC и HEVC в том, что можешь использовать любой битрейт, тогда как в ProRes есть только пресеты (тут могу ошибаться).
Так что отсутствие HEVC 4:2:2 логично, зачем снимать то, что потом хрен посмотришь, ну и для этого производителям SOC нужно реализовывать кодеры, тут уже вендоры вообще ни при чём. У Apple свой SOC, вот они и реализовали что им нужно и что реально смотреть без аппаратной поддержки. В теории то можно реализовать любой all-intra кодек вместо ProRes, но это опять же упирается в большинство, которым оно и даром не нужно.
А самое смешное, что моя rtx 3060 спокойно аппаратно кодирует в HEVC 4:4:4, но при этом по каким-то неведомым мне причинам не может аппаратно декодировать то, что сама закодировала.
А в чём проблема гуглу в своём ютубе дать возможность смотреть любое разрешение видео? Я вышел на vanced только из-за разрешения видео, до этого с рутом менял разрешение в build.prop (а ещё раньше просто смотрел в браузере, там то все разрешения доступны), чтобы сток ютуб показывал все разрешения, а без рута только vanced. Ещё бы выбор кодека добавили в vanced вообще было бы отлично, на ПК я всегда включаю тот кодек в котором видос скорее всего будет лучшего качества, сравниваю по размерам файлов и теоретическому приросту качества от кодека. Сейчас с внедрением av1 выбор аж из трёх вариантов.
Я считаю, что задуматься должен гугл, а не какой-то там вендор, сделать в своих аппаратах эталон и обязать других делать всё по документации. И главное активно эту документацию развивать с каждой новой версией андройда. А сейчас получается гугл даёт какой-то андроид, делайте в нём что хотите, мы сами так же делаем, так что это норма.
В принципе получается как будто дан только какой-то стандарт приложений и ядро системы, а дальше вы уж там сами. В какой-то степени это доказывают разные линуксы на мобилках с возможностью запуска apk и та же гармония от хуавея.
Печально, когда оптимальный телефон для фото не может в видео и наоборот.
Прикольно, сам гугл помогает вендорам творить дичь, и при этом ещё пытается от этой же дичи избавиться (по крайней мере пытается плане обновления и поддержки устройств).
Вот блочил бы гугл за Reflections абсолютно всех одинаково, тогда думаю было бы меньше костылей со стороны вендоров и больше использования Android API. А так конечно вендорам насрать, делают всё, чтобы пипл хавал их приложения.
Логично же что вендорам нужно продать свой телефон и судя по тому что происходит, дешевле и проще рекламить свой софт (саму прошивку, камеру и некоторые другие проги), чем использовать более дорогие комплектующие (матрицы, оптику, экран, проц, оперативку, память, материалы корпуса) и качественную сборку, и рекламировать именно их. Стандартная фраза же: "ничего личного, только бизнес".
И главное, у Apple нет конкурентов (имею ввиду на той же ОС), поэтому всё открыто для разработчиков. Андроид же используется всеми и конкуренция дикая, делать всё по документации ради 10% пользователей никто не будет, я думаю даже если такой подход поднимет % этих пользователей до 30%, всё равно нет смысла.
Первый, смешно. Хотя глюкам винды я уже не удивляюсь, был случай с одним ноутом, у которого просто не открывался один раздел панели задач (ну он открывался, только через минут 5), ничего не помогало, хоть как винду переставляй, был такой глюк на виндах 10 после определенной версии, на более ранних не было.
У меня такая проблема со сжатием на нескольких ПК, не зависимо от того только что винду поставил или давно, а так же не зависимо от версии винды и железа ПК. Не было ещё такого, чтобы после сжатия системы она не умерла. Любые папки сжимает без проблем, а системную никак и всё тут, поэтому я и не понимаю как так я первый. Единственное я пока что не ставил систему сразу со включенным сжатием, сжимал только из под рабочей, может и так тоже не поставилась бы.
Доступ к командной строке и так есть из среды восстановления, вот только я не пойму как прописать там путь до винды и чтобы он запустил команду. По умолчанию там путь вида: x:\windows\system32, поэтому команду он выполняет в этом пути и просто пытается распаковать среду восстановления. Загрузочная флешка имеется, прямо хоть ставь винду на другой диск и из под неё распаковывай не рабочую.
А что такое WinPE я не знаю.
У него, как и у всех, не написано что делать, если винда умерла после сжатия.
Как отменить это сжатие, если винда просто перестала грузиться после его включения?
Может кто-нибудь посоветовать как восстановить винду после сжатия? Отменить это сжатие как нибудь.
Сжал командой compact.exe /CompactOS:always, после перезагрузки показывает "подготовка автоматического восстановления" и не грузится. Такое произошло со всеми ПК на которых я сжал.
Странно что о таких приколах нигде не пишут, много видел статей про это сжатие и ни в одной не пишут, что винда может умереть после этого.
Не в максимальном качестве, а максимум 1080р и то зависит от видео, некоторые даже 1080р только в vp9 кодеке, соответственно с h264ify такое видео будет максимум в 720р.
Ютуб постепенно отказывается от h264, раньше в h264 было и 4к, потом осталось максимум 1440р, а сейчас вот 1080р и всё больше видео только 720р, а более высокие разрешения vp9 и av1.
А вот «пока» скрыто или же навсегда и с последующим выпилом в будущих обновах (как вариант ещё не успели выпилить) — это неизвестно. Но в любом случае танцевать с реестром для настройки интерфейса — это край уже.
Странные изменения, возможно они это делают основываясь на телеметрии, ведь обычный пользователь (например тот, кто не может винду поставить) даже не знает, что панель задач можно как-то изменить.