Привет Дима. Я работаю на кабельном телевидение раньше работал на эфирном канале там у нас стояли Canopusы DV-Storm работали с нижним полем все было отлично. Сейчас здесь на кабельном считаю все видео без полей, потому-то умные люди сказали мне что если в видео нет изначально полей, то они там и ненужны. Считеам все в Microsoft DV. Он насколько я знаю всобще без полей работает. На врезках стоят платы AKULы (TELE) врезки осуществляются с компьютера с каким полями они работают мне ни кто конкретно не говорит. Если что знеашь объясни мне пожалуйста.

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


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


Насколько мне известно, ей вообще пофигу что выводить и с каким полем.... это зависит от софта. В твоём случае софт "ТЕЛЕ" - работает с полями.

Можно поковырять Гугл.

...но согласись, для кодека это может стать КЛЮЧЕВОЙ разницей (влияющей как на качество так и на размер) =) , для чего в том же DV используется DCTB8x8 для одного, а - DCTB2х4х8 для другого варианта. А также можно посмотреть что станет если видео с полями через cinepack пропустить =))))



с Акулой пришлось в свое время поработать (правда не долго), и насколько я помню она не учитывает порядок полей, она просто генерирует отдельную картинку на каждый вертикальный обратный ход луча... т.е для i25 она будет делать p50...

зы: с ТЕLE не работал, но насолько могу судить она должна заниматься передачей полукадров в саму "железку"... т.е DimSUN прав, тут больше от нее и зависит =)

gvz

Не соглашусь.
Бррр.... да как оно может повлиять на размер? В итоговом клипе что с полями 625 строк, что без полей... За счёт чего должен увеличиться вес-то? Зато вот на качество влияет конечно.

А вообще, вопрос был в том работает MDV с полями или нет. Ответ - работает.

Warwar wrote:

DimSUN wrote:

gvz поправил:


непонял в чем моя прореха ?

зы: не пойми не правильно, я не пытался цеплятся к словам...

gvz
я прорехи не вижу
и цепляний не вижу

Хочу убедиться что наличие или отсутствие полей будет влиять на размер выходного файла. И в чём проявляется ключевой момент?

...Да ! например для некоторых реализаций MJPG будет влиять на размер (при этом "коэффициент качественности" будет оставаться неизменным)

а вот в DV будет влиять только на качество т.к. по стандарту имеет фиксированный размер DIF-секвенции

для поддтверждения вышесказанного можешь глянуть в "Jack K. Video demystified (2001)" в инете она еще досих пор валяется

gvz

Сразу бы и сказал, что разговор про MJPEG .

ну скажем так не о MJPG, а о кодеках вообще, без разницы каких (за исключением losless, а также основанных на сжатии строк)

gvz
Ну вот позажимал я сегодня для тесту и в Microsoft DV, и в DivX и в Canopus DV/HQ и в Matrox DV. НЕТ НИКАКОЙ РАЗНИЦЫ.

Так что надо сделать чтобы её увидеть?

Может если речь идёт о дублировании строк (если надо убрать поля во время пережатия), тогда конечно и картинка ухудшится и вес уменьшится заметно.

А так по прежнему - НЕ ВЕРЮ!. Более того, я не вижу и не понимаю за счёт чего должен меняться вес...

Сори за долгое молчание, был в командировке.

Попытаюсь объяснить на пальцах, и в очень общем виде... главное чтоб мысль была ясна.

Допустим у нас есть кадр без полей следующего вида (число - это значение цвета... для простоты будем считать что картинка у нас черно-белая =))):

0,0,0,0,4,4,4,4
1,1,1,1,5,5,5,5

С полями, при движении <одна строка за один кадр> (при учете что поля у нас вертикальные !!! это для упрощения) мы получим вот это:

0,1,0,1,4,5,4,5
1,0,1,0,5,4,5,4

попытаемся теперь все это дело сжать. использовать будем упрощенный вариант rle (первое число длина, второе - цвет)

для варианта без полей мы получим:
4,0,4,4
4,1,4,5
(заметь, даже столь примитивный метод дал коэффициент х/2)

а вот результат для варианта с полями:
1,0,1,1,1,0,1,1,1,4,1,5,1,4,1,5
1,1,1,0,1,1,1,0,1,5,1,4,1,5,1,4
размер увеличился =(((...

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

левое поле:
0,0,4,4
1,1,5,5
правое поле:
1,1,5,5
0,0,4,4

сожмем:
2,0,2,4
2,1,2,5

2,1,2,5
2,0,2,4

ну что-ж, покрайней мере остались при том-же размере... =)

ну а для того, чтоб уместится в х/2, можно (к примеру) сделать допущение что два близко расположеных значения цвета, визульно воспринимаются как среднее арифметическое этих цветов. т.е <4,6> выглядит "почти также" как <5,5>, но тем самым в угоду размера, мы потеряем качество.

как я уже и говорил, это чистой воды "объяснялка на пальцах", в реальных кодеках все намного сложней (а ко всему вышесказанному надо еще и оговорить кучу поправок)... НО суть здесь показана верная - при сжатии кадров с полями будет либо увеличиваться размер, либо сильнее теряться качество (что встречается чаще)... и тут тоже стоит добавить: "за исключением некоторых случаев".

Кашмар!

QZ9 оба монитора подключены по VGA? я так понял? у 8500 как это все же давно было всего один RAMDAC - потому только клон у вас и получится. чтобы сделать расширение - надо один по VGA и другой по DVI

Это ты к чему?