All streams
Search
Write a publication
Pull to refresh
18
0
Виктор Ефимов @tp7

Пользователь

Send message
Дык распаковывайте в 16, а то и в 32.
Есть сумасшедшее количество алгоритмов, которым float в принципе не сдался, и которые гораздо быстрее провести в целочисленных вычислениях. Даже если в теории точность может пострадать, очень часто никого не волнуют +-0.5 отклонения.
Указанное требование заставляет пересматривать способы хранения данных, например, хранить цветное изображение в виде набора отдельных цветовых плоскостей, а не в единой плоскости с чередованием цветовых каналов для каждой точки (как в BGR-24).

Проблема BGR24 не в том, что он BGR, а в том, что он 24. Это заставляет писать сумасшедшие костыли, которые чаще всего сводятся к конвертации этого дела в BGR32 и обратно. И хорошо, если у вас доступнен pshufb из SSSE3, а если нет?..

Если читатели сочтут эту тему интересной, то я готов написать несколько статей, которые будут описывать особенности оптимизации на конкретных примерах.

Да, было бы интересно почитать.
6. Блю-рей. Вывод: возможно, сказана правда, никогда ими не пользовался: кино и цифровой контент наше все.

Имеется ввиду BD-J. Это лишь небольшая часть стандарта, так что то, что «Blu-Ray стандарт построен вокруг Java» — очень сильное преувеличение. Но то, что Java там используется — правда.
Вопрос: почему при всей крутости Java, огромное количество (большинство?) приложений, написанных на ней, выглядят так отвратительно под Windows? Нет, Intel, правда?

А вообще статья ну уж слишком холиварная.
Проголосовал именно так (ну разве что Python в используемых).
На работе пишу в основном на C# под веб.
В свободное время занимаюсь мультимедией, а там в принципе исключительно С(++).
Что именно? Что плох на практике? А где библиотеки? Или вы всё будете с нуля реализовывать? А где пользователи, огромное сообщество на SO, кучи гайдов? Или с каждой проблемой вы будете сами разбираться? Всё может быть сколько угодно красиво в теории, но использовать подобое «в продакшине» — нет, извините.

Языку больше 10 лет, а факт того, что один из его главных идеологов закоммитил 5 тысяч строк, использующих D, в код фэйсбука, преподносится как нечто невероятное. По-моему, очевидно, что не взлетел и уже вряд ли взлетит.

EDIT: и нет, не поймите меня неправильно. Я двумя руками был бы за то, чтобы D «выстрелил». У плюсов горы недостатков и большое количество из них D таки закрывает. Но вот пока как-то не очень вышло.
D хорош в теории. Пока, к сожалению, не на практике. И, чего лукавить, вряд ли когда-нибудь будет.
Против браузера ничего не имею, но фрэймрейт в 12-8 фпс в движении в первой половине ролика это, конечно, позор. Не знаю, что помешало им сделать нормально.
С Code First особых проблем не заметил. Пришлось изменить некоторые нэймспейсы, методы класса EntityFunctions были заменены на аналогичные из DbFunctions и в принципе всё.
Но, к сожалению, с 6м EF-ом еще не работает MiniProfiler, поэтому пока тоже решил обождать с переходом. Критичных для меня плюшек в него не добавили.
Лучше, строго говоря, применять интринсики.
AT&T слишком «другой» по сравнению с MSVC-шным синтаксисом, который был у меня первым, и который я до сих пор считаю лучшим, плюс как уже сказали, непохожесть на nasm/yasm, только и всего. Плюc AT&T на первый взгляд содержит немного больше мусора, чем остальные варианты.
Не знаю, почему они решили использовать его дефолтным, разве что для совместимости с gcc/clang.
AT&T синтаксис — не самое лучшее, что я видел, на самом деле. Пишут что есть возможность использовать интеловский, и то хорошо.
Синтаксис не очень, конечно…
А есть ли в языке поддержка интринсиков для работы с SIMD операциями или возможность написания инлайн ассемблерного кода?
Да без проблем
            for (int i = 0; i < this.subtitleBitmap.Size.Height; i++)
            {
                for (int j = 0; j < this.subtitleBitmap.Size.Width; j++)
                {
                    int num1 = num;
                    num = num1 + 1;
                    int num2 = num;
                    num = num2 + 1;
                    int num3 = num;
                    num = num3 + 1;
                    int num4 = num;
                    num = num4 + 1;
                    byte num5 = (byte)((numArray[num1] + numArray[num2] + numArray[num3]) * numArray[num4] / 768);
                    if (num5 >= 30)
                    {
                        this.subtitleArray[i, j] = num5;
                    }
                    else
                    {
                        this.subtitleArray[i, j] = 0;
                    }
                }
            }


Лично мне версия от ILSpy понравилась больше всех.
Клёво, да
	for (int i = 0; i < this.subtitleBitmap.Size.Height; i++)
	{
		for (int j = 0; j < this.subtitleBitmap.Size.Width; j++)
		{
			byte b = (byte)((int)((array[num++] + array[num++] + array[num++]) * array[num++]) / 768);
			if (b < 30)
			{
				this.subtitleArray[i, j] = 0;
			}
			else
			{
				this.subtitleArray[i, j] = b;
			}
		}
	}


Спасибо за наводку на проект, не знал о нем.
К сожалению, иногда читаемость кода на выходе по-прежнему значительно уступает рефлектору.
Кусок метода SubtitleImage.CreateSubtitleArray из проекта SupRip,
Как его выдает Reflector
 for (int i = 0; i < this.subtitleBitmap.Size.Height; i++)
    {
        for (int j = 0; j < this.subtitleBitmap.Size.Width; j++)
        {
            byte num4 = (byte) ((((destination[num++] + destination[num++]) + destination[num++]) * destination[num++]) / 0x300);
            if (num4 < 30)
            {
                this.subtitleArray[i, j] = 0;
            }
            else
            {
                this.subtitleArray[i, j] = num4;
            }
        }
    }


И как dotPeek 1.1
      for (int index1 = 0; index1 < this.subtitleBitmap.Size.Height; ++index1)
      {
        for (int index2 = 0; index2 < this.subtitleBitmap.Size.Width; ++index2)
        {
          byte[] numArray1 = destination;
          int index3 = num1;
          int num2 = 1;
          int num3 = index3 + num2;
          int num4 = (int) numArray1[index3];
          byte[] numArray2 = destination;
          int index4 = num3;
          int num5 = 1;
          int num6 = index4 + num5;
          int num7 = (int) numArray2[index4];
          int num8 = num4 + num7;
          byte[] numArray3 = destination;
          int index5 = num6;
          int num9 = 1;
          int num10 = index5 + num9;
          int num11 = (int) numArray3[index5];
          int num12 = num8 + num11;
          byte[] numArray4 = destination;
          int index6 = num10;
          int num13 = 1;
          num1 = index6 + num13;
          int num14 = (int) numArray4[index6];
          byte num15 = (byte) (num12 * num14 / 768);
          this.subtitleArray[index1, index2] = (int) num15 >= 30 ? num15 : (byte) 0;
        }
      }


Пожалуй, главный (единственный?) недостаток в проекте для меня.
Спасибо за Go to Everything, удобно иметь его и здесь.
We could have used the --tune psnr switch to generate higher values, though this negatively affects subjective quality compared to the settings used here.

И потом сравнивали именно PSNR. Ай да молодцы. Забыли, правда, что в таком случае x264 использует гору оптимизаций, которые выдают лучшую картинки при худших метриках.

Ну и непосредственно визуальное сравнение. Все скриншоты были сняты с mpv -vo opengl-hq --screenshot-format=png и потом сжаты. На вход поступала идентичная 8-битная картинка.

Аниме
исходник
1, 2, 3, 4
x265: encoded 421 frames in 448.46s (0.94 fps), 2707.03 kb/s (настройки из статьи с -q 10)
1, 2, 3, 4
x264 10bit: encoded 421 frames, 4.65 fps, 1441.08 kb/s (--crf 18 --preset veryslow)
1, 2, 3, 4
x264 10bit: encoded 421 frames, 3.75 fps, 2841.58 kb/s (-crf 17.5 --no-mbtree --preset veryslow --aq-mode 2 --aq-strength=0.9)
1, 2, 3, 4
x264 8bit: encoded 421 frames, 6.19 fps, 2326.26 kb/s (--crf 16 --preset veryslow)
1, 2, 3, 4

Людишки
исходник
1, 2
x265: encoded 251 frames in 173.67s (1.45 fps), 1327.60 kb/s (те же настройки с -q 20)
1, 2
x264 10bit: encoded 251 frames, 5.42 fps, 1342.83 kb/s (--crf 23.5 --no-mbtree --preset veryslow)
1, 2

Выводы
1. Не стоит верить журналистам.
2. x265 пока — настоящий фестиваль бандинга и блюра.
3. x265 пока, скорее всего в силу отсутствия визуальных оптимизаций (адаптивного квантования и психовизуальщины), показывает лучшие результаты на детальных областях (линии), если не выкручивать настройки x264 для этого дела.
4. x264 10bit при грамотных настройках без особых трудностей опередит сегодняшний x265. Восьмибитному будет сложнее, но тоже сможет.
5. Это всё равно гигантский прогресс по сравнению с референсной реализацией. Посмотрим, что будет уже через пару месяцев.
Большое спасибо за релиз, Go to everything замечательный!

В тему автокомплита — мне очень нравятся Live templates и особенно их регионозависимость, но я почему-то не могу переносить автокомплит в решарпере и использую студийный. Можно ли как-то полноценно использовать темплейты со стандартным комплитом? Вызывать вставку через хоткей — не самое приятное занятие.
Под линуксами — да, конечно.
А попробуйте ffmpeg под виндой. Или, например, Aegisub. А можно еще vapoursynth. И это еще вполне адекватные примеры.
Собрать всё из этого реально. Вопрос в том, сколько на это надо потратить усилий «с нуля».

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity