Текущее время: 12 май 2024, 23:20 • Часовой пояс: UTC + 3 часа |
Снова о рассинхронизации звука
Автор | Сообщение |
r.aleks
|
|
Зарегистрирован: 18 фев 2006, 16:02 Сообщения: 14
|
Глубоко извиняюсь, данная тема неоднократно поднималась на форуме, но какого-то цельного понимания нет.
Огорчила недавно рассинхронизация в записанном 1:30 фильме, хотя до этого писалось нормально. Писалось в AVI M-JPEGом, "режим чередования" и "главный поток" были "None" (как рекомендовалось в помощи), установлены флажки "Запись через PCI" и "Привязка звука", "Высокий приоритет при записи". Форсирование буферизации в памяти было на максимуме. При записи процессор не "перегружался", выпадения кадров не было. ПО и драйвера - последние. Сигнал - кабельный, т.е. не очень плохой.
А я уже расслабился...
Можно ли (и надо ли) в режиме записи через шину выставлять "Главный поток" - Аудио?
Потом в форуме был совет захватывать через шину, а просматривать через шнурок, но подтверждения от Поддержки не было.
Поможет ли это при рассинхронизации?
Если более глобально, то непонятны принципы захвата и причины рассинхронизации.
Например, если захват по шине это "аппаратные способности" тюнера, то почему в помощи пишется, что только "снижается вероятность рассинхронизации"? Потом, насколько я понял, галочка "Привязка звука" как раз работает при потере синхронизации источника сигнала? Так ли это и стоит ли её включать? И как, кстати, определить, когда это срабатывает? При любых побочных звуковых эффектах?
Далее непонятно, почему "Чередование" buffered не рекомендуется использовать при больших потоках? Зачем вообще нужна буферизация, как не для больших потоков? И какие проблемы при этом могут возникнуть?
В общем, галочки ставишь, а что происходит не представляешь, как слепой котенок тыкаешься...
Оччень хотелось бы нормальных пояснений от Поддержки по проблемам захвата в AVI и оптимальным настройкам.
З.Ы.
Влияют ли на рассинхрон кратковременные загрузки процессора на 100%, если используется высокий приоритет при записи и буферизация в памяти (при отсутствии выпавших кадров).
А в контейнере ASF подобные же проблемы?
|
|
|
AlexCrush
|
|
Зарегистрирован: 02 фев 2006, 07:40 Сообщения: 276 Откуда: Екатеринбург
|
r.aleks писал(а): Например, если захват по шине это "аппаратные способности" тюнера, то почему в помощи пишется, что только "снижается вероятность рассинхронизации"? Насколько я понимаю, причины таковы: 1) частота кадров может слегка отличаться от 25 кадров в сек,т.е. например 25.002 (у меня почему то всегда так). А в заголовке АВИ программа БТВ ставит 25 ровно. При воспоизведении получается рассинхрон 2) в случае выпадения кадров, (при большой загрузке, срыв синхронизации, или там, звезды не так встали) эти кадры в ави файле пропускаются, а соответствующий им звук - записывается. Опять рассинхрон. r.aleks писал(а): Потом, насколько я понял, галочка "Привязка звука" как раз работает при потере синхронизации источника сигнала? Насколько я понял, эффект возникает опять же при частоте кадров не равной 25. Т.е. периодически чип/софт вырезает "лишний" или "добавляет" отсутсвующий фрагмент звука. Действительно, это слегка спасает от рассинхрона, но часто вызывает звуковые спецеффекты - в момент "привязки" как будьто кто-то слегка бъет в барабан, вернее в бубен. (напоминает любимую всеми админами и программерами фразу "танцы с бубном"). r.aleks писал(а): Так ли это и стоит ли её включать? Я раньше включал, пока не заметил что это приводит к бубну. r.aleks писал(а): Далее непонятно, почему "Чередование" buffered не рекомендуется использовать при больших потоках? Зачем вообще нужна буферизация, как не для больших потоков? И какие проблемы при этом могут возникнуть? Присоединяюсь к вопросу r.aleks писал(а): Оччень хотелось бы нормальных пояснений от Поддержки по проблемам захвата в AVI и оптимальным настройкам. Знаю я эту техподдержку. Скажут - мы не виноваты, виноват АВИ, захватывайте в мпег2,асф, вмв. Хотя может они и будут правы. r.aleks писал(а): А в контейнере ASF подобные же проблемы?
Вроде нет. Вроде все замечательно. Проблема лишь с неудобством обработки записанного, хотя это наверное победимо.
Попутно хочу задать вопрос по этой теме Саппорту/админу.
Когда я делаю захват в ави я всегда получаю (из лога): 0 выпадений, средняя частота кадров - 24.998. В заголовке АВИ стоит 25 кадров => 100% рассинхрон. В виртуал дубе я ставлю галочку "change video frame rate so audio and video lengths match". Дуб насчитывает частоту кадров 25.002. При этом рассинхрона уже нет. Прошу объяснить причины всего этого дела, и как с этим бороться.
|
|
|
Dimitry
|
Добавлено: 06 сен 2006, 06:56. Заголовок сообщения: |
|
|
Зарегистрирован: 31 авг 2006, 07:52 Сообщения: 9
|
Я такое заметил: когда пишу AVI (нипример divx5) со сжатым звуком (например MP3), то наблюдается рассинхронизация. а когда звук PCM несжатый, то всё нормально. Но при таком раскладе, видео и аудиопотоки по битности сопоставимы.
|
|
|
AlexCrush
|
Добавлено: 06 сен 2006, 08:04. Заголовок сообщения: |
|
|
Зарегистрирован: 02 фев 2006, 07:40 Сообщения: 276 Откуда: Екатеринбург
|
Это уже слегка другая проблема. Увы, часто рассинхрон возникает и при несжатом звуке.
P.S.А саппорт молчит, хотя тут некоторые вопросы именно им предназначены...
|
|
|
r.aleks
|
Добавлено: 06 сен 2006, 08:14. Заголовок сообщения: |
|
|
Зарегистрирован: 18 фев 2006, 16:02 Сообщения: 14
|
AlexCrush, спасибо, осталось только Поддержки дождаться. Для полного счастья.
|
|
|
Krutya
|
Добавлено: 06 сен 2006, 11:49. Заголовок сообщения: |
|
|
Зарегистрирован: 06 мар 2006, 09:19 Сообщения: 206 Откуда: Смоленск
|
AlexCrush писал(а): Увы, часто рассинхрон возникает и при несжатом звуке.
Да, у меня именно так.
Саппорт, ответьте людЯм на вопросы - прокомментируйте происходящее!
Мёртвые белки уходят на север!
AMD Ath64 3500+ Venice (939), Foxconn NF4UK8AA-8EKRS, MSI PCI-E 7600GT (256Mb), DDR400 1024Mb DUAL,
IDE 80Gb, SATA-II 250+750+2000Gb, SB Live! 5.1ch, DVD±RW PIONEER DVR-111D, InWin 350W, NEC 1970NX, M6Extra, WinXP SP3
|
|
|
Admin
|
|
Beholder | ![Аватара пользователя](./download/file.php?avatar=2.jpg) |
Зарегистрирован: 13 июл 2004, 13:23 Сообщения: 1089
|
AlexCrush писал(а): Знаю я эту техподдержку. Скажут - мы не виноваты, виноват АВИ, захватывайте в мпег2,асф, вмв. Хотя может они и будут правы.
Ваш юмор подобных ситуациях совершенно неуместен. Именно так мы и скажем. А правы мы или нет, судите сами. Этот вопрос будет добавлен в FAQ.
Небольшая рассинхронизация происходит даже при оцифровке звука чипсетом из-за работы контейнера AVI, точнее, AVI-мультиплексора, который сшивает видеоряд и звук в один файл. Во-первых, этот мультиплексор не формирует пакеты с полной привязкой звука и видео в каждом пакете. Во-вторых, он накапливает свою внутреннюю статистику, которая недоступна для контроля и анализа со стороны программного обеспечения и зависит от множества обстоятельств (например, используемых аудио и видео-кодеков), и получившуюся в результате частоту кадров (как правило, некруглую, например 24.996) сохраняет по окончании записи в заголовке AVI-файла. В результате этот файл имеет частоту кадров, не соответствующую реально необходимой скорости воспроизведения. Для того, чтобы избежать такой рассинхронизации необходимо или по окончании записи отредактировать её в видеоредакторе, выставив правильную частоту кадров в AVI-заголовке, основываясь на реальной длительности видео и звуковой дорожек, или использовать другие контейнеры, например, ASF, WMV или MPEG.
|
|
|
r.aleks
|
Добавлено: 06 сен 2006, 14:22. Заголовок сообщения: |
|
|
Зарегистрирован: 18 фев 2006, 16:02 Сообщения: 14
|
Уважаемый admin, спасибо за ответ.
Дело в том, что любой здравомыслящий пользователь Бехолдера не будет требовать от разработчиков отвечать за "неподвластные" им области, будь то работа чипсета или контейнера. Хочется получить максимально исчерпывающие ответы касательно аспектов, которые находятся в вашей "власти". К тому же, кто лучше вас может и присоветовать, как обойти или исправить проблемы возникающие при использовании ИМЕННО ВАШЕГО изделия (железа + ПО). Например захват в контейнер AVI. Да, я могу углубленно изучить все проблемы связанные с ним и в других местах (чем сейчас и занимаюсь), хоть на сайте iuvcr, хоть api посмотреть. Но когда дело заходит до реальных действий (реализации захвата), тут уже инфа с iuvcr (например) может и не помочь, когда в дело всупают какие-либо специфические приемы работы (например, для решения проблем рассинхронизации), тут помочь можете только ВЫ.
То есть необходимо (на мой взгляд) более развернутое изложение (по сравнению с существующей помощью).
Повторю, что здесь хотелось бы обсудить проблемы с захватом именно в AVI TV-сигнала, с НЕСЖАТЫМ звуком, через шину PCI, без дропов.
Вот для такой конкретной ситуации, я думаю, в могли бы прояснить следующие моменты:
1. Захват звука - через шину, прослушивание во время захвата через шнурок. Повлияет ли это как-нибудь это на сабж? Или это танец с бубном?
2. Правильно ли я понял, что рассинхронизация возникает не только из-за железа и сигнала, но и из-за работы контейнера?
3. Какой набор параметров записи, как контейнера (здесь - "Режим..." и "Главный поток"), так и "общих" (здесь - "привязка...") будет оптимальным при дальнейшей подстройке частот в VDube (как писалось выше)?
3а. Тут же - хотелось бы более детального объяснения параметра "Привязка...", какие у него есть плюсы и минусы (помимо описанных в помощи). Хотелось бы более осознанного его использования (если уж он есть ![Smile :)](./images/smilies/icon_smile.gif) ).
3б. Не советуют включать главный поток аудио при записи через шину. ПОЧЕМУ?
Помощь:
"При использовании режима "Audio" возможно незначительное отклонение среднего ЗНАЧЕНИЯ частоты кадров в ту или иную сторону"
Если из-за этого, то мы их так и так будем менять в VDube. Но наверное, он же (параметр) ещё и вносит изменения в поток видеофайла (кроме цифирки среднего значения частоты)? КАКИЕ? В контексте вышесказанного СТОИТ ИЛИ НЕ СТОИТ его включать?
+++
Вдогонку:
admin:
"...он [контейнер] накапливает свою внутреннюю статистику..., и получившуюся в результате частоту кадров (как правило, некруглую, например 24.996) сохраняет по окончании записи в заголовке AVI-файла"
Неверно.
Это только при Главном потоке - audio. При none - он при статистике выводит дроби, а как раз в заголовок он записывает целое, которое потом и "дробится" (нами) в Dub-е. О чем и писал AlexCrush. Ни в том, ни в другом случае конечная частота не совпадает с исходной.
3в. Про злосчастный buffered (да ещё и более загадочный full).
Ну совершенно не устраивает "помощное" описание. Типа в XP есть такой полезный параметр, но включать его не стоит, а то будут проблемы... КАКИЕ? С каких потоков? Поток не больше 5МБ/с (MJPEG,Q=19,768x576).
|
|
|
AlexCrush
|
|
Зарегистрирован: 02 фев 2006, 07:40 Сообщения: 276 Откуда: Екатеринбург
|
admin писал(а): получившуюся в результате частоту кадров (как правило, некруглую, например 24.996) сохраняет по окончании записи в заголовке AVI-файла. В результате этот файл имеет частоту кадров, не соответствующую реально необходимой скорости воспроизведения. Для того, чтобы избежать такой рассинхронизации необходимо или по окончании записи отредактировать её в видеоредакторе, выставив правильную частоту кадров в AVI-заголовке, основываясь на реальной длительности видео и звуковой дорожек
А не могли бы Вы сказать, почему получается что в лог-файле частота кадров - 24.998, а в заголовке файла - РОВНО 25. А чтобы не было рассинхрона - надо ставить 25.002 ? Почему так? Зачем тогда вообще в логе пишется 24.998 и что оно значит?
|
|
|
AlexCrush
|
Добавлено: 06 сен 2006, 16:07. Заголовок сообщения: |
|
|
Зарегистрирован: 02 фев 2006, 07:40 Сообщения: 276 Откуда: Екатеринбург
|
Посмотрел записанные файлы. Везде запись ведется в AVI, кодек MJPEG (19), аудио - PCM (mono,32 kHz,16bit, ч/з PCI). AVI mux interleaving..: Buffered (XP only).
Файл c AVI mux master stream: None.
Код: 13:50:21.562 Record task started success. 15:10:01.468 Record task stop. Total captured frames...: 119450 Total dropped frames....: 0 Average frame rate......: 24,998 fps Длина записи - 1 час 19 мин и 39,906 сек = 4779,906 сек. Делим кол-во кадров на длину: 24.99003. В заголовке АВИ имеем: 25.0. Длина видео: 1:19:39.0 , аудио: 1:19:38.6. Т.е. к концу файла рассинхрон составляет 0.4 сек (весьма заметно). Правильная частота кадров (по рассчетам дуба) должна быть 25.002. Файл c AVI mux master stream: Audio.Код: 21:28:35.890 Record task started success. 22:56:35.390 Record task stop. Total captured frames....: 131968 Total dropped frames...: 0 Average frame rate.....: 24,998 fps
Видим что всего запись длилась 1 час 27 мин 59,500 сек. = 5279,500 сек. Делим кол-во кадров на длительность получаем 24.996306. В заголовке файла стоит 25.000. Длина аудио и видео совпадает и составляет 1:27:58.720. Все в порядке, рассинхрона нет.
Есть файлы с MainStream = None без рассинхрона. Пока нет файлов с MainStream = Audio с рассинхроном.
Т.е. вроде бы MainStream = Audio спасает от проблемы. Но как то неубедительно.
Вопросы к саппорту:
0) Почему в логе всегда 24.998? Как это рассчитано и, вообще, имеет ли отношение к реальности?
1...3) вопросы от r.aleks
|
|
|
Admin
|
Добавлено: 07 сен 2006, 11:30. Заголовок сообщения: |
|
|
Beholder | ![Аватара пользователя](./download/file.php?avatar=2.jpg) |
Зарегистрирован: 13 июл 2004, 13:23 Сообщения: 1089
|
r.aleks писал(а): 1. Захват звука - через шину, прослушивание во время захвата через шнурок. Повлияет ли это как-нибудь это на сабж? Или это танец с бубном? Нет, не повлияет. Захват по-любому лучше делать через PCI, поскольку звуковая карта (её драйвер и разные частоты оцифровки), могут только усугубить рассинхронизацию. r.aleks писал(а): 2. Правильно ли я понял, что рассинхронизация возникает не только из-за железа и сигнала, но и из-за работы контейнера? Именно так. r.aleks писал(а): 3. Какой набор параметров записи, как контейнера (здесь - "Режим..." и "Главный поток"), так и "общих" (здесь - "привязка...") будет оптимальным при дальнейшей подстройке частот в VDube (как писалось выше)? Что касается контейнера, то это в определённой степени вещь в себе. Детали его внутренних алгоритмов нам не доступны. Поэтому здесь стоит поплясать с бубном, может быть определённые сочетания параметров ослабят или усугубят рассинхронизацию. Однозначно мы сказать не можем. r.aleks писал(а): 3а. Тут же - хотелось бы более детального объяснения параметра "Привязка...", какие у него есть плюсы и минусы (помимо описанных в помощи). Хотелось бы более осознанного его использования (если уж он есть ![Smile :)](./images/smilies/icon_smile.gif) ). Вы имеете ввиду привязку звука к частоте кадров? Если да, то можно сказать следующее. На хорошем видеосигнале с эфира эту опцию лучше не использовать. Суть её заключается в том, что тактовый генератор оцифровки звука привязывается к видео-синхросигналам. Однако эта привязка имеет тот негативный момент, что в момент перестройки тактового генератора оцифровка звука сбивается. На слух это выглядит как нерегулярные щелчки или бульканья. Происходит это из-за того, что фронты синхросигналов могут слегка отклоняться во времени от своего среднестатистического значения и к этим отклонениям чипсет будет пытаться "привязаться". Этот параметр может помочь при записи кассет с видеоплеера если кассета старая, запись плохая или видеоплеер "тянет". r.aleks писал(а): 3б. Не советуют включать главный поток аудио при записи через шину. ПОЧЕМУ? Когда главный поток Аудио, мультиплексор равняет видео под звук. Это означает, что он может сделать дроп или дубликат кадра. При записи звука чипсетом, этого делать не нужно, так как потоки идут синхронно. r.aleks писал(а): Но наверное, он же (параметр) ещё и вносит изменения в поток видеофайла (кроме цифирки среднего значения частоты)? Нет. В поток ничего дополнительно не вносится. Кроме того, AVI-поток формируется уже самим мультиплексором и процесс этого формирования нам уже не особенно доступен. AlexCrush писал(а): А не могли бы Вы сказать, почему получается что в лог-файле частота кадров - 24.998, а в заголовке файла - РОВНО 25.
Программное обеспечение и AVI-мультиплексор раздельно считают статистику. Статистика мультиплексора не доступна ПО. А в лог пишется именно статистика накопленная ПО. По поводу разницы. Всё зависит от того, как считать и на что опираться при счёте. Есть два фактора вносящие отклонения в частоту кадров. 1) Момент старта работы графа. Драйвер выдаёт кадр по его полной оцифровке. Звуковой поток начинает оцифровываться независимо от момента старта кадра, таким образом разница в длительности уже присутствует по определению. AVI-мультиплексор же рассчитывает время по старту графа. 2) Частота оцифровки звука не может иметь всегда в точности одинаковую соотношение с частотой оцифровки видео. Неизбежно возникает разница из-за отклонения частоты кварцевого генератора и из-за отклонения реальной частоты видеопотока от 25 кадров в секунду (а кто сказал, что телевидение вещает ровно 25, а не 24.99?).
Режим INTERLEAVE = NONE это предельно простое мультиплексирование по принципу кто первым пришел, тот и будет записан в поток. Оно максимально безопасно, так как мультиплексор не ожидает какой-то из потоков а просто непрерывно кладет семплы в файл в порядке их поступления.
В режиме INTERLEAVE = FULL, мультиплексор сплетает потоки очень строго, но время от времени блокируя потоки. Cтрого – значит в строгой последовательности, например на каждый кадр – 2 звуковых чанка. Все зависит от длины звукового семпла. INTERLEAVE = FULL более правильный с точки зрения структуры AVI потока, но в этом режиме важна буферизация драйвера, так как пока мультиплексор ожидает, драйвер должен иметь свободные буфера, чтобы сохранять поступающие данные. INTERLEAVE = NONE – максимально безопасно для живого потока. Если по какой-то причине в режиме INTERLEAVE = FULL мы приостановим поступление звуковых семплов, мультиплексор заблокирует видеопоток и драйвер исчерпая буферизацию, начнет пропускать какдры.
|
|
|
r.aleks
|
Добавлено: 07 сен 2006, 13:26. Заголовок сообщения: |
|
|
Зарегистрирован: 18 фев 2006, 16:02 Сообщения: 14
|
Уважаемый admin, спасибо большое за ответ.
Со шнурком понятно.
Насчет привязки (да, это ...звука к частоте кадров; там другого-то и нет). Насколько я понял, реальная частота кадров никогда не бывает 25, поэтому даже на хорошем сигнале она будет периодически срабатывать? То есть, основное её предназначение для захвата сложного источника, когда придется мириться с "перестроечными" шумами?
А в какие моменты она срабатывает? Заметил, что около раза в минуту.
За последний абзац отдельное спасибо.
По поводу работы full - буферизация драйвера - это которая в окошке виодеообработка?
И что за причины приостановления поступления звуковых семплов? Должно произойти что-то страшное...
И что насчет buffered?
Скажите, а контейнер ASF (в частности) действительно решает проблему?
А вообще возникло очень много вопросов, но постараюсь сначала самостоятельно поднакопить знаний. Но потом все равно придется вас опять побеспокоить. ![Wink ;-)](./images/smilies/icon_wink.gif)
|
|
|
Support
|
Добавлено: 07 сен 2006, 16:09. Заголовок сообщения: |
|
|
Beholder | ![Аватара пользователя](./download/file.php?avatar=4.jpg) |
Зарегистрирован: 19 авг 2004, 11:45 Сообщения: 616
|
r.aleks писал(а): А в какие моменты она срабатывает? Например, при откровенном срыве синхронизации на старых видеолентах, на стыках между фрагментами видеозаписи, в моменты вставки региональными ТВ-компаниями собственных рекламных блоков в программы государственного вещания. r.aleks писал(а): По поводу работы full - буферизация драйвера - это которая в окошке виодеообработка? Да. r.aleks писал(а): И что за причины приостановления поступления звуковых семплов? Должно произойти что-то страшное... В многозадачной операционной системе временная приостановка работы разных процессов, потоков данных и пр. – обычное явление. Всё это так или иначе учитывается в медиаприложениях. Пример тому – режим INTERLEAVE = FULL. r.aleks писал(а): И что насчет buffered? Buffered (XP only) – режим, эквивалентный режиму «None», с той разницей, что данные при записи в файл предварительно буферизуются в памяти. Это снижает нагрузку на дисковую систему за счёт уменьшения количества обращений к накопителю. Режим доступен в XP и более старших версиях операционных систем. r.aleks писал(а): Скажите, а контейнер ASF (в частности) действительно решает проблему?
Подобных проблем с ним пока не замечено.
|
|
|
r.aleks
|
Добавлено: 08 сен 2006, 13:31. Заголовок сообщения: |
|
|
Зарегистрирован: 18 фев 2006, 16:02 Сообщения: 14
|
Поддержка, спасибо за ответ!
Еще вопросы.
Захватил 3-часовой AVI, MJPEG,
звук PCM, привязку отключил, главный поток=none, чередование=full. Dropped frames=9 (0 in AVI codec).
В заголовке (из VDuba) длительности видео и аудио совпадают с точностью до секунды (видео - .40, аудио - .76), видимого (по губам) рассинхрона нет.
Вопрос в следующем в GSpot у файла в контейнере строки:
Size: 9.36 GB (or 9,594 MB or 9,825,018 KB or 10,060,818,572 bytes)
Container:
260005 frames in first part, 5 frames follow (в Dube показана длина видео как 260010)
Garbage at end
Габидж был и вчера, когда хватал на FAT32, до упора заполнив положенный размер, запись остановилась сама. А сегодня запись была завершена корректно.
В каких случаях появляется подобная надпись? (Когда нормально - тогда Container: File length correct).
И потом, выходит вы используете (или API) Multipart OpenDML AVI (инфо из GSpot тоже), а там вроде бы какие-то дополнения для улучшения синхронизации? Или это вам неподвластно?
По поводу дропов:
admin:
"
Если по какой-то причине в режиме INTERLEAVE = FULL мы приостановим поступление звуковых семплов, мультиплексор заблокирует видеопоток и драйвер исчерпая буферизацию, начнет пропускать кадры."
При этом эти дропы будут фигурировать в логе не как дропы AVI кодека (0 in AVI codec)?
И еще - при этом помимо пропуска кадров будет также приостанавливаться и звуковой поток? То есть синхронизация будет (кадры будут дропаться, пока мультиплексор не разблокирует видеопоток)? (см. вашу цитату выше)
И как вообще определять причины дропов (исключая опять загрузки проца)? Например, в режиме none дропы будут только из-за загрузки, а в режиме full - ещё и из-за работы мультиплексора? Ну и ещё глюки в драйвере?
Спасибо.
|
|
|
Support
|
Добавлено: 08 сен 2006, 15:42. Заголовок сообщения: |
|
|
Beholder | ![Аватара пользователя](./download/file.php?avatar=4.jpg) |
Зарегистрирован: 19 авг 2004, 11:45 Сообщения: 616
|
r.aleks писал(а): Garbage at end В каких случаях появляется подобная надпись? Если запись была остановлена корректно (руками или автоматом), значит мусорит AVI Mux. r.aleks писал(а): И потом, выходит вы используете (или API) Multipart OpenDML AVI (инфо из GSpot тоже), а там вроде бы какие-то дополнения для улучшения синхронизации? Или это вам неподвластно? Мы используем только MS AVI. r.aleks писал(а): "Если по какой-то причине в режиме INTERLEAVE = FULL мы приостановим поступление звуковых семплов, мультиплексор заблокирует видеопоток и драйвер исчерпая буферизацию, начнет пропускать кадры."
При этом эти дропы будут фигурировать в логе не как дропы AVI кодека (0 in AVI codec)? Как потери кадров в драйвере. r.aleks писал(а): То есть синхронизация будет (кадры будут дропаться, пока мультиплексор не разблокирует видеопоток)? Да, кадры будут теряться, пока поток не будет разблокирован. Наш драйвер буферизирует по умолчанию 20 кадров, причем можно установить через ПО большее значение. Устанавливать больше 50 не рекомендуется, так как ведет к дефициту несвопируемой памяти. 50 кадров – это 2 сек. Трудно представить, чтобы конвейер был приостановлен на такое длительное время. В штатных ситуациях задержки в AVI Mux в режиме Full вполне разумные. r.aleks писал(а): И как вообще определять причины дропов (исключая опять загрузки проца)?
Нетривиальная задача. Если бы причины дропов так легко выявлялись, о них бы не говорили столько времени, сколько существует мультимедиа и запись на компьютере.
|
|
|
Кто сейчас на конференции |
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 55 |
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
|
|