Форум: ТЕХНИЧЕСКАЯ ЧАСТЬ
Тема: VirtualDubMod
автор: narsil

сообщение оставил narsil , 21 марта 2005, 22:01
Потребовалось, значит, из клипа маленький кусок вырезать. Да еще пожать его, что поменьше весил. Ну там resize/2, bitrate/8 и все такое. Вырезал, сохранил, как uncompressed RGB. При попытке его потом сжать DivX/XviD выдает вот это:
Cannot start video compression:

The source image format is not acceptable.
(Error code -2)


При попытке сохранить кусок вырезаный путём Direct stream copy DivX`ом с установленым Variable bitrate mode: Multipass, nth pass выдает вот это:
Video compression error: An unknown error occurred(may be corrupt data). (error code -100)

Исходник закоден ДивИКСом.

Хелп плизз...

сообщение оставил TVB , 21 марта 2005, 22:25
narsil
Цитата
The source image format is not acceptable.
(Error code -2)

У тебя размеры картинки делятся на 4? А то для многих кодеков необходимо, чтобы ширина и высота картинки на входе были кратны двум или четырем. А если это не выполняется, то они выдают как раз эту ошибку.

Цитата
При попытке сохранить кусок вырезаный путём Direct stream copy DivX`ом

Вообще, Direct Stream Copy - это "Прямое копирование потока", при котором пережатия видео не происходит. Но, судя по:
Цитата
Video compression error: An unknown error occurred(may be corrupt data). (error code -100)

делалось не Direct Stream Copy. Ошибка скорей всего произошла из-за того, что ты выбрал Multipass(Многопроходный) режим и начал его с n-го прохода(nth pass), не выполнив первый. Поэтому, не был создан файл с данными от первого прохода, кодек его не нашел и выдал ошибку.



сообщение оставил narsil , 21 марта 2005, 22:45
Цитата (TVB @ 21 марта 2005, 22:25)
У тебя размеры картинки делятся на 4?
нет... 320:175. Попробую поменять.
Цитата
Вообще, Direct Stream Copy - это "Прямое копирование потока"
Это я знаю. Я в смысле, что вырезал кусок этим прямым копмрованием. А потом этот вырезаный кусок попытался пожать вышеуказаным способом.

Так н-ый проход не пошел, потому что не сделан первый(нет лога). А первый не сделан, потому что размеры неправильные. Ну вроде логично. Пойду править.

2 TVB: пасиба =)



сообщение оставил narsil , 21 марта 2005, 23:12
Сделал 320:170. Все работает.
сообщение оставил Esc , 22 марта 2005, 07:12
Добавлю-ка вопрос в ФАК, который никто не читает. :biggrin:
сообщение оставил FJ , 31 марта 2005, 08:56
Извините, хотелось бы узнать: сильно ли снижается качество куска видео вырезаного VDM или VD в режиме Full processing mode (без сжатия) и если да, то насколько  режим Direct stream copy лучше.
сообщение оставил Esc , 31 марта 2005, 09:03
FJ
Если ты делаешь фулл процессинг без сжатия, то разумеется никакого ухудшения не будет. Возможно будет произведена конвертация цветового пространства, но обычно её невооружённым глазом не видно.
Вот только где ты столько места возьмёшь под несжатое видео?
В режиме директ стрима не просиходит никакого изменения видео вообще. Поэтому качество не меняется гарантированно. Плюс конечно видео остаётся того же размера.

сообщение оставил FJ , 08 апреля 2005, 10:44
Esc
Спасибо за ответ. Места хватит т.к. купил новый винт на 200 Гб, а сохранять видео без сжатия для меня предпочтительнее, т.к. мой вегас чего-то тормозит при других вариантах.

сообщение оставил Sy , 21 апреля 2005, 00:42
Esc спасибки ша замутю у м-ня 320GB
И как зделать в Vegas'e  так чтобы один мувик был
в нутри другого мувика.
Зарание спиб  :laugh:

сообщение оставил TomodachiDevanai , 22 апреля 2005, 23:04
Тут скачал относительно новый дуб VirtualDub-1.6.4.zip
вобщем прога почему то через раз вылетает при этом пишет...
------------------------------------------
Программа VIRTUALDUB вызвала ошибку защиты памяти
в модуле USER.EXE по адресу 001c:000013b8.
Регистры:
EAX=00030000 CS=16ff EIP=000013b8 EFLGS=00000212
EBX=17d721dc SS=a9ff ESP=00008cf8 EBP=00008d06
ECX=0002050c DS=16cf ESI=2ee821dc FS=8c2f
EDX=00000002 ES=16cf EDI=00002ee8 GS=0000
Байты по адресу CS:EIP:
67 8b 5e 08 67 8b 7e 0a 3b d9 75 04 3b fa 74 dc
Содержимое стека:
8c2f01cf 01cf0000 bff70000 8d500002 01ff0028 0bd40002 81e1001c 00000000 bff50000 bff59818 bff58df8 000000dc bff583b0 bff53724 007e7000 bff741f7
--------------------
кто знает чё за хрень и как с ней боротся
винда 98я в ХРене вроде работает



сообщение оставил Esc , 23 апреля 2005, 05:11
TomodachiDevanai
А как у 98 винды с инструкциями SSE дружба? Единственное, что приходит в голову.
А ещё я не понимаю, зачем качать бесплатный софт с левых сайтов.

сообщение оставил TomodachiDevanai , 23 апреля 2005, 19:40
вроде атлон-плюсы с первым ССЕ точно дружат
насчёт винды безпонятия, но раньше прога работала
запускаю старые версии они тоже вылетают :sad:

сообщение оставил FJ , 24 апреля 2005, 07:31
Привет всем! Кто подскажет можно ли приделать в VDM две звуковые дорожки, чтобы они проигрывались как одна, т.е. я отключаю оригинальный звук клипа, загружаю wav-исходник и корректирую синхронизацию с кадрами т.к. клип начинается с заставки, но у меня  заставка со звуком и при загрузке VDM выводит этот звук во вторую дорожку - как этого избежать?
сообщение оставил narsil , 14 июня 2005, 16:12
Гомен, если не туда черкнул. Но вобщем вопрос уже к кодированию относится, а сие мероприятие без VDM не обходится.

Короче ползут вот такие артефакты по экрану(см. аттач).
XVID
Два прохода.
Quantization type H.263
no Adaptive quantization
no Interlaced encoding
no Quarter pixel
no GMC
no Reduced Resolution

Motion Search Precision - 6
VHQ mode - 4
using Chroma motion
using Trellis quantization
not using Cartoon mode

Bitrate ~1500
Картинка очень динамичная. Стробоскоп+мелкая и быстрая нарезка.
Статью Del`a читал. Не помогло :(

сообщение оставил 79D37 fallout , 14 июня 2005, 16:19
Ба, знакомые квадраты =)  
У меня это было как-то связанно с завышенным фреймрейтом исходника, как у тебя с этим?

сообщение оставил narsil , 14 июня 2005, 16:43
79D37 fallout
У исходника fps: 15.000; 19.980; 23.976; 29.970;
Клип 30.000 fps



сообщение оставил 79D37 fallout , 14 июня 2005, 17:12
Что будет если рендерить на таких же настройках, но с 23.97?
При сжатии vp6 или дивх кубики тоже появляются?

сообщение оставил narsil , 14 июня 2005, 17:52
А Дивх не глючит. Даже весит меньше.
79D37 fallout Пасиба :)

сообщение оставил Esc , 14 июня 2005, 17:58
Йошь!! :biggrin:
сообщение оставил KocTonpaB , 28 июля 2005, 08:11
Сделал клип закодировал DivXом, все нормально только два кусочка почему-то ужасного качества вот:
< http://www.giznedav.nm.ru/bscap014.jpg >
< http://www.giznedav.nm.ru/bscap007.jpg >

сообщение оставил Esc , 28 июля 2005, 15:54
Прикольно. Рассказывай параметры кодирования.
сообщение оставил KocTonpaB , 30 июля 2005, 08:22
Esc Все кодировал как написано в твоей статье...
Версия ДивХ 5.0.5.

сообщение оставил Esc , 30 июля 2005, 23:23
Странные мелкие квадратики, если честно. Откуда такие могут быть, не знаю. Если б видео под рукой было...
Вариант решения проблемы могу предложить такой. Режешь кино по ключевым кадрам так, чтоб можно было повыкидывать плохие куски. Потом кодируешь только соответствующие отрывки с более высоким битрейтом и сшиваешь всё обратно.

сообщение оставил Soprana , 31 июля 2005, 00:59
За какоке время вспышка происходит? и она заполняет весь экран? это к первой картинке, а у второй скорее всего быстрое движение? угадала?
если правельно, то происходит это из-за системы кодирования видео. Кодировка MPEG, DivX происходит примерно таким методом: кадр разбивается на сектара (кубики) и анализируются .... в конечном счете получается что в новом кадре не перерисовывается весь кадр, а только изменение по отношению к предыдущему, поэтому MPEG плохо реагирует на быстрые и резкие смены цветова (движения в нутри кадра), он просто не успевает с реагировать на изменения. Решение проблемы в тонком подборе к конкретному клипу переходов (лучше наплывы, а не монтажный стык), и подбором настроек к конкретному клипу.
Еще я заметила прикол, что вот эти самые кубики реагируют на качество исходников из котрых монтируешь, например: из no compres - идеально, а из того же МЕПЕГА кубики валятся отовсюду.



сообщение оставил Esc , 31 июля 2005, 05:48
Soprana, это ерунда. Во-первых, кодироваться должно всё. Подбирать переходы, чтоб не нагружали кодировщик - это пораженчество. Во-вторых, впервые слышу про "не успевает реагировать". Если изменений слишком много - ставится ключевой кадр, и дело с концом. А тут как будто стоит ограничение по количеству доступных цветов. Очень непонятный глюк.

KocTonpaB, а какая версия дивыха?

сообщение оставил narsil , 31 июля 2005, 07:37
KocTonpaB
Глюк и впрямь интересный...
Попробуйте отключить глобальную компенсацию движения(Global Motion Compensation), если она включена. Хз, но может помочь.

сообщение оставил KocTonpaB , 31 июля 2005, 14:25
Esc Версия 5.0.5, такое-же происходит и если кодировать Хвидом.
narsil
Цитата
Попробуйте отключить глобальную компенсацию движения(Global Motion Compensation), если она включена. Хз, но может помочь.

А где это находится?
Esc
Цитата
Режешь кино по ключевым кадрам так, чтоб можно было повыкидывать плохие куски. Потом кодируешь только соответствующие отрывки с более высоким битрейтом и сшиваешь всё обратно.

Буду делать так, но это ж нудно и долго блин...

сообщение оставил Esc , 31 июля 2005, 17:28
KocTonpaB
Цитата
такое-же происходит и если кодировать Хвидом.

Ах такое же! Фигасе. А как эти картинки в исходном видео выглядят?

Цитата
А где это находится?

Если не знаешь, где находится, то скорей всего нормально всё. По умолчанию он отключён.

сообщение оставил Soprana , 01 августа 2005, 02:53
зря вы так, может не правельно сказа, но смысл от этого не меняется! Заметьть, что даже в лицензионных DVD вылезают кубики при резких сменах кадра, цвета, на большой части кадра!
Может и не нейспевает, но дело в системе кодирования, я просто читала статью по этому поводу.

сообщение оставил Esc , 01 августа 2005, 06:23
Soprana
Объясняю. Кубики вылезают при нехватке битрейта. Но это проблема кодирования, а не недостаток формата или ещё что-то. Если при кодировании фильма поставили потолок по битрейту, а его и не хватило. Но в этом случае квадраты хоть и видны, но цвет внутри них всё же имеет градиент и такие квадраты в основном на границе контрастных зон. И квадраты в таком случае большие, потому что кодек стремится первым делом компенсировать нехватку увеличением квантизатора. А тут мы видим мелкие и (на второй картинке) практически одноцветные квадраты по всему изображению, как мозаика. Как будто стоит ограничение не только по битрейту, но и по квантизатору. Или по количеству цветов. %) А я прекрасно знаю, что в DivX 5 подобных ограничений нет. И поэтому офигеваю.
При нормальном исходном видео проблема нехватки битрейта решается в лоб путём его увеличения. А вообще при нормальном двухпроходном кодировании такой проблемы возникать не должно, потому что битрейт перераспределяется динамически в пользу более сложных сцен. То есть либо всё будет плохо, либо всё хорошо. А вот так чтоб всё хорошо и пара кадров кривых, ненормально это. И я могу поверить, что глючит кодек. Но вот чтоб сразу два разных - это фантастика. Наверно всё же что-то не так в исходнике.

сообщение оставил KocTonpaB , 01 августа 2005, 09:10
Esc
Цитата
Ах такое же! Фигасе. А как эти картинки в исходном видео выглядят?

В исходном нормально выглядят, как и все остальные...Дело не в исходнике, у меня такое было уже, только тогда я клип по фильму кодировал вот:http://www.giznedav.nm.ru/bscap018.jpg
< http://www.giznedav.nm.ru/bscap016.jpg >
Кодеки у меня из одного пакета,может из-за этого и оба глючат, попробую установить другую версию и закодировать.

сообщение оставил KocTonpaB , 02 августа 2005, 08:49
Все перекодировал Дивиксом 5.0.4. все нормально, хорошее качество получилось...
Всем большое спасибо за разьяснения.

Powered by Ikonboard 3.1.2a
Ikonboard © 2001 Jarvis Entertainment Group, Inc.