|
bespredelunet
Стаж: 10 лет 6 месяцев Сообщений: 44
|
bespredelunet ·
10-Янв-15 12:26
(9 лет 11 месяцев назад, ред. 10-Янв-15 12:33)
Tempter57
В последнем архиве Вы внесли изменения в DVD_SAT QTGMC, проблема в том, что теперь выше пресета Slower происходит вылет.
С предыдущим архивом на другом компе, где не добавлены SLrad=3,SLMode=2 всё работает. С чем это связано и возможно ли исправить?
|
|
Tempter57
Стаж: 16 лет 2 месяца Сообщений: 4963
|
Tempter57 ·
10-Янв-15 12:42
(спустя 15 мин.)
bespredelunet
Вам окно подсказок говорит: подключите в пресет плагин fft3dfilter.dll
|
|
bespredelunet
Стаж: 10 лет 6 месяцев Сообщений: 44
|
bespredelunet ·
10-Янв-15 13:07
(спустя 25 мин.)
Tempter57
Подскажите, есть ли методы борьбы с таким явлением, как на лычках, воротнике, возле лица?
|
|
Tempter57
Стаж: 16 лет 2 месяца Сообщений: 4963
|
Tempter57 ·
10-Янв-15 13:58
(спустя 51 мин.)
bespredelunet
Один ореол был бы , можно было применить фильтр Dehalo, а здесь у вас по 3-4 ореола и боюсь трудно будет убрать. Возможно стоит применить многокаскадный LGhost, а возможно и такой код :
Код:
o = last
spline36resize(240,height)
x = mt_luts(last,last,mode="median",pixels="-1 0 0 0 1 0",yexpr="y",uexpr="y",vexpr="y",U=3,V=3)
mt_makediff(last,x,U=3,V=3).spline36resize(o.width,height)
mt_lut(expr="x 128 - abs 1 x 128 - abs 6 / 4 ^ + / x 128 - x 128 - abs 0.0001 + / * 128 +",U=3,V=3)
o.mt_makediff(last,U=3,V=3)
Пробуйте подключать пресеты TV Fizzkiller (там 3 варианта перепробуйте) и DeHalo Dither
|
|
bespredelunet
Стаж: 10 лет 6 месяцев Сообщений: 44
|
bespredelunet ·
10-Янв-15 14:32
(спустя 33 мин.)
Tempter57 писал(а):
66477653bespredelunet
Один ореол был бы , можно было применить фильтр Dehalo, а здесь у вас по 3-4 ореола и боюсь трудно будет убрать. Возможно стоит применить многокаскадный LGhost, а возможно и такой код :
Код:
o = last
spline36resize(240,height)
x = mt_luts(last,last,mode="median",pixels="-1 0 0 0 1 0",yexpr="y",uexpr="y",vexpr="y",U=3,V=3)
mt_makediff(last,x,U=3,V=3).spline36resize(o.width,height)
mt_lut(expr="x 128 - abs 1 x 128 - abs 6 / 4 ^ + / x 128 - x 128 - abs 0.0001 + / * 128 +",U=3,V=3)
o.mt_makediff(last,U=3,V=3)
Пробуйте подключать пресеты TV Fizzkiller (там 3 варианта перепробуйте) и DeHalo Dither
Буду пробовать, спасибо!
|
|
fcp
Стаж: 16 лет 3 месяца Сообщений: 1470
|
fcp ·
10-Янв-15 14:54
(спустя 21 мин.)
busoti4444 писал(а):
В чём и как могут проявляться эти проблемы ?
В том, что программа указывает плагину номер трека, думая, что это звук, а это либо не тот звук, либо вообще не звук.
busoti4444 писал(а):
Если будет декодироваться не та дорожка, которую выбрали, то это не проблема. Индекс создаётся на все дорожки в контейнере, поэтому проверив в плеере МРС-НС (отключив на интерлейсе деинтерлейс, чтобы не тормозил) какая дорожка реально декодируется в скрипт, можно всегда переключить её на другую в окне "Настроить". В крайнем случае, предварительно нужную аудиодорожку можно извлечь в папку Темп, и из окна Настроить загрузить её на любом кошерном аудиодекодере.
Да индекс-то создается, кто же спорит. Только выбранный номер трека в Настроить запросто может не соответствовать никаким ожиданиям Вообще это глобальная проблема 5-й версии, что все эти номера треков, берущиеся и от MediaInfo (там аж два варианта), и от FFmpeg, которые потом используются и для FFMS2\LSMASH, и для муксинга\демуксинга через mkvtoolnix, и где они еще там используются.. Их везде надо как-то сопоставлять! А это вот и есть проблема. Нужно вживить в программу некий интеллект, который будет сопоставлять дорожки, думать, где когда какую цифру подставить и т.д.
Старый FFmpeg для vob-файлов выдавал такой порядок треков (на примере конкретного файла)
FFMS2 тех времен расчитывал получить 1, чтоб выдать звук.
Потом более новый FFmpeg стал для того же файла выдавать уже вот такой порядок треков:
Код:
0 - dvd_nav_packet
1 - video
2 - audio
Собранный на его основе FFMS2 требует для звука указать номер 2. Такая несостыковка уже была в r330, просто дальше она могла пойти еще дальше.
FFMS2, однако, может использовать для mpeg-файлов не только демуксер из FFmpeg, но и демуксер от Haali (если он установлен, то это произойдет автоматом). И тут снова несостыковка, для Haali номер трека так и остался 1. Я вчера ночью на этом попался, подумал даже, что в FFMS2 решили выкидывать лишние треки и таким образом сдвинули нумерацию - но нет, это выбор демуксера влияет на трек, при "lavf" несостыковка вернулась
Теперь представьте, в Настроить мы выбрали некую дорожку (допустим всего в исходнике было несколько звуковых дорожек). Слушаем в превью - оно. Дальше ставим для звука Copy, смотрим результат - нет, теперь уже не оно. Т.к. для плагина и для думуксера-муксера циферки для одного и того же трека запросто могут быть разными. Вот например для mkvmerge используется разный источник информации о требуемом номере трека (ff_order - порядковый номер от FFmpeg, mi_order - поле StreamOrder от MediaInfo, mi_id - поле ID от MediaInfo). Не факт, что эти цифры всегда будут соответствовать ожиданиям mkvmerge, и не факт, что XviD4PSP, собрав все эти три цифры от FFmpeg и MI для одного какого-то трека, собрала их в обоих случаях для того же самого трека, а не для разных.
busoti4444 писал(а):
На 10 бит делать цвет 420 нет никакого смысла, должен быть выбор как минимум между YUV422 и YUV444, в зависимости от исходника.
Я может чего-то не понимаю, но в самом деле не понимаю, чем 422 или 444 тут будут лучше, если исходник 420, просто вместо 8-ми бит там 10. Ну и идущий далее ConvertToYV12, который пока-что останется на своем месте, тоже как-бы намекает, что нет смысла в 422\444. Кто будет его убирать в скрипте, тот и требуемый формат может сам выставить, наверно.
|
|
busoti
Стаж: 13 лет 6 месяцев Сообщений: 2839
|
busoti ·
10-Янв-15 16:51
(спустя 1 час 57 мин., ред. 10-Янв-15 23:03)
fcp
В таком случае наверное номера треков надо стыковать между последними Haali 1.13.138.14, MediaInfo 0.7.71.0, MKVToolnix 5.8.0, tsMuxeR 1.10.6 (если я правильно понял, у них нумерация треков одна), а к ним уже пристраивать версию FFmpeg без учёта его кодеров. В таком случае мы потеряем только декодирование FFMS2 из контейнера (галку в окне декодера со звуком убрать). В данном случае минус только в том случае, когда FFmpeg не сможет извлечь дорожку. Выход - декодер DSS cо звуком, или предварительно извлечь дорожку любым демуксером. В резерве декодеры LSMASHVideo и LWLibavVideo со звуком (я с ними не разбирался).
Второй вариант - сделать упор на FFmpeg, чтобы он по максимуму извлекал дорожки, и декодирование со звуком использовать только на декодере DSS.
Лично я декодирование из контейнера не использую вообще. Открывал несколько раз файлы на DSS , когда bassAudio не мог декодировать, но сейчас его минусы перекрывает FFAudioSource.
|
|
fcp
Стаж: 16 лет 3 месяца Сообщений: 1470
|
fcp ·
10-Янв-15 22:05
(спустя 5 часов)
busoti4444 писал(а):
66479077fcp
В таком случае наверное номера треков надо стыковать между последними Haali 1.13.138.14, MediaInfo 0.7.71.0, MKVToolnix 5.8.0, tsMuxeR 1.10.6 (если я правильно понял, у них нумерация треков одна)
Как их стыковать-то? Если даже кол-во треков по мнению разных утилит может быть разным. Я о чем и говорю, нужно как-то сопоставлять треки, взяв, к примеру, трек номер один от MediaInfo и по тем или иным признакам найти такой-же в логе FFmpeg. С Haali и tsMuxeR темный лес. Автор MKVToolnix пишет, что ID треков в его программе - это есть ни что иное, как ID, выдаваемые по команде mkvmerge --identify для конкретного файла. Там далее есть некоторые уточнения, но вот третий пункт (The track IDs are assigned in order the tracks are found in the file starting at 0.) не дает ведь никакой гарантии, что MediaInfo или FFmpeg будут находить треки в точно таком же порядке, не пропустят никакой, не выдадут что-то лишнее. Поэтому в идеале надо еще и его инфу получать через --identify и состыковывать с уже имеющейся Если в исходном файле есть только по 1шт. аудио и видео - то задача несколько упрощается, а если там несколько звуковых дорожек, да еще и одинаковых по основным признакам (язык, кодек, битрейт, хотя битрейт вообще не всегда может быть известен\верен) - то всё становится намного веселее.
Никому не интересная часть
Сейчас сделано вот как: от MediaInfo для самого первого видео трека берется его инфа (порядковый номер, ID, всё прочее). Берется кол-во аудиотреков от всё той-же MediaInfo, для каждого из них точно так-же берется инфа (порядковый номер, ID, всё прочее). Далее запускается FFmpeg. От него берется номер первой видеодорожки в его логе и, если надо, дополняется\уточняется какая-то инфа, уже взятая от MediaInfo. Обе утилиты теоретически первым видео треком могут считать разные треки (бывают ведь файлы и с несколькими видеодорожками, а бывают баги в утилитах). Да если даже и один, то неизвестно потом, как другие утилиты будут смотреть на их мнение в плане его нумерации. Теперь звук. В простейшем цикле от 0 до кол-во_треков_от_MI для каждого из них информация снова дополняется\уточняется от FFmpeg, т.е. первый аудио трек от MI = первый аудио трек от FFmpeg, второй аудио трек от MI = второй аудио трек от FFmpeg, и так до самого конца. Но ведь снова никто не гарантирует, что первый от MI есть тот самый первый от FFmpeg. Ну а если FFmpeg увидел вообще больше аудиотреков, чем MI, то к уже имеющимся еще раз добавляются все треки от FFmpeg, т.е. было 3 vs 4, в итоге стало 7 Хотя тут можно было бы просто продолжить вставлять треки с того номера, на котором закончился прошлый этап. Но все-равно в идеале во всех случаях должна быть сортировка-сопоставление. У меня даже есть набросок, я пробовал сопоставлять треки по некоторым их параметрам, присваивая разные баллы при совпадении тех или иных, но это не всегда работало как нужно, инфа от MI и FFmpeg далеко не всегда была одинаковой для точно одинаковых треков и т.д. - идея была заброшена.
скрытый текст
Код:
//Аудио от FFmpeg
if (ff.AudioStreams().Count > 0)
{
ArrayList FFStreams = new ArrayList(); //Новый список аудио треков
foreach (int id in ff.AudioStreams()) //Заполняем его FFmpeg-инфой
{
AudioStream stream = new AudioStream();
stream.codec = ff.StreamCodec(id);
stream.codecshort = ff.StreamCodecShort(id);
stream.samplerate = ff.StreamSamplerate(id);
stream.channels = ff.StreamChannels(id);
stream.language = ff.StreamLanguage(id);
stream.bitrate = ff.StreamBitrate(id);
stream.bits = ff.StreamBits(id);
stream.ffid = id;
FFStreams.Add(stream.Clone());
} //Начинаем сортировку.. Сортировка нужна, т.к. очередность наших треков может
//не совпадаеть с их очередностью в FFmpeg, и их кол-во так-же может не совпадать.
foreach (AudioStream s in m.inaudiostreams)
{
int max = -1, max_pos = -1;
ArrayList results = new ArrayList(); //Обходим сортировку, если трек всего один
if (m.inaudiostreams.Count == 1 && FFStreams.Count == 1)
{
max_pos = 0;
}
else
{
//Сравниваем текущий трек со всеми FF-треками, считаем совпадения параметров
foreach (AudioStream f in FFStreams)
{
int result = -1;
if (!string.IsNullOrEmpty(s.codecshort) && s.codecshort == f.codecshort) result += 5;
if (!string.IsNullOrEmpty(s.samplerate) && s.samplerate == f.samplerate) result += 5;
if (s.channels != 0 && s.channels == f.channels) result += 4;
if (s.bits != 0 && s.bits == f.bits) result += 2;
if (!string.IsNullOrEmpty(s.language) && s.language != "Unknown")
if (s.language == f.language) result += 2;
results.Add(result);
} //Перебираем в обратном порядке, пропуская повторы. Т.е. если нам подходит
//несколько треков, возьмем тот, который был ближе всего к началу списка.
for (int i = results.Count - 1; i >= 0; i--)
{
int value = (int)results[i];
if (value >= max) { max = value; max_pos = i; }
}
} //Если трек найден, берем что нужно и удаляем его из общего списка
if (max_pos >= 0)
{
AudioStream max_f = (AudioStream)FFStreams[max_pos];
if (s.bitrate == 0) s.bitrate = max_f.bitrate;
if (s.channels == 0) s.channels = max_f.channels;
if (s.samplerate == null) s.samplerate = max_f.samplerate;
if (s.language == "Unknown") s.language = max_f.language;
if (s.codec == "A_MS/ACM")
{
s.codec = max_f.codec;
s.codecshort = max_f.codecshort;
}
s.ffid = max_f.ffid; FFStreams.RemoveAt(max_pos);
}
} //Если у FFmpeg было больше треков, добавляем оставшиеся к имеющимся
foreach (AudioStream stream in FFStreams)
m.inaudiostreams.Add(stream.Clone());
|
|
AkvenJan
Стаж: 15 лет 6 месяцев Сообщений: 584
|
AkvenJan ·
10-Янв-15 22:23
(спустя 18 мин., ред. 10-Янв-15 22:23)
Люди, нужно ваше совместное экспертное мнение по двум вопросам:
1. Стоит ли городить зоопарк официальных установочных версий MSVC в инсталляторе или воспользоваться паком отсюда
https://rutr.life/forum/viewtopic.php?t=4594892
И ставить всё в систему через один общий файл? Я вроде инсталлятор наконец победил, и он все пять разных MSVC ставит корректно.
2. У нас тут наметился лёгкий зоопарк пресетов x264 в программе, которые уже во многом устарели. Есть желающие их подчистить, переписать и привести к какому-то более удобному виду? На мой взгляд для x264 в настоящее время связки --preset medium/slow/placebo и -tune film/animation за глаза. И поэтому я не знаю что там можно городить. Разве что сделать деление DXVA-SD и DXVA-HD, жёстко прописав профиль, уровень и vbv, и два направления - crf и bitrate. Типа такого:
DXVA-SD-2P-1500 --profile high --level 3.1 -vbv-maxrate bla bla bla
DXVA-SD-Q18
DXVA-HD-2P-8000 --profile high --level 4.1 -vbv-maxrate bla bla bla
DXVA-HD-Q18
В крайнем случае поиграться с preset, и сделать быструю, среднюю и медленную версии (fast, medium, placebo), в самом крайнем случае для анимэ сделать tune animation
В общем есть какие-то дельные предложения или даже лучше готовые результаты?
P.S. fcp, я ту твою проблему с установкой MSVC подебил. Во всяком случае у меня на компе сейчас без проблем отрабатывает. Тестовую версию тебе скину как зальётся (ADSL все дела), проблема в ключе была.
|
|
DARKAN
Стаж: 14 лет Сообщений: 552
|
DARKAN ·
10-Янв-15 22:38
(спустя 14 мин., ред. 10-Янв-15 23:52)
В том паке не обновлён MSVC 2013, там версия 12.0.21005, в данный момент последняя версия 12.0.30501. Поэтому лучше пользоваться официальными установочными версиями на данный момент.
|
|
AkvenJan
Стаж: 15 лет 6 месяцев Сообщений: 584
|
AkvenJan ·
10-Янв-15 22:54
(спустя 16 мин.)
P.S. Откопал у себя на компе вот такой старый архив от 2013 года
скрытый текст
Набор пресетов c постоянным битрейтом для кодека QAAC, прогрммы Xvid4PSP.
Смысл этих пресетов в том что там добавлена строчка --no-delay,
которая убирает задержку(свойственную AAC) в начале файла.
Папку положить в корень Xvid4PSP 5.
--no-delay лобалвяется при кодировании только если выбранный пресет не изменялся в прогрмме, иначе
строчка убирается и задержка будет присутствовать, поэтому в архиме неск.пресетов с наиболее
популярными значениями битрейта - от 128 до 640 kbps.
Оно ещё актуально, кто-нибудь вообще помнит?
|
|
DFM515
Стаж: 12 лет 9 месяцев Сообщений: 407
|
DFM515 ·
10-Янв-15 22:58
(спустя 3 мин.)
AkvenJan писал(а):
66484201У нас тут наметился лёгкий зоопарк пресетов x264 в программе, которые уже во многом устарели.
Мои пять копеек как простого юзера сабжа. Вот мне бы по парочке "тяжелых" пресетов с CRF 15-16 (в которых были бы выверены все вспомогательные настройки на основе опыта людей сведущих) для фильмов и анимации + парочку (или больше?) "тяжелых" пресетов для Hi10P с CRF.
Далее, вот такое замечание: у меня кастомные шрифты, большие экраны для работы. Короче все эти эти окошки в программе не масштабируются под текст в них. И иногда хрен поймешь. что там написано. Не критично, но все-таки.
Правда я тут боюсь, я как то написал Бункусу, а тот сказал , что у него просто такой отстойный API, но он обязательно сделает. И сделал, млин, начиная с 6.7.0. Ну, все в курсе. ..
так и ладно бы так, но почему тогда мышкой нет возможности подкорректировать размеры полей в проге - растянуть и все-такое.
Есть конечно и еще пожелания, да ладно.
|
|
fcp
Стаж: 16 лет 3 месяца Сообщений: 1470
|
fcp ·
10-Янв-15 23:10
(спустя 11 мин.)
AkvenJan писал(а):
Оно ещё актуально, кто-нибудь вообще помнит?
Даже если да (хотя помоему ключ добавляется по желанию и не строго всегда может быть нужен, но спорить не хочу), то он же будет сбрасываться. Пока-что можно без них, либо можно ввести этот ключ, но тогда столько пресетов не нужно будет.
DFM515 писал(а):
Далее, вот такое замечание: у меня кастомные шрифты, большие экраны для работы. Короче все эти эти окошки в программе не масштабируются под текст в них. И иногда хрен поймешь. что там написано. Не критично, но все-таки.
Кастомные шрифты - это когда берется шрифт такой-то номер 14, а буквы в итоге выглядят как 28, т.к. где-то там файлы шрифтов в системе подменены? Если да - то я ничем не помогу и со своей стороны даже не знаю, что можно сделать в XviD4PSP. Если вы знаете как это делается в WPF (не в WinForms!) - напишите посмотрю. В остальном же всё корректно масштабируется при изменении dpi. Ну и естественно сделать каждое поле ввода изменяемым мышкой - я себе этого не предсталяю (не как это сделать, а как по уродски это будет выглядеть потом, во всяком случае именно так оно мне видится), неужели существуют программы, где это есть?!
|
|
AkvenJan
Стаж: 15 лет 6 месяцев Сообщений: 584
|
AkvenJan ·
10-Янв-15 23:19
(спустя 9 мин.)
fcp писал(а):
Даже если да (хотя помоему ключ добавляется по желанию и не строго всегда может быть нужен, но спорить не хочу), то он же будет сбрасываться. Пока-что можно без них, либо можно ввести этот ключ, но тогда столько пресетов не нужно будет.
Проще одно поле под ключ добавить имхо. Если он в новых версиях qAAC ещё остался вообще, проверить надо.
|
|
busoti
Стаж: 13 лет 6 месяцев Сообщений: 2839
|
busoti ·
10-Янв-15 23:46
(спустя 26 мин., ред. 11-Янв-15 04:31)
fcp
Остаётся по трекам вариант с которого я начал - оставляем FFmpeg, Haali, tsMuxeR, MediaInfo на версиях 330-й версии проги. Откатить MKVToolnix на версию 5.8.0, убрать все кодеры из FFmpeg, чтобы они не портили впечатление и не рождали ненужные вопросы. Работает же, по этому поводу никто не жалуется ...
Откатывать MediaInfo на более раннюю версию нельзя, там идёт неправильное определение fps на интерлейсных исходниках с движением в каждом поле. У меня обновление MediaInfo на последнюю версию не дало ничего нового, но и проблем не добавило.
Декодеры конечно обновлять на последние версии, и отказаться от декодирования из контейнера. Многие и не знают о такой возможности (поэтому и вопросов нет ), а те кто знает, в состоянии решить проблему, если она возникнет.
Добиться идеала в этом вопросе на автомате, как я понял невозможно. Винни попробовал ...
|
|
DFM515
Стаж: 12 лет 9 месяцев Сообщений: 407
|
DFM515 ·
11-Янв-15 00:15
(спустя 29 мин., ред. 11-Янв-15 00:15)
fcp писал(а):
66484782где-то там файлы шрифтов в системе подменены?
скрытый текст
ну да. и размеры и сам шрифт и сглаживание там всякое-такое.
fcp писал(а):
66484782а как по уродски это будет выглядеть потом, во всяком случае именно так оно мне видится), неужели существуют программы, где это есть?!
ну да. полно таких программ. Не, ну есть программы, которые всё это игнорирят, плевать им на мои кастомы - у них всё своё. А есть программы, которые участвуют в этом, т.е. я вижу свои шрифты. А уж как они это делают - я фиг знает. Подозреваю, что как-то приспосабливают себя под мою систему, а как иначе-то?
Да ладно. переживу. пилИте свой инсталлятор поскорее уже (но и потщательнеЕ эт вэ сэйм тайм!:)), а то так хочется поюзать, что аж переночевать негде .
|
|
fcp
Стаж: 16 лет 3 месяца Сообщений: 1470
|
fcp ·
11-Янв-15 00:40
(спустя 25 мин., ред. 11-Янв-15 00:40)
busoti4444 писал(а):
Работает же, по этому поводу ни кто не жалуется ...
Достаточно найти такой файл, где нумерация треков не будет совпадать - и что-то уже не будет работать как задумано Для r330 у меня такие файлы были, да и кусок с сортировкой выше я же не просто так когда-то написал, под него тоже были файлы, от которых были проблемы (правда было это намного раньше 330-й, где-то так в конце 2010-го).
busoti4444 писал(а):
Откатывать MediaInfo на более
раннюю версию нельзя, там идёт неправильное определение fps на интерлейсных исходниках с движением в каждом поле. У меня обновление MediaInfo на последнюю версию не дало ни чего нового, но и проблем не добавило.
Я думаю в MediaInfo за это время правился не только баг с fps, но и разные другие, с добавлением новых конечно. Так-что тут не угадаешь.
busoti4444 писал(а):
Добиться идеала в этом вопросе на автомате, как я понял невозможно. Винни попробовал ...
На автомате.. Ну можно насоздавать себе кучу батников, кидать на них исходники и не использовать никакие ГУИ Путь Винни тоже понятен (кроме Winnydows Commander'а если честно), возиться с кучей сторонних программ, пытаясь дирижировать их работу, тогда как сами программы не всегда к этому располагают.. Да и вечно надо быть в курсе всех изменений в каждой из них - рано или поздно это может надоесть.
DFM515 писал(а):
пилИте свой инсталлятор поскорее уже (но и потщательнеЕ эт вэ сэйм тайм!:))
Как я несколько дней назад писал, особо тщательной проверки всего и вся сейчас нет. Принцип простой: будут баги - будут багрепорты, а дальше будет видно. Сейчас в основном вопрос в интеграции установки рантаймов в инсталлер. И с LSMASH еще что-то надо придумать.
|
|
busoti
Стаж: 13 лет 6 месяцев Сообщений: 2839
|
busoti ·
11-Янв-15 04:38
(спустя 3 часа, ред. 25-Янв-15 04:02)
fcp
Цитата:
с LSMASH еще что-то надо придумать
Можно забить стартовый формат YUV420P8 , но я не уверен, что на нём будет загружаться хак. Если после открытия файла на YUV420P8, при записи в строку декодера YUV422P8, будет загружаться хак (как на FFMS2mod ), то можно начинать с цвета 420. Я исходники с цветом 420 и искусственными 10 бит не беру во внимание, а наверное напрасно, кодировать будут и с них.
И если на старте будет цвет 422, вряд ли декодер будет делать в него ресайз с 420, он просто выдаст ошибку. Также как в х264, если подать на вход 420 и выводить в 422, он выдаёт ошибку. А если подать 422 и выводить в 420, то делает ресайз.
В плане 10 бит, я бы ещё поискал декодер для кодека Авид (для исходников CineForm), т.к. FFMS2mod не декодирует его. Вот здесь, начиная отсюда и заканчивая этим постом, мы немного подискутировали на эту тему.
Если интересно, вот уже готовый файл Avid 10 бит 422
|
|
george$t
Стаж: 14 лет 8 месяцев Сообщений: 4308
|
george$t ·
11-Янв-15 13:39
(спустя 9 часов, ред. 11-Янв-15 13:39)
fcp писал(а):
66452923плюс с картинками вверху окна что-то придумывать надо будет..
По быстрому так.
Хотел пустить волну, да что-то у меня что-то застопорилось... Пламя вроде надоело, а?
Если есть желающие добить, пустить градиент по тайпу, psd прилагается.
|
|
AkvenJan
Стаж: 15 лет 6 месяцев Сообщений: 584
|
AkvenJan ·
11-Янв-15 14:05
(спустя 25 мин.)
Бедный бедный fcp george$t
А что тебе не понравилось в итоговом логотипе? По-моему нормально получилось. Там разве что картинку волны надо смасштабировать, чтобы она сильнее выделялась в логотипе. Вероятнее всего её уменьшить надо, чтобы нижний изгиб волны влез.
Ну и буквы я бы не делал наклонными, оставил по шаблону предыдуших х262 и х264. И всё, больше недоработок не вижу.
Другое дело, что у нас нет шаблона для расстановки ключей - вот это гораздо серьёзнее.
|
|
george$t
Стаж: 14 лет 8 месяцев Сообщений: 4308
|
george$t ·
11-Янв-15 16:09
(спустя 2 часа 3 мин., ред. 11-Янв-15 16:38)
AkvenJan
Учитывая неторопливость сабжа, можно и сосульки на Х нарастить, будет ближе к правде жизни, только делать это должен художник а не дилетант, как я. Думаю, надо попросить помочь в разделе аватарок. Скорее всего с прицелом на отдалённое будущее. Пока же аргументы критиков формата представляются весомее.
Так не лучше? Может, центральное окошко потемнее сделать? Цифры пока без градиента, не соображу...
|
|
busoti
Стаж: 13 лет 6 месяцев Сообщений: 2839
|
busoti ·
11-Янв-15 16:36
(спустя 27 мин., ред. 14-Янв-15 18:18)
george$t
Согласен с тобой, что форсировать сегодня кодер х265 нет необходимости.
Прежде, чем делать окно и вкладки настроек, надо разобраться с самими настройками, и в первую очередь с последовательностью их задания. Т.к. все ключи в окно на поместятся, определиться какие ключи не следует трогать вообще и не включать их во вкладки. Те, кто освоит кодер, данные ключи всегда могут изменить на вкладке CLI .
Если говорить о последовательности (по аналогии с х264), то на первой вкладке помещать ключи, которые задают 70 % основных настроек - пресет кодера, профиль, level, возможно ещё что-то. Выставив на следующей вкладке --ref , --bframes , --deblock под исходник, мы задаём ещё кучу тонких настроек, и т.д.
|
|
george$t
Стаж: 14 лет 8 месяцев Сообщений: 4308
|
george$t ·
11-Янв-15 17:16
(спустя 39 мин., ред. 11-Янв-15 17:16)
busoti4444 писал(а):
66492862надо, чтобы его очертания было видно полностью.
Ну всё уже, икс с волной - один слой. Если сверху ещё раз наложить с прозрачностью, выходит бленд непонятно-ненатуральный.
Вот большой, нормально всё видно.
Доработаешь?
|
|
DFM515
Стаж: 12 лет 9 месяцев Сообщений: 407
|
DFM515 ·
11-Янв-15 17:19
(спустя 3 мин., ред. 11-Янв-15 17:19)
busoti4444 писал(а):
66492862Согласен с тобой, что форсировать сегодня кодер х265 нет необходимости.
скрытый текст
Я вот опять. Можно? Такая мысль меня посетила. А не практичнее ли будет сделать 3 (!) сборки: под Xvid, под x264, под x265. Поясню. У каждого есть свои предпочтения. На моем примере: никогда не кодировал в Xvid и не собираюсь, хотя несомненно он нужен огромному количеству людей; x265 с учетом прений нужен опять-таки отдельной категории, кто-то его сейчас использует, но я нет.
Может так проще будет?
|
|
fcp
Стаж: 16 лет 3 месяца Сообщений: 1470
|
fcp ·
11-Янв-15 17:30
(спустя 10 мин., ред. 11-Янв-15 17:30)
busoti4444 писал(а):
Можно забить стартовый формат YUV420P8 (YV12), но я не уверен, что он 10-ти битный, и на нём будет загружаться хак. Если после открытия файла на YUV420P8, при записи в строку декодера YUV422P8, будет загружаться хак (как на FFMS2mod ), то можно начинать с цвета 420. Я исходники с цветом 420 и искусственными 10 бит не беру во внимание, а наверное напрасно, кодировать будут и с них.
И если на старте будет цвет 422, вряд ли декодер будет делать в него ресайз с 420, он просто выдаст ошибку. Также как в х264, если подать на вход 420 и выводить в 422, он выдаёт ошибку. А если подать 422 и выводить в 420, то делает ресайз.
В плане 10 бит я бы ещё поискал (возможно позже) декодер для кодека Авид (для исходников CineForm), т.к. FFMS2mod не декодирует его. Вот здесь, начиная отсюда и заканчивая этим постом, мы немного подискутировали на эту тему.
Если интересно, вот уже готовый файл Avid 10 бит 422
Я хочу просто вернуть возможность открывать в XviD4PSP многобитные файлы без этой самой многобитности, т.е. с её потерей. Как через обычные FFMS2 и DSS2. Если кому-то понадобится этот хак - тем придется подправить требуемый формат в вызове LSMASH (и скорее всего вписать stacked=true), но ConvertToYV12 все-равно же убирать из скрипта..
Маленький тест по поводу того, что FFMS2 и DSS2+LAV выдают Ависинту при разных исходниках:
Код:
DSS2 и FFMS2
444 10b -> RGB32
422 10b -> YUY2
420 10b -> YV12 FFMS2 (c-plugin)
444 10b -> YV24
422 10b -> YUY2
420 10b -> YV12
C-plugin поддерживает дополнительные форматы Ависинта 2.6, обычный - нет (как и DSS2). Мне только 422 10b в YUY2 не ясно, почему оно так, а не YV16. Да и все-равно потом либо вручную править скрипт (если надо), либо всё сконвертится в YV12 чуть дальше george$t
Картинка - это хорошо, но у меня пока-что в плане x265 ничего нет, а после того теста с мылом - так вообще стоит еще подумать, а надо ли оно. Кстати на их сайте есть что-то типа логотипа, с очень маленькой x и со здоровенной дырой в шестерке
DFM515 писал(а):
А не практичнее ли будет сделать 3 (!) сборки: под Xvid, под x264, под x265.
...
Может так проще будет?
Если имеется ввиду три версии, в каждой из которы будет только один энкодер - то проще не будет, нет. x265 особо мешаться не должен в любом случае, x262 же сейчас не мешается.
|
|
busoti
Стаж: 13 лет 6 месяцев Сообщений: 2839
|
busoti ·
11-Янв-15 18:12
(спустя 41 мин., ред. 11-Янв-15 18:12)
fcp
Цитата:
Я хочу просто вернуть возможность открывать в XviD4PSP многобитные файлы без этой самой многобитности
Теперь наверное я чего-то не понимаю ...
Эту возможность никто и не забирал. При открытии файлов 10 бит 422@444 все декодеры (DSS + LAV, DSS2, FFMS2, QTInput, AVISource) загружают в Ависинт не более 8 бит 422.
Со строкой ConvertToYV12() кодируем в 8 бит 420, убрав вручную строку - в 8 бит 422.
Использовать декодер LSMASH, заточенный для 10 бит (как и FFMS2mod ), при кодировании в 8 бит не вижу смысла.
|
|
george$t
Стаж: 14 лет 8 месяцев Сообщений: 4308
|
george$t ·
11-Янв-15 18:54
(спустя 42 мин., ред. 11-Янв-15 22:03)
fcp писал(а):
66493744Мне только 422 10b в YUY2 не ясно, почему оно так, а не YV16.
|
|
fcp
Стаж: 16 лет 3 месяца Сообщений: 1470
|
fcp ·
11-Янв-15 19:44
(спустя 50 мин.)
george$t
Яснее не стало
busoti4444 писал(а):
При открытии файлов 10 бит 422@444 все декодеры (DSS + LAV, DSS2, FFMS2, QTInput, AVISource) загружают в Ависинт не более 8 бит 422.
Эти - да, LSMASH - загружает не то, что нужно. Ну собственно вопрос в общих чертах уже решен, какой формат он выдает Ависинту в хакнутом виде, такой же и перезадается ему с 8-кой в конце. По поводу корректности такого подохода - не знаю..
как-то вот так
Код:
public static string GetLSMASHFormat8(AviSynthColorspace csp)
{
if (csp == AviSynthColorspace.I420) return "YUV420P8";
if (csp == AviSynthColorspace.YV12) return "YUV420P8";
if (csp == AviSynthColorspace.YV16) return "YUV422P8";
if (csp == AviSynthColorspace.YV24) return "YUV444P8";
if (csp == AviSynthColorspace.YV411) return "YUV411P8";
return "YUY2";
}
И увы в самом деле вылез неприятный баг, если LSMASH'у скормить какой-то неперевариваемый им файл, то он будет долго его индексировать, а в конце выдаст, что не может найти видеодорожку. После чего память процесса не освобождается, а сам файл похоже при этом читается именно в неё, полностью. В моём случае это был 2Гб файлик (пытался я какой-то многобитный RGB в FFmpeg создать, чтоб посмотреть, что для него выдаст LSMASH).
|
|
george$t
Стаж: 14 лет 8 месяцев Сообщений: 4308
|
george$t ·
11-Янв-15 22:00
(спустя 2 часа 15 мин., ред. 11-Янв-15 22:10)
fcp
Ну как, я имел ввиду посмотреть по аналогии с ffms2, который с хаком подаёт YV16, но с двойным стеком, без него в YUY2 без стека.
И.... у меня YV16. А дальше - какой "формат" укажешь. Или я вообще не в ту сторону танцую и неправильно понял про YUY2?
Фу ты, об эльсмэше вообще речи не шло. С х265 картинками перестал понимать простые вещи. сорри.
|
|
fcp
Стаж: 16 лет 3 месяца Сообщений: 1470
|
fcp ·
11-Янв-15 22:07
(спустя 6 мин., ред. 11-Янв-15 23:48)
george$t
Вопрос в том, почему все они* при выводе многобитного 422 выводят его в YUY2 (когда выводят без хака, имеется ввиду). Почему не в YV16? Оба 422, первый interleaved, второй planar - это мне avisynth.nl подсказывает Может таким путем получается меньше преобразований, или может так оно быстрее, или может еще что-то..
*С DSS2 и FFMS2 (не С) понятно почему, потому-что YV16 они и не умеют.
-------
Попробовал замерить скорость декодирования с YUV422P8, YUY2, YUV422P8+ConvertToYV12, YUY2+ConvertToYV12, и вообще безо всего (сам по себе хакнутый вывод), исходником был ProRes 1280х720 422-10b ~60Mbps, декодером LWLibavVideoSource.
~176fps - выход "как есть"
~170fps - YUV422P8
~172fps - YUY2
~158fps - YUV422P8+ConvertToYV12
~162fps - YUY2+ConvertToYV12
По скорости YUY2 всегда чуть быстрее, а вот четкость выше у YUV422, что с ConvertToYV12, что без него (ну и далее в превью еще всегда вызывается ConvertToRGB32, т.е. он тут тоже участвует, но не в замерах скорости). Либо я что-то делаю не так и разницы не должно быть, либо цепочка превращений в LSMASH и Ависинте работает вот так.
|
|
|