|
|
|
degifly
Стаж: 14 лет 1 месяц Сообщений: 951
|
degifly ·
18-Июн-12 15:44
(12 лет 5 месяцев назад)
http://forum.doom9.org/showthread.php?t=143624 (в первом посте неактуальная версия, вот ссылка на архив - http://umezawa.dyndns.info/archive/utvideo/ Там и сам кодек и ридми на английском).
Он тоже vfw онли.
|
|
|
|
shark000X
Стаж: 14 лет 4 месяца Сообщений: 434
|
shark000X ·
18-Июн-12 17:43
(спустя 1 час 58 мин., ред. 18-Июн-12 17:43)
Хм, почитал на счет UT -- и тута, и тама. В официальном ридми весьма показательная таблица и описание: "In "8-bit full-range" of RGB formats, R,G,B=0-255. In "8-bit limited" of YUV formats, Y=16-235 and U,V=16-240". При этом "8-bit full-range" не предусмотрен для YUV! Чёй-то у меня в голове не укладывается: какой это нафиг лосслесс, если рубит YUV до ТВ-диапазона, в то время как многие камкодеры выдают результат 16-255 без дополнительных левелз? Выходит, что лосслесс только для RGB -- может по этой причине его не включают в кодек-паки? Не замечал такого за Lagarith, но теперь озадачился, придется попристальней глянуть при оказии. В любом случае, в отношении Lagarith такой фигни нигде не упоминается, не встречал по крайней мере.
|
|
|
|
degifly
Стаж: 14 лет 1 месяц Сообщений: 951
|
degifly ·
18-Июн-12 17:49
(спустя 6 мин., ред. 18-Июн-12 17:49)
А зачем фуллрэндж yuv? о_О
Для записи с экрана - RGB, потом в любом случае кодировать в YV12 в тв-диапазоне. И я даже не удивлюсь если убогие рендереры вроде EVR точно также плюют на флаг диапазона в потоке, как на флаг матрицы..
В любом случае, если нужен лосслесс для записи с экрана - то исключительно ргб. А если хочется сжать видео чисто для пэка, и чтоб оно офигенно выглядело - то 10-bit 4:4:4 в помощь.
shark000X писал(а):
Выходит, что лосслесс только для RGB
are you retarded? 99.99% видео в мире - тв-диапазона.
shark000X писал(а):
кодек-паки?
Кодек-паки - дерьмо по определению. А в x264, как и в LAV Decoder'е есть декодер для UT.
Также ставить декодер без энкодера - очень сомнительное удовольствие. Часто кто-нибудь кому-нибудь передает по сети видео сжатое луззлесс кодеком? Если уж и передавать - то не издеваться на людьми, а потратить чуть больше времени на кодирование иксой.
|
|
|
|
shark000X
Стаж: 14 лет 4 месяца Сообщений: 434
|
shark000X ·
18-Июн-12 17:53
(спустя 3 мин.)
Мы несколько ушли в широкие моря... Суть вопроса изначально была "лосслесс не для хранения, а промежуточный", т.е. используются тяжелые фильтры и, чтобы не мучаться, процесс разбивается на пару этапов, а между ними лосслесс. И что, каждый раз парить себе мозги еще проверкой диапазона на выходе первого этапа? о_О
Гы, читал о UT, а там же узнал, что FFV1 все-таки красавчик, 10 бит позволяет.
|
|
|
|
Lenchik
Стаж: 18 лет 4 месяца Сообщений: 854
|
Lenchik ·
18-Июн-12 17:54
(спустя 1 мин.)
degifly писал(а):
А зачем фуллрэндж yuv?
AVCHD c xvYCC вроде как с Соневских камер, например. На практике не видел, но говорят есть и много.
degifly писал(а):
И я даже не удивлюсь если убогие рендереры вроде EVR точно также плюют на флаг диапазона в потоке, как на флаг матрицы.
Это не повод отказываться от фуллрэндж yuv.
shark000X
С разработчиками лагарифа или ут не пробовали связаться на тему консольных вариантов запуска?
Цитата:
FFV1 все-таки красавчик, 10 бит позволяет.
Круто! Надо будет попробовать его.
|
|
|
|
shark000X
Стаж: 14 лет 4 месяца Сообщений: 434
|
shark000X ·
18-Июн-12 18:05
(спустя 10 мин., ред. 18-Июн-12 18:05)
Lenchik
Судя по сравнительным таблицам, FFV1 получается самый лучший лосслесс для 10 бит по соотношению скорость/сжатие.
С разрабами нету времени щас связываться, у меня еще та прежняя тема зависла -- хочу на гора выдать результат, а дальше немец пущай думает, или признается что ему это уже не интересно 
Вот только 10 бит там оказывается не так давно: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=1eabd71c2bed13648643433249386f4b965b5c14
..... а нет, уже год как присутствует, должно быть проверено.
degifly
кхм, первичная тема таки да размазалась по двум веткам, поэтому мог быть недопонят
|
|
|
|
degifly
Стаж: 14 лет 1 месяц Сообщений: 951
|
degifly ·
18-Июн-12 18:16
(спустя 10 мин., ред. 18-Июн-12 18:16)
shark000X писал(а):
Суть вопроса изначально была "лосслесс не для хранения, а промежуточный", т.е. используются тяжелые фильтры и, чтобы не мучаться, процесс разбивается на пару этапов, а между ними лосслесс.
Именно. На входе либо ргб с экрана, либо yv12 tv-range из видео. В первом случае разумно использовать ргб, во втором - yv12 с тв-диапазоном.
При тв сорце использовать пк-диапазон для промежуточного файла, чтобы потом опять в тв-диапазон кодировать - довольно глупо...
Lenchik писал(а):
AVCHD c xvYCC вроде как с Соневских камер, например.
Ну ок, эти бедные люди обделены этим замечательным кодеком. 
Lenchik писал(а):
Это не повод отказываться от фуллрэндж yuv.
Это повод отказаться от EVR и железных плееров :3
|
|
|
|
shark000X
Стаж: 14 лет 4 месяца Сообщений: 434
|
shark000X ·
18-Июн-12 18:27
(спустя 11 мин., ред. 18-Июн-12 21:38)
degifly писал(а):
При тв сорце использовать пк-диапазон для промежуточного файла, чтобы потом опять в тв-диапазон кодировать - довольно глупо...
Согласен, но еще более глупо не учитывать, что в некоторых случаях невозможно избежать расширения диапазона вследствие фильтрации. Если рассматривать вариант сорец-лосслесс-выход без фильтров, то тогда и лосслесс не нужен применительно к моей ситуации.
ПС: а вообще эт уже больше походит на "из пустого в порожнее", ибо таки камкодеры имеют расширенный диапазон, хоть и неполный PC.
Lenchik
народ уже умудряется использовать FFV1 для 16-битного енкода (RGB48):
http://ffmpeg-users.933282.n4.nabble.com/FFv1-Encode-rgb48le-td4650747.html
хоть он еще не поддерживается официально 
НО все эти фишки, включая 10 бит, не умеет версия FFV1, входящая в состав libav, если не ошибаюсь.
|
|
|
|
Tim68
Стаж: 14 лет 9 месяцев Сообщений: 712
|
Tim68 ·
18-Июн-12 23:00
(спустя 4 часа)
shark000X писал(а):
таки камкодеры имеют расширенный диапазон, хоть и неполный PC.
Обратил внимание на то, что даже в AVC HD (не AVCHD) камерах, сужу по своей Тоше, диапазон PC полный, что наводит на мысль что камкордеры возможно снимают еще шире, а при декодировании происходит клиппирование до 0-255, что вроде на первый взгляд не вяжется с 8-ю битами.
degifly писал(а):
При тв сорце использовать пк-диапазон для промежуточного файла, чтобы потом опять в тв-диапазон кодировать - довольно глупо...
можно и потом в РС диапазон кодировать. Не секрет, что практически все современные DVD и Blu-Ray издания имеют полезную информацию в областях "чернее черного" (0-15) и "белее белого" (236-255) и единственной возможностью это все увидить является воспроизведение в полном диапазоне, тем более, что это все стандартизованно в формате AVCHD. Работа с полным диапазонам дает возможность заменить оригинальные "черные полосы" (значение >=16 ) на "черные" (значение=0), которые абсолютно не видно на любом устройстве отображения и которые почти абсолютно не съедают битрейт, тем самым позволяя держать "форматный" размер кадра.
shark000X писал(а):
в некоторых случаях невозможно избежать расширения диапазона вследствие фильтрации.
Действительно даже простые действия с яркостью (двигает) и контрастностью (растягивает/сжимает) всегда приводили и будут приводить к указанному изменению гистограммы сигнала.
|
|
|
|
unreal666
Стаж: 16 лет 10 месяцев Сообщений: 1713
|
unreal666 ·
19-Июн-12 06:29
(спустя 7 часов, ред. 19-Июн-12 06:29)
Tim68 писал(а):
является воспроизведение в полном диапазоне
Что есть "воспроизведение в полном диапазоне" ? "YV12 Limited -> RGB Full" или "YV12 Full -> RGB Full". Если 2-ой вариант, тогда черный станет серым. Если конечно видео не изначально YV12 Full.
Tim68 писал(а):
которые абсолютно не видно на любом устройстве отображения
На компе они и так абсолютно черные (YV12 Limited -> RGB Full) и без всяких супер-черных и супер-белых.
|
|
|
|
agz
Стаж: 17 лет 5 месяцев Сообщений: 1440
|
agz ·
19-Июн-12 17:19
(спустя 10 часов)
А что за mode=2 в tdeint?
Цитата:
2 - smartbobbed field-matching (same rate output, blend frames from bobbed stream)
У меня при его включении удаляются испорченные кадры при смене сюжета. В DVB часто такие кадры встречаются. Я скрины как то уже постил.
|
|
|
|
Tim68
Стаж: 14 лет 9 месяцев Сообщений: 712
|
Tim68 ·
19-Июн-12 17:54
(спустя 35 мин., ред. 19-Июн-12 17:54)
unreal666 писал(а):
"YV12 Full -> RGB Full". Если 2-ой вариант, тогда черный станет серым. Если конечно видео не изначально YV12 Full.
Обычно Я поступаю так:
- индексирую в PC диапазоне;
- отрезаю "оригинальные" черные полосы;
- фильтрация, обработка => расширение диапазона;
- добавляю новые через RGB, например:
Код:
ConvertToRGB(matrix="PC.601")
addborders(8,0,8,0)
ConvertToYV12(matrix="PC.601")
;
- кодирую Х-ом в полный диапазон, чаще всего анаморф т.к. использую "форматные" как sar, так и размер кадра.
unreal666 писал(а):
На компе они и так абсолютно черные
получаются абсолютно черные на любом устройстве в т.ч. и на TV и даже с любого аппаратного декодера, но самое главное практически не съедают битрейт.
Пример того, как это может выглядеть. Расчет на любой аппаратный декодер. Бывает пускаю в авторинг на оптический носитель.
|
|
|
|
Vic124
Стаж: 17 лет 8 месяцев Сообщений: 81
|
Vic124 ·
19-Июн-12 18:25
(спустя 30 мин.)
Скажите, программa MeGUI имеет опцию резюме кодирования после, например крэша компютера и прочего?
|
|
|
|
unreal666
Стаж: 16 лет 10 месяцев Сообщений: 1713
|
unreal666 ·
19-Июн-12 18:40
(спустя 14 мин., ред. 19-Июн-12 18:40)
MeGUI сама ничего не кодирует. Она всего лишь GUI над консольными кодировщиками + некоторые плюшки в виде промежуточного звена между ависинтом и аудиокодировщиками.
Tim68 писал(а):
- индексирую в PC диапазоне;
Это где при индексе выставляется диапазон? Может не при индексации, а при собственно импорте видео?
|
|
|
|
Lenchik
Стаж: 18 лет 4 месяца Сообщений: 854
|
Lenchik ·
19-Июн-12 18:55
(спустя 15 мин.)
Vic124 писал(а):
Скажите, программa MeGUI имеет опцию резюме кодирования после, например крэша компютера и прочего?
не имеет
|
|
|
|
Tim68
Стаж: 14 лет 9 месяцев Сообщений: 712
|
Tim68 ·
19-Июн-12 19:12
(спустя 16 мин., ред. 19-Июн-12 19:12)
unreal666 писал(а):
Это где при индексе выставляется диапазон?
Подразумевал, например DGIndex: Video => YUV->RGB => PC Scale.
|
|
|
|
Vic124
Стаж: 17 лет 8 месяцев Сообщений: 81
|
Vic124 ·
19-Июн-12 19:42
(спустя 30 мин.)
unreal666
Lenchik
Спасибо!
|
|
|
|
Ang+
Стаж: 16 лет 7 месяцев Сообщений: 993
|
Ang+ ·
23-Июн-12 21:24
(спустя 4 дня)
Есть 2 исходника: VC-1 и AVC. В основном, второй лучше - более четкий, присутствует шумок, отсутствуют замылы. Но некоторые кадры все же лучше в первом.
1. Можно ли как-то автоматизированно получить номера лучших кадров из первого сорса?
Сравнение:
http://screenshotcomparison.com/comparison/131819
Сам ковырял Subtract-ы всякие, mt_makediff. Но не выходит, не хватает знаний. Была идея еще рипнуть оба источника с какими-то определенными настройками, а затем сравнить битрейты каждого кадра - у более шумных он должен быть выше. Только на практике тоже какая-то белиберда получается. Каким образом заставить каждый кадр сжиматься сам по себе, без влияния соседей, и т.п.? Выйдет ли вообще задумка?
2. Исходники, как видно и на этих скринах, немного отличаются яркостью/цветностью. Как привести значения этих параметров у 2-го к значениям первого (более темные оттенки)?
Mergeluma/hroma, overlay что-то не помогают - либо полностью копируют картинку, либо теряют шумовую составляющую.
|
|
|
|
Yurasyk
Стаж: 16 лет 1 месяц Сообщений: 3506
|
Yurasyk ·
23-Июн-12 21:36
(спустя 11 мин.)
Ang+, а вы слышали о i, p и b кадрах? Если слышали и знаете, что это такое, тогда вы должны понять ответ. Это если я правильно понял, что на приведённых скриншотах на одном AVC лучше, а на другом VC-1.
|
|
|
|
Ang+
Стаж: 16 лет 7 месяцев Сообщений: 993
|
Ang+ ·
23-Июн-12 22:45
(спустя 1 час 9 мин.)
Yurasyk, увы, к типам кадров там привязки нет. В одних случаях P(VC-1) лучше B(AVC), в других B(VC-1) лучше P(ACV).
|
|
|
|
Yurasyk
Стаж: 16 лет 1 месяц Сообщений: 3506
|
Yurasyk ·
23-Июн-12 23:11
(спустя 25 мин.)
Ang+ писал(а):
Yurasyk, увы, к типам кадров там привязки нет. В одних случаях P(VC-1) лучше B(AVC), в других B(VC-1) лучше P(ACV).
Тогда даже не знаю. Это больше похоже будет на сортировку песчинок.
|
|
|
|
shark000X
Стаж: 14 лет 4 месяца Сообщений: 434
|
shark000X ·
23-Июн-12 23:49
(спустя 37 мин., ред. 23-Июн-12 23:49)
Ang+
По второму вопросу:
Фильтр HistogramAdjust авторства V.C.Mohan (к его творчеству вообще стоит присмотреться, с цветом можно делать что угодно):
http://avisynth.org/vcmohan/HistogramAdjust/HistogramAdjust.html
Также фильтры ColourLike и Average авторства mg262. Подробности здесь:
http://forum.doom9.org/showthread.php?t=96308
http://forum.doom9.org/showthread.php?p=717192
К сожалению, автор долгое время отсутствует, поэтому сами фильтры качать отсюда:
http://forum.doom9.org/showthread.php?t=118430
Если будете работать с указанными выше фильтрами, то можете поизвращаться дополнительно еще таким способом (на примере ColourLike):
Код:
Merge(ColourLike(*параметры*), *исходное видео*, 0.5)
По первому вопросу:
http://compression.ru/video/quality_measure/video_measurement_tool.html
но это всё компьютерные вычисления -- не забывайте об этом, человек субъективно воспринимает качество иначе.
Чтобы производить какие-либо автоматические выборки, необходимо задавать четкие критерии, которые при этом должны исчерпывающее описывать отбираемые объекты. Думаю, что вряд ли представляете таковые, глядя на свои два исходника...
Что касается самих исходников, то они приблизительно одинакового уровня -- высокого, поэтому сравнивать их качество по скриншотам -- бессмысленно. Складывается впечатление, что они не хуже и не лучше, а просто чуть-чуть разные, где-то на уровне разного распределения шумов квантования. Или хотите получить еще одно видео с третьим вариантом распределения? По-моему, не очень продуктивная затея.
|
|
|
|
oneoneleven
Стаж: 14 лет 11 месяцев Сообщений: 619
|
oneoneleven ·
24-Июн-12 09:58
(спустя 10 часов)
|
|
|
|
eronex
Стаж: 15 лет 9 месяцев Сообщений: 427
|
eronex ·
24-Июн-12 10:57
(спустя 58 мин.)
Здравствуйте!
Пакетная конвертация видео, используя аппаратное ускорение.
Например есть у AMD средство для получения divx-видео ресурсами видеокарты, но там каждый конвертируемый файл выбирается отдельно.
Есть FormatFactory, которым удобно конвертировать сразу множество файлов, но при этом видеокарта простаивает.
Существует ли средство конвертации видео, совмещающее в себе преимущества аппаратного кодирования и пакетной обработки? Или можно ли так настроить кодеки, чтобы они использовали аппаратное ускорение?
|
|
|
|
shark000X
Стаж: 14 лет 4 месяца Сообщений: 434
|
shark000X ·
24-Июн-12 11:42
(спустя 45 мин., ред. 24-Июн-12 11:42)
eronex
- AVCWare Video Converter
- Movavi
- Badaboom
Однако, к сведению: самый популярный кодек х264, ввиду своей архитектуры, не способен и никогда не будет поддерживать кодирование с помощью ресурсов видеокарты. При этом, возможности GPU могут быть использованы для предварительной фильтрации, если разработчики фильтров позаботились об этом.
|
|
|
|
eronex
Стаж: 15 лет 9 месяцев Сообщений: 427
|
eronex ·
24-Июн-12 13:53
(спустя 2 часа 10 мин.)
shark000X писал(а):
eronex
- AVCWare Video Converter
- Movavi
- Badaboom
Однако, к сведению: самый популярный кодек х264, ввиду своей архитектуры, не способен и никогда не будет поддерживать кодирование с помощью ресурсов видеокарты. При этом, возможности GPU могут быть использованы для предварительной фильтрации, если разработчики фильтров позаботились об этом.
Спасибо!
А можно ли кодеки из комплекта K-Lite Codec Pack настроить таким образом, чтобы максимум где это возможно использовалось аппаратное ускорение, и как это сделать? Заметил, что при конвертации используется mencoder, но он в свою очередь ведь ffdshow использует и LAV-кодеки, так? Или какие там цепочки?
|
|
|
|
unreal666
Стаж: 16 лет 10 месяцев Сообщений: 1713
|
unreal666 ·
24-Июн-12 15:23
(спустя 1 час 30 мин., ред. 24-Июн-12 15:23)
eronex писал(а):
Или какие там цепочки?
mencoder сам по себе.
тем более ffdshow и LAV-кодеки - это декодеры, а не кодеры (хотя в ffdshow есть какие-то кодеры, но некоторые из него уже выкинуты: x264 и чего-то еще; да и ресурсы GPU он все равно для кодирования не использует)
eronex писал(а):
А можно ли кодеки из комплекта K-Lite Codec Pack настроить таким образом, чтобы максимум где это возможно использовалось аппаратное ускорение, и как это сделать?
для кодирования никак.
|
|
|
|
shark000X
Стаж: 14 лет 4 месяца Сообщений: 434
|
shark000X ·
25-Июн-12 20:06
(спустя 1 день 4 часа, ред. 25-Июн-12 22:38)
unreal666
Привет!
Не запускается ffmpeg.exe сборки libav -- даже с ключем "-help" (путь короткий). Капец, я в шоке... что за чертовщина. Подскажешь че-нить дельное -- как решить проблему и в чем она порыта?
|
|
|
|
unreal666
Стаж: 16 лет 10 месяцев Сообщений: 1713
|
unreal666 ·
26-Июн-12 03:56
(спустя 7 часов, ред. 26-Июн-12 03:56)
shark000X писал(а):
ffmpeg.exe сборки libav
Я ffmpeg использую очень редко, поэтому даже не знаю, что за libav сборка.
Какие еще виды сборки есть?
ЗЫ.
Развелось этих ffmpeg'ов.
- группа разработчиков FFmpeg теперь продолжает разработку FFmpeg под именем Libav. Притом, что сам ffmpeg выкинули и вместо него используется avconv с отличающимся синтаксисом.
- на ffmpeg.org (дизайн сайта, кстати, такой же как на libav.org) бинарников под винду вообще не нашел. И если это не разработчики ffmpeg (судя по пункту выше), то тогда кто это разрабатывает?
- еще есть ffmpeg от LAV.
|
|
|
|
shark000X
Стаж: 14 лет 4 месяца Сообщений: 434
|
shark000X ·
26-Июн-12 10:37
(спустя 6 часов, ред. 26-Июн-12 10:37)
unreal666
Проект FFmpeg разделился на два "враждующих" более года назад. Один остался под прежним именем, а второй -- Libav. Основа у обоих осталась прежняя, просто Libav в ряде случаев поменял синтаксис и порядок обращения, чтобы не было взаимной совместимости. Бытует мнение, что после развода тырят друг у друга идеи но не суть важно. На одном из компов у меня Libav не запускается, так называемая "static" сборка (видимо кривые костыли ей приделали). Уже обошел проблему -- скачал свежую "ночную", часики затикали.
ПС: ffdshow и LAV каким-то образом умудряются использовать наработки обоих вариантов FFmpeg, но основа вроде бы Libav, если не ошибаюсь.
|
|
|
|
