Вопросы Теги

Проблемы с буферизацией MFT и качеством видео в Windows Media Foundation (потеря цветов, не очень плавные кривые, особенно текст)

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

    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js" type="text/javascript"></script>
    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js" type="text/javascript"></script>
    <script>var $j = jQuery.noConflict(true);</script>
    <script>
      $(document).ready(function(){
       console.log($().jquery); // This prints v1.4.2
       console.log($j().jquery); // This prints v1.9.1
      });
   </script>

Итак, добавление «j» после «$» было всем, что мне нужно было сделать. 

$j(function () {
        $j('.button-pro').on('click', function () {
            var el = $('#cnt' + this.id.replace('btn', ''));
            $j('#contentnew > div').not(el).animate({
                height: "toggle",
                opacity: "toggle"
            }, 100).hide();
            el.toggle();
        });
    });
9
задан Ram 11 March 2019 в 08:24
поделиться

2 ответа

Большинство потребительских кодеров H.264 подбирают информацию о цвете до 4: 2: 0. (RGB в YUV) Это означает, что до того, как процесс кодирования даже запустит ваше растровое изображение RGB, теряет 75% информации о цвете. H.264 был больше разработан для естественного контента, а не для захвата экрана. Но есть кодеки, которые специально разработаны для обеспечения хорошего сжатия содержимого экрана. Например: https://docs.microsoft.com/en-us/windows/desktop/medfound/usingthewindowsmediavideo9screencodec Даже если вы увеличиваете битрейт вашего кодера H.264 - вы работаете только с 25% исходной информации о цвете для начала.

Итак, ваши изменения формата выглядят так:

Вы начинаете с 1920x1080 красных, зеленых и синих пикселей. Вы превращаетесь в YUV. Теперь у вас есть 1920x1080 люма, Cb и Cr. где Cb и Cr являются компонентами разности цветов. Это просто другой способ представления цветов. Теперь вы масштабируете плоскости Cb и Cr до 1/4 их первоначального размера. Таким образом, ваши результирующие каналы Cb и Cr составляют около 960x540, а ваша плоскость яркости по-прежнему составляет 1920x1080. Масштабируя информацию о цвете с 1920x1080 до 960x540, вы уменьшаете размер до 25% от исходного размера. Затем в кодер передаются полноразмерные плоскости яркости и 25% цветоразностных каналов. Этот уровень уменьшения информации о цвете называется подвыборкой до 4: 2: 0. Вход субсэмплирования требуется кодером и выполняется автоматически мультимедийной структурой. Вы ничего не можете сделать, чтобы избежать этого - выбрать другой формат. 

R = red
G = green
B = blue

Y = luminescence
U = blue difference  (Cb)
V = red difference  (Cr)

YUV используется для выделения сигнала яркости (Y), который может быть сохранен с высоким разрешением или передан с высокой пропускной способностью, и двух компонентов цветности (U и V), которые могут быть уменьшены по ширине полосы, подвергнуты дискретизации и сжаты или иным образом обрабатывается отдельно для повышения эффективности системы. (Википедия) 

Original format

RGB (4:4:4) 3 bytes per pixel

R  R  R  R   R  R  R  R    R  R  R  R   R  R  R  R
G  G  G  G   G  G  G  G    G  G  G  G   G  G  G  G
B  B  B  B   B  B  B  B    B  B  B  B   B  B  B  B

Encoder input format - before H.264 compression

YUV (4:2:0) 1.5 bytes per pixel (6 bytes per 4 pixel)

Y  Y  Y  Y   Y  Y  Y  Y   Y  Y  Y  Y   Y  Y  Y  Y
    UV           UV           UV           UV
0
ответ дан Markus Schumann 11 March 2019 в 08:24
поделиться

Я пытаюсь понять вашу проблему.

Моя программа ScreenCaptureEncode использует стандартные настройки кодировщика Microsoft:

  • Профиль: базовый уровень
  • Уровень: 40
  • CODECAPI_AVEncCommonQuality: 70 [117 ]
  • Битрейт: 2000000

Исходя из моих результатов, я считаю, что качество хорошее / приемлемое.

Вы можете изменить профиль / уровень / битрейт с помощью MF_MT_MPEG2_PROFILE / MF_MT_MPEG2_LEVEL / MF_MT_AVG_BITRATE. Для CODECAPI_AVEncCommonQuality кажется, что вы пытаетесь использовать локально зарегистрированный кодер, потому что вы на Win7, чтобы установить это значение на 100, я думаю.

Но я не думаю, что это сильно изменит ситуацию.

Зв

здесь 3 скриншота с экраном печати клавиатуры:

  • экран
  • кодированный экран, воспроизводимый видеоплеером в полноэкранном режиме
  • кодированный экран Воспроизведение видео проигрывателем в не полноэкранном режиме

enter image description here

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

Я думаю, что псевдоним исходит от вашего видеоплеера, и потому что не играет в полноэкранном режиме.

PS: я использую видеоплеер MPC-HC.

PS2: мою программу нужно улучшить:

  • (не уверен) использовать IDirect3D9Ex для улучшения буферизованного механизма. В Windows7 для рендеринга лучше использовать IDirect3D9Ex (без буфера подкачки). Возможно, это то же самое для экрана захвата (список задач).
  • Я должен использовать два потока, один для экрана захвата и один для кодирования.

РЕДАКТИРОВАТЬ

Вы читали это:

CODECAPI_AVLowLatencyMode

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

О том, почему моя программа использует MFVideoFormat_RGB32, а ваша - MFVideoFormat_YUY2. По умолчанию в SinkWriter включены конвертеры. SinkWriter преобразует MFVideoFormat_RGB32 в совместимый формат кодера h264. Для кодировщика Microsoft прочитайте это: Видеокодер H.264

Формат ввода:

  • MFVideoFormat_I420
  • MFVideoFormat_IYUV
  • MFVideoFormat_NV12
  • MFVideoFormat_YUY2
  • MFVideoFormat_YV12

Таким образом, MFVideoFormat_RGB32 отсутствует. Я думаю, что SinkWriter выполняет преобразование с использованием DSP Color Converter.

Так что определенно проблема не в преобразовании rgb в yuv до кодирования.

PS (последний)

, как сказал Маркус Шуман,

H.264 больше предназначен для естественного контента, а не для захвата экрана.

Он должен был упомянуть, что проблема особенно связана с захватом текста.

Вы только что нашли ограничение кодера. Я просто думаю, что ни один кодировщик не подходит для кодирования текста с приемлемым растяжением, как я упоминал при рендеринге видеоплеера.

Вы видите псевдоним при окончательном захвате видео, потому что это фиксированная информация внутри фильма. Воспроизведение этого фильма в полноэкранном режиме (так же, как захват) - это нормально.

В Windows текст рассчитывается в соответствии с разрешением экрана. Так что дисплей всегда хорош.

это мой последний вывод.

0
ответ дан mofo77 11 March 2019 в 08:24
поделиться
Другие вопросы по тегам:

Похожие вопросы: