Знову про рассинхронизации звуку
Глибоко перепрошую, дана тема неодноразово піднімалася на форумі, але якогось цілісного розуміння немає.
Засмутила недавно рассинхронизация в записаному 1:30 фільмі, хоча до цього писалося нормально. Писалося в AVI M-JPEGом, "режим чергування" і "головний потік" були "None" (як рекомендувалося в допомоги), встановлені прапорці "Запис через PCI" і "Прив'язка звуку", "Високий пріоритет при записі". Форсування буферизації в пам'яті було на максимумі. При записи процесор не "перевантажувався", випадання кадрів не було. ПО і драйвера - останні. Сигнал - кабельний, тобто не надто поганий.
А я вже розслабився.
Чи можна (і треба) в режимі запису через шину виставляти "Головний потік" - Аудіо?
Потім в форумі був рада захоплювати через шину, а переглядати через шнурок, але підтвердження від Підтримки не було.
Чи допоможе це при рассинхронизации?
Якщо більш глобально, то незрозумілі принципи захоплення і причини рассинхронизации.
Наприклад, якщо захоплення по шині це "апаратні можливості" тюнера, то чому в допомоги пишеться, що тільки "знижується ймовірність рассинхронизации"? Потім, наскільки я зрозумів, галочка "Прив'язка звуку" якраз працює при втраті синхронізації джерела сигналу? Чи так це і чи варто її включати? І як, до речі, визначити, коли це спрацьовує? При будь-яких побічних звукових ефектах?
Далі незрозуміло, чому "Чергування" buffered не рекомендується використовувати при великих потоках? Навіщо взагалі потрібна буферизация, як не для великих потоків? І які проблеми при цьому можуть виникнути?
Загалом, галочки ставиш, а що відбувається не уявляєш, як сліпе кошеня тикати.
Оччень хотілося б нормальних пояснень від Підтримки з проблем захоплення в AVI і оптимальним налаштувань.
З.И.
Чи впливають на рассінхрон короткочасні завантаження процесора на 100%, якщо використовується високий пріоритет при записі і буферизація в пам'яті (за відсутності випали кадрів).
А в контейнері ASF подібні ж проблеми?
Re: Знову про рассинхронизации звуку
Наприклад, якщо захоплення по шині це "апаратні можливості" тюнера, то чому в допомоги пишеться, що тільки "знижується ймовірність рассинхронизации"?
Наскільки я розумію, причини такі:
1) частота кадрів може злегка відрізнятися від 25 кадрів в сек, тобто. наприклад 25.002 (у мене чомусь завжди так). А в заголовку АВИ програма БТВ ставить 25 рівно. При воспоізведеніі виходить рассінхрон
2) в разі випадання кадрів, (при великому завантаженні, зрив синхронізації, або там, зірки не так встали) ці кадри в авіакв файлі пропускаються, а відповідний їм звук - записується. Знову рассінхрон.
Потім, наскільки я зрозумів, галочка "Прив'язка звуку" якраз працює при втраті синхронізації джерела сигналу?
Наскільки я зрозумів, ефект виникає знову ж при частоті кадрів не рівної 25. Тобто періодично чіп / софт вирізає "зайвий" або "додає" отсутсвии фрагмент звуку. Дійсно, це злегка рятує від рассінхрон, але часто викликає звукові спецефекти - в момент "прив'язки" як будьто хтось злегка б'є в барабан, вірніше в бубон. (Нагадує улюблену всіма адміністраторами і програмістами фразу "танці з бубном").
Чи так це і чи варто її включати?
Я раніше включав, поки не помітив що це призводить до бубна.
Далі незрозуміло, чому "Чергування" buffered не рекомендується використовувати при великих потоках? Навіщо взагалі потрібна буферизация, як не для великих потоків? І які проблеми при цьому можуть виникнути?
Приєднуюся до питання
Оччень хотілося б нормальних пояснень від Підтримки з проблем захоплення в AVI і оптимальним налаштувань.
Знаю я цю підтримку. Скажуть - ми не винні, винен АВИ, захоплюйте в мпег2, АСФ, ВМВ. Хоча може вони і будуть праві.
А в контейнері ASF подібні ж проблеми?
Начебто немає. Начебто все чудово. Проблема лише з незручністю обробки записаного, хоча це напевно победіма.
Попутно хочу задати питання по цій темі САППОРТ / адміну.
Коли я роблю захоплення в авіакв я завжди отримую (з балки): 0 випадінь, середня частота кадрів - 24.998. У заголовку АВИ коштує 25 кадрів => 100% рассінхрон. У виртуал дубі я ставлю галочку "change video frame rate so audio and video lengths match". Дуб налічує частоту кадрів 25.002. При цьому рассінхрон вже немає. Прошу пояснити причини всієї цієї справи, і як з цим боротися.
Re: Знову про рассинхронизации звуку
Знаю я цю підтримку. Скажуть - ми не винні, винен АВИ, захоплюйте в мпег2, АСФ, ВМВ. Хоча може вони і будуть праві.
Шановний admin, спасибі за відповідь.
Справа в тому, що будь-яка розсудлива користувач Бехолдера не вимагатиме від розробників відповідати за "непідвладні" їм області, будь то робота чіпсета або контейнера. Хочеться отримати максимально вичерпні відповіді щодо аспектів, які знаходяться у вашій "влади". До того ж, хто краще вас може і порадити, як обійти або виправити проблеми виникають при використанні САМЕ ВАШОГО вироби (заліза + ПО). Наприклад захоплення в контейнер AVI. Так, я можу поглиблено вивчити всі проблеми пов'язані з ним і в інших місцях (чим зараз і займаюся), хоч на сайті iuvcr, хоч api подивитися. Але коли справа заходить до реальних дій (реалізації захоплення), тут вже інфа з iuvcr (наприклад) може і не допомогти, коли в справу всупают будь-які специфічні прийоми роботи (наприклад, для вирішення проблем рассинхронизации), тут допомогти можете тільки ВИ.
Тобто необхідно (на мій погляд) більш розгорнутий виклад (у порівнянні з існуючою допомогою).
Повторю, що тут хотілося б обговорити проблеми із захопленням саме в AVI TV-сигналу, з стислому вигляді звуком, через шину PCI, без дропов.
Ось для такої конкретної ситуації, я думаю, в могли б прояснити наступні моменти:
1. Захоплення звуку - через шину, прослуховування під час захоплення через шнурок. Чи вплине це якось це на сабж? Або це танець з бубном?
2. Чи правильно я зрозумів, що рассинхронизация виникає не тільки через заліза і сигналу, але і через роботу контейнера?
3. Який набір параметрів запису, як контейнера (тут - "Режим." І "Головний потік"), так і "загальних" (тут - "прив'язка.") Буде оптимальним при подальшій підстроювання частот в VDube (як писалося вище)?
3а. Тут же - хотілося б більш детального пояснення параметра "Прив'язка.", Які у нього є плюси і мінуси (крім описаних в допомоги). Хотілося б більш усвідомленого його використання (якщо вже він є).
3б. Не радять включати головний потік аудіо при записі через шину. ЧОМУ?
Допомога:
"При використанні режиму" Audio "можливо незначне відхилення середнього ЗНАЧЕННЯ частоти кадрів в ту чи іншу сторону"
навздогін:
admin:
". Він [контейнер] накопичує свою внутрішню статистику. І вийшла в результаті частоту кадрів (як правило, некруглу, наприклад 24.996) зберігає після закінчення запису в заголовку AVI-файлу"
Невірно.
Це тільки при Головному потоці - audio. При none - він при статистикою виводить дробу, а саме в заголовок він записує ціле, яке потім і "дробиться" (нами) в Dub-е. Про що і писав AlexCrush. Ні в тому, ні в іншому випадку кінцева частота не збігається з вихідною.
3в. Про злощасний buffered (та ще й більш загадковий full).
Ну зовсім не влаштовує "потужніший" опис. Типу в XP є такий корисний параметр, але включати його не варто, а то будуть проблеми. ЯКІ? З яких потоків? Потік не більше 5МБ / с (MJPEG, Q = 19,768x576).
Подивився записані файли. Скрізь запис ведеться в 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
Файл 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
Є файли з MainStream = None без рассінхрон. Поки немає файлів з MainStream = Audio з рассінхрон.
Тобто начебто MainStream = Audio рятує від проблеми. Але як то непереконливо.
Питання до саппорт:
0) Чому в балці завжди 24.998? Як це розраховано і, взагалі, чи має відношення до реальності?
1. 3) питання від r.aleks
1. Захоплення звуку - через шину, прослуховування під час захоплення через шнурок. Чи вплине це якось це на сабж? Або це танець з бубном?
Ні, не вплине. Захоплення по-любому краще робити через PCI, оскільки звукова карта (її драйвер і різні частоти оцифровки), можуть тільки погіршити розсинхронізація.
2. Чи правильно я зрозумів, що рассинхронизация виникає не тільки через заліза і сигналу, але і через роботу контейнера?
3. Який набір параметрів запису, як контейнера (тут - "Режим." І "Головний потік"), так і "загальних" (тут - "прив'язка.") Буде оптимальним при подальшій підстроювання частот в VDube (як писалося вище)?
Що стосується контейнера, то це певною мірою річ в собі. Деталі його внутрішніх алгоритмів нам не доступні. Тому тут варто потанцювати з бубном, може бути певні поєднання параметрів послаблять або погіршать розсинхронізація. Однозначно ми сказати не можемо.
3а. Тут же - хотілося б більш детального пояснення параметра "Прив'язка.", Які у нього є плюси і мінуси (крім описаних в допомоги). Хотілося б більш усвідомленого його використання (якщо вже він є).
3б. Не радять включати головний потік аудіо при записі через шину. ЧОМУ?
Ні. У потік нічого додатково не вноситься. Крім того, AVI-потік формується вже самим мультиплексором і процес цього формування нам вже не особливо доступний.
А не могли б Ви сказати, чому виходить що в лог-файлі частота кадрів - 24.998, а в заголовку файлу - РІВНЕ 25.
Шановний admin, спасибі велике за відповідь.
З шнурком зрозуміло.
Щодо прив'язки (так, це. Звуку до частоти кадрів; там іншого-то і немає). Наскільки я зрозумів, реальна частота кадрів ніколи не буває 25, тому навіть на хорошому сигналі вона буде періодично спрацьовувати? Тобто, основне її призначення для захоплення складного джерела, коли доведеться миритися з "перебудовними" шумами?
А в які моменти вона спрацьовує? Помітив, що близько одного разу на хвилину.
За останній абзац окреме спасибі.
З приводу роботи full - буферизація драйвера - це яка у віконці віодеообработка?
І що за причини призупинення надходження звукових семплів? Повинно відбутися щось страшне.
І що щодо buffered?
Скажіть, а контейнер ASF (зокрема) дійсно вирішує проблему?
А взагалі виникло дуже багато питань, але постараюся спочатку самостійно накопичити знань. Але потім все одно доведеться вас знову потурбувати.