66 ответов в этой теме

[Alf_Zetas]

Я эту табличку уже публиковал - но вопрос поднимается вновь и вновь - мне надоело отправлять всех к тому топику и я решил здесь пришпилить отдельный. К тому же добавилась пара удручающих результатов - последние версии кодеков от Сони и Канопус значительно хуже предыдущих - тенденция однако
Тест был таким -
некомпрессированную RGB авишку кодировал каким-либо кодеком, потом этим же кодеком разжимал обратно до RGB
полученный результат утилитой VideoComparer покадрово сравнивал с оригиналом - результат сравнения ниже
(чем меньше цифра - тем меньше отличий от оригинала).

________________________ DVSD ___ DV25

Matrox DV 4.0 __________ 2.05 ___ 2.98
Apple QT DV 6.5 ________ 2.31 ___ 3.17
Canopus DV 3.12 ________ 2.58 ___ 3.36
SoftLab-NSK 2.5 ________ 2.78
Pinnacle Liquid (FAST) _ 3.05 ___ ?
Canopus DV 4.0 _________ 3.37 ___ 4.17
Avid DV 1.0 ____________ 3.68 ___ 3.8
Sony DVgate 2.23 _______ 3.98
Pinnacle DS DV 2.0 _____ 4.31
MainConcept DV 2.49 ____ 4.84
Pinnacle QT DV (FAST) __ 5.51 ___ 6.46
Pinnacle RAL DV (miro) _ 5.52
Microsoft DS DV 6.5 ____ 6.57
ffdshow DVSD ___________ 6.65
Canopus DV 3.0 _________ 6.94 ___ (expand RGB 150%)
Panasonic DV 2.64 ______ 7.62
Sony Vegas 4.0 _________ 8.2
Sony DVgate 2.25 _______ 9.49

другие кодеки для сравнения:
Matrox DV50 ____________ 1.54
Pegasus PICVideo MJPG __ 2.10 (ratio 5:1)
Matrox MPEG-2 I-f ______ 2.13
Mainconcept DV50 _______ 4.01
Pinnacle QT DV50 _______ 4.21

ЗЫ корпоративные редакции всех кодеков живут здесь - FREEWARE CODECs

[rushal]

Прочитал в форуме опыты Alf_Zetas с кодеками и очень удивился

результатам. Дело в том, что я года 2 назад лично для себя проводил

подобное тестирование с кодеками и тогда у меня победил MainConcept, и

где-то на уровне с ним Cаnopus. Кодеков было протестировано штук 8, из

них Microsoft, Pinnacle и Matrox попали у меня в разряд «полный

отстой». После этого я спокойно работал с MainConcept и был доволен.

Однако данные опыты все это опровергали, и я решил снова взяться за

дело.
Прежде Всего решил сгрузить новые версии кодеков, какие смог найти. И

с каждым из них вышел казуз.
1. MainConcept. На их сайте последняя версия ProDV 3.0.16 Тем

не менее странно, т. к. файл mcdv_pro.dll их предыдущей версия 3.0.9

имеет дату создания 28.11.2003 а новая версия ProDV 3.0.16 дату

31.10.2003. Тем не менее, будем пользоваться последней версией.
2 Сanopus. Файл Кодека hlcdvc.dll Canopus_DV_CODECv3.2 имеет

дату 07.05.2004. Тем не менее, до этого у меня в системе стоял кодек

Сanopus с датой создания 10.06.2002, имел точно такой же размер

376 832 байт и имел точно такую же версию файла 1.0.0.4.
3 Matrox. Здесь вообще полный улет. Файл, который я сгрузил

под видом Matrox.4.0.0.92 установил мне кодек DigiVCap.dll созданный

27.07.2002, а сам файл имел версию 2.5.0.63. После этого я для

гарантии сгрузил еще 3 файла с кодеками с разных мест,в том числе

официальные Matrox VfW от Digisuite 7.1. Все они содержали одну и ту

же версию файла.
У меня сложилось впечатление, что все эти новые версии кодеков -

просто приписанные кем то цифры. И больше ничего.
Ну, а теперь непосредственно к тестам.
Прежде всего, надо правильно подготовить исходную картинку. Надо

понимать, что если мы попытаемся сжать однотонную серую картинку, а

потом сравнить с оригиналом, то и искажений получим 0, т. к. любой

кодек сожмет это «на ура». То есть количество искажений зависит еще и

от исходного сигнала. Поэтому картинку готовим соответствующую.

Методика профессиональных испытаний была как-то давно подробно описана

в журнале «Мультимедиа и видео». Там создавали композиционное

изображение, где в центре кадра в круге помещалась полезная картинка,

а вокруг подавался сигнал с генератора шума. Такой сигнал очень трудно

сжать, т. к. он содержит огромное количество мелких, хаотически

меняющихся точек и очень сложно поддается анализу для кодера. В

процессе эксперимента размеры круга уменьшали, увеличивая площадь

сигнала шума и смотрели, когда кодек «сломается», т. е. искажения

выйдут за допустимый предел. Нечто подобное попробуем сделать и мы.

Кстати, по поводу программ, меряющих степень искажений. Как-то у меня

была подобная программа, но толку я с ней не дал, и по времени она

была утеряна за ненадобностью. К сожалению, программу, которую

использовал Alf_Zetas, я выкачать не смог, т. к. ссылка умерла.

Поэтому мерять будем «на глаз».
Итак, исходное изображение. Я взял картинку из фотошопа с утенком,

приделал к ней альфаканал, и кроме того, убрал цвет. все это положил

на 2 дорожку в Previere 6.5. Это будет наша полезная картинка. Для

дорожки 1 создал Color Matte серого цвета и применил к ней фильтр

Noise 100%. Получился цветной, хаотичный шум. Установки проекта и

экспорта - некомпрессированное AVI и без полей, чтобы они, не дай бог,

чем нибудь помешали. В результате имеем такую вот картинку.

http://rushal.russian.ru/original.jpg

Заметьте, я намереено сделал утенка однотонным, т.к. на ровном оттенке

легче будет заметить искажения. Фон же, наоборот, как можно более

контрастный и цветной (ведь погрешности цвета мы тоже хотим оценить,

неправда ли?). Так легче понять, как фон будет влиять на утенка.
Теперь - кодирование. Установки проекта и экспорта ставим на

соответствующий кодек и просчитываем соответственно Matrox.avi,

MainConcept.avi, Сanopus.avi. Перед сменой кодека Preriere выгружаем,

чтобы исключить возможное влияние.
Теперь самое главное - сравнение. Создаем новый проект с установками

проекта и экспорта - некопмрессированное видео. На дорожку 1 кладем

наш исходный некомпрессированный файл и применяем к нему фильтр Invert

RGB, получая таким образом, негатив. Теперь сложим его с одним из

закодированных файлов. На дорожку 2 кладем один и файлов и

устанавливаем для него уроверь прозрачности. Что должно получитья в

результате на выходе, если кодер не внес искажений? Правильно,

равномерный серый фон. Все же то, что мы увидим в результате, и будут

искажения, которые внес кодер. Чтобы сделать все это более наглядным

для глаза, создадим из композиции виртуальный клип и наложим на него

эффект Contrast c уровнем 70. Просчитаем 3 файла для каждого из

кодеков. Не забываем перед каждой сменой кодека выгружать Preriere.
Итак, вот результат:

http://rushal.russia...Mainconcept.jpg
MainConcept

http://rushal.russian.ru/Canopus.jpg
Сanopus

http://rushal.russian.ru/matrox.jpg
Matrox


На MainConcept у утенка мы можем увидеть глаза. Это означает некоторую

неравномерность преобразаваний по яркости. Вокруг утенка, кодек,

конечно же, «сломался». В реальном изображении то что у нас шум, -

это резкие цветные и яркостные переходы, и там «неправильность»

каждого пиксела на несколько значений гораздо менее заметна, чем на

обнотонных участках. Тем не менее весь утенок равномерно серый,

влияние шума минимально. Результат можно признать очень хорошим.
Сanopus. Окружающий шум имеет примерно одинаковую с MainConcept

величину, а вот глаза превратились в рассадник артефактов, тоже самое

клюв. Как повлиял шум на равномерные участки, хорошо видно в самом

низу утенка (сравните у MainConcept). Оощая оценка - хорошо.
Matrox Тут и говорить особенно нечего - и так все видно. Шум имеет

большую амплитуду, а также частицы шума более крупные. Это означает,

что реальное изображение будет «замыливаться»(может этим и объясняются

хорошие полученные результаты Matrox в других тестах - картинка

становится более «мягкой»). Сам же утенок в видеоварианте выглядит

ужасно - если у MainConcept и Сanopus просто присутствуют, то на

Matrox они шевеляться! Впечатление дикое. В реальном видео это значит,

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

перемащений других. Общая оценка - плохо.
Вот вобщем то и все. Если что не так - товарищи меня поправят.

[Alf_Zetas]

1. у тебя весьма поверхностное представление о кодеках - они давно уже состоят не из 1 файла, а из 4-5 файлов. Конкретно версию движка (а не VfW переходника на который указывает FOURCC) надо смотреть у Матрокса в файле SwcDvvfw.dll, у Канопуса в файле cscCDVC.dll (или cscDVSD.dll в dvsd версии)
2. я тестировал авишку из 20 типов разных изображений и получил средний результат. На разных типах изображения кодеки ведут себя по разному - Майнконцепт например дает сильную интерференцию на чистых цветах (синтетическая графика и титры) - поэтому так и упал в общем зачете. А на некоторых картинках он был действительно среди лучших.

ЗЫ Video Comparer лежит здесь

Сообщение отредактировано Alf_Zetas: 16 Sep 2004 - 04:10

[Alf_Zetas]

Официальное тестирование Квиктаймовских кодеков -
http://www.oneriverm...odecs/index.htm

тестовая картинка


и описание на что надо обращать внимание

http://www.oneriverm...ecs/testing.htm

[rushal]

1. Насчет количества файлов в кодеках - действительно согласен. Тем не менее дата выпуса матроксовского SwcDvvfw.dll 27.07.2002 (версия 4.0.0.92) - какой же он новый?

2. Сравнивать качество с помощью программы, то есть путем простых арифметических вычислений, считаю некорректным. Ведь на изображении могут быть контрастные участки, с резкими переходами, где изменение яркости и цвета конкретного пикселя на несколько единиц незаметно для глаз; и участки относительно равномерные, где эта разница сразу бросается в глаза. И среднеарифметическое здесь обманчиво. Кстате, в тесте из журнала, о котором я писал выше, исседовали хардовые кодеки видеомагнитофонов, а оценку качества в баллах выставляла группа профессиональных экспертов по психовизуальной оценке качества картинки, То есть оно зависело от восприятия человеком, а не счетной машинкой. DV и так жмет достаточно сильно, и понятно, что без потерь здесь никак не обойтись, и нужно, чтобы эти потери были не среднеарифметические, а наименее заметные для глаз.
Кстати, если в моем варианте тест усложнить,- задать утенку движение через весь кадр, например слева направо, то можно увидеть, как в тесте Matrox вместе с утенком на шумящем участке параллельно движется его тень, или силуэт, отстоящий от него на половину ширины кадра. Это была одна из причин, по которым я забраковал Matrox в прошлый раз, и на этот раз ситуация не изменилась.

Что касается измерений с помощью VideoComparer (Кстати, я вспомнил что в прошлый раз я тоже пробовал именно эту программу), то вот они:

Main concept
62,5

Canopus
54,3

Matrox
74,07

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

[VVV]

Цифирьки-то и правда у всех разные будут
Результат всё равно один

Сравнивается каждая точка первого кадра с точкой, с теми
же координатами, второго кадра след. Способами:
1. Обе точки рисунка представляются, как точки в
трехмерном пространстве RGB. Далее вычисляется
расстояние между ними по обычной геометрической
формуле: S=Sqrt((r2-r1)^2+(g2-g1)^2+(b2-b1)^2).
2. Вычисляются яркости точек по формуле
Y=((76*r)+(150*g)+(29*)/255. Вычисляется расстояние     
между двумя яркостями.

Результаты сравнения для отдельного кадра (изменяются
в процессе сравнения):
"Совпадений" - Число  точек, которые не изменились
(одинаковы в обоих кадрах), выраженное в процентах.
"Экстр.Совп" - не используется.
"Отл. Яркости" - Среднее отличие яркости между точками с
одинаковыми коорд.
"ЭкстЯркОтл" - Максимальное отличие яркости между 2-я
точками.
"Отл. Цветов" - Среднее расстояние по RGB.
"ЭкстЦвОтл" - Максимальное расстояние по RGB между 2-я
соответствующими точками.
"Общий" - обобщающее значение, т.к надо учесть
особенности человеческого восприятия - человек более
чувствителен к изменению яркости, чем к изменению
цветности - "Общий" в большей мере учитывает значение
"Отл. Яркости", чем "Отл. Цветов".
"Экстр.Общ" - не используется.

Общие Результаты сравнения для всей
последовательности кадров:
"Совпадений" - Среднее от "Совпадений" в
последовательности кадров. (Сумма значения
"Совпадений" для каждого кадра, поделенная на
количество кадров)
"Экстр.Совп" - Максимальное Coincidents в
последовательности кадров.
"Отл. Яркости" - Среднее отличие яркости в
последовательности кадров.
"ЭкстЯркОтл" - Максимальное отличие яркости в
последовательности кадров.
"Отл. Цветов" - Среднее от RGB Diff в последовательности
кадров.
"ЭкстЦвОтл" - Максимальное RGB Diff в
последовательности.
"Общий" - обобщающее значение, Сумма всех "Общий"
поделенная на кол-во кадров.
"Экстр.Общ" - Максимальное "Общий" в последовательности
кадров.

Чем значение МЕНЬШЕ, тем МЕНЬШЕ РАЗЛИЧИЯ между
рисунками (соответственно кодек ЛУЧШЕ). Исключение
составляет значение "Совпадений" - чем оно больше, тем
отличий меньше. Вообще на значение "Совпадений"  можно
не обращать внимание - оно мало что характеризует.
Все значения (исключение, опять же, значение
"Совпадений", которое выражено в процентах) могут
изменяться от O(для 2-х одинаковых кадров) до 1000(для 2-х
совершенно различных кадров, т.е тех, где каждой белой
точке соответствует черная точка.) Если "Общий" меньше
10-11, то отличия, на глаз, не заметны, т.е качество
фильма высокое. Если "Общий" больше 17-20, то качество
очень низкое.
Эта программа FREEWARE, поэтому я позволил себе не
добавлять некоторых проверок и возможностей - так
программа гарантированно работает только для фильмов
в формате 352x288 точек, не проверяется правильность
параметров "Выборка кадров".
Программа должна работать в 24 битном цвете!

Читайте хелпы Прграмма - то что надо!

[Gradov_Georg]

Alf_Zetas

Сенкс за расшифровку.
Давно хотел заиметь ссылочку и красивой картинкой для тестирования... Доставучих клиентов посылать 8-).

[rushal]

Зря вы так. Я вовсе не сказал что программа плохая. Я просто предложил оценить результаты визуальных измерений. А вот по ним как раз никто и не высказался.

[rushal]

Я сейчас попытаюсь обяснить, почему VideoComparer не подходит для оцеки качества кодирования.
На сей раз у нас будут реальные исходники и синтетические кодеки.
Возьмем кусок Uncompress видеоряда. Это будет наш исходник.
1. Пережмем его в какой-нибудь DV кодек и сравним с оригиналом утилитой VideoComparer. Значение "Общий" получилось 2,74 (возможно исходник был не очень сложный).
2. Смоделируем теперь синтетический кодек "Х". Это будет кодек, который жмет в некомпрессированное видео, но вносит небольшие искажения по яркости и цвету.
Кинем исходник в Premiere и применим к нему фильтр Level с патаметрами гаммы:
Красный 0,98 Зеленый 0,98 Синий 1,04. и просчитаем все в Uncompress. Полученное изобрадение на глаз практически неотличимо от оригинала - где-то синего побольше, где-то красного поменьше. Теперь сравним с оригиналом. Значение "Общий" - 6,34.
Что же получилось, что некомпрессированное видео хуже чем DV?. Думаю что нет. Просто программа не оценивает именно характерные для DV, DVD, да и для Jpeg искажения, связанные с "квадратизацией" изображения. Поэтому я и сказал, что использовать ее для оценки качества нельзя.

[Gradov_Georg]

Твоя ошибка в том что ты задался вопросом на чей глаз неотличимо, и на чей монитор?

Алгоритм "без сжатия", но с накапливающимся уходом в синее и исчезновением красного лучше чем квадратизация 8-).

Ню-ню...

Напиши свою прогу для ловли квадратизации....

[rushal]

Напиши свою прогу для ловли квадратизации....

На зрительное восприятие изображения не сильно влияет, какие цветовые координаты имеет конкретный пиксел, и насколько сильно это отличается от оригинала. Изображение, или даже скажем так, образ,- это некая область пикселов, и восприятие изображения, или формируемый образ зависит от разницы цветовых координат данного пиксела и окружающих. (Утенок, даже если он будет темнее, синее или краснее, тем не менее останется утенком. А вот если в нем изменить цвет отдельных пикселов, он вполне может превратиться в крокодила )
Я бы поверил результатам VideoComparer, если бы в ней сравнивалась не просто координаты точки из клипа а с точкой из клипа b. Я бы поверил, если бы сравнивались разницы между точкой из первого клипа и соседними пикселами и то же самое из второго клипа. Т. е. алгоритм должен быть примерно такой:

Клип1
a
b x c
d

Клип2
a1
b1 x1 c1
d1

Вычисляем разницу между точками x и a (x-a) и точками x1 и a1 (x1-a1) и далее (x-a)-(x1-a1) (в трехмерном пространстве RGB). Это будет разница между клипом1 и клипом2 в точке x в направлении a. Естественно, все это с корнями и квадратами. Делаем то же для других направлений. Разница между клипом1 и клипом2 в точке x будет иметь примерно такой вид: (x-a)-(x1-a1)+(x--(x1-b1)+(x-c)-(x1-c1)+(x-d)-(x1-d1).
Если бы кто-нибудь реализовал подобный алгоритм, было бы интересно.

Сообщение отредактировано rushal: 12 Dec 2004 - 11:51

[Gradov_Georg]

Прочитай хелп к сомпреру. Судя по тому что ты написал, ты его не прочитал.

[Михаил Аранышев]

Есть такая штука в Фотошопе - Difference

[Aleksandr_Oleynik]

Я слабо представляю смысл всех этих разборок, ну разве как теоретический.
Если материал в процессе работы более чем два раза пережимался - значит нужно учится работать, а не искать качественные DV кодеки у которых. кстати, показатели пережатия по 10-15 раз лучше чем 1-2 раза .

Сообщение отредактировано Aleksandr_Oleynik: 12 Dec 2004 - 19:44

[DaLiV]

Aleksandr : prosto esli bolee chem 2 - ti budesh videtj eto uzhe slishkom javno ...
v obshem vspomni rassuzhdenija pro HIFI audio - i perenesi eto na video - ibo tam shnuri - zdesj kodeki i sootvetstvujushij okras ... ibo odnogo raza perekodirovatj dostatochno dlja rozovogo ili zelenogo okrasa ot opredelennih kodekov

[VVV]

Я и один раз увидел СЛИШКОМ явно
Не буду расстраивать многих...

[Aleksandr_Oleynik]

Братцы, у меня и одного раза нет.
Я в проекте Рэндер кодек ставлю НЕКОМПРЕС. В Некомпресе делаю все сторонние работы в том числе и по доработке DV материала.
И с Таймлайна готовый проект через Некомпрес выгоняю в M2V.
Какая мне разница какой DV кодек? Разве что у них разное качество декодирования в Некомпрес???

Вот как раз аналогия со звуком и именно с HiEnd и зставляеет меня работать с Некомпресом, причем если охота работать с 4-6-8 слоями DV в РиалТайме всеравно нужен Рэйд из 4-6 дисков, а значит проблем с местом по определению уже нет.

Точно также буду работать и с HDV - кодек для Рэндера и Фуза буду ставить только HD Некомпрес!!!

[DaLiV]

ne zabudj snto iz dv u tebja cherez kodek v odnu storonu prohodit v ljubom sluchaje ... DV->nekompress a tam tozhe mogut bitj iskazhenija ... a esli potom obratno v dv i nesti na studiju - to vot tebe i polnij cikl kodeka ...

[Aleksandr_Oleynik]

Про декомпрес я написал, но как не присматривался и какие только тесты не делал - разницы я не вижу. Более того, попытки снять скриншот с DV кадра - это ведь тоже декодирование в некомпрес, такчто и не будет разницы, если мерить это программами или в фотошопе по диференсу. Посему самый честный тест - это сравнение на внешнем профи TV мониторе.
А что касается обратно на DV ленту -
мне это не нужно, а тем кому нужно - УВЕРЕН никакой разницы также не увидят. При однократном декодировании- кодировании самого разного материала и самых разных тестов как я только не всматривался в проф TV монитор подключенный к Хрому - я разницы не вижу с DV кодеком от пинакла, который позицианируется по качеству не как самый лучший .

[DaLiV]

ne budj tak uveren. problema 16-235 tozhe sushestvujet i tozhe kodekozavisimaja.
to chto ti ee dlja sebja reshil poljzuja Liquid - to ne vse sidjat na likvide i mogut ne sobiratjsja dazhe ...

kazhdij kodek imeet svoi osobennosti i gljuki po смещению cvetov ....

ne ukazana versija kodeka ... starije kodeki ot pinnacla dolbali kartinku eshe kak ...
ne kazhdij uslishit raznicu ot raznoj akustiki i sootvetstvenno ne kazhdij uvidit raznicu mezhdu RGB 255,255,255 i 254,255,255 /prosjba ne vosprinimatj bukvaljno - primer grubij... mozhet bitj i YUV i drugije ... a mninimaljnoje delenije u kazhdogo estj)

[VVV]

Я тут как-то предлагал публичный тест, но все скромно промолчали...
Я его сам сделал и пришёл к определённым выводам. А 0-255 это мелочи, на котрые (зная это) можно просто не обращать внимания

[rushal]

Не думаю что, кодеки имеют разницу при раскодировании. Ведь что такое кодек - это сборник жестко стандартизтрованных алгоритмов, по которому проходит сжатие или разжатие сигнала. Именно потому что они стандартизированы, изображение сжатое одним DV кодеком мы можем разжать другим. Если бы было по-другому - кодеки бы просто не поняли друг - друга. Т. е. если в изображении закодировано - блок 16х16 такой-то разжимать таким-то алгоритмом - кодек именно так его и будет разжимать. И никак по-другому. То же самое и при сжатии. Другое дело, как при кодировании кодер определяет, каким именно из алгоритмов сжимать данный блок, какой ему выделять битрейт, чтобы и передача этого блока не пострадала, и другие блоки не обделить. Именно в этом и различие кодеков.

[DaLiV]

rushal - delo takoje chto kazhdij proizvoditelj kodeka delajet ego kak umeet - poetomu i raznije rezuljtati ... a to bilobi u vseh kodekov i skorostj odinakovaja i rashozhdenij po cvetam / jarkosti ne nabljudalosj ...
a to chto oni ponimajut drug druga - to eto potomu chto estj standart DV iz kotorogo kodek uzhe izvlekajet i zasovivajet informaciju - a naskoljko korrektna sama informacija - eto vishe ...
P.S. standart - pochta, a pisjmo (dazhe odnogo soderzhanija) kazhdij po raznomu napishet - u kazhdogo svoj pocherk i gramatiku znajut na raznom urovne...

[Aleksandr_Oleynik]

Я тут как-то предлагал публичный тест, но все скромно промолчали...
Я его сам сделал и пришёл к определённым выводам. А 0-255 это мелочи, на котрые (зная это) можно просто не обращать внимания

Даешь тест!!!
Я согласен.

[VVV]

Поздно...
Я уже сделал выводы.
format C: и переустановка винды и редактора, годного для работы с DV и в DV:) И МПЕГ2 в LE_6.0 проигрывает прилично.
ВСЁ - ИМХО.
Тестите сами, устраивает, не надо расстраиваться - надо работать!

[SlawDD]

... МПЕГ2 в LE_6.0 проигрывает прилично.

Проигрывает по сравнению с чем, простите?

[VVV]

По сравнению с тем (с одинаковым битрейтом), на чём кодирую.
Не парьтесь так
Я никогда и никого за определённый софт не агитировал и не буду.
Смотрите сами.

[SlawDD]

Тогда, я тоже буду писать, что-нибудь типа: нееет, мой самый лучший, но я его вам не посоветую! вдруг вы там изъяны найдете . Очень конструктивно

[VVV]

Прокодер 1.01.35 со своим же движком.
Не секрет вовсе ни для кого - много раз говорил, что предпочёл его медленный, но более качественный движок.
Я не буду выкладывать скриншоты. Проверял на своём тестовом куске - фонтаны Петергофа.

[Aleksandr_Oleynik]

Ух как все быстро свернулось .
Да и не о MPEG2 мы говорили, ну да ладно.
Только вот в Edius тоже свой DV кодек .
И работать с MPEG2 как с DV пока не могет, кажись.
Но для HDV я его всеже гляну, но в инкарнации NX.

[VVV]

OFF, извините.
В Эдиусе кодек свой, не лучший, но и не худший.
Только при чём здесь Эдиус? Я разве за него агитирую?
HD меня в ближайшие 1.5 (примерно) года не интересует. Один раз на новинку формата позарился, теперь до устаканивания носителя и самого формата зарёкся Валяются до сих пор лазерные видеодиски размером с обычный винил
МПЕГ я тоже не редактирую

А кодеки (и всё остальное) лучше сравнивать САМОМУ - технология и тесты известны.

[Aleksandr_Oleynik]

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

[Alf_Zetas]

Валяются до сих пор лазерные видеодиски размером с обычный винил

зато какой презентабельный вид
Видеомашина даже монтировать с них могла

[Aleksandr_Oleynik]

У меня, кстати, тоже и проигрыватель в гараже и дисков штук 10 .

[rushal]

Кстати, в плане разговоров о качестве DV кодеков мы упустили одну важную вещь - оценить тот кодек, который стоит самым первым и вносит искажения, - речь о хардверном кодеке, который стоит в камере. (Думаю, что DV-монтаж используют снимающие в DV, вряд ли найдутся сумасшедшие, снимающие на Digital Betacam, а потом монтирующие все в DV). Порядок эксперимента может быть примерно такой:
1. С качественного источника по SDI материал загоняется в DV-магнитофон (происходит хардверное кодирование в DV), а затем по 1394 (без перекомпрессии) все это заливается в комп - готов материал, закодированный хардверным кодеком.
2. С того же источника по SDI материал некомпресс загоняется в комп (если в качестве источника используется комп, этот пункт можно исключить), а затем софтово кодируется в DV.
3. Материал сравнивается.
Если кто-то сможет провести подобное, было бы интересно.
Почти уверен, что софтовые кодеки сильно побьют хардверный. Все микросхемы для dv кодирования разработаны минимум лет пять назад, а какие-то уже и десять (dv существует с 1995 г.) и вряд ли в них кто-то что-то с тех пор улучшал. Скорее разработчики вложаться в изготовление новых кодеков, например HDV. А софтовые версии обновляются до сих пор.

[VVV]

Бессмыслица полная.
Понянто ещё, если в некомпресс DV хватать и его же монтировать и его же сразу в МПЕГ2. Здесь ПОТЕРИ могут быть меньше. Это надо у А.Олейника консультироваться - он так делал.
Остальное - ерунда.

[Gradov_Georg]

8-).

rushal, молитва старого еврея:
Боже дай сил бороться там, где это возможно...
Боже дай сил терперь там, где боротся бессмыслено...
и главное Боже -- дай ума различать эти два случая...

Камеры отличаются в других местах -- настолько, что сравнивать их чипы-кодеки между собой бессмысленно... И что самое смешное -- у тебя есть возможность ЗАМЕНИТЬ один чип на другой?

К тому же откуда у тебя инфа, о том что в камерах стоят отдельные чипы конверторы пятилетней давности -- СХЕМЫ в студию.

КАМЕРА И КОНВЕРТОР -- разные вещи.

В свое время тут сравнивали (аналог-DV)-конверторы и выносился приговор отдельным устройствам -- это смысл имеет ибо проверяется ОБЯЗАТЕЛЬНАЯ ФУНКЦИЯ устройства, а не сопутствующая...

[Aleksandr_Oleynik]

........................(Думаю, что DV-монтаж используют снимающие в DV, вряд ли найдутся сумасшедшие, снимающие на Digital Betacam, а потом монтирующие все в DV).

Знаю очень много таких случаев, и особенно для телевещания.

А все остальное - безсмыслица.
Сравнивать можно то, на что можно повлиять.

[rushal]

Сравнивать можно то, на что можно повлиять.

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

[Antoha]

Ну и зачем оценивать кодек камеры, усли мы загружаем в компьютер цифровой (не декодированый) поток с ленты???

[DaLiV]

softovij kodek mi mozhem pomenjatj v ljubuju minutu - a vot zhelezku ne kazhdij sebe pozvolit kazhdij mesjac menjatj ...

[Aleksandr_Oleynik]

Ну и зачем оценивать кодек камеры, усли мы загружаем в компьютер цифровой (не декодированый)  поток с ленты???

Чтобы поменять камеру.

Проблема ВЫБОРА, опять проблема выбора.
Кудаж от нее дется.
rushal
Только оценка качества съемки DV камер включает в себя не только кодек, а еще кучу всего прочего, также как и оценка железного DV кодека привязанного к конкретной плате, которую мы не только по качеству работы с DV выбираем, а еще по куче других параметров.

А эта тема звучала вполне ясно.

[MuTeK]

если кому интересно, то вот тут: _http://www.moonlight.co.il/cons_mseye.php
есть софтина которая, позволяет мерить качество в привычных PNSR-ах, а так же в VQM и NQI.

[YNUS]

Хотелось бы на неё глянуть но 404, как называется?

[Virs]

http://www.moonlight...e_Suite_1_1.zip
http://www.moonlight...umer/streameye/

Сообщение отредактировано Virs: 18 Apr 2005 - 18:22

[billiepiper]

Ну так какой DV-кодек был признан лучшим?

[billiepiper]

Хочу задать ещё такой вопрос: когда я переписываю видео с камеры программой Pinnacle Studio, редактирую его и вывожу на hard-drive в виде DV, есть ли пережатие из DV в DV программой монтажа (своим кодеком), помимо тех мест, где накладываются переходы и эффекты.
Я хочу удостовериться, что тот материал, на котором эффекты не применялись, просто копируется программой монтажа из оригинального захваченного файла БЕЗ ПЕРЕЖАТИЯ.

Пробовал вместо DV Video Encoder выставлять одк от MainConcept или Canopus, но Студия отказывается рендерить в них.

Сообщение отредактировано billiepiper: 02 May 2005 - 00:42

[VVV]

Ну так какой DV-кодек был признан лучшим?

Уточняющий вопрос - кем признан?

[billiepiper]

Форумчанами

[DaLiV]

каждому свое. ставь Матрокс - не ошибешся.