Перейти к содержимому


!!! Только у нас на форуме !!!
Спектакли от дяди Пчёлки

для просмотра необходима регистрация
Фотография
- - - - -

Увеличение расширения кадра при сжатии не увеличивает вес файла


  • Please log in to reply
10 ответов в этой теме

#1 Dick

Dick
  • Участник
  • 11 196 Сообщений:

Отправлено 04 мар 2010 - 01:56

Сжимаю кусок DV(avi) 36 сек. для Интернета через СРС2.
В настройках выбираю:
WEB - MPEG - mpeg1-web PAL
320х240 25.000 VGA Highest CBR поток видео 1000, поток звука 128 ( расширение mpg) Получаю вес – 5 мб. Если смотреть на весь экран, качество препаршивое.

Если в настройках там же поставить не 320х240, а 720х540 - то получаю файл с таким же весом 5 мб, но качество картинки, если смотреть на весь экран, значительно лучше.
Мне непонятна логика: ведь обычно улучшение качества видео должно приводить к увеличению веса файла. Я и раньше замечал при других сжатиях, что размер картинки (расширение) не влияют на вес файла.
Поэтому конкретные вопросы:

1. Почему увеличение расширения в настройках не приводит к увеличению веса файла?
2. Зачем тогда вообще нужно расширение 320х240 (в каких случаях его надо использовать?), если при 720х540 (при сохранении других настроек) получаем лучшее качество при том же весе?
(значит, и скорость скачки-закачки этих файлов одинакова)

Эти два файла для сравнения (общ. вес 9 мб)

Сообщение отредактировано Dick: 04 мар 2010 - 03:03

  • 0

#2 nixa

nixa
  • Участник
  • 5 840 Сообщений:

Отправлено 04 мар 2010 - 02:34

Я так понимаю: вес зависит от длительности клипа и его битрейта, а какчество от битрейта и размера картинки.
В первом клипе ты просто выбрал поток (битрейт) с большим запасом, которого хватило на пиксели (размер) второго клипа.

извини, я по колхозному объяснил :rolleyes:

кстати, большой разницы в качестве не заметил
  • 0

#3 пчёл

пчёл
  • Администратор
  • 4 544 Сообщений:

Отправлено 04 мар 2010 - 03:35

развёрнуто отвечал в одной из тем, кажется Маклауд.

1. Расширение бывает у файла... а для кадра, параметр называется разрешение.
2. Кодеку, при одинаковом битрейте, по фортепьяну с каким разрешением будет кадр.
Он всё равно впихнёт его в конечный объём файла.
Просто 720х576 он жмакнет с более низким качеством, чем 320х240.
  • 0

#4 Dick

Dick
  • Участник
  • 11 196 Сообщений:

Отправлено 04 мар 2010 - 03:59

nixa: "большой разницы в качестве не заметил"

Разница налицо, если смотреть на весь экран.

Вот эту фразу хотел бы разобрать:
nixa: "В первом клипе ты просто выбрал поток (битрейт) с большим запасом, которого хватило на пиксели (размер) второго клипа."

Про первый клип... Ты хочешь сказать, что у меня 1000 kbps - это нерационально большая скорость потока для этого 320х240 разрешения? Т.е. разрешению 320х240 соответствует какой-то оптимальный битрейт (ниже 1000), а все что выше - избыточно, и не дает прироста качества картинки?

Тогда как определить тот необходимый и достаточный битрейт, чтобы зазря не тратить вес файла? Опытным путем? Или есть какой-то калькулятор?

1. Расширение бывает у файла... а для кадра, параметр называется разрешение.
2. Кодеку при одинаковаом битрейте по фортепьяну с каким разрешением будет кадр.
Он всё равно впихнёт его в конечный объём файла.
Просто 720х576 он жмакнет с более низким качеством, чем 320х240.


1. Да, спасибо. Я чувствовал что не так говорю.... конечно - разрешение.
2. Надо разобраться... Видимо каждому разрешению соответствует какой-то оптимальный битрейт, выше которого бессмысленная трата веса. Например, при сжатии из DV(avi) в DVD 720х576 не всегда (ну, почти) вижу разницу качества картинки между скоростью потока 6000 и 9000.... А вес возрастет на треть!
Понятно, что если писать диск на кот. умещается эти 9000 - то и ладно. А если этот DVD посылать через Инет, то лучше 6000 (ради всяких экономий)

Короче, что-то начинаю понимать о соответствии разрешения и скорости потока.... о избыточности потока...
  • 0

#5 PavelBuilder

PavelBuilder
  • Участник
  • 1 232 Сообщений:

Отправлено 04 мар 2010 - 11:37

Тогда как определить тот необходимый и достаточный битрейт, чтобы зазря не тратить вес файла? Опытным путем? Или есть какой-то калькулятор?


Если ты в свое время изучал программу Gordian Knot (она вроде и сейчас есть в виде эволюционного развития) то знал бы ответ. Разработчики взяли за основу качества величину "кол-во битрейта на блок" соответственно все твои предыдущие вопросы легко раскладываются. Например, по этой формуле ясно, что если разрещение кадра больше, то в нем больше макроблоков и соответственно битрейта на этот блок будет меньше, т.е. качество хуже. Очевидно, что уменьшая разрешение кадра при том же битрейте блок будет кодироваться с большим качеством, т.о. иногда лучше снизить разрешение кадра для плоучения лучшего качества при том же битрейте. Отвечeу теперь на вопрос: "Почему увеличение расширения кадра при сжатии не увеличивает вес файла?", - уменьшается удельный вес битрейта на блок, но при этом увеличивается кол-во макроблоков. Мысленно многие догадываются, что где то что то увеличивается, но плохо представляя процесс не могут прогнозировать результат.

Вообще с термином "кол-во битрейта на блок" все проще объясняется. Этот коэффициент не зависит от разрешения кадра, например (надеюсь по описанию выше понятно стало). Сама программа Gordian Knot манипулирует дробью (отношением) и в описании просто пишет оптимальную циферку :) (всё уже за нас сделали) которая является своего рода точкой резкого перегиба графика зависимости качества от битрейта, я имею ввиду, что при таком коэффициенте достигается некое условно требуемое качество, а последующее увеличение битрейта не приводит к серьезному улучшению картинки, наверное об этом идет речь, когда говорят об избыточности битрейта. Жаль, что многие современные кодеки не имеют такого функционала настроек, которыми обладал старый, теперь уж умерший divx. А ведь можно было получить и кривые распределения битрейта по фильму и регулировать увеличение битрейта на темных и светлых участках, на уровне коэффициентов задавать битрейт от степени движения в кадре и пр. и пр. ... что то как-то развитие идет по пути упрощения ... скоро так и до кнопки "сделай мне хорошо" доберёмся

Сообщение отредактировано PavelBuilder: 04 мар 2010 - 11:50

  • 2

#6 Dick

Dick
  • Участник
  • 11 196 Сообщений:

Отправлено 04 мар 2010 - 22:44

PavelBuilder: "Например, по этой формуле ясно, что если разрещение кадра больше, то в нем больше макроблоков и соответственно битрейта на этот блок будет меньше, т.е. качество хуже. Очевидно, что уменьшая разрешение кадра при том же битрейте блок будет кодироваться с большим качеством, т.о. иногда лучше снизить разрешение кадра для плоучения лучшего качества при том же битрейте"

Наверно, здесь имеется ввиду не качество картинки, увеличенной на весь экран (о чем я писал в #1), а качество того реального размера, той площади, которая определяется разрешением, например, - 320х240. При низком битрейте, уменьшая площадь картинки на мониторе, естественно, мы повышаем ее четкость. А при том же маленьком битрейте, понятно, бОльшая площадь картинки, например, 720х540 - размоется. Оценка четкости в твоем примере идет по реальному размеру картинки.
Под "блоком", как понимаю, подразумевается конкретная площадь части изображения, которая одинакова и для картинки разрешением 320х240 и для картинки 720х540.... Ну, как "сотка" на земельном участке - где 12 соток, где только шесть...

=========================================================
Про избыточность битрейта... Часть того же интервью закодировал при тех же установках (что в #1), но при потоках: 500, 1000, 2000...
Скачать три файла Тут (общий вес 2.4 мб)

Вывод: и на реальной маленькой площади картинки 320х240 и увеличенной на весь экран монитора - качество трех файлов почти одинаковое.... Значит, поток всё что выше 500 - уже избыточный... т.е. не приводит к заметному улучшению картинки. О чем и писал nixa. А поток 1000 уже лучше вытягивал 720х540... Этим и объясняется мое недоумение - почему при том же весе файла качество картинки на весь экран во втором случае (720х540, поток 1000) лучше.
Эээ... мозги закипели :)

Короче, если нет спец. калькулятора, перед кодировкой можно проводить маленькую пробу (на глаз) для определения оптимального соотношения разрешения и битрейта (качество/вес)

Сообщение отредактировано Dick: 04 мар 2010 - 22:55

  • 0

#7 -=TRO=-

-=TRO=-
  • Участник
  • 477 Сообщений:

Отправлено 06 мар 2010 - 20:02

На торентс.ру не зря в описании к видео идёт параметр "бит в секунду на пиксель".
Но это то-же величина абстрактная, потому-что количество движения в фильме и скорость смены сцен очень сильно влияют на расчёт оптимального битрейта.
Поэтому если точным размером мы не ограничены, то выбирать в настройках нужно кодирование не по битрейту, а по установкам качества.
А поскольку понятие качества для всех разное, то без пробного кодирования новичку не обойтись.
А бывалые, быстренько промотав видеоряд, уже по опыту знают в каком кодеке сколько квалити поставить, чтобы картинка устроила и размер не раздулся.

Поэтому советую взять два коротких ролика (один с динамичным, а второй с плавным сюжетами), и пробовать.
  • 0

#8 DaLiV

DaLiV
  • Администратор
  • 1 173 Сообщений:

Отправлено 06 мар 2010 - 20:13

CBR поток видео 1000, поток звука 128 ( расширение mpg) Получаю вес – 5 мб.

CBR - a ostaljnyje parametry uzhe pofig stanovjatsja
http://ru.wikipedia....B9.D1.82

esli budesh poljzovat' VBR - to razmer faila budet menjatsja ...
  • 0

#9 Маклауд

Маклауд
  • Модератор
  • 1 908 Сообщений:

Отправлено 06 мар 2010 - 20:58

esli budesh poljzovat' VBR - to razmer faila budet menjatsja ...

О, как!? Уменьшение объёма возможно только при уменьшении битрейта, а переменный битрейт подразумевает отклонение потока не только в сторону уменьшения, но и что важно - в сторону увеличения от среднего битрейта. Именно "сэкономленный" на более статичных кадрах битрейт и даёт возможность увеличить поток на более динамичных. Делается это для сохранения качества картинки при неизменном конечном объёме, а уж никак не для уменьшения объёма файла. Ну, естественно, есть небольшая разница в объёмах, просто из-за разницы алгоритмов ... но разница совсем уж незначительная, чтоб говорить о VBR, как о способе уменьшения объёма видеофайла. Даже сжатие CBR разными кодерами даст немного отличающиеся по объёму файлы.

Сообщение отредактировано Маклауд: 06 мар 2010 - 21:13

  • 0

#10 Dick

Dick
  • Участник
  • 11 196 Сообщений:

Отправлено 06 мар 2010 - 23:25

Скажу честно, открою тайну (У, сейчас помидорами забросаете) - когда время просчета из-за двухпроходного VBR увеличивается почти в два раза (по сравнению с CBR), мне становится тоскливо...
Поэтому всё чаще выбираю CBR.
Когда уж совсем необходимо загнать большой объем видео с хорошим качеством в диск DVD, тогда да... - VBR рулит

В приведенных мной примерах видео (#1 и #6) - говорящая голова, съемка со штатива - движение в кадре отсутствует, поэтому и было достаточно для WEB-MPEG 500 kbps и CBR...
Если бы снимал с руки (камера гуляла) и интервьюируемый всё время двигался - тогда, наверно потребовался бы поток (для WEB-MPEG) не ниже 1000 kbps, и ради хорошего соотношения "вес/качество" - VBR

===============================================
Совсем ламерский вопрос - все ли плеера (и софтовые и девайсы) одинаково хорошо проигрывают и CBR и VBR ?
Что-то мне кажется, что некоторым легче кушать простой постоянный CBR, чем сложный VBR.
  • 0

#11 DiSel

DiSel
  • Модераторы
  • 1 541 Сообщений:

Отправлено 07 мар 2010 - 00:10

Когда уж совсем необходимо загнать большой объем видео с хорошим качеством в диск DVD, тогда да... - VBR рулит

На длинных фильмах в TMPEGEcnoder почти всегда ставлю Motion search precision: Highest quality - это почти в 4 раза медленнее, чем стандартный, да плюс ещё два прохода. Но повышение качества картинки при этом компенсирует снижение битрейта (на глаз, 5000 на highest выглядит примерно как 9000 на normal). Трёхчасовой фильм с такими параметарми на моём компьютере считается сутки, плюс/минус в зависимости от динамичности сцен.

Совсем ламерский вопрос - все ли плеера (и софтовые и девайсы) одинаково хорошо проигрывают и CBR и VBR ?

Раньше с Mp3 была такая проблема, возможно, из-за сложности с вычислением позиции при переходе на произвольное время. VirtualDub тоже не любит mp3 с VBR.
А вот чтобы к видео быть капризными - не попадалось. Может на низком уровне и есть аналогичная проблема с позиционированием, но плееры её аккуратно маскируют?
  • 0


0 человек читают эту тему

0 пользователей, 0 гостей, 0 скрытых пользователей

Rambler's Top100