|
|
|
alfsuind
Стаж: 14 лет 8 месяцев Сообщений: 880
|
alfsuind ·
30-Окт-12 20:06
(12 лет 1 месяц назад)
kirill_sky
FillMargins поддерживает только цветовой формат YV12 (он на DVD, Blu-ray...). Могу предположить, что исходный материал грузится через DirectShowSource, а декодер, установленный в системе, выдает сразу RGB. Соответственно, использовать FFVideoSource, AVCSource... или найти настройки этого декодера (например, в MPC HomeCinema правой кнопкой по видео - фильтры - какой-нибудь decoder).
|
|
|
|
Vivianus
Стаж: 14 лет 11 месяцев Сообщений: 5772
|
Vivianus ·
31-Окт-12 01:20
(спустя 5 часов, ред. 31-Окт-12 01:20)
Yurasyk писал(а):
56034435
Vivianus писал(а):
56034361Если взять видео с 30 к/с и сделать 15, будет ли изменение качества при таком же битрейте?
если учесть убитость картинки прореживанием кадров, то никакого улучшения качества не будет.
Сделал эксперимент :
скрытый текст
Оригинал RGB 14,985 fps (свойства проекта Sony Vegas - 14,985 fps, рендеринг 14,985 fps):
http://linkme.ufanet.ru/images/d4f178b074092f491ff6c1d7b64b7b79.png
То же самое, 14/14, но уже после обработки youtube:
14,985 fps (свойства проекта Sony Vegas - 14,985 fps, рендеринг 14,985 fps):
http://linkme.ufanet.ru/images/0f0fcb2738130aa643fef3e9ef454e01.png
http://www.youtube.com/watch?v=pmHBBvh_-pM
===
29,970 fps, полученные из 14,985 путем дублирования кадров в Virtualdub (свойства проекта Sony Vegas - 14,985 fps, рендеринг 14,985 fps, Virtualdub - Convert to fps 29,970 ):
http://linkme.ufanet.ru/images/9e3d903cb32d3ad756b000125b94ca29.png
http://www.youtube.com/watch?v=GUyn0JAmi_8
===
29,970 fps (свойства проекта Sony Vegas - 29,970 fps, рендеринг 29,970 fps):
http://linkme.ufanet.ru/images/3e7e0d7b2c0bc9dc0d6e381d69897da2.png
http://www.youtube.com/watch?v=l2yoF5XraZk
14fps и 29, полученные из 14 путем дублирования кадров, отличить не смог - различия есть, но что лучше, не увидел.
29fps, полученные из 29fps, явно хуже, так как меньше четкости и больше артефактов по краям линий. Когда просматривал видео с 29fps, полученное из видео с 14fps путем дублирования кадров, в Sony Vegas на таймлайне с 29fps, то кадры дубликаты ничем не отличаются от оригинальных, видимо, кодек просто копирует одинаковый кадр или дает декодеру прочитать один кадр 2 раза (не знаю, как на самом деле он это делает) по принципу нулевых кадров в кодеке Lagarith.
Выходит, что если видео медленное, и на глаз разницы в движении не заметно (не появляется эффект строба strobe), то, по крайней мере, для youtube лучше делать меньше кадров. Хотя, вероятно, что в другом случае с другим видео результат будет обратным
PS В Sony Vegas у всех видео отключил motion blur и поставил Disable resample, иначе Smart resample вместо двойных кадров у видео с 14fps, удаляя кадры дубликаты, генерировал ужасные смазанные промежуточные кадры. До этого не знал, что он такое делает в случае, когда видео с 14fps добавляешь на таймлайн с 29fps. Скриншоты взяты из первой части видео - там где движение. В свойствах проекта, где сравнивал видео, выставил Pixel format 32 bit floating point (Full Range) Compositing gamma 1.0 (linear), чтобы видео avc не декодировались к TV-range (16-235).
Вывод: В общем, логично, что качество у 29fps хуже, т.к. больше кадров делят между собой битрейт, но было интересно, может ли картинка быть четче за счет большего числа ключевых кадров, которых в видео с 29fps наверно больше, или по другой причине .
|
|
|
|
degifly
Стаж: 14 лет 2 месяца Сообщений: 951
|
degifly ·
31-Окт-12 01:36
(спустя 16 мин.)
Vivianus писал(а):
56054254Выходит, что если видео медленное, и на глаз разницы в движении не заметно (не появляется эффект строба strobe)
На данном видео оно очень сильно заметно. Да и вообще практически не существует видео, на котором это незаметно. Поэтому надо на 60 фпс переходить, а не на 15 
Vivianus писал(а):
56054254то, по крайней мере, для youtube лучше делать меньше кадров.
На ютубе отвратительный энкодер, он даже практически статичное видео не может нормально закодировать.
Логично что при кодировании с одинаковым битрейтом видео с меньшим фпс будет иметь кадры лучше (в сравнении с другим результатом кодирования). Но на таких битрейтах, на которых будет заметно разница видео лучше вообще не кодировать.
Vivianus писал(а):
56054254но было интересно, может ли картинка быть четче за счет большего числа ключевых кадров, которых в видео с 29fps наверно больше
для начала достаточно ознакомиться с параметрами кодирования x264, которыми можно это задать...
|
|
|
|
ka81
Стаж: 18 лет 4 месяца Сообщений: 1233
|
ka81 ·
06-Ноя-12 15:27
(спустя 6 дней)
Приветствую.
Мной был куплен лот http://www.ebay.com/itm/170930234533 - это первые три сезона сериала - https://rutr.life/forum/viewtopic.php?t=1011540
На дисках - только английский язык. Поэтому выкладывать тут их не выйдет, пока не будет подключена русская дорога.
Я буду заниматься синхронизацией русской и украинской дороги под эти материалы.
Надо бы перекодировать купленный ДВД материал в рипы AVC с максимально возможным лучшим видео и аудиокачеством в формат MKV (ну чтобы "железяки" тоже читали).
Я профан в деле КАЧЕСВТЕННОГО конвертирования из DVD в MKV (AVC).
Посему обращаюсь к вам - не будет ли у кого возможности помочь с этим?
В любом случае - благодарствую!
|
|
|
|
alfsuind
Стаж: 14 лет 8 месяцев Сообщений: 880
|
alfsuind ·
11-Ноя-12 20:02
(спустя 5 дней, ред. 11-Ноя-12 20:02)
Как выбрать битрейт и ключевые параметры для кодирования Blu-ray, часть 2 - как все-таки надо :).
Новый выпуск концерта Queen ( диск / ремукс с MediaInfo) закодирован с --pass 2 --bitrate 33000 --preset veryslow --tune film + ограничения Blu-ray + 16 логических ядер CPU :). Уже лучше.
|
|
|
|
unreal666
Стаж: 16 лет 11 месяцев Сообщений: 1713
|
unreal666 ·
11-Ноя-12 20:43
(спустя 40 мин.)
alfsuind писал(а):
56269653+ 16 логических ядер CPU
а с чего ты взял, что 16 логических ядер ? Там видно только, что кодилось в 24 потока.
|
|
|
|
Ювелир
Стаж: 14 лет Сообщений: 6434
|
Ювелир ·
11-Ноя-12 20:47
(спустя 4 мин.)
unreal666 писал(а):
56270659а с чего ты взял, что 16 логических ядер ? Там видно только, что кодилось в 24 потока.
Ну как бы параметр threads автоматом ставится равный 1,5*кол-во ядер. Не? 
|
|
|
|
unreal666
Стаж: 16 лет 11 месяцев Сообщений: 1713
|
unreal666 ·
11-Ноя-12 20:50
(спустя 2 мин.)
может они вручную выставляли нужное кол-во. Я, к примеру, кодю в 12 потоков с 6 ядрами.
|
|
|
|
Yurasyk
Стаж: 16 лет 2 месяца Сообщений: 3506
|
Yurasyk ·
11-Ноя-12 20:52
(спустя 1 мин.)
Ювелиp писал(а):
56270760Ну как бы параметр threads автоматом ставится равный 1,5*кол-во ядер
Ну какбы никто не мешает его задать вручную. Но скорее всего здесь таки работала парочка Ксеончиков.
|
|
|
|
Ювелир
Стаж: 14 лет Сообщений: 6434
|
Ювелир ·
11-Ноя-12 21:08
(спустя 15 мин.)
Yurasyk писал(а):
56270862Ну какбы никто не мешает его задать вручную.
ну в принципе да. только в чём соль? 
единственное знаю, что кодируя xvid'ом, надо параметр threads (для ускорения энкода) ставить точно равный кол-ву ядер, хотя автоматом ставит так же 1,5x...
unreal666 писал(а):
56270816Я, к примеру, кодю в 12 потоков с 6 ядрами.
повторюсь: в чем соль?
артефактов не наблюдается? а то много раз читал про перегрузку кодека из-за превышения...
|
|
|
|
unreal666
Стаж: 16 лет 11 месяцев Сообщений: 1713
|
unreal666 ·
11-Ноя-12 21:18
(спустя 10 мин., ред. 11-Ноя-12 21:18)
Ювелиp писал(а):
56271175артефактов не наблюдается?
не вижу. Да и некоторые люди на думе9 даже на кластерах или чем-то подобном кодили то ли в 32 , то ли в 64 потока. У x264 наблюдается некоторая деградация качества с увеличением кол-ва потоков, но не настолько сильно, чтобы это видеть при 12 потоках. При намного большем - может быть.
Ювелиp писал(а):
56271175повторюсь: в чем соль?
при 9 потоках мой феном загружается не полностью. Даже при 12 потоках система нормально отзывается и еще всякие сторонние тяжелые проги местами включаю во врея кодинга.
У AMD какая-то хитрожопная архитектура процов.
Да и данный блюрик тоже могли кодить на кластере с большим кол-вом ядер с принудительным указанием меньшего кол-ва потоков.
|
|
|
|
Ювелир
Стаж: 14 лет Сообщений: 6434
|
Ювелир ·
11-Ноя-12 21:33
(спустя 15 мин.)
unreal666
то есть получается небольшой прирост скорости из-за большей загруженности проца, при этом и небольшое ухудшение качества, так?
|
|
|
|
<VIRUS>
Стаж: 16 лет 5 месяцев Сообщений: 7354
|
<VIRUS> ·
11-Ноя-12 21:46
(спустя 13 мин., ред. 11-Ноя-12 22:48)
Ювелиp писал(а):
56271708unreal666
то есть получается небольшой прирост скорости из-за большей загруженности проца, при этом и небольшое ухудшение качества, так?
А почему должно быть ухудшение качества? Кодирование осуществляется по математическому алгоритму, который независим от методов машинной обработки, которые всего лишь предусмотривают оптимизацию вычислений, за счет использования дополнительных потоков.
|
|
|
|
agz
Стаж: 17 лет 6 месяцев Сообщений: 1444
|
agz ·
11-Ноя-12 21:47
(спустя 1 мин.)
unreal666, дык это не только на иксе. С XviD та же фигня. С увеличением кол-ва тредов шумы смазываются и становятся похожими не скажу на что. Кванты растут значительно.
|
|
|
|
Ювелир
Стаж: 14 лет Сообщений: 6434
|
Ювелир ·
11-Ноя-12 22:24
(спустя 37 мин.)
agz писал(а):
56272015С XviD та же фигня. С увеличением кол-ва тредов шумы смазываются и становятся похожими не скажу на что. Кванты растут значительно.
Но при этом на xvid скорость энкода не увеличивается... у меня она максимальна, когда threads=кол-ву ядер.
<VIRUS> писал(а):
56271966А почему должно быть ухудшение качества? Кодирование осуществляется по математическому алгоритму, который независим от методов машинной обработки, которые всего лишь предусмотренная оптимизация вычислений, за счет использования дополнительных потоков.
Вроде из-за перескакиваний с одного ядра на другое и при более сильных нагрузках проца, кодер менее точно что-то распределяет.
|
|
|
|
<VIRUS>
Стаж: 16 лет 5 месяцев Сообщений: 7354
|
<VIRUS> ·
11-Ноя-12 22:52
(спустя 27 мин., ред. 11-Ноя-12 22:52)
Ювелиp
Значит есть программные ошибки в оптимизации, потому что алгоритм в любом случае должен быть неизменен. Ну да в любом случае, имеем то что есть.
|
|
|
|
Ювелир
Стаж: 14 лет Сообщений: 6434
|
Ювелир ·
11-Ноя-12 22:55
(спустя 3 мин.)
<VIRUS>
Может и так. Сам точно не знаю, не экспериментировал (лишнюю нагрузку давать - как то проц жалко) поэтому спорить не буду.
|
|
|
|
degifly
Стаж: 14 лет 2 месяца Сообщений: 951
|
degifly ·
11-Ноя-12 23:05
(спустя 9 мин., ред. 11-Ноя-12 23:05)
<VIRUS> писал(а):
56271966Кодирование осуществляется по математическому алгоритму, который независим от методов машинной обработки
и который воооообще не параллелится. Поэтому каждый поток независимо кодирует свой кадр. А т.к. он может ссылаться на еще незакодированные кадры - это имеет свои последствия:
Цитата:
The quality loss from multiple threads is mostly negligible unless using very high numbers of threads (say, above 16).
|
|
|
|
<VIRUS>
Стаж: 16 лет 5 месяцев Сообщений: 7354
|
<VIRUS> ·
11-Ноя-12 23:48
(спустя 43 мин.)
degifly писал(а):
56273524Поэтому каждый поток независимо кодирует свой кадр.
Непонятно как это вообще может быть, применительно к кодекам использующим ссылочные кадры. В них видеопоток не может быть разделен на какие-то отдельные единицы, меньшие чем GOP - как при монтаже, так и при кодировании и декодировании. Вот раскидывание отдельных GOP по потокам, это еще куда ни шло, потому что они независимы друг от друга.
degifly писал(а):
56273524А т.к. он может ссылаться на еще незакодированные кадры - это имеет свои последствия:
И как он может ссылаться на еще незакодированные кадры? Ведь ссылка на какой то кадр происходит после анализа его содержимого.
Впрочем это уже дебри в которые совсем не хочется лезть.
|
|
|
|
Tim68
Стаж: 14 лет 10 месяцев Сообщений: 712
|
Tim68 ·
12-Ноя-12 09:11
(спустя 9 часов, ред. 12-Ноя-12 09:11)
<VIRUS> писал(а):
56274580как он может ссылаться на еще незакодированные кадры?
Последовательности: хронологическая и кодирования/декодирования отличаются друг от друга, но тем не менее относятся к одному и тому же видеоряду.
|
|
|
|
Юpист
Стаж: 15 лет 11 месяцев Сообщений: 2729
|
Юpист ·
12-Ноя-12 21:07
(спустя 11 часов, ред. 12-Ноя-12 21:07)
agz писал(а):
56272015unreal666, дык это не только на иксе. С XviD та же фигня. С увеличением кол-ва тредов шумы смазываются и становятся похожими не скажу на что. Кванты растут значительно.
в иксе при разных треадсах выхлоп получается разный в байтах, c каждым новым потоком качество оч незначительно изменяется (заметил ещё на первых тестах), в иксвиде(73-й) - выхлоп одинаковый, что при 1, что при 8тр
using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
|
|
|
|
agz
Стаж: 17 лет 6 месяцев Сообщений: 1444
|
agz ·
12-Ноя-12 21:47
(спустя 39 мин.)
Юpист, ну я 1.2.2 использую
|
|
|
|
<VIRUS>
Стаж: 16 лет 5 месяцев Сообщений: 7354
|
<VIRUS> ·
12-Ноя-12 22:40
(спустя 53 мин.)
Юpист писал(а):
56288959в иксвиде(73-й) - выхлоп одинаковый, что при 1, что при 8тр
А скорость кодирования меняется сильно?
|
|
|
|
Ювелир
Стаж: 14 лет Сообщений: 6434
|
Ювелир ·
12-Ноя-12 23:06
(спустя 26 мин., ред. 12-Ноя-12 23:06)
<VIRUS> писал(а):
56291613А скорость кодирования меняется сильно?
Лично у меня, когда ставишь threads=кол-ву ядер, скорость возрастает где-то на 10-20 fps по сравнению с threads=auto. И это в модифицированном под многопоточность 73 билде.
|
|
|
|
degifly
Стаж: 14 лет 2 месяца Сообщений: 951
|
degifly ·
12-Ноя-12 23:16
(спустя 9 мин., ред. 12-Ноя-12 23:16)
<VIRUS> писал(а):
56274580Непонятно как это вообще может быть, применительно к кодекам использующим ссылочные кадры. В них видеопоток не может быть разделен на какие-то отдельные единицы, меньшие чем GOP - как при монтаже, так и при кодировании и декодировании.
До записи в файл (ну и до CABACа) - может.
<VIRUS> писал(а):
56274580И как он может ссылаться на еще незакодированные кадры? Ведь ссылка на какой то кадр происходит после анализа его содержимого.
На кадры источника. И анализировать (компенсацию движения, например) его же, а не с декодированный закодированный кадр.
|
|
|
|
MasterNobody
Стаж: 16 лет 4 месяца Сообщений: 158
|
MasterNobody ·
13-Ноя-12 02:02
(спустя 2 часа 46 мин., ред. 13-Ноя-12 02:02)
degifly писал(а):
На кадры источника. И анализировать (компенсацию движения, например) его же, а не с декодированный закодированный кадр.
Это плохой метод, большие потери компрессии, по правильному нужно использовать уже декодированный вариант для поиска движения. x264 просто напросто юзает синхронизацию потоков по мере готовности, т.е. когда в 1-м кадре уже закодировано N-строк, то можно приступать к кодированию M-строк из второго (а в это время количество закодированных строк в 1-м растет, увеличивая N), где M<N, ограничивая предсказании уже закодированной областью из 1-го (так что получается типа лесенки/конвейера).
|
|
|
|
CaNчEs
Стаж: 15 лет 5 месяцев Сообщений: 20
|
CaNчEs ·
16-Ноя-12 15:05
(спустя 3 дня, ред. 17-Ноя-12 13:24)
Есть ли какая специфика в кодировании черно-белого кино ?
|
|
|
|
Nitey
Стаж: 17 лет 3 месяца Сообщений: 3007
|
Nitey ·
16-Ноя-12 16:33
(спустя 1 час 28 мин.)
CaNчEs писал(а):
56350813Есть ли какая специфика в кодировании черно-белого кино ?
mbtree скорее всего не нужно.
|
|
|
|
alfsuind
Стаж: 14 лет 8 месяцев Сообщений: 880
|
alfsuind ·
16-Ноя-12 19:30
(спустя 2 часа 57 мин., ред. 16-Ноя-12 19:59)
Буду благодарен за настройки x264 под битрейт 2100. Не хочу позориться в киношном разделе с preset/tune/deblock/все :).
В сэмплах (SelectRangeEvery(Framecount()/50)) обработанное видео, сохраненное в CRF 10. В двух вариантах - без дальнейшей обработки и убрав шум через SMDegrain (настройки - TR 2, LSB, ContraSharp).
No Denoise (95 МБ) Narod / SendFile.su
Denoise (69 МБ) Narod / SendFile.su
|
|
|
|
Skazhutin
Стаж: 17 лет 5 месяцев Сообщений: 6701
|
Skazhutin ·
16-Ноя-12 19:32
(спустя 1 мин.)
Nitey писал(а):
56352064mbtree скорее всего не нужно
никак к черно-белому не относится, так же зависит от исходника
|
|
|
|
