Синхронизация Audio & Video. "Жуткий Метод" (TM)
Версия для печати

Конференция: Конференция iXBT.com (http://forum.ixbt.com/)
Форум: Цифровое видео: захват, монтаж, обработка (http://forum.ixbt.com/?id=29)
URL: http://forum.ixbt.com/topic.cgi?id=29:20089

Время GMT +03. Даты в формате dd.mm.yyyy.


TAB, 02.08.2004 12:29
Синхронизация (http://alvator.narod.ru/articles/av_sync/default.htm) . Предлагаю обсудить. Конструктивные предложения и критика весьма приветствуются.

PS Автором trademark "Жуткий Метод" является Vladimir с форума www.iulabs.com (Лаборатория Ивана Ускова)

1. Симеон, 02.08.2004 13:36
вопрос критический : если количество кадров становиться нормальным, то почему звук надо подгонять ?

2. TAB, 02.08.2004 13:50
Симеон
если количество кадров становиться нормальным, то почему звук надо подгонять?
Для дальнейшей беспроблемной работы с видео необходима стандартная частота кадров, напр. 25fps (PAL). Источники аналогового сигнала не всегда выдают 25.000fps, например для моей камеры типовое значение ~24.997fps. При оцифровке звука отдельной картой нужно учитывать также погрешность частоты опорного генератора ее АЦП. Все это приводит к тому, что потоки воспроизводятся не с той скоростью, с которой они захватывались. Соответстенно время их воспроизведения будет также отличаться. На клипах малой продолжительности этим можно пренебречь, но на длинных клипах эти погрешности необходимо компенсировать и гораздо удобнее это проделать с аудиопотоком.

3. Симеон, 02.08.2004 13:54
TAB
а у virtualVCR метод динамический ресемпл прокоментируйте пойжалуста.
еще частота 25.3 при мастере звук это результат "мнимых" дропов ?
( источник видеокассета запись нескольких передач в стык без пауз
сделаная на местной тв на Svhs магнитофоне на vhs кассету )

Добавление от 02.08.2004 13:57:

кстати о мнимых дропах : программа захвата в теории в состоянии отличить "мнимый" дроп от настоящего ?

4. TAB, 02.08.2004 14:18
Симеон
Динамический ресемпл штука хорошая. Если кратко, то он ресемплирует звук реалтайм, постоянно выравнивая скорости потоков. На выходе имеем достаточно синхронный клип со стандартными параметрами. Но есть одно но: т.к. система по определению не может предсказать будущие дропы или иные проблемы, то корректировка аудио потока происходит после обнаружения проблем с синхронизацией. И как в любой системе автоматической регулировки, ей присущ такой параметр как "время реакции", а в данном случае правильнее сказать - "время интеграции". Если по-простому, то одиночные дропы динамический ресемпл скомпенсирует хорошо - короткой рассинхронизации никто даже не заметит. Но если попадется серия дропов (а с "мнимыми" дропами так и бывает обычно) то коррекция займет некоторое время и в этот период рассинхрон будет заметен. И кстати, после динамического ресемпла мой метод уже не поможет - там вообще уже ничего нельзя будет сделать. Но для материалов вида "записал-посмотрел-удалил" эта фича очень даже подходящая.

программа захвата в теории в состоянии отличить "мнимый" дроп от настоящего ?
ИМХО "мнимый" дроп добавляется не программой захвата, этим занимается AVImux. Так что программа его не отслеживает.

5. Симеон, 03.08.2004 05:46
TAB
ресэмпл DX делает ?

6. anyata, 03.08.2004 11:50
ТАВ,
Спасибо за статью!
Отличная работа! Попробую и всем сообщу результат.

Вопрос знатокам.
При захвате наблюдаются 2 проблемы:
1. Рассинхронизация - скорее всего, из-за дропов, особенно с VHS.
2. Захваченный звук имеет какое-то странное эхо, правда, небольшое, но неприятное.

Режимы захвата:
Video: PicVideo MJPEG, 19-20
Audio: PCM, 16 bit, mono, 44100 Hz

Пробую захватывать разными прогами, дропов иногда больше, иногда меньше, но есть всегда.

Вопрос: происходит ли это из-за встроенной звуковой карты (on-board)?
Я читал в одном форуме, что встроенные звуковые карты (AC97) работают в режиме меньшего приоритета, и это может привести к дропам и/или рассинхронизации.

7. Симеон, 03.08.2004 12:11
anyata
прошу прощения, а какое устр-во захвата ?

цитата:
anyata:
Захваченный звук имеет какое-то странное эхо, правда, небольшое, но неприятное.

на какой программе захвата + какие опции выставлены.

8. ksv2000, 03.08.2004 12:50
anyata

Попробуй сделать звук 16 bit, 48000 Hz, это родная частота кодека на материнке
А дропы будут почти всегда, особенно при оцифровке некачественных записей.

9. anyata, 03.08.2004 14:52
Симеон
Устройство: ATI Radeon 9200 VIVO 128 MB Atlantis, производитель Sapphire
(забыл указать в конфигурации, простите ).

цитата:
на какой программе захвата + какие опции выставлены
Перепробовал следующие:
- VirtualDub
- ATI MMC 9.0 & 9.1
- Ulead Media Studio 8
- FlyCap 2.52 (не FlyDS)

Резолюция всегда 720х576 или 704х576, смотря что позволяет та или иная программа.

В последний раз захватывал через iuVCR, без мастер-стрима.
Захватывал (больше для теста) 45-минутную детскую передачу с оригинальной кассеты и следил за дропами. Дропы появились только к концу, прибл. 10 штук, точно не помню.
При просмотре захваченного (необработанного) материала обнаружил следующее: где-то до 30-ой минуты всё идёт гладко, потом изображение как-то неровно прыгает (на долю секунды, но глаз успевает заметить) - скорее всего, дроп - и после этого видео начинает отставать почти на 1 секунду.

На заметку: trial period у iuVCR еще не закончился, вроде бы пока-что должна работать без сбоев. Кстати, обязательно зарегистрируюсь и приобрету платную версию, если этa программа решит проблему дропов.

Через VirtualVCR еще не пробовал, сделаю на днях.


ksv2000
цитата:
Попробуй сделать звук 16 bit, 48000 Hz, это родная частота кодека на материнке
Попробую, спасибо.

цитата:
А дропы будут почти всегда...
Эта проблема неразрешима?


По поводу моего первоначального вопроса.
Если поставить PCI звуковую карту (недорогую, типа Creative Vibra 4D, дороже, по-моему, нет смысла), решит ли это хоть как-то проблему дропов и качества звука?

10. TAB, 03.08.2004 15:17
Симеон
ресэмпл DX делает ?
Нет. Это делает AudioResample.ax из состава VirtualVCR.

anyata
Отличная работа! Попробую и всем сообщу результат.
Спасибо. Ваши результаты мне тоже очень интересны, хотя я в них вроде как уверен.

Рассинхронизация - скорее всего, из-за дропов, особенно с VHS.
Скорее всего. Хотя эта причина не единственная.

Захваченный звук имеет какое-то странное эхо
Я думаю, ksv2000 правильно указал причину. Дело в том, что многие звуковые карты изначально оцифровывают сигнал с частотой именно 48кГц. Любая другая дискретизация (в данном случае 44.1кГц) получается ресемплом из исходной. А небольшое эхо - это как раз характерный артефакт некоторых алгоритмов ресемплирования.

Эта проблема неразрешима?
Проще с ней смириться

11. ksv2000, 03.08.2004 17:42
anyata
Дропы появились только к концу, прибл. 10 штук, точно не помню.
10 штук за 45 минут совсем немного. Чтобы не было рассинхронизации, нужно в настройках программы захвата назначить главным аудиопоток, а видео будет привязываться к нему, и соответственно дропиться, когда надо.

При просмотре захваченного (необработанного) материала обнаружил следующее: где-то до 30-ой минуты всё идёт гладко, потом изображение как-то неровно прыгает (на долю секунды, но глаз успевает заметить) - скорее всего, дроп - и после этого видео начинает отставать почти на 1 секунду.
Перед захватом надо дефрагментировать диск, чтобы видео писалось потоком. Если винт будет долго искать чистые кластеры, возможны выпадения десятков кадров.

Если поставить PCI звуковую карту (недорогую, типа Creative Vibra 4D, дороже, по-моему, нет смысла), решит ли это хоть как-то проблему дропов и качества звука?
Проблему качества звука может и решит (если кодек на материнке совсем хреновый), а проблему дропов врядли.

12. anyata, 03.08.2004 17:54
ИТОГО
1. Дропы есть и будут, а, значит, и рассинхронизация, и "проще с этим смириться ".
2. Конкретно эту задачу можно решить методом, описанным в статье.

Что-ж, будем пробовать.

13. TAB, 03.08.2004 18:09
ksv2000
Чтобы не было рассинхронизации, нужно в настройках программы захвата назначить главным аудиопоток, а видео будет привязываться к нему, и соответственно дропиться, когда надо.
Вот это весьма распространенное заблуждение. Видео не будет "дропиться". И привязываться тоже не будет. Фича Master Stream влияет всего лишь на заголовок AVI: FPS (или Sample Rate, в случае Master Video) будет установлен из расчета равной длительности потоков. Если FPS был стабильным во время захвата (дропов не было или они все были аккуратно скомпенсированы дельта-фреймами), то синхронизация будет достигнута, но при этом FPS будет нестандартным. Но как правило дропы таки есть и синхронизироать потоки с помощью Master Stream не получится - синхронными они будут только в начале и в конце клипа. Но даже если все дропы были скомпенсированы при захвате (такое возможно на оптимизированной под захват системе с дефрагментированным винтом), в дальнейшей обработке видео нестандартный FPS неудобен и может опять привести к потере синхронизации.

14. Craz, 04.08.2004 00:41
цитата:
anyata:
ИТОГО
1. Дропы есть и будут, а, значит, и рассинхронизация, и "проще с этим смириться ".
2. Конкретно эту задачу можно решить методом, описанным в статье.

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

15. anyata, 04.08.2004 12:27
В случае появления рассинхронизации только в конце сэмпла можно попробовать захватить лишний кусок, сжать (если надо), а потом его отрезать. мне пару раз помогло.
Согласен. Я об этом сразу и подумал.
Но мне непонятно следующее: если iuVCR начал показывать дропы только к концу, на 44-45 минутах, почему рассинхрон начинается с 30-й?

16. TAB, 05.08.2004 10:14
anyata
если iuVCR начал показывать дропы только к концу, на 44-45 минутах, почему рассинхрон начинается с 30-й?
"Внутренний детектор" дропов в iuVCR вычисляет их наличие по изменению FPS. И он не может определить точное место дропа, да и показывает их с некоторой задержкой.

17. Симеон, 05.08.2004 12:44
позавчера сного нехорошую кассету попробовал на iuvcr с опцией короткие сэмплы - расинхрона как и не бывало за 3 часа захвата нон-стоп, больше того после правки, удаления части видео ( в AP ) на dvd тоже синхронно

18. Eugen65, 07.08.2004 07:03
TAB
Если производить растягивание-сжатие звука, то SF лучше не использовать. У него точность выставления изменения продолжительности +-0,01%. При 3 часовом захвате это получится 1 секунда. Непозволительная ошибка... WaveLab это делает с точностью 0,001%, что можно считать приемлимым.

19. TAB, 07.08.2004 13:11
Eugen65
SF лучше не использовать. У него точность выставления изменения продолжительности +-0,01%
Может быть, спасибо. Я просто 3-х часовой захват не делаю, нет у меня такой необходимости. Но все же, я не уверен, что SF может так накосячить (1 сек): в Sony Time Strecth нужное время клипа указывается с точносью до миллисекунд, ты с процентами случайно не перепутал? Там же можно выбрать, как именно вводить параметры: в процентах от длительности или же указывая точное время.

20. Eugen65, 07.08.2004 15:47
TAB
цитата:
ты с процентами случайно не перепутал?
Нет, не напутал. При перемещении движка внизу видим изменяющиеся проценты, вверху длительность. Передвинь движок чуть чуть. Посмотри, какие значения времени будут при 100,01% и 100,02%. Попробуй задать длительность вручную между этими цифрами. SF ничего не скажет, но при изменении длительности свалится к ближайшему процентному значению.

21. TAB, 07.08.2004 16:42
Eugen65
У меня нет сейчас никаких трехчасовых оли около того материалов - ни аудио, ни видео. Так что достоверно проверить я не могу. Тот материал, который я в статье использовал, всего лишь 17 минут. Но на нем версия с движком не подтверждается: передвигая слайдер я пролучаю два значения - 00:17:04.435 и 00:17:04.538. Реально, задав значение 00:17:04.480 я получил WAV длительностью 00:17:04.484. Но надо отметить, что эту длительность я получил в Mode: A02. Music 2. В других режимах были другие цифры, но со значениями выдаваемыми слайдером, они не коррелировали.

22. Eugen65, 08.08.2004 12:38
Да уж... В SF6 было именно так. В SF7 ситуация ещё хуже. Взял кусок звуковой дорожки длительностью 1:53:22,912. Поигрался слайдером 100,10-100,11%. Время в этих точках получилось 1:53:29,715 и 1:53:30,395. Установил длительность на 1:53:30,0. В режиме A01 получил длительность 1:53:29,532, а в режиме A02-1:53:30,134... режим А06-1:53:30,479. Весьма странные результаты...
Для WaveLab результат всегда предсказуем - ближайшее % значение с точностью до 0,001%.

23. anyata, 26.08.2004 20:12
Давненько нас здесь не было...

Вчера проверил описанный в статье метод - действительно работает!
ТАВ,

Теперь о деталях.
Записал для теста очередную серию какого-то сериала - 46 минут.
Мне повезло - рассинхрон был, прибл. 1 секунда.
Построил график по логам VirtualVCR.
Дропы были в двух местах, а список выпавших кадров, полученный после захвата, это подтверждал: серия из 10 кадров и серия из 15.
Причем в обоих местах это были дублированные, а не выпавшие кадры. Я их и удалил в Дубе.
Затем для звука сделал stretch в WaveLab, и всё встало на место!

Кстати, заменил частоту аудио на 48KHz при захвате - звук стал намного лучше.
ksv2000, thanks!
Небольшой гул всё-равно чувствуется (а может, это мне так кажется ). В любом случае, сегодня установлю звуковую карту Creative Vibra 4D и сравню.

Это пока-что единственный проведенный мною эксперимент. Далее собираюсь проверить захват с VHS и Video8 (конечная цель: оцифровать несколько семейных кассет), где в силу вышеописанных причин должно быть больше дропов. Но, если метод работает, то всё ОК!

Кстати, вопрос о программах захвата. Влияет ли сама программа на качество захваченного материала, или совершенно неважно чем захватывать, т.к. по теории захват ведется через WDM или VFW драйвер, а программа всего-лишь получает захваченные кадры и просто пишет на диск?

ТАВ, попозже хочу задать несколько вопросов про построение графов. В принципе, график у меня получился, но я не спец по Excel и хочу уточнить кое-какие детали, но об этом в следующий раз.

24. TAB, 27.08.2004 11:32
anyata
метод - действительно работает!
Ну и отлично
Я в принципе и не сомневался, но сторонняя проверка - это всегда хорошо.

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

25. SweetLow, 27.08.2004 13:20
Идея компенсировать вручную дропы по логам - хороша. Осталось дождаться частичной автоматизации этого процесса. В принципе Excel не очень нужен - достаточно по логам взять производную от FPS и изучить точки, где она резко отличается от нуля. Это в принципе на 3 минуты работы программисту. Ну а подгонка времени аудио под стандартный FPS у видео не резанием, а растяжение/сжатием - это точно не новость

26. TAB, 27.08.2004 13:46
SweetLow
достаточно по логам взять производную от FPS и изучить точки, где она резко отличается от нуля. Это в принципе на 3 минуты работы программисту.
Согласен на все сто. Вот только я не программист, а здесь нужен фильтр к VD или AviSynth.

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

27. SweetLow, 27.08.2004 14:12
TAB
Вот только я не программист, а здесь нужен фильтр к VD или AviSynth.
Автоматически вставлять/резать ненужные кадры - слишком круто(для начала) будет, да и тяжело без башки человека принять правильное решение в ошибочной ситуации. Если устроит простой анализ - программа просматривает лог и говорит на каких кадрах потенциальные проблемы - устроит? Тогда нужен выложенный лог с проблемами (в архиве). Или не надо?
P.S. Можно попытаться автоматически скрипт дял ависинта сгенерировать, но это уж как получится.

28. TAB, 27.08.2004 14:37
SweetLow
Такая прога была бы очень полезна. У меня в Exel это занимает немного времени, но конечно раздражает вручную делать то, что легко автоматизируется. Я могу лог подготовить (старые я потер), но только в понедельник выложить смогу.

29. SweetLow, 02.09.2004 12:58
TAB
Я могу лог подготовить (старые я потер), но только в понедельник выложить смогу.
Ну и? Где обещанное

30. Симеон, 07.12.2004 06:32
TAB
могу попробовать автоматезировать процес, результаты будут avs скрипт
мат. модель только не совсем ясна, предлагаю "мылом" созвонится.

31. 11283, 07.12.2004 20:53
Симеон
Вот я и прочитал эту ветку,оказывается не я первый заикнулся про VD,к которому надо фильтр антидропный написать(какому-нибудь доброму дядьке).А у меня с синхрой всё чики-пуки,хватаю VD-ом,где ставлю галу в чекбоксе о привязке звука к видео...Virtualvcr не скачался,когда скачаю,отпишусь ...

32. Симеон, 08.12.2004 06:14
11283
хочеш я тебе его почтой ?.
у меня на cx23881 VD захватывать в полном разрешении отказывается ( не сильно и заставлял )
с дропами - мне прежде всего раздражают подергушки в dvd на месте дропов, из за чего все и начал.

Добавление от 08.12.2004 06:36:

просьба есть : вышлите мне AVdiff.txt и список дропов к нему.
( gumerov@mail.ru )

33. 11283, 08.12.2004 14:20




Симеон
хочеш я тебе его почтой Похоже что хочу...Ибо не качается он ниоткуда(кривые руки )

34. Eugen65, 08.02.2005 19:19
Ну вот, получите и отрицательный отзыв о жутком методе синхронизации. Принесли тут кассетку, нужно было на DVD загнать. А там все записи кусками, да куски ещё по 5 минут. Для захката использовал VirtualVCR. Дропов получилось море. Посмотел на статистику, всё посчитал. Отклонение получилось только 3 раза. Было 26 кадров. Подрезал я эти кадры, полный уверенности сунул это дело в Procoder. И только после кодирования обнаружил жуткий рассинхрон. Начал прыгат с ручной подгонкой. Прыгал 1,5 дня. Результат средней паршивости. И только позже вспомнил про VfW. Захватил, всё пучком. Резуме такое,"жуткий" метод не всегда работает. Не знаю, программа не то выдавала, алгоритм просчёта должен быть другой... но я получил неправильный результат. Захват под VfW всё исправил.

35. TAB, 09.02.2005 01:30
Eugen65
Не могу прокомментировать: в теории все должно получаться. Моя практика эту теорию подтверждает. Но разумеется, нет правил без исключения...

36. Chunga, 19.02.2005 01:54
TAB
Опробовавал предложенный в твоей статье метод. Мне он понравился, хотя пока в теории, поскольку "криминальных" дропов при анализе лога обннаружено не было. Все, что у меня имелись - продукт честной компенсации и ни излишков, ни недостачи кадров не было. Вопросов у меня больше по VirtualVCR
1. На моем компе прога почему-то несколько глючит. К примеру, не работает просмотр при 720*576, хотя захват идет.
2. В отличие от iuVCR, у которой внизу окна указывается начальная задержка видео относительно аудио, здесь я подобной штуки не увидел. Правильно ли я понимаю, что прога в начале захвата синхронизирует видео и аудио и задержка=0?
3. Поясните пожалуйста, чем отличаюся Dropped01и Dropped02. Первое значение у меня было равно 1, второе равно 3. При открытии в Дубе захваченного файла наблюдалось 3 D-кадра.

37. TAB, 19.02.2005 02:12
Chunga
не работает просмотр при 720*576, хотя захват идет.
Здесь от имеющегося железа зависит: нужно попробовать включить/выключить фильтр SmarTee на вкладке "View".

указывается начальная задержка видео относительно аудио
"Ajust Stream Offset" на вкладке "AV Sync"

чем отличаюся Dropped01и Dropped02
Dropped01 - дропы, сообщения о которых приходят с драйвера устройства ("железные" дропы).
Dropped02 - дропы, детектированные собственной "дрополовкой" VVCR.
Реальное количество дропов следует оценивать по Dropped02.

38. Chunga, 19.02.2005 02:41
TAB
Спасибо, просмотр запустил.

Ajust Stream Offset" на вкладке "AV Sync"
Но ведь это, насколько я понимаю, значение, которое мы можем выставить для приблизительной компенсации начального расхождения. А где прога указывает реальное начальное расхождение для конкретного случая захвата? Судя по iuVCR, начальное расхождение может быть весьма значительным и хотелось бы иметь возможность знать его значение точно. а не подбирать на глазок. Так в iuVCR я не пытаюсь компенсировать начальное расхождение при захвате, а беру реальное значение из ИНФО, и уже после захвата совмещаю начало при обработке в ависинте. Ну и звук, если требуется, в нем же потом поджимаю.

39. TAB, 19.02.2005 02:55
Chunga
Так там же есть флажок "Sync using stream offset". Оно как раз делает то, что делаешь ты: прописывает в AVI детектированную задержку потоков. Корректность этого детектирования под бальшим вапросом, но к показываемым iuVCR значениям оно относится в той же мере.

40. Chunga, 19.02.2005 03:28
TAB
Дык я ж тебя сразу про это спрашивал. Я ведь захватывал с установками, которые ты дал в статье, а там флажок выставлен. В захваченном файле я рассинхронизации в нулевой точке не узрел (да и нигде ее не было ). Ну я и заподозрил, что во всяком случае начало прога пытается синхронизировать, как и iuVCR при выставленных системных таймерах, хотя я обычно их не включаю (там тоже в ИНФО в этом случае пишется, что задержка видео равна 0). Короче, мне VirtualVCR пока нравится. Зря я на нее в соседней ветке бочки катил.

Добавление от 19.02.2005 10:42:

А есть ли возможность в VirtualVCR вручную вводить частоты каналов, а то при автонастройке не все каналы ловятся?

41. TAB, 19.02.2005 11:23
Chunga
как и iuVCR при выставленных системных таймерах
Нет, в iuVCR "системные таймеры" совсем другое делают: меняют timestamp во фреймах на значения из системного таймера. В DX 9.0 их лучше не применять, иначе дропы не будут заменяться дельтами.

Про частоты каналов не скажу - у меня тюнер отсутствует.

42. Chunga, 19.02.2005 11:48
TAB
Просто у меня при включении одного из них - сист. таймера для видео, задержка видео относительно аудио в ИНФО всегда равна нулю. И вот у меня еще какой вопрос. При захвате с видака одного и того же фрагмента через VirtualVCR и iuVCR(с включенным альт. муксером и вн. детектором FPS) вроде как получается, что iuVCR дает несколько меньше дропов, чем VirtualVCR. Почему так происходит?

Добавление от 20.02.2005 00:14:

TAB
Попробовал захватить с видика 35-мин. кусок и применить твой метод. За один раз были захвачены 30-мин. и 5-мин. клипы. Между ними, как это обычно водится на ленте, имелись помехи и пропадание сигнала. На протяжении 1-го клипа появилcя 1 дроп, как я понимаю нормально скомпенсированный. В перерыве между клипами добавилось еще 24. К примеру, фреймам 48207; 48232; 48256; 48280, относяшихся к промежутку между клипами, соответствовали дропы: 1; 6; 18; 25 и FPS: 24.99696; 24.8648; 24.28868; 24.35597. Подозрительными являются последних два значения fps, но все же они достаточно далеки от 24. Их трактовать, как 24?

43. TAB, 20.02.2005 00:20
Chunga
вроде как получается, что iuVCR дает несколько меньше дропов, чем VirtualVCR
Встроенная в iuVCR "дрополовка" имеет бОльшую погрешность, чем в VVCR, что никак не уменьшает достоинств программы: что в iuVCR, что в VVCR, индикатор дропов имеет только информативное значение и на собсно захват никакого влияния не оказывает.

44. Chunga, 20.02.2005 00:51
TAB
Т.е., если я тебя правильно понимаю, может реализовываться следующая ситуация:
VVCR - 11K, 12D, 13K, где 12D копия 11K
iuVCR - 11K, 12K, где12D просто не замечается и 13K становится 12K, и мы в iuVCR получаем рассинхрон. на длину одного кадра?
Или же в iuVCR реализуется 11K, 12K, 13K и прога просто воспринимает 12D, как 12K, а захваченный клип абсолютно аналогичен клипу, захваченному в VVCR, только при открытии iuVCR'овского клипа в Дубе будет показано на один дроп меньше, притом, что 12K является копией 11K? То есть, что означает неточность дрополовки? Выпавший кадр не замечается вообще, либо компенсационный D-фрейм воспринимается, как ключевой?

45. TAB, 20.02.2005 01:15
Chunga
Что-то я ничего не понял из твоего поста, м.б. потому что не очень трезв сейчас
В любом случае: детекторы дропов в iuVCR/VVCR имеют только информативное значение и в процессы захвата, кодирования и записи никак не вмешиваются. Т.е. существуют исключительно ради ознакомления особо любопытных видеозахватчиков
Компенсацию дропов дельта-фреймами осуществляет avimux из состава DX9, "нестандартный" avimux в iuVCR, и, дополнительную синхронизацию может обеспечивать AudioResample.ax из состава VVCR. Сами программы iuVCR/VVCR непосредственной компенсацией дропов не занимаются.
"Неточность дрополовки" в означает статистический характер индикатора дропов в iuVCR.

46. Chunga, 20.02.2005 01:27
TAB
VVCR работает со "стандартным" avimux'ом, правильно? iuVCR может работать как со "стандартным", так и с "нестандартным". Какой же avimux, на ваш взгляд, более корректно работает?

Добавление от 20.02.2005 02:02:

И еще вот какой вопрос. Везде пишут, что дропы возникают, когда не справляются либо проц., либо винчестер. С процессором понятно, кадр не успевает обрабатываться и вместо него муксер подсовывает копию предыдущего кадра, т.е. дельта-фрейм. Теперь о винчестере. В условиях, когда он под завязку заполнен и сильно фрагментирован, в захваченном файле при открытии в Дубе наблюдается большое кол-во D-кадров. Так что же получается, оцифрованные кадры винт писать не успевает, а дельта-фреймы успевает? А какая, собственно, разница, что писать? Объясните, пожалуйста. Или же винт в этой ситуации не успевает записывать в полном объеме как нормальнае кадры, так и поставляемые муксером D-кадры?


Встроенная в iuVCR "дрополовка" имеет бОльшую погрешность, чем в VVCR
Когда я писал, что при захвате с одного источника кол-во дропов в (iuVCR+альт. муксер) меньше, чем в VVCR, я ориентировался не на показания вышеупомянутых программ захвата, а на показания VirtualDub.

47. TAB, 20.02.2005 12:00
Chunga
Какой же avimux, на ваш взгляд, более корректно работает?
На мой взгляд стандартный, т.к. у него не возникает проблем с Huffyuv
Но стандартный avimux стал корректно обрабатывать дропы начиная с девятой версии DirectX.

кадры винт писать не успевает, а дельта-фреймы успевает?
Боюсь соврать, но ИМХО дельта-фрейм не является полноценным кадром, в данном случае это что-то вроде линка.

48. Chunga, 22.02.2005 15:00
Любопытная штука получается. Оцифровал через TV-тюнер и iuVCR фагмент с видика. Прога показала, что начальное расхождение видео и аудио равно 98ms.Тот же самый фрагмент оцифровал через цифр. камеру (1394+сценалайзер). Сравнил в SoundForge оба захваченных куска, разумеется предварительно сделав так, чтобы клипы начинались с одного кадра. Оказалось, что для того, чтобы совместить в начальный момент аудиодорожки, нужно у клипа, захваченного в iuVCR, выставить начальное расхождение не 98ms, а всего лишь 27ms. Вот и вопрос, кто врет? То ли iuVCR нельзя верить, то ли у клипа, захваченного по 1394, нельзя считать начальное расхождение равным нулю, то ли вообще верить никому нельзя.

49. Рыба-кит, 07.07.2005 13:32
Chunga
то ли вообще верить никому нельзя.
скорее всего - это как можно измерять начальное расхождение захвата, если у тебя нет девайса, который выдаст эталонный сигнал? Но вообще, камере я бы доверял больше - ИМХО если у нее и гуляет смещение, то не сильно

50. AzikAtom, 11.07.2005 17:02
Chunga
Так что же получается, оцифрованные кадры винт писать не успевает, а дельта-фреймы успевает? А какая, собственно, разница, что писать?
дельта-фрейм на самом деле пустой, и имеет размер 0 байт (без учета заголовка в 8 байт в avi), просто прежняя картинка не обновляется.

51. Chunga, 11.07.2005 17:52
AzikAtom
дельта-фрейм на самом деле пустой
Ну, что [D]-кадр пустой, я уже понял. Дело-то давно было. С тех пор мы чуток спрогрессировали. В частности, благодаря TABу и тебе.
Кстати, чтобы не было путаница в терминологии. По-моему, я неправильно давеча обозвал D-кадры (dropped frame) дельта-фреймами. Если следовать терминологии Дуба, то при открыти в нем DivX, дельта-фреймами являются все "вычисленные" кадры, т.е. все кроме ключевых [K] и дропов [D]. Их (AVI delta frame) Дуб обозначает, как пустоту в квадратных скобках - [].
.

52. AzikAtom, 11.07.2005 22:13
Chunga
неправильно давеча обозвал D-кадры (dropped frame) дельта-фреймами
Да, действительно. Я тоже сразу не сообразил

53. Симеон, 12.07.2005 05:42
как на счет VD версии 1.68 в режиме захвата ? он уже wdm дрова держит.

54. TAB, 12.07.2005 11:29
Симеон
как на счет VD версии 1.68 в режиме захвата ?
Очень хорошо. В работе удобна, рассинхрон устраняет. На офсайте уже v.1.6.9

55. borispr, 12.07.2005 16:19
Кстати этот жуткий метод использовался еще в году так 99-м
Я даже писал программу, которая могла сжимать/растягивать звук. Задавалась требуемая длина в сэмплах и готово.

56. Eugen65, 12.07.2005 17:14
TAB
цитата:
В работе удобна, рассинхрон устраняет. На офсайте уже v.1.6.9

Только сам по себе на ровном месте дропы ставит. Похоже, какой-то кривенький DS прикрутили, а движок остался от VfW. Там именно так и работало.

57. Chunga, 12.07.2005 17:36
Eugen65
Только сам по себе на ровном месте дропы ставит
На ровном месте он, по-моему, ставит только первые два (иногда один) дропа, которые выскакивают в самом начале. Все остальные дропы идут в полном соответствии с логом, т.е. там, где они нужны. Разумеется, в свойстах системы - параметры - быстродействие нужно выставить максимальное быстродействие, иначе валится много дропов, а уж "лишние" они или "настоящие" в этом случае - я не проверял. По крайней мере у меня так. Я хватал в новом дубе по 7 часов с эфира(в Main Concept DV) - рассинхрона нет, переключался во время захвата на пустой канал и возвращался обратно - рассинхрона нет, захватывал с самых паршивых кассет, во время захвата временами нажимал "стоп"-кадр и ускоренное воспроизведение - рассинхрона нет.

58. TAB, 12.07.2005 17:51
borispr
этот жуткий метод использовался еще в году так 99-м
Здесь суть не в звуке, а в восстановлении линейности видео.

Eugen65
Только сам по себе на ровном месте дропы ставит
Не замечал. Как уже сказал Chunga есть лишние 1-3 первых кадра. В дальнейшем все работает четко.

59. borispr, 12.07.2005 18:06
ну я вообще противник программ, которые удаляют/добавляют кадры в процессе захвата
кстати, оцифровка через камеру (ну или DV конвертер) спасает от рассинхрона при захвате видео с плохим сигналом.

60. AzikAtom, 12.07.2005 20:33
borispr
оцифровка через камеру (ну или DV конвертер) спасает от рассинхрона при захвате видео с плохим сигналом
Да, но только не у всех имеются камеры или DV конвертеры, потому и мучаемся

61. Eugen65, 12.07.2005 21:59
TAB
цитата:
Как уже сказал Chunga есть лишние 1-3 первых кадра. В дальнейшем все работает четко.
А у меня через каждые 5 минут ставит. Против VD, AVI_IO работает абсолютно без них (при качественном сигнале)

62. Chunga, 12.07.2005 23:40
Eugen65
А у меня через каждые 5 минут ставит
Ну, может быть, Дуб процессор грузит побольше, чем AVI_IO. Помнится, при захвате через Дуб семи часов эфира, у меня помимо двух левых дропов в самом начале (2-й и 3-й кадры) было еще всего лишь 2 дропа где-то в середине, причем эти D-кадры были вставлены вместо двух реально пропущенных кадров (проверял по логу). Короче, если не считать начальные дропы, новый Дуб у меня дропов дает нисколько не больше, чем iuVCR. Только у Дуба оправданность вставки дропов можно проверить по логу, а чего там iuVCR навставлял, известно лишь И.Ускову, который похоже забил на прогу, судя по частоте появления на СВОЕМ же форуме. По-моему, там давным давно за все отдувается Vladimir.

63. AzikAtom, 13.07.2005 00:58
Вопрос дропов кадров решит вставка номеров кадров прямо во входящий видеосигнал своеобразных маркеров. Примерно так, как работает телетекст. И мешать он не будет. После захвата и проверки качества захвата на предмет дропов можно залить черным 5% сверху картинки - там, где маркеры стоят. Это не будет видно, так как эта область попадает в safe area.
Идея - это хорошо. Осталось ее реализовать. Что думаете об этом?

64. Рыба-кит, 13.07.2005 01:46
AzikAtom
А чем дропнутый кадр с маркером лучше дропнутого кадра без маркера?

65. Симеон, 13.07.2005 06:01
цитата:
Рыба-кит:
AzikAtom
А чем дропнутый кадр с маркером лучше дропнутого кадра без маркера?

два кадра будут с одним маркером - дроп

Добавление от 13.07.2005 06:06:

цитата:
AzikAtom:
Вопрос дропов кадров решит вставка номеров кадров прямо во входящий видеосигнал своеобразных маркеров. Примерно так, как работает телетекст. И мешать он не будет. После захвата и проверки качества захвата на предмет дропов можно залить черным 5% сверху картинки - там, где маркеры стоят. Это не будет видно, так как эта область попадает в safe area.
Идея - это хорошо. Осталось ее реализовать. Что думаете об этом?

железку паять на основе 174ха11 + плм какую-нибудь ?
для проверки интерестно, но потом практического смысла не вижу или кто-то "детектор" "тайм кода" напишит - тогда есть смысл.

Добавление от 13.07.2005 06:07:

ALL

пришлите мне пойжалуста сылку или саму sdk для написания фильтра на avisynth.

66. AzikAtom, 13.07.2005 08:54
Рыба-кит
А чем дропнутый кадр с маркером лучше дропнутого кадра без маркера?
Определенно лучше. На кадрах будут номера, типа: 0 1 2 3 4...
При реальном дропе будет: 0 1 2 2 4...
При ложном дропе будет: 0 1 2 2 3 4...
Вот здесь и нужно будет убрать один лишний кадр. И это можно сделать автоматически.

Симеон
железку паять на основе 174ха11 + плм какую-нибудь ?
Еще надо подумать, как и на чем это делать.
для проверки интерестно, но потом практического смысла не вижу или кто-то "детектор" "тайм кода" напишит - тогда есть смысл
Почему только для проверки? Совместно со способом, описаным в Попытка решения проблемы синхронизации звука на корню - синхронизация звуковой карты с тюнером (http://forum.ixbt.com/topic.cgi?id=29:22774) , это позволит решить проблему рассинхрона. Минус - то, что нужна дополнительная железка, которую в магазине не купишь. И естественно, нужна прога, которая во всем этом будет разбираться и править видео.

67. TAB, 13.07.2005 11:35
AzikAtom
Вот здесь и нужно будет убрать один лишний кадр. И это можно сделать автоматически
Вообще-то в Дубе есть соотв. галки - всавлять дропы или не вставлять. Причем галок две - одна для добавления дропа в случаях отсутствия реального кадра в заданное время, а другая - для удаления избыточных кадров (ложных дублей). Сами дропы (точнее добавленные дубли) можно увидеть в том же Дубе и без дополнительных меток - там есть поиск соответствующий. И общее количество дублей (как и общее количество кадров вообще) можно в Дубе сразу увидеть.

68. Riki Chang, 04.12.2008 17:33
цитата:
AzikAtom:
Рыба-кит
А чем дропнутый кадр с маркером лучше дропнутого кадра без маркера?
Определенно лучше. На кадрах будут номера, типа: 0 1 2 3 4...
При реальном дропе будет: 0 1 2 2 4...
При ложном дропе будет: 0 1 2 2 3 4...
Вот здесь и нужно будет убрать один лишний кадр. И это можно сделать автоматически.
ну и как же это сделать автоматически? (и чем?)

69. TAB, 04.12.2008 20:06
Riki Chang
ну и как же это сделать автоматически? (и чем?)
VirtualDub последних версий делает это автоматически во время захвата. iuVCR последних версий также не имеет проблем с синхронизацией.



URL: http://forum.ixbt.com/topic.cgi?id=29:20089

Время GMT +03. Даты в формате dd.mm.yyyy.
Rambler's Top100