Рассинхронизация звука и видео, теория или практика? (+)
Версия для печати (стр. 1)

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

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

Страницы: 1 2 · далее / все сообщения темы на одной странице

OGC, 19.06.2001 02:33
После победы над видео захватом (VHS->AverMedia->AVI@RGB24->SVCD) наступил на очередную кучу дерьма под названием "Рассинхронизация звука и видео". Теоретическое обоснование этой проблемы мне совершенно не понятно.
Поиски по данной конфе дали только одно псевдо-научное объяснение, а именно: "рассогласование частот кварцев на двух независимых устройствах оцифровки звука и видео". Видимо имеется в виду уход частоты кварца (в силу разных причин) от номинальной.
Но это, по мне, так - полный бред. Если предположить, что в системе нет потерь данных, то потоки не могут разойтись, ибо цифруется ровно то, что я слышу и вижу. В следствии ухода частот кварцев могут появиться только искажения в восстановленном сигнале! Замечу, что расхождение имеет место быть уже в сыром AVI, где нет (в моём случае) никакого сжатия ни видео, ни аудио.

Возможно причиной могло бы быть выпадение кадров (Dropped Frames), но только в случае некорректной работы программы захвата, когда место пропущенного кадра занимает следующий, а не дублируется предыдущий. Не знаю страдает ли этим iuVCR. Довольно удобная, но не слишком видимо корректно работающая под W2k программа. Она "умудряется" терять кадры при полном отсутствии к тому причин. Пример: 352х576, RGB24. Скорость потока - каких-то паршивых 7.5Мб/сек. Мой комп: A7V133@150/Atlon1133@1275/RAM256Mb@150(2-2-2)/2x30Gb DTLA(Stripe). Автора?!

И теперь немного практических впросов. Что-то я не понял, есть ли собственная оцифровка звука в AverMedia Studio w/VCR или нет? Зачем там тогда аудио вход? В "мультимедиа" болтается какой-то драйвер под именем "AverMedia, WDM Audio Capture", но в качестве источника звука он ни в каких программах захвата не предлагается. Да и в "Device status" значится, что "No drivers are installed for this device"...

Thanks.

1. DJonson, 19.06.2001 08:03
Я, может, что-то не понял, но у меня в проге захвата видео есть опция- синхронизация аудио-видео . Пользуюсь Hauppage WinTV PCI/ Не фонтан- но тогда денег на лучшее не было

2. FM, 19.06.2001 11:05
OGC, можешь попробовать AVI_IO, чтобы в теорию не углубляться. Там выпадений меньше всего будет. Но если получишь "0" выпавших фреймов и рассинхронизацию звука и видео - тогда поверишь...

Практика: сохрани звук как WAV и изображение как AVI без звука, потом снова сложи вместе. Обычно помогает... Сделать это можно, например, Дубом.

3. borispr, 19.06.2001 12:09
Теория рассогласования звука. Мне так надоело объяснять причину расхождения звука, что однажды я привел следущую (как мне кажется, удачную) аналогию.
------
Представим два магнитофона - один пишет видео, другой звук. Первый час видео записывает на 100 метров пленки, второй час звука записывает на 100 м и 10 см пленки. Если потом их оба запустить на воспроизведение, первый прокрутит 100 м, второй 100.1 м и никакого расхождения не будет.
Теперь берем видеоредактор. Он знает, что на 1 час надо 100 метров пленки, на полчаса 50 и т.д. От звука он также будет отрезать куски из расчета 100 м/час Так он обе пленки покромсает, а 10 см "лишнего" звука отбросит. Потом мы начинаем воспроизводить смонтированные куски и видим, что получилось несоответствие видео и звука. Решением проблемы здесь является "сжатие" 100.1 м звуковой пленки до 100.0 м. Потом осуществляем монтаж как обычно, а после этого пропорционально "растягиваем" звуковую пленку. Теперь можно все воспроизводить от начала до конца без остановок и расхождения не будет.

4. lekx, 19.06.2001 12:30
OGC
Dropped frames, если нет background программ и дисковая система в порядке, могут появляться как раз для синхронизации звука и видео. VirtualDub во время захвата показывает частоту оцифровки звука, она никогда не равна 44100кГц, все время плавает плюс-минус 10-200. Видимо, это и есть та самая рассинхронизация кварцев. Я думаю, VD как раз дропает кадры, чтобы это компенсировать.

После того, как я поставил свежайшие драйвера для SoundMAX на Intel 815EPEA маму, добился рекорда -- 1-й дроп после 1ч10мин. До етого было ~10 дропов на час, что и так не страшно, ибо там сотни тыщ кадров

Точно слышал, что есть проблемы синхронизации у SoundBlaster-ов, тут помочь не могу, ибо не имею.

Попробуй для capture VirtualDub -- у него на сайте очень хорошее описание, с чего начинать и как добиться результата.

Кстати, он умеет самостоятельно отключать Windows Write behind cache, а это -- очень вредная штука для видеозахвата, многие другие программы сыпятся из-за нее. Про AVI-IO не знаю, до крака не добрался пока...

И еще. Если ты жмешь видео Huffyuv-ом, не надейся его воспроизводить. Если такой AVI файл играть MediaPlayer-ом, звук конкретно обгоняет видео. А при кодировании все ок, енкодеру некуда спешить

5. Ян Пофигелов, 19.06.2001 14:12
OGC
Я захватываю uiVCR и дровами Ускова в 768х576, YUY2, MJPEG-кодек PICVIDEO2, кач-во 19. Скорость потока 3-3.5 МБайт/с. Без дропов. С кодеком LOSELESS MJPEG дропы уже были, потока не помню скорость, но выше гораздо. Звук оцифровывается имхо через звуковую карту. Кстати, у кварцев частота настолько стабильная, что ни о каком колебании 10-200 Гц речи идти не может (при центральной частоте 44100 Гц). Причина отклонений частоты другая имхо.

6. A-Gugu, 19.06.2001 14:52
borispr, a pochemu zvuk zapisivaetsa na 100m i 10sm?
pochemu on toje ne pishetsa na 100m?

7. OGC, 19.06.2001 15:14
borispr
Эта аналогия (сравнение с аналоговым сигналом ) - для чайников и верна быть может только в связи с конкретным алгоритмом восстановления сигнала.
А на практике же, если рассматривать массив отсчетов в виду заданной (номинальной) частоты дескретизации, то тогда этой самой "пленки" и будет чуть-чуть меньше или больше в зависимости от ухода частоты кварца.
Но! Если принять в качестве опорной чатоту дискретизации видео сигнала (т.к. она много выше и относительная ошибка не велика) и привязывать аудио отсчеты к видео, то "пленки" будет ровно столько, сколько нужно.
Однако и в первом и во втором случае неизбежны искажения аудио сигнала, ибо мы не знаем реальной частоты кварца (или интервала между отсчетами).
Все это лишь при подходе к захвату "в лоб". А если, например, в процессе выгребания отсчетов привязываться к чему-нибудь более стабильному (как то, например, системный таймер), то можно вносить поправку и для видео и для аудио. Хотя я не совсем уверен в стабильности системного таймера, но наверное при достаточно большом интервале замеров ошибка должна быть приемлемой. В любом случае нам ведь надо компенсировать только систематическую ошибку (кварц же не "плавает" туда-сюда, а смещается например от температуры в корпусе).
Все это наводит меня на мысль, что uiVCR мало чего умеет. Остается только Dub или AVI_IO. Последнего зверя еще не пробовал. Дайте ссылку, please... Однако Dup почему-то часто ругается на Capture драйвера, что мол заняты кем-то, чего и в помине нет. К чему бы это?

DJonson
В штатах и денег нет? Ты там на вэлфоры, что ли, все покупаешь? (шутка, не обижайся!)

lekx
Frame Drops для синхронизации - это сильно! Ты это серьёзно?

Добавление от 19-06-2001 15:19:

Ян Пофигелов

Под W2K?

Чатота кварца конечно стабильна, но температурный уход может быть весьма существенным. Это надо у спецов по радиопередатчикам/приемникам спросить. У меня специальность немного другая.

8. borispr, 19.06.2001 16:27
A-Gugu
У звуковой карты свой НЕЗАВИСИМЫЙ от видео кварцевый генератор. Частота у него не "плавает" со временем, но частота этого генератор подстраивается в достаточно широком диаппазоне (потому что нельзя получить кварц с частотой строго 44100 Гц). От качества подстройки этого генератора и зависит, будет ли он выдавать в абсолютную секунду 44100 колебаний, а не 44077 или 44183 колебания.

OGC
Видно, что вы никогда не программировали временные процессы. Системный таймер СОВСЕМ не годится для таких тонких вещей.

"Но! Если принять в качестве опорной чатоту дискретизации видео сигнала (т.к. она много выше и относительная ошибка не велика)"
С чего же это она много выше?! Такой же кварцевый генератор.

"и привязывать аудио отсчеты к видео, то "пленки" будет ровно столько, сколько нужно."
Дык вот именно, привязывать! А когда захват идет например через DC10 и самостоятельную звуковую карту, то видео идет своей частотой, а звук записывается сам по себе.

9. lekx, 19.06.2001 16:52
OGC
А почему бы и нет? Предложи лучшее объяснение, почему обновление драйвера звуковухи уменьшило дропы в 10 раз, и я с ним соглашусь.

Дополнение:
Может, дело в оверклокинге? Вот выдержка из VirtualDub Knowledge Base, почти в тему :

http://www.virtualdub.org/virtualdub_kb

BUG: Audio not synchronized during capture
------------------------------------------
Symptom: VirtualDub's capture mode produces AVI files whose audio isn't synchronized with the video. Compatibility mode capture (F5) is not being used.
Cause: VirtualDub only corrects capture timing by 1ms per audio buffer. Audio blocks are always at least half a second long, so this limits VirtualDub's timing correction to 0.2%. Some video/sound card combos are off by more than this, and VirtualDub doesn't have enough +/-1ms chances to correct for it.

Note that overclocking the PCI bus can seriously exacerbate this problem.
(Thanks to Korey Atterberry for help in diagnosing this problem.)

Workaround: Capture PCM (uncompressed) audio and override the default audio buffer size in Capture > Settings; the value is in bytes. For 44KHz/16-bit/stereo, use 17640 for a 100ms block size.

10. Ян Пофигелов, 19.06.2001 17:25
OGC
Да, в Вин2000.

borispr
Кварц с частотой строго 44100 получить можно. Строго говоря, там кварц более высокочастотный, а потом частота делится.
Пример кварца для декодера PAL: 4,43хххх Гц с точностью до герц (точное значение не помню, помню, что оно с точностью до герца). Но отклонение (даже температурное) на 10 Гц даже - это для кварца нереально.

11. borispr, 19.06.2001 18:06
Ян Пофигелов
Дык все зависит от качества генератора, а не только самого кварца.

12. OGC, 19.06.2001 18:15
borispr
Да, уж... Чего не было, того не было В детстве разве только, но не серьезно и не на PC... Однако есть сомнения о совсем уж непригодности системного таймера хотя бы для оценки. Повторюсь, все зависит от интервала выборки.

"С чего же это она много выше?! Такой же кварцевый генератор"
Кварцы тоже разными бывают

"... то видео идет своей частотой, а звук записывается сам по себе"

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

lekx
Терять КАДРЫ ради синхронизации - полный идиотизм ИМХО. За такое убивать надо! Думаю все дело в W2k и присущей Билу Гейтсу лаже с прерываниями в системе. Не даром у многих звук в системе вообще глючит, особенно при ACPI. Я слышал, что серьёзные люди (и в облати каптуринга тоже) на дух этот ACPI не терпят. Я на своей AMD 761 based PC в офисе снес ACPI и Promise stripe заработал в ДВА РАЗА быстрее!!!

Спасибо за ссылку. Попробую убрать разгон и посмотрю...

13. FM, 19.06.2001 18:29
Про Дуб и Ко в плане дропов: у Дуба их больше, чем у AVI_IO, и рассинхронизация - тоже больше. AVI_IO без дропов капчурит почти всегда, а рассинхронизация - ещё реже бывает...

14. A-Gugu, 19.06.2001 20:01
2All:

а при чём тут отдельные кварцы?
ведь у ПК есть ОДИН опорный генератор, так вот почему по нему не синхронизировать всю периферию?

15. OGC, 19.06.2001 20:37
A-Gugu

Ты имеешь ввиду тот самый External Clock в биосе, который обычно и подлежит "разгону"? Ну, на него полагаться - себя не уважать! Его даже сами "мамы" слегка двигают по своим внутренним соображениям и без всякого overclocking-а.

16. Пороль, 19.06.2001 20:47
A-Gugu, в нашем случае с твоим подходом надо весь комп синхронизировать по входным кадровым и строчным синхроимпульсам

17. A-Gugu, 19.06.2001 20:57
ia je ne imel v vidu chto ispolzovat ego kak opornii generator, ia imel v vidu chtobi vse sinxronizirovalos po nemu

18. Пороль, 19.06.2001 22:20
А как ты себе представляешь синхронизацию без опорного генератора? Есть всегда опорная частота относительно которой все остальное подгоняется

19. OGC, 19.06.2001 23:37
ALL
Дык как же быть с моим вопросом об аудио входе в AverMedia? И каком-то странном драйвере для него?

20. Guest1, 20.06.2001 11:17
Рассинхронизация: в идеальном случае у меня всегда 1сек/час (~0.03%) при нуле дропов. Просто потом AVi файлу в заголовке выставляешь чуть-чуть другой fps и все OK.

21. FM, 20.06.2001 11:30
OGC, нету там аудиовхода... А драйвер этот нужен только самому Аверу, чтобы работать со звуковой картой. Если ошибаюсь, IvUs поправит.

22. Valery_t, 20.06.2001 13:31
2 Ян Пофигелов:
> Пример кварца для декодера PAL:
> 4,43хххх Гц с точностью до герц
> (точное значение не помню, помню,
> что оно с точностью до герца).
> Но отклонение (даже температурное) на
> 10 Гц даже - это для кварца нереально.
см.: http://www.qct.nl/page11.html
для информации: ppm - это "Parts Per Million", т.е. для 4.43MHz стабильность +- 220 Hz. Это стабильность хорошего кварца с хорошим генератором. А если вместо кварца взять керамику (что практикуют китайские братья), то ...
2 OGC:
> Поиски по данной конфе дали только одно псевдо-научное объяснение, а
> именно: "рассогласование частот кварцев на двух независимых устройствах
> оцифровки звука и видео". Видимо имеется в виду уход частоты кварца (в силу
> разных причин) от номинальной.
> Но это, по мне, так - полный бред. Если
> предположить, что в системе нет потерь данных, то потоки не могут разойтись, ибо
> цифруется ровно то, что я слышу и вижу.
В следствии ухода частот кварцев могут
> появиться только искажения в восстановленном сигнале! Замечу, что
> расхождение имеет место быть уже в сыром AVI, где нет (в моём случае) никакого
> сжатия ни видео, ни аудио.
Интресно что наиболее категорично о каком-либо предмете рассуждают люди, которые знают о нем совсем понаслышке, IMHO
2 ALL:
borispr весьма образно и доступно обьснил почему звук и видео разбегаются, но и это многим оказалось непонятно
Не хочу ввязываться в споры и попробую кратко обозначить свое понимание вопроса:
1. Использование различных опорных частот для системной платы, видео, аудио и проч. потребителей синхронизации будем считать аксиомой (если кто не понимает необходимость этого, дальше может не читать).
2. Если захват аудио и видео несинхронизированы между собой каким либо способом (как в мирах или DV), то _неизбежно_ рассогласование как минимум на стабильность кварца (помноженную на 1.4 - не буду обьянять почему . Это немного, но _неизбежно_! В принципе, рассогласование у Guest1, может быть обьяcнено этим фактором.
3. Некорректная работа драйверов, запрет прерываний и при этом потеря звуковых пакетов при DMA пересылках, а также дропы кадров (и неправильная их обработка) - могут "весить" для рассогласования намного больше, но это не является неизбежным

P.S. 2 OGC:
> Мой комп: A7V133@150/Atlon1133@1275/RAM256Mb@150(2-2-2)/2x30Gb DTLA(Stripe).
При таком компе не вытянуть 7.5МБ.сек !?
У меня 30МБ/сек на запись, на чтение еще выше (на "жалком" iP733).
Как говориться, hand.sys неправильно установлен

23. OGC, 20.06.2001 15:09
Valery_t
Уважаемый, если хочешь хамить - иди во флейм. Больше всего не терплю анонимного хамства.

Теперь по делу. Прежде, чем клеить ярлыки надо ВНИМАТЕЛЬНО прочитать ход дискуссии до конца, а не передергивать, манипулируя отдельными цитатами. Там и в помине нет категоричности. Может ты и не имел ввиду только меня, но написал под обращением ко мне. За сим и получите...
Я уже говорил, что объяснения borispr правомерны только в связи с конкретным алгоритмом восстановления сигналов и не могут претендовать на общность. "Профессионалу" это должно быть понятно...
Немного логики. Частота дискретизации звука (скажем 41кГц) получается путем деления рабочей частоты кварцевого генератора. т.е. в вашем примере 4.43МГц/41кГц ~ 100. Таким образом уход частоты дискретизации всего +-2.2Гц, что составляет рассинхронизацию +-0.2сек в ЧАС! Врядли это было бы так уж заметно.
Таким образом я и сейчас считаю, что объяснять рассогласование частот кварцев основной причиной - бред.
Ты и сам косвенно это подтвердил в своем 3-ем пункте. В одном из моих последних постингов я высказывал аналогичную мысль, что все дело в некоректно работающих драйверах и программах захвата под W2K. Программирование под W2K такого рода софта - дело гораздо более тонкое (в системном смысле) нежели скажем под Win9x.

>Как говориться, hand.sys неправильно установлен
Моя система скофигурирована идеально (если не считать все еще мешающегося под ногами ACPI). И цифровые показатели производительности системы (как минимум по тем, что ты привел) примерно вдвое выше... Именно при таком положении дел iuVCR теряет кадры. Примерно 60-70 на 30 минут. Кстати, учитывая, что не были известны эти последние цифры, что дало тебе право поминать hand.sys?

Добавление от 20-06-2001 15:19:

FM
Да что-то не видать его...
А этот драйвер как-то криво встал под W2K. Винды считают, что железа под него! А вот под ME он честно сел на то-же прерывание, что и Video Cature. Но на фига оно ему нужно тогда?

24. С_Г, 20.06.2001 15:50
Конечно кварцы тут нипричем.Это здесь уже много раз объяснялось.В том числе и мной.
Причина программного характера-трудности программной синхронизации в виндах,хотя есть и еще ньюансы-но они не главные.Погрешности кварцев-на последнем месте.Кварцы и звуковой платы и платы видеозахвата работают в одинаковых условиях,их температурная погрешность порядка 10-5-10-6 (желающие могут привести погрешность к 1 часу,например и если видео и звук сведены правильно при захвате-то они не расходятся при воспроизведении на разных платах,компах,процах и т.п.(Спросите у видеопиратов,делающих МП4 )

25. Valery_t, 20.06.2001 15:56
2 OGC:
Зря Вы батенька насчет моей анонимности:
valery_t@yahoo.com, valery_t@mtu-net - могу Вам и свой телефон дать. Да и на форуме меня многие знают
А насчет хамства... Так это Вы первый именно мою гипотезу насчет отклонения частот кварцов назвали "псевдонаучным обьяснением" и"бредом", когда мы обсуждали подобную тему несколько месяцев назад в компании с русским маусом, С_Г и многими другими.
Сорри, но приоритет (в оскорблениях) здесь Ваш
А за то что я забыл вставить смену обращения на ALL - мои глубочайшие извинения! Исправляю!
Теперь о цифрах...
Даже у приличного кварца есть tolerance (30-50ppm) и fr.stability (50ppm). Кварцев в оцифровке участвуют два. Итак берем эти 4-е погрешности и согласно законам математической статистики вычисляем конечную Матанализ, мат.физику и теорию статист.измерений помните ?
Цифирки стали заметно больше 0.2 сек, не правда ли? А Вы не пробовали запускать кварцы в генераторе без емкостей, про которые чаще всего китайцы забывают ?
А если перепутать кварц с керамикой ?
Секундочка на час - тут очень неплохой результат будет
А что касается hand.sys - извините если обидел, но прочитайте Ваш вводный труд - там сказано про дропы при 7.5 МБ/сек, если я правильно понимаю по русски!

Добавление от 20-06-2001 16:14:

2 С_Г:
IMHO, MPEG4 - это AVI - Audio Video Interlaced. Какие могут быть проблемы при воспроизведении правильного avi - представить трудно... Если прочитал сектор с перемешанными видео- и аудио-данными, то как можно рассинхронизироваться?
P.S. А Вашу квалификацию как специалиста в радиоэлектронике я уже оценил . На словах у Вас правда лучше все получается

26. С_Г, 20.06.2001 16:25
Valery_t
На чем же народ рассинхронизацию наблюдает- не на AVI ?
of-top
А вы уже сделали цифровой осциллоскоп с памятью 32Кх8?

27. Ян Пофигелов, 20.06.2001 16:35
Valery_t
Спасибо за объективную информацию, я несколько преувеличил достоинства кварцев. Но тем не менее, как показал OGC и подтвердил С_Г, расхождение только из-за кварцев незначительное.

Т.о., главные причины, видимо, программные.

OGC
Если есть дропы, то наверно, из-за них и расхождения?
Попробуй как я сжимать. Без дропов. У меня расхождений не возникает.

28. С_Г, 20.06.2001 16:42
Ян Пофигелов
У вас видно кварцы прецизионные,по килобаксу за штуку

29. OGC, 20.06.2001 16:44
Valery_t
OK. Примите мои извинения в свою очередь, что задел ненароком. Никак не имел ввиду кого-то конкретно, а токма чистую идею. Мой e-mail: oleg@artsoft.ru, ежели пожелаете продолжить сей офф вне рамок этой конфы.
А также, мое обращение на "ты" прошу считать применением общепринятой практики в подобных форумах. That's all.

Даже у приличного кварца есть tolerance (30-50ppm) и fr.stability (50ppm). Кварцев в оцифровке участвуют два. Итак берем эти 4-е погрешности и согласно законам математической статистики вычисляем конечную Матанализ, мат.физику и теорию статист.измерений помните ?

Как же, помню конечно! И именно с этих позиций стоило бы не смешивать в одну кучу систематическую погрешность и стохастическую (за точность терминов не ручаюсь...), ибо последняя на больших интервалах (например часа) скорее всего заметна не будет. В своем предыдущем утверждении ты вроде бы привел абсолютное значение отклонения частоты, не так ли?

"Про китайцев"
Вполне допускаю, но я имел ввиду brand name железо, пусть даже собранное в Китае...

Секундочка на час - тут очень неплохой результат будет
В моем случае речь идет о секунде на несколько минут!!! И именно поэтому я и говорю о том, что кварцы тут не при чем.
Я согласен с С_Г, руки у некоторых программеров кривые. Хорошо еще, что не у всех хватает наглости деньги за такой софт просить... Для freeware или shareware, это - нормально.

там сказано про дропы при 7.5 МБ/сек, если я правильно понимаю по русски!

Правильно-то, правильно, но контекст опять же нарушен. Там это сказано в связи с КОНКРЕТНОЙ программой. Причем тут вся система?

30. Доктор Пух, 20.06.2001 16:53
Ян Пофигелов, Валерий прав на 100%. Полная синхронизация может быть только аппаратной, но никак не программной. Если у кого-то при двух кварцах не видно рассинхронизации, то это не значит что ее нет. А чем ее меряли? На слух? Ну так это же детский сад. Она есть, только этому товарищу очень и очень повезло, что она такая маленькая и на слух не заметна. Вы возьмите двухканальный осцилограф, сделайте тестовую запись и посмотрите как оно все будет разбегаться. Даже на DC30 нет аппаратной синхронизации, я сам по наивности когда-то думал, что есть, а после нескольких случаев пришлось задуматься что происходит. К прмеру в самом начале я пробовал вводить и выводить через DC30 и SB, так расхождение достигало 0.5 сек через 20-25 минут.

31. Valery_t, 20.06.2001 16:59
2 С_Г:
Вы же уже наступали тогда на эти грабли с MPEG4! Они (пиратские MPEG4 ) делаются из VOB-файлов DVD, которые весьма квалифицировано делаются на студиях и поэтому расхожнения в них быть не может.
Пираты их не цифруют!
А что касается девайса, на который Вам не не хватило силенок, то у меня макет в основном собран и работает (пока в автономном режиме - без связи с компьютером) В виду Вашей капитуляции я не стал его делать особо срочным образом.
На борту стоит обычный SIM-30pin 4MB (более 4-х кадров) - легко записывает 14MB/sec. Для специальных задач обработки я дополнительно поставил пару 64kBx8. Логическую обвязку сделал на Altera Flex 10k.
Сорри 2 OGC, что мы с С_Г отвлеклись от темы Вашей ветки

32. С_Г, 20.06.2001 17:05
Доктор Пух
Есть такой принцип-эквивалентности аппаратных и программных средств.
Абсолютная синхронизация может быть и программной-Если делать все на АSM а не в Виндах на верхних языках На ASMe можно делать с точностью до такта процессора.В виндах ИМХО достижимый уровень милисекуны.Погрешность кварцев минимум на порядок меньше.

Или вид сбоку:
При захвате одного и тогоже эпизода с нескольких попыток рассинхра есть,а при захвате многих других,прямо тут же-нет.
Кварцы не менял

33. FM, 20.06.2001 18:49
Кстати, есть случай, когда гарантировано будет рассинхронизация. К кварцам он не относится.

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

ещё, говорят, из-за слабых синхроимпульсов от бытовых видеоустройств это бывает...

34. OGC, 20.06.2001 19:46
FM
Вот мы и добрались до места, где "собака порылась"... И это очень похоже на правду! Я ведь захватывал с CVHS кассеты, где между разными сюжетами я ВЫКЛЮЧАЛ камеру. На глаз стыки не особенно то заметны, но скорее всего разрывы в синхронизации есть.
Следовательно, это - все та же софтверная проблема.

35. DeDe, 20.06.2001 20:20
OGC
Следовательно, это - все та же софтверная проблема.
99%
pomoimy eto bred (kbarcevaya desenhronizaciya)
zvuk i video zahvativautsya paralil'no i f faile 4ereduutsya mezdu saboi'
iz etogo sleduet 4to esli uz nastol'ko plohi kvarci to bilib zbukovie provali a nekak ne raspolzanie zvuka i video
vse ostalnoe toka mosno svalit' na netravelnuyu siftoviu senhronesaziu zvuka i video
ili 4toz polu4aetsya cto 4erez 2 chasa iz za togo 4to kvarci krevie na vhohe zvuk v 2 cekundi razaitet'sya?- net!
za4it i v fail eto *dolzno* prodolsat'sya pihat'sya paralel'no

36. Доктор Пух, 20.06.2001 20:21
[С_Г]
>Есть такой принцип-эквивалентности аппаратных и программных средств

Это у наивного программиста есть такой принцип.

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

37. OGC, 20.06.2001 21:18
Доктор Пух
Учитывать это надо при сваливании в AVI! Здесь уже вопрос масштаба милисекунд (1/25 или 1/30 секунды) и значит поддается отслеживанию, опираясь на тот-же системный таймер. Я не прав?

Добавление от 20-06-2001 21:26:

С_Г
Cool! Следующую прогу захвата вы нам сваяете на ассемблере под DOS! OK?
Просто "операционную систему читать надо" (Copyright - не мой)

38. С_Г, 20.06.2001 21:27
Доктор Пух
это не у наивных программистов,а у "профессоров,что студентов учат",азам цифровой техники,а если у вас есть возражения,то плиз,в нобелевские лауреаты.


Добавление от 20-06-2001 21:35:

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

39. Z80, 20.06.2001 21:41
Очень больная для меня тема. Очень надеюсь решить её совместными усилиями. О кварцах - есть такая беда, лечится тремя способами:
1.Выключаем в дубе синхронизацию V&A, выделяем из захваченного AVI звук, растягиваем или сжимаем, доводя до длительности видео, и опять замешиваем.
2.Включаем в дубе синхронизацию V&A и он по ходу захвата удаляет добавляет пустые кадры, подгоняя длительность видео под длительность аудио.
3. Не обращаем на это дело особого внимания из-за его несущественности.
Эти проблемы у меня бывают при захвате до порога 352*288, и я пользуюсь третьим способом. В рабочем режиме 720*576 захват превращается в лотерею, при выравнивании длительностей видео и аудио в течении захваченного фрагмента есть очень некрасивое несовпадение V&A, преходящее и непредсказуемое.
AVI_IO даёт более предсказуемый результат, но сильнее дропит.
О теории. Думаю дело в неравномерности и отклонении среднего значения скорости лентопротягов пишущего и воспроизводящего устройств, деформации ленты. Идеальное согласование возможно при точном ведении входным сигналом генератора ЦАПа звуковой карты.

40. Доктор Пух, 20.06.2001 22:16
[OGG]
>и значит поддается отслеживанию, опираясь на тот-же системный таймер. Я не прав?
По теории конечно как-то можно отследить, а на практике нет. Драйвер имеет внутри очереди данных, вы обмениваетесь данными с драйвером асинхронно, что означает - у вас нет точной информации, когда кадр поступил и когда ушел. Ну и как вы будете измерять интервалы между кадрами не имея привязки кадров к системному времени?

С_Г, реальная жизнь и профессора понятия несопоставимые. В книжках давно про все прописано и все решено, на практике увы далеко не так. Научный результат профессора - написать стаью, книжку, где показать, что проблема в принципе может быть решена. Практический результат (т.е. реальная жизнь) - это то, что уже работает и что можно увидеть, пощупать руками.

41. С_Г, 20.06.2001 23:07
Доктор Пух
профессора здесь правы.
Этот принцип общий,как закон всемирного тяготения и не означает,что ВСЕ задачи,решаемые НА ДАННЫЙ МОМЕНТ аппаратно,в ДАННЫЙ МОМЕНТ решаемы программно.
То,что делалось 10 лет назад исключительно аппаратно,сейчас запросто решаются програмно.К примеру,синтез звука в реальном времени.
носительно сабжа-при быстродействии современных процов программная синхра видео и аудио в общем-то не вопрос,но,как всегда есть но...

42. Andrey_VK, 21.06.2001 00:39
Еще одна идея,по личным наблюдениям :
у меня рассинхронизация имеется при выпадении кадров не по причине слабости системы , а из-за дефектов в исходном видеосигнале ,что может быть и дефектом пленки и помехой в сигнале TV.
И если не включена опция ,как говорил DJonson, синхронизации (я её называю MasterStreamAudio - как в FlyCapture ) звуку ,пусть и жеванному и с помехами, никак не втиснуться в поток видео у которого части кадров просто нет.А вот наоборот ,беря за основной поток звук ,можно на место отсутствующих кадров дубликаты предыдущих поместить.
Ведь ,по определению, звук - это поток, а видео - набор кадров.
Выпадения по причине тормознутости проца-винта-матери-памяти и тд. и тп. одинаково дропят и видео и аудио,поэтому наблюдаются заикания,прыжки но не рассинхронизация.
Ногами не бейте ,это только мое мнение.

43. Доктор Пух, 21.06.2001 01:04
[С_Г]
>Этот принцип общий,как закон всемирного тяготения и не означает,что
>
ВСЕ задачи,решаемые НА ДАННЫЙ МОМЕНТ аппаратно,в ДАННЫЙ МОМЕНТ решаемы программно.

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

>А вот наоборот ,беря за основной поток звук ,можно на место отсутствующих
>кадров дубликаты предыдущих поместить

Да, такое возможно, если у вас есть привязка одного потока к другому, но ее этой привязки нет. Оба потока вводятся обособлено друг от друга, отсюда и проблема синхронизации. Решить ее можно только на аппаратном уровне, засинхронизировав оба потока от одного источника на уровне железа.

44. OGC, 21.06.2001 01:23
Доктор Пух
Значит С_Г прав и придется "быть ближе" к железу, подальше от мультизадачности и поближе к real-time. Сдается мне, что даже в таком гнилом железе как PC (да простят меня фаны, но со времен DEC иначе сказать не могу...) возможно решить эту задачу и по уму и программно...
Я лично - "за". FAT32 под DOS вроде бы есть, а под виндами во время каптуринга все равно не жизнь - лишний раз мышку тронуть трашно. Ну что, скинемся на конкурс?

45. Ян Пофигелов, 21.06.2001 09:11
А вот такой вопросец вскочил: тут говорили, что у профессионалов на DVD рассинхронизации нет. Но ведь при воспроизведении используются те же кварцевые генераторы, что и при записи. Почему же не возникает аппаратной рассинхронизации при воспроизведении? Или это как-то компенсируется?

46. borispr, 21.06.2001 10:10
Ян Пофигелов
Насколько я знаю, в мпег-2 предусмотрена синхронизация звука и видео. Незнаю уж как она там реализована, но можно, например, писать тайм код вместе с кадром и порцией звука и по таймкоду их сверять, что воспроизводится то, что нужно.
Кстати при воспроизведении в дивидишном плеере используется один генератор, а не два как на компе.

47. Valery_t, 21.06.2001 11:36
2 Ян Пофигелов and ALL:
Необходимо различать логику процессов записи и воспроизведения. .. Воспроизведение - это процесс целиком опирающийся на внутренние таймеры компа. Хард или CD не будут сами подваливать информацию с себя по мере надобности . Ее надо регулярно скачивать с них. Поэтому никакой рассинхронизации при воспроизведении быть не может!
В записи другой подход... Если видео - самосинхронизирующийся процесс (поступление _снаружи_кадров/полей), то звук себя никак проявить не может - надо просто хватать данные с ADC с частотой оцифровки (даже если там ничего нет - включен mute) и запихивать отчеты в файл. Вот теперь надо понять принципиальный момент (я тоже кое-что для себя по новому понял)... Для начала надо разделить мух и котлеты
Берем идеальный вариант... Дропов нет, синхры хорошие, драйвера достаточно хороши, чтобы не терять ни кадры, ни звуковые пакеты (на самом деле это бывает как ни странно ). И еще - запись идет одним блоком - целый час. ОК? Что получается?
- По видео... Теоретически, один час записи - это 3600х25 (для PAL/SECAM) кадров. Если это идет из студии, то результат будет практически именно такой. Если это с бытовой камеры, то расхождении будет плюс/минус 10-25 кадров (из-за нестабильности кварца камеры), но если мы берем с видака, то я точно не берусь назвать что выйдет . Механика лентопротяга живет по другим законам . Если представить, что скорость протяжки меняется по ходу ленты, то нетрудно догадаться, что и рассогласование может быть нелинейным (2 FM )
- Теперь звук... За час мы должны получить 3600х44100 отчетов, полученных с ADC. Их будет плюс-минус 44100x(0.4-1sec). Все верно?
Теперь не расслабляйтесь Осталось еще одно усилие, чтобы понять почему нельзя добиться совпадения этих отчетов. Если это делать в реал-тайме, опираясь на временные метки системного клока, то очевидно что надо какие-то отчеты отбрасывать (или дублировать) для видео или звука. Кто-то упомянул что специально организуются дропы кадров, что было расценено как святотатство . Но если подумать, то выбрасывание (или дублирование) звуковых отчетов еще хуже. Вы получите такие щелчки по ушам, что тошно будет !
То есть в реалтайме рассинхронизация не "лечится"! ОК?
Однако можно удтверждать что и после окончания захвата, каптурящая программа не начинает сравнивать кол-во отчетов и быстренько пережимать звук, чтобы подогнать его под видео! Так ведь!? Ни у кого ведь после нажатия ESC в конце захвата не начинает хрустеть винт перепахивая уже записаное! Так? Наиболее сообразительные (почитайте эту ветку), просто ручками сами пережимают звук и все ok-ob. Но в случае с неравномерным разбеганием это не поможет. В предыдущем обсуждении Russian Mouse сказал (возможно не точно но близко к тексту) что в профессинальных системах захвата AV потоки сопровождаются тайм-кодами. Вот тогда можно добиться настоящей синхронизации.
P.S. ГОCПОДА ! Еще раз обращаю внимание, что я говорю о небольшой рассинхронизации, вызванной отклонением частоты кварца звуковой платы от темпа поступления видео (меряется по кадрам) .
Она _небольшая_ (обычно), но она неизбежна! С кварцами с отклонением на 100ppm (вполне обычные цифры для дешевых кварцев) - это будет в пределах 1сек на 1 час записи!
Я _не_рассматриваю_ кривые драйвера, сбои синхронизации и прочая-прочая-прочая!
Это отдельная песня.
Сие уточнение г-да DeDe и С_Г могут не читать. Им это бесполезно. Первый по-видимому зашел на эту ветку похамить, второму как я заметил, нужна не логика и понимание, а возможность восстановить свою подмоченную репутацию и цепляться к чему угодно.


48. FM, 21.06.2001 12:14
Valery_t, спасибо за ценные мысли, есть над чем подумать. По поводу "хруста" после захвата - тут, наверно, ещё одна причина есть. Дуб дописывает что-то в АВИшки после окончания захвата. Если ему не дать это сделать (например, ресетом или "тремя пальцами"), то АВИшник нельзя открыть плеером, хотя заголовок в нём присутствует. При открытии же Дубом он пишет, что идёт реконструкция индексных блоков. Я не разбирался с форматом АВИ и не знаю, что это такое. Возможно, это то, о чём ты писал про "кол-во отчётов". Косвенно это подтверждается тем, что AVI_IO может захватить совсем без дропов, а потом почему-то отрепортировать их 7-8 штук на часовой фильм. И такое бывает не так уж редко.

К стати, если тот "недописанный" файл превышает 2Гб, то только первые 2Гб будут обработаны. Всё остальное улетит в мусор... Это не совсем в тему, но интересный факт.

ALL:
Значит, мы примерно установили, что рассинхронизация может быть из-за пропадания/искажения импульсов синхронизации, которые могут быть вызваны:
- слабым сигналом
- помехами
- нестабильностью лентопротяжки (???).

49. OGC, 21.06.2001 13:58
Valery_t
Сильно выступил, внушаешь!
Только вот про "щелчки" звука - не согласен. Так по варварски обращаться с отсчетами не следует. Численные алгоритмы цифровой обработки звука не так уж сложны, чтобы не реализовать их в real-time для сглаживания переходных процессов. Во всяком случае такая "подгонка" на слух будет восприниматься не хуже, чем MP3

Я все же остаюсь сторонником превращения PC в спец-процессор по захвату видео/аудио под DOS. А в интернет, тем временем, можно и с отдельно стоящего нотебука походить...

50. borispr, 21.06.2001 14:20
Valery_t
Хочу добавить некоторое уточнение по поводу звука.
После того, как у меня сгорел звуковой вход на DC30+, вынужден вводить звук через SBLive. И на 2-гиговый файл у меня получается от 0.04 до 0.12 сек лишнего звука (от 1 до 3 кадров). Чтобы не париться со сжатием звука, я просто руками в заголовке вписываю нужное число сэмплов для данного количества кадров. Потом я все это воспроизвожу через мировский звук и никаких щелчков не слышно, я специально как-то решил на это пообращать внимание. Правда исходником были фильмы, думаю на музыке это было бы заметно.

Для инфы: 2-х гиговый файл у меня около 12000 кадров

51. С_Г, 21.06.2001 14:22
Valery_t
Если в камере стоит кварц от производителя по
приведенной Вами ссылки на производителя низкопрофильных кварцев-весьма посредственных-то там погрешность 30ррм,т.е. 3х10-5,что даст погрешность за час 0.108 сек,т.е 2,6 кадра,а не 10-25 как вы пишете.,но самое смешное,что кварц камеры вообще тут ни при чем.Задача софта-правильно вычислить среднюю скорость кадров,и тогда рассогласования не будет.

ЗЫ. Хрустящий софт после esc был,но сейчас от этого уже ушли.

Пока писал-появился постинг borispr выше-тоже примерно о том же.

52. borispr, 21.06.2001 14:37
С_Г
"Задача софта-правильно вычислить среднюю скорость"
ЧУШЬ!!! Вам хоть раз встречалась авишка, в которой бы было прописано 24.745 или 25.115 кадров в секунду?! В том то и проблема, что видео захватывается вроде бы 25 к/с (и в заголовке об этом написано), а реально кадры поступают совсем не через 40 мс!

Добавление от 21-06-2001 14:39:

С_Г
У меня 1-3 кадра на 8 минут, а на час как раз и выйдет 10-25!

53. Valery_t, 21.06.2001 15:37
2 borispr:
Да бери в голову, что С_Г пишет! Ему лишь бы за что зацепиться, а истина побоку. Знал бы хоть он теорию как следует, раз с практикой у него беда...
Freq. tolerance определяет максимальный разброс частот различных кварцев при подключении их в один и тот же _настроенный_ генератор. Никаких настроенных генераторов на звуковухах нет! Пример работы ненастроенного генератора это дешевые китайские часы, которые убегают на 25-30 сек/сутки (т.е.около 1сек/час). Достаточно запаять подстроечный кондер и по хорошему частотометру (где выверенный кварц с термостабилизацией) выставить частоту, то уход уменьшается на порядок-полтора (можно полностью компенсировать этот fr. tolerance - остается только термоуход). Что 2-а десятка лет назад я делал для себя и друзей . Сейчас в _хороших_ электронных часах чаще используется цифровая коррекция хода (поправка прошивается в предустановку счетчиков) или лазерная настройка емкости генератора.
Для Вас, г-н С_Г, дам персональную ссылку. По видимому, правильный генератор Вы сделать не в состоянии - используйте готовый - типа следующего:
http://www.foxonline.com/3000.htm
Ему никаких подстроечников не надо, но отклонение будет от 100 до 200 ppm, но Вы вероятно все равно это не заметите
И ради Бога, почитайте немного теорию - хоть не будете людей в заблуждение вводить! Может быть даже поймете, что даже кварц с 30ppm можно перестоить в гораздо более широком диапазоне частот, сравнимом с разницей частот последовательного и параллельного резонанса! Однако, что-то я размечтался

Добавление от 21-06-2001 15:53:

2 OGC:
Насчет рекомпрессии звука в реалтайме...
Правильно много что можно сделать, но я как то с трудом себе представляю, что драйверописатели от производилей карт, каптурящих _видео_ будут ломать себе мозги над правильным захватом звука !
Посмотри на Асустек! Сколько он еще будет драйвера для win2k делать !?

54. Ян Пофигелов, 21.06.2001 16:39
borispr
цитата:
Вам хоть раз встречалась авишка, в которой бы было прописано 24.745 или 25.115 кадров в секунду?!

Я встречал: 24.996. Правда, это ВиртуалДуб определял. Как - не знаю.

55. borispr, 21.06.2001 17:01
Ян Пофигелов
может 23.96? Это киношная скорость, которую как правило округляют до 24, так же как и NTSC-шную 29.97 до 30

56. Valery_t, 21.06.2001 17:15
2 Ян Пофигелов:
> Я встречал: 24.996
Это не _измеренная_ скорость поступления видео. Это то что ты _задаешь_ дубу. Поставишь там 5.0000 и он будет брать лишь каждый пятый кадр - остальные мочить .
К тому же у дуба есть свои заскоки. Дашь ему 25 - он пропишет 24.996. Надо давать 25.0000 - тогда он успокоится .

57. OGC, 21.06.2001 17:28
Valery_t
Пардон, я чего-то не понял. Драйвер - вещь как правило тупая (в смысле алгоритмов сжатия) и основной задачей его является привести конкретную железку к стандартному софтовому интерфейсу (e.g. WDM). Все остальное - на совести собственно программы каптуринга (как то Дуб или iuVCR...)
Я понимаю, что универсальные драйвера к аудио карте не способствуют синхронизации, особенно в мультизадачной системе а-ля Билл Гейтс.

58. Valery_t, 21.06.2001 18:25
2 OGC:
Как я понимаю этот вопрос, это сфера компетенции все-таки именно драйверов, не тех которые занимаются сжатием и т.п. , а управлящие конкретными железками, типа аудио и каптурных плат. В каком то смысле это вещь тупая , но судя по корявости большинства из них - сложнореализуемая. IMHO, корни проблемы в разделенности видео и аудио устройств как в смысле физическом (железки), так и в софтовом (разные драйверописатели). Причем подстраиваться приходится тем, кто пишет драйверочки под видео - "аудистам" все пофигу - они как бы первичны. Ситуацию усугубляет множество приложений, живущих в компьютере (посмотрите на диспечер задач). И каждая из них стремится доказать что она более "реалтаймная" чем другая. Начиная от регенерации памяти и до видеокапчура . Короче гнилая ситуация. Зачастую при мизерной загрузке CPU, шины происходит затор между драйверами, обрабатывающими события в реальном времени. Виновато здесь плохое наследство PC-шной архитектуры и в значительно большой степени - творчество г-на Гейтса в лице Виндусов. Трудно представить более нерациональное пожирание железных ресурсов
Но если вернуться к теме рассинхронизации, то я бы как "железячник" стал решать эту проблему только со стороны интеграции аудио и видео захвата. Причем использовал бы PLL генератор, синхронизирующийся по видео и создающие из него клок для аудио ADC. Также не забывал бы про хороший буфер для накопления AV потоков. Чтобы тогда не творилось на шине и в операционной системе (кроме полного зависания), видео и адио строго синхронно записались бы на диск .
Впрочем в серьезных системах эти проблемы решают приблизительно также .
P.S. А насчет красивого ресайза звука на лету вместо тривиальных дропов (для выравнивания A&V потоков) - я бы на это особо не расчитывал
Хотя бы вставляли временные метки в эти потоки. А уж в оф-лайне потом все сами совместим

59. С_Г, 21.06.2001 18:58
borispr
Должен Вас огорчить,я никогда не видел при капчинге с аналоговой камеры 25.000 к\сек (про цифровую,здесь.есно речь не идет)
Если вы считаете,что там всегда 25.000 к\сек,то вы обречены резать\сжимать\растягивать звук и искать китайцев в кварцах.
Успехов в поисках!

60. lekx, 21.06.2001 19:12
borispr и ALL
Вот, почитайте на досуге про авишки, кадры в секунду и практическую борьбу с рассинхронизацией звука: http://www.digital-digest.com/nickyguides/audio-synch.htm

Сам я ничего такого не пробовал, но раз тот буржуй скриншотами разбрасывается, значит, должно работать. Да и вообще, сайт полезный.

61. borispr, 21.06.2001 19:54
С_Г
Ему про Фому, а он про Ярему! ВСЕ, я больше не собираюсь ничего объяснять! Я знаю как с расхождением бороться, знаю почему оно происходит и объяснять это особо упрямым не собираюсь.

62. Z80, 22.06.2001 15:13
lekx
Сенькью за ссылку. Но тому парню повезло у него стабильный Stretch и Displacement, а что делать, если аудио елозит вдоль видео по таинственному закону?
Проблема решается при захвате в MPEG2 через DirectShow, но там свои заморочки, делающие вариант неприемлимым.

63. Dmytro MD, 22.06.2001 22:17
borispr
"Задача софта-правильно вычислить среднюю скорость"
ЧУШЬ!!! Вам хоть раз встречалась авишка, в которой бы было прописано 24.745 или 25.115 кадров в секунду?! В том то и проблема, что видео захватывается вроде бы 25 к/с (и в заголовке об этом написано), а реально кадры поступают совсем не через 40 мс!

Т.е. Вы хотите сказать, что нельзя поменять в готовом AVI частоту кадров с 25.000 на реальное среднее значение по записанному участку?! Что же тогда дуб делает, когда предлагает поменять частоту кадров для согласования длины видео и аудио?

Как я понимаю суть проблемы в том, что видео всегда вводится дискретно, т.е. при любом захвате одной и той же сцены, мы всегда будем захватывать строго определенное количество кадров. При этом время самого захвата будет варьироваться. ВОТ ТУТ ПРОБЛЕМА. Звук то захватывается как непрерывный поток и карта сама его разбивает на пакеты. Таким образом для одной и той же сцены мы будем иметь одинаковое количество видео пакетов и разное (зависящее от условий воспроизведения на видео источнике) количество аудио пакетов и соответственно временная длина эпизода будет варьироваться .
Шло бы аудио блоками как видео или наоборот, было бы видео непрерывным - не надо было бы ничего синхронизировать (кроме кварцев).
Что мешает софту делающему захват, ставить метку на аудио пакете если он пришел после конца очередного поля? А дальше можно уже либо сжимать/растягивать звук по полям или подстраивать время между кадрами(полями)
А нестабильность кварцов - это предельно достежимая стабильность без покадровой синзронизации

64. Доктор Пух, 23.06.2001 00:56
>Что мешает софту делающему захват, ставить метку на аудио пакете если он
>пришел после конца очередного поля?

А как он об этом узнает?

65. marimba, 23.06.2001 01:34
А может это из-за стабильности VHS?
Кто сказал, что он делает 25кадров в секунду? А не 24.99+/-5%
(у меня есть транскодер PALxNTSC - он дает систематическое рассогласование. Наверное, потому, что для него NTSC 30fps - a для остальных 29.97)

И потом, есть ошибки округления.
Да и Виндовс - это ж не система реального времени.

Кстати, а почему программы типа DVD2AVI
дают рассогласование звука и видео? Там вообще все в цифре и не привязано к кварцам? Ошибки округления?

66. Dmytro MD, 23.06.2001 04:16
Доктор Пух
Я конечно слабо знаком с DirectX, но разве нельзя пустить поток видео через себя и аудио тоже!? Я не думаю что это сколько-нибудь серьезная проблема.
Или Вы имели что-то другое ввиду?

67. Z80, 23.06.2001 16:08
Оцифровщик видео изначально приспособлен к нестабильной синхронизации по входному сигналу, петли ФАПЧ отслеживают все мыслимые отклонения и подстраивают тактовый генератор. Для VHS надо более широкую ФАПЧ. Оцифровщик аудио изначально предназначен для работы с чисто аналоговым сигналом без всякой синхры, и у него стабильный тактовый генератор. Вот здесь собака зарыта. Программа-кэпчер в режиме синхронизации A&V, не имея возможности изменять такты аудио, реализует программную ФАПЧ путём удаления или добавления кадров в видео. Весь вопрос насколько хорошо у нее это получается. Если захватывать без синхронизации A&V, а затем выравнивать по длительности результат, то можно получить временную внутреннюю рассинхронизацию. Проблема усугубляется при работе на разрешении 720Х576 и программном сжатии, в этом случае до процессора на шине потоки данных достигают 20-25 мб/с, и возможны потери аудио, о которых в отличии от дропов видео не сообщается.Вопрос ко всем, как убедится в том, что все снятые звуковые отчёты были записаны в файл?
Факт, всё это вылезает на старых потертых кассетах, которые, к сожалению, самые ценныё.
Dmytro MD
Шло бы аудио блоками как видео
На границах полей будут фазовые скачки звука, пусть лучше аудио остается непрерывным, а корежит будем видео, тем более так уже делается PAL<>NTSC<>FILM

68. Доктор Пух, 23.06.2001 16:51
>Я конечно слабо знаком с DirectX, но разве нельзя пустить поток видео через себя и аудио тоже!?

Хоть через себя, хоть через соседа, а в драйверах нет поддержки временных меток. Даже если они были бы, то они должны ставиться относительно ОДНОГО таймера, т.е. должна быть физическая связь между аудио-железом и видео-железом от одного тактового генератора, т.е. должна быть АППАРАТНАЯ поддержка синхронизации. А что есть у вас? Есть отдельно стоящий видео захват и отдельно стоящий аудио захват. Ах у вас есть системный таймер? Ну это же смешно! Как он связан с железом ввода/вывода? Да никак. Что им можно намерять? Когда включить утюг можно определить и не более. Как правильно сказано выше - Windows это ОС не реального времени. Windows в принципе не предназначена для обработки сигналов в реальном масштабе времени. Все, что в ней сделано, все прибито гвоздями с боку и криво и по другому быть просто не может. Если вы хотите иметь настоящую синхронизацию, то купите себе плату ввода/вывода, с аппаратной синхронизацией.

69. тов. Камаринский, 23.06.2001 16:53
Конечно проблема в видео сигнале, а не в звуке. Звук пишется "опираясь" только на точный кварц аудиокарты. Видео синхронизируется с источником. Там частота всего 25(может 50Гц ). Вот там и проблема. Из своего опыта скажу, что есть определенные куски записи которые при захвате обязательно дадут "кривизну", а тут же, не меняя настроек, соседний кусок пишется на ура.

70. Доктор Пух, 23.06.2001 16:59
[Z80]
>Оцифровщик видео изначально приспособлен к нестабильной
>синхронизации по входному сигналу, петли ФАПЧ отслеживают все мыслимые
>отклонения и подстраивают тактовый генератор. Для VHS надо более широкую
>ФАПЧ. Оцифровщик аудио изначально предназначен для работы с чисто
>аналоговым сигналом без всякой синхры, и у него стабильный тактовый генератор. Вот
>здесь собака зарыта

Совершенно правильно! Вот когда вы засинхронизируете аудио-ввод от видео-синхроимпульсов, вот тогда и получите полную синхронизацию. Это можно сделать только аппаратно и только аппаратно. Правда у читателя академических книжек С_Г свое особое мнение на сей счет, но Бог с ним, пусть витает в своих академических мечтах о софтварном решении. Когда он приступит к практическим действиям он осознает свое нынешнее положение.

Добавление от 23-06-2001 17:02:

>Конечно проблема в видео сигнале, а не в звуке

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

71. OGC, 25.06.2001 14:57
Доктор Пух

Проблема в том, что один единый поток разрывают на два отдельных

Интресная мысль. Разрывают... А разве в обычном TV их не разывают? Представьте себе, что вы дублируете сигналы на PC и на TV. При просмотре на TV вы никакого расхождения не заметите, а вот в AVI оно появится. Здесь я не говорю о проблеме кварцев (возмжно, что эта проблема и не имеет софтверного решения в конфигурации PC), но о расхождении в секунду на несколько минут (будь то из-за видео синхронизации или чего-то другого). На лицо неверная модель обработки, реализованная в ПРОГРАММЕ PC по отношению к аналоговому TV (да и цифровому тоже). Главная проблема - неадекватное отображение аналогового TV-сигнала в цифровой поток. Не знаю, происходит ли это только из-за софта или чип тоже берет на себя смелость решать что-нибудь: "мол не буду всякую фигню на входе цифровать...". В последнем случае тоже есть математические методы решения, типа интерполяции. Важно, чтобы железка была адекватна реальному времени. Если нет - базар бесполезен...

72. Доктор Пух, 25.06.2001 15:09
Нет, в обычном ТВ их не разрывают. И в видаках разные выходы для видео и аудио не означает разрыва потока. По времени оба потока жестко связаны между собой. Попробуйте доказать обратное.

73. OGC, 25.06.2001 15:29
Доктор Пух
Попробуйте доказать обратное

Легко. Как только звук и видео "сняты" с ленты РАЗНЫМИ головами - они существуют раздельно и могут разойтись во времени даже в аналоговом виде на всевозможных (естественных и искуственных) линиях задержки (ревербератор на пружинках знаешь как устроен или линия задержки сигнала цветности в TV?). И наконец, я слышал, что скорость звука много меньше скорости света ( ) и чем дальше вы от телевизора, тем вам хуже...
Таким образом я и утверждаю, что подобные эффекты задержек не скомпенсированны адекватно в каптуринге на PC (не рассматривая спец. оборудования типа DC30 конечно)!

74. IvUs, 25.06.2001 16:23
Очень похоже, что никто так доконца и не представляет себе что происходит в процессе захвата. Я к сожалению до конца с этой проблемой тоже не разобрался (возможно пройдет еще год, пока до меня дойдет с такой ясностью, что можно будет расскозать об этом на форуме) но некоторое IMHO я все же вставлю :
1. О причинах рассинхронизации. Главной причиной я считаю нестабильность видеосигнала, т.к. он имеет аналоговую природу и вместе с тем дискретен - т.е. видеопоток разбивается на кадры, которые в свою очередь разбиваются на строки. Длина строк в пределах кадра имеет заметную нестабильность, Длительность кадра - тоже. Видеопоток при этом нельзя легко резать с произвольной дискретностью, как это можно делать со звуком. Софт, который думает, что в одну секунду укладывается ровно 25 кадров обламывается. Если грабить с VHS эффект более заметен, т.к. видеосигнал менее стабилен.

2. О кварцах. Все рассуждения о нестабильности кварцев, их "синхронизации", я склонен считать пустой болтовней мало относящейся к топику.

3. Компьютерных часов вполне достаточно для синхронизации звука и видео - Во всяком случае механизмы имеющиеся в DirectShow позволяют отсчитывать интервалы с точностью до 100ns.

75. Ян Пофигелов, 25.06.2001 16:37
IvUs
А каковы практические временные рассогласования в случае, например, с VHS?

76. Доктор Пух, 25.06.2001 16:44
[OGC]
А разве в обычном TV их не разывают?
Нет, не разрывают, попробуйте доказать

>Легко. Как только звук и видео "сняты" с ленты РАЗНЫМИ головами - они существуют
>раздельно и могут разойтись во времени даже в аналоговом виде на всевозможных
>(естественных и искуственных) линиях задержки (ревербератор на пружинках
>знаешь как устроен или линия задержки сигнала цветности в TV?).

Ясень пень, нет ничего идеального. Тот же фазовый сдвиг - это задержка на малую величину ну и что? Да, фаза у потоков в телевизоре может не совпадать, но скорость-то одна и та же. Покажите мне телевизор, где звук уходит от изображения через каждые 20-30 минут хотя бы на десятые доли секунды, что означает РАЗНУЮ скорость потоков.

>И наконец, я слышал, что скорость звука много меньше скорости света ( ) и чем
>дальше вы от телевизора, тем вам хуже...
Таким образом я и утверждаю, что
>подобные эффекты задержек не скомпенсированны адекватно в каптуринге
>на PC (не рассматривая спец. оборудования типа DC30 конечно)!

Это просто полный бардак

77. IvUs, 25.06.2001 17:12
цитата:
Ян Пофигелов:
IvUs
А каковы практические временные рассогласования в случае, например, с VHS?

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

Я и так со своей iuVCR уже толком ничего дома не пишу - некогда, все время уходит на программирование и отладку... ("Охотник не больше не охотится, охотник пишет книгу о теории охоты" (c) "Обыкновееное чудо")

78. borispr, 25.06.2001 18:53
Попробую еще раз обяснить с программистской точки зрения.
Итак захват видео и звука происходит двумя параллельными процессами.
Захват видео:
Имеем несколько буферов для накопления информации. Вот в один из них записался полностью кадр. Процесс накопления переходит в другой буфер, а первый в это время записываются в авишку.
Захват звука:
Так же выделяются буферы накопления. Когда буфер заполнился, то накопление переходит в другой, а готовый записывается в авишку.

Хоть AVI это и AUDIO VIDEO INTERLEAVED, потоки звука и видео совсем независимы, они только записаны с чередованием, чтобы при вычитке из файла указатель текущей позиции в файле не скакал из конца в начало (образно говоря).

Теперь ключевой момент! Если запись видео кадра это временнОй процесс (пока не появился кадровый синхроимпульс, идет запись кадра), то запись звука накопительный процесс. Скажем буфер звука расчитан на 7056 байт (это порция звука на один кадр при 16 битах стерео и частоте 44100). За какое реальное время эти 7056 байт будут накоплены, зависит от точности настройки кварца.
Если бы запись звука была точно также привязана к кадровому синхроимпульсу, то это означало бы, что остановка записи звука за текущий кадр идет не по заполнению БУФЕРА, а по реальному концу КАДРА. А уж записалось ли в буфер 7056 байт или другое количество другой вопрос.
При таком варианте захвата порция звука всегда бы была привязана к своему кадру и данной проблемы бы не было совсем.

79. -Andrew-, 25.06.2001 19:49
All
Это все замечательно, но а если все-таки "ближе к телу": как с этим бороться?

Конкретная ситуация: капчурю ДУБом в MPEG-4 с помощью DivX, low. Когда дропов немного, то особых проблем с рассинхронизацией нет. Но при одном захвате не знаю что случилось, и было потеряно на коротком временном отрезке порядка 50 кадров! При этом, ясное дело, произошел конкретный сдвиг звуковой дорожки, и клип был запорчен.

Вопрос 1: Можно ли такой клип как-то восстановить? Думаю, что сжатие-растяжение звуковой дорожки в данном случае ничего не даст. (Провал-то был локальным, а мы будем проводить коррекцию звука по ВСЕЙ длине фрагмента.) Или я не прав?

Вопрос 2: Можно ли уменьшить количество дропов уменьшением задаваемого fps? Вернее, то, что можно - это ясно, а чем это нам грозит? Насколько сильно упадет качество или еще что-то?

80. borispr, 25.06.2001 20:11
-Andrew-
Ну и какие проблемы? Режешь клип в месте, где были дропы. Во второй части сдвигаешь звук для синхронизации.

81. -Andrew-, 25.06.2001 22:55
borispr
Tanks, попробую. А что насчет вопроса #2?

82. Доктор Пух, 25.06.2001 23:22
>Можно ли уменьшить количество дропов уменьшением задаваемого fps?
Можно, меньше кадров, меньше нагрузка на РС

>а чем это нам грозит?
Дергалка будет типа мультфильма, стробоскоп, пропадает плавность движения

Зачем сразу в DivX жать? Сожми в промежуточный формат с полным числом кадров, а потом в DivX

83. OGC, 26.06.2001 01:07
IvUs
Ну наконец-то услышали голос практика! Дык объясните общественности почему модель работы iuVCR к примеру не адекватна тому же телевизору? Ведь если я вижу испорченный в смысле изображения кусок фильма (те же дропы при каптуринге), то звук идет своим чередом! Почему не соблюдать ИЗМЕРЕННУЮ (эмпирическую) частоту кадров в AVI, заполняя дропы каким-нить черным квадратом ( ) или повторением последнего хорошего? В чем проблема? Объясните "теоретикам"!
Тем более, что сообщение о 100ns в DirectShow вдохновляет (я на это в тайне надеялся)!

Доктор Пух
Не бери в голову, я местами прикалываюсь. Я лишь доказывал частное утверждение.
Главное - два колебательных процесса существуют в среде (акромя нелинейностей) независимо, ровно с момента отделения их от пленки! Ну а скорость... А если вспомнить эффект доплера? Скажем я пробегал мимо телевизора! Так, что...

84. Доктор Пух, 26.06.2001 01:25
Да что ты! Что ты! Я не беру!

85. -Andrew-, 26.06.2001 07:53
Доктор Пух
Зачем сразу в DivX жать? Сожми в промежуточный формат с полным числом кадров, а потом в DivX

Повторяю свой же постинг из другой ветки:

цитата:
Попробовал я тут два варианта:
1) Захват в MPEG-1 с достаточно высоким потоком (но все-таки таким, чтобы 1 час видео занимал <2Gb) и дальнейшее "ужатие" в MPEG-4.
2) Непосредственный захват Дубом в MPEG-4. Кодек DivX, low.
При одинаковом размере конечного файла, во втором случае качество получилось ГОРАЗДО выше. Не говоря уже об экономии времени: не требуется повторного кодирования видео - поджимаю только звук в mp3 и все.

Писать предполагается фильмы с эфира, поэтому варианты без сжатия или с малым сжатием не катят: у меня на винче всего 8Gb, а ось - Win98. Так что имеем кучу ограничений.

86. IvUs, 26.06.2001 09:57
цитата:
borispr:

Теперь ключевой момент! Если запись видео кадра это временнОй процесс (пока не появился кадровый синхроимпульс, идет запись кадра), то запись звука накопительный процесс. Скажем буфер звука расчитан на 7056 байт (это порция звука на один кадр при 16 битах стерео и частоте 44100). За какое реальное время эти 7056 байт будут накоплены, зависит от точности настройки кварца.
Если бы запись звука была точно также привязана к кадровому синхроимпульсу, то это означало бы, что остановка записи звука за текущий кадр идет не по заполнению БУФЕРА, а по реальному концу КАДРА. А уж записалось ли в буфер 7056 байт или другое количество другой вопрос.
При таком варианте захвата порция звука всегда бы была привязана к своему кадру и данной проблемы бы не было совсем.


Это уже теплее, но на самом деле все зависит от того, как AVI Writer (назовем так условно часть capture-программы, которая собственно сливает оба потока и записывает на диск) расставит в выходном файле кадры. Ничто не мешает _по окончании записи клипа_ заполнить аудио- и видеозаголовки AVI-файла так, как нам нравится, например, слегка увеличить длительность клипа, подогнав ее под звук, сделав частоту кадров не 25кадров/сек, а 24,9 кадров. Можно наоборот извратится со звуком, немного ужать или потянуть его частотой дискретизации выставив "нестандартные" 44150 или 44033Hz. Насколько я подозреваю, именно так поступает FileWriter в DirectShow, при установке MasterStream=Audio|Video.

Если сделать так, как ты предлагаешь, мы получим звуковое сопровождение с щелчками на границах кадра - звук вообще нельзя _резать_ в каком-либо виде - в этом вся и сложность.

Добавление от 26-06-2001 10:08:

цитата:
OGC:
IvUs
Ну наконец-то услышали голос практика! Дык объясните общественности почему модель работы iuVCR к примеру не адекватна тому же телевизору? Ведь если я вижу испорченный в смысле изображения кусок фильма (те же дропы при каптуринге), то звук идет своим чередом! Почему не соблюдать ИЗМЕРЕННУЮ (эмпирическую) частоту кадров в AVI, заполняя дропы каким-нить черным квадратом ( ) или повторением последнего хорошего? В чем проблема? Объясните "теоретикам"!
Тем более, что сообщение о 100ns в DirectShow вдохновляет (я на это в тайне надеялся)!


Насколько я понимаю (возможно неправильно) устройство AVI-файла и механизм его воспроизведения - нет смысла вставлять "черные квадраты", или дублировать одинаковые кадры в авишнике - это делается с помощью индексов и прочей служебной информации в заголовках. Поэтому в нормальной ситуации дропы обрабатываются плеером так:
Звук продолжает воспроизводится, а плеер просто показывает последний кадр, _ожидая_, пока настанет момент времени, соответствующий первому кадру после "дропнутого" куска. То есть синхронизация должна восстанавливаться автоматически. Если у меня будет время, я попробую немножко поэксперементировать с тем, как обстоят дела на самом деле, но уже сейчас могу высказать предположение, что некоторые кодеки плохо преспособленные для реалтайм-кодирования (такие как DivX) могут вместо "честных" дропов делать "нечестные" - т.е. капчеру сообщается, что все ОК, а на самом деле кадры выкидываются - и из-за этого такие ситуации могут отрабатываться некорректно.

87. borispr, 26.06.2001 10:33
IvUs
:кадров не 25кадров/сек, а 24,9 кадров
ага! а потом это все вывести скажем через миру на телевизор и посмотреть как он будет показывать эти 24.9 кадров в секунду!

:Можно наоборот извратится со звуком, немного ужать или потянуть его частотой дискретизации выставив "нестандартные" 44150 или 44033Hz.
И получить сообщение, что невозможно проплеить, потому что нет соответствующего кодека.

:Насколько я понимаю (возможно неправильно) устройство AVI-файла и механизм его воспроизведения
Именно неправильно! Нет там никаких индексов и служебной информации по этому поводу. Если кадр пропощен, то его место занимает следующий. И при воспроизведении между ними пустой кадр не вставит!
Выше сказанное справдливо, ТОЛЬКО если плеер не успевает выводить всю последовательность кадров. Тогда он некоторые пропускает и перепрыгивает к нужному кадру, при этом звук не прерывается

P.S.
Сколько же тут теоретиков собралось и все такие грамотные... Теперь уж я точно больше в эту тему писать не буду! Нахрен надо тратить свои силы на объяснения людям, которые не знают как все работает, но рассуждают об этом... теоретически

88. A-Gugu, 26.06.2001 11:24
borispr, любая современная видеокарта умеет плавно играть звук разных частот.

Добавление от 26-06-2001 11:24:

тфу, хотель скахать, аудиокарта

89. FM, 26.06.2001 11:55
Внимание: и Дуб, и АВИ_ИО вставляют "пустые" кадры вместо пропусков и при получении менее заданного числа кадров в секунду. АВИ_ИО может повторять предыдущий кадр. Легко убедиться, открыв такой файл в том же Дубе и посмотрев покадрово типы фреймов.

С моей точки зрения, сообщения IvUs ("Очень похоже, что никто так доконца...") и borispr ("Попробую еще раз обяснить с программистской...") наиболее близки к истине. Однако объяснения, которое подходит к случаю, когда всеми дропнутые фреймы заменены пустыми или предыдущими - пока ещё нет. Кварцы?..

90. Доктор Пух, 26.06.2001 15:14
Andrew, я прекрасно понимаю, что вы хотите "и рыбку сьесть и..." фильму записать, да только не получится с вашими запросами и на таком железе. Не вы первый, не вы последний. Купите себе последний Matrox с фичей "Цифровой видеомагнитофон" и не мучайтесь.

Добавление от 26-06-2001 15:19:

borispr, не отчаивайтесь, ламеры они такие. Иисус Христос тоже в свое время обьяснял, обьяснял ламерам, а они его за это камнями и на крест. Зато потом...

91. OGC, 26.06.2001 16:32
borispr
А Вы, уважаемый, что-нибудь руками то делали в своей жизни по данной теме? Или только ламеров поучать? Если ничего, тогда Ваш выпад выглядит довольно смешно...

All
Дайте наводочку на AVI_IO. Что-то мне сходу не удалось такого зверя живьем из инета выловить...

92. FM, 26.06.2001 17:15
AVI_IO: http://www.nct.ch/multimedia/avi_io/

93. Dmytro MD, 26.06.2001 22:15
borispr
Не стоит обращать внимания на глупости недалеких людей.
В результате всего обсуждения я пришел к выводу, что если предполагается вывод на TV в том или ином формате, то кадровая частота должна строго соответствовать стандартам ( 25 PAL, 29.*** NTSC). Значит, учитывая что нормально можно выводить звук только с определенной частотой дискретизации, нужно делать сжатие/растяжение звука в подходящих аудио редакторах.
Правильно ли это?

94. OGC, 27.06.2001 01:23
Dmytro MD,
borispr
& All

На правах инициатора данной темы призываю вас (и себя) соблюдать корректность в дискуссии. И уж во всяком случае не поливать всех (безадресно и беспредметно) грязью. Я бы хотел, чтобы здесь могли высказаться все, кто имеет что сказать по данной теме.
Ну ей богу, господа, на фоне нерешенности проблемы, отсутствия четкого и систематизированного рецепта или программного продукта, все снобистские и заносчивые заявления выглядят по меньшей мере комично!
Я уверен, что всякий из участников в чем-то своем является профессионалом и может поучить своих "ламеров". Ну давайте теперь все кинемся в программирование драйверов, программ захвата и редактирования видео... По моему глубокому убеждению, подобные форумы предназначены именно для ламеров в чем-то, желающих получить ЯСНЫЙ и ЧЕТКИЙ ответ от профессионалов. А для междусобойчика есть закрытые собрания...

95. Andrey_VK, 27.06.2001 02:08
А вот такой прикол : у нас в городе ,как впрочем и у многих, есть кабельное телевидение. И было время ,когда на канале TB-6 были невооруженным "ухом" заметны расхождения звука с изображением.Канал спутниковый и ,насколько я понимаю,в данный момент цифровой - Mpeg-2 значит. У них там явно не Mir-ы с Aver-ами стоят ,но тоже пробле-мы бывают ))

96. Доктор Пух, 27.06.2001 03:08
OGC, ламер - это не ругательство и не оскорбление, это синоним антонима к слову "профессионал".

>По моему глубокому убеждению, подобные форумы предназначены именно
>для ламеров в чем-то, желающих получить ЯСНЫЙ и ЧЕТКИЙ ответ от профессионалов

Ответ был дан, даже несколько раз (спасибо borispr за терпение и старания). Если видеолюбитель (так лучше?) не понимает его, то это проблема видеолюбителя, а не людей полно ответивших на поставленный вопрос.

Вот здесь типичная ламерская ситуация (уж простите, но по другому не могу). Ламер спрашивает, ему отвечают, а он в ответ - что ты мне за ерунду несешь? Простите, если ты все знаешь, так чего спрашиваешь? Если не знаешь - скажи спасибо за ответ или как минимум помолчи, подумай, прежде чем нести ламерскую чушь.

97. mil_alex, 27.06.2001 04:51
Господа, а вот и я Чесслово, больших трудов стоило мне дочитать досюда.

Хочу подбросить вам новую ветку для обсуждения. Допустим, мы оцифровали идеальный клип идеальными кварцами и рассогласования звука и видео на момент захвата не было. Ну, пленка там тоже супер, короче, видеосигнал как от ГСС

А теперь хочу вас спросить, особенно тех кто упоминал дробные (вещественные) числа говоря о частоте кадров. Как, по вашему, она хранится в заголовке ави файла ? Заметно, что не все в курсе

Итак, заголовок содержит два 32 разрядных целых числа, делением одного на другое получается частота, а наоборот - период, или межкадровый интервал. В идеальном случае точность такой целочисленной арифметики не превышает 1/2^32 или что-то порядка 1*10^(-9), а на практике при захвате "старыми" средствами т.е. драйверами VfW период вычисляется делением 1000000 на константу. Понятно, что точность определения периода еще ниже. Как верно заметил Иван, в новом интерфейсе (WDM aka DirectShow) используется в десять раз большая константа, 10.000.000 что дает вычислительную погрешность 1/10 микросекунды, или 100нс. Однако это не гарантирует наличия таймера, генератора или подобного механизма на системной плате или где-то в компьютере еще. В составе WinAPI (Иван, поправьте...) есть функции определения preformance, т.е. производительности типичных операций типа BitBlt (копирование блока пикселов на экран или в память), на основе которых и строится типичный тайминг программный. А аппаратное решение, как имхо вполне трезво было сказано выше, определяется стабильностью и расхождением частот кварцев. Кстати, уж до кучи, они (частоты) тоже целочисленные. Это к вопросу о том, есть там дрейф от этого или нет. Попробуйте, с бумажкой и карандашом, или калькулятором, найти общий делитель (т.е. установить кратность) частот, к примеру, 12345678 и 12346578. После этого давайте продолжим доказывать что кварцы тут не при чем...

Насчет синхронизации в популярных на рынке MP4, там же интерлив черезкадровый. А захват видео никогда не выполняется в таком режиме. Т.е. на десяток кадров видео захватывается что-то порядка 30-60 кбайт аудио (точные цифры я могу пересчитать, но долго), и там естественно речь не идет о черезкадровом интерливе. Отсюда и уходы синхро. А карточки класса DC30 (не знаю кроме нее еще...) содержат синхронный аудиоканал. Пинакл все же не дураки, да... Насчет малого расхождения аудио на клипе в 12 тысяч кадров, могу только порекомендовать захватить 180-200 тысяч кадров и сравнить результат.

не сочтите за рекламу, но на моем www.am-softhome.com можно взять попробовать утилитку для тюнинга межкадрового интервала (или частоты кадров, что то же самое) - AVIfrate. Она прояснит ряд моментов

98. Доктор Пух, 27.06.2001 05:02
>А карточки класса DC30 (не знаю кроме нее еще...) содержат синхронный аудиоканал. Пинакл все же не дураки, да...

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

Об остальном наверно в следующий раз, сейчас нет времени

99. Konstantin Shilov, 27.06.2001 05:29
To Andrew_VK, а вы случайно не из Кемерова? А то у нас эта печенюха с ТВ-6 уже почти год идет и дело тут не в спутнике и не в тюнере, а в головах и руках инженеров ТВ-6 Кемерово.
To All Сорри за оффтопик, наболело просто.

Страницы: 1 2 · далее / все сообщения темы на одной странице


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

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