x264 - обратите внимание! (часть 2я)

Делимся опытом. Задаем вопросы и отвечаем на них. Обсуждаем статьи и новости.

Модератор: Модераторы Обсерватории

x264 - обратите внимание! (часть 2я)

Сообщение VicoNT » Вс дек 25, 2005 12:06 pm

В связи с "переполнением" предыдущей ветки о x264, диалог продолжаем здесь.
Предыдущая часть обсуждения доступна по этой ссылке
Последний раз редактировалось VicoNT Вт май 02, 2006 12:38 pm, всего редактировалось 1 раз.
Жизнь нужно прожить так, чтобы Боги в восторге предложили еще одну //// Жизнь удалась, если коньяк, который мы пьем, старше женщин, с которыми мы спим
VicoNT
Капитан 2го ранга
Капитан 2го ранга
 
Сообщения: 5809
Зарегистрирован: Чт янв 01, 1970 6:00 am
Откуда: Новосибирск

Сообщение Igor_D » Пн дек 26, 2005 10:54 am

Да, Апаче, а ну ка покажи как на бейсике спецы програмируют (в сводное время от работы, консерватории,а/в копресии и мало ещё чего). Это вам не Билл Гейтс со своим С/С++ :lol: . Да и все а/в кодеки сегодня написаны на С/С++ но это ни о чём не говорит, неправда ли? :x . И вся элетронника просто не существовала бы сегодня без с/с++ + ассемблер. Но кому это важно, не правда ли?

Видели что х264 вышел победителем на думе9. Мне не обидно за то кто из кодеков стандарта Н.264 займёт в сравнении первое место.
Даже наоборот рад за х264. :)
Только это неправда. 1-е Место было уступлено х264 как представителю открытых исходников, чтобы привлечь больше интереса у потенциальных разработчиков, чтобы потом же обогатиться за счёт тех же открытых источников. Да и разница между этими двумя кодеками совсем не большая.

Одним словом говоря, Н.264 станет черезвычайно востребованным и популярным.
Igor_D
Лейтенант
Лейтенант
 
Сообщения: 633
Зарегистрирован: Сб сен 11, 2004 9:10 am

Сообщение Andy-Andrei » Пн дек 26, 2005 11:18 am

И........ что? :)

Вы развивайте свою мысль, развивайте :)
Andy-Andrei
Капитан-Лейтенант
Капитан-Лейтенант
 
Сообщения: 877
Зарегистрирован: Пн июл 14, 2003 8:50 pm
Откуда: Северный Кавказ

Сообщение SCIF » Пн дек 26, 2005 1:14 pm

Что за рождественская сборка? Что в себя включает? У всех шарктузовские документы на x264.nl не открываются или только во Вл-оке?
SCIF
Капитан-Лейтенант
Капитан-Лейтенант
 
Сообщения: 849
Зарегистрирован: Ср июл 14, 2004 1:02 pm
Откуда: г.Владивосток

Сообщение nitri » Пн дек 26, 2005 1:28 pm

Apache2 писал(а):Э.. я тут поспорю!! у меня было 3-4 различный ролика.. и везде менял только кол B-fr и Ref и делал SSIM тесты.. результаты всегда показывали повышение SSIM-а. Также нужно учитывать, что меняеться размер конечного файла.. не помню в какой сторону на %1-6.. это тоже нужно учитывать.
Если построить график зависимости B-fr и увеличения SSIM:
0 B-fr = 0%
от 1 до 5 B-fr = 20-60%(очень ощутимо меняеться)
от 6 до 10 B-fr = 65-85% (есть ещё прирост)
от 11 до 16 B-fr = 90%-100% (оч малые изменения.. но есть)
от 17 до 32 B-fr = 100% (увеличение не происходит, т.е. 16 - это предел)..


Решил кое что проверить поэтому отвечаю с запозданием.
Результаты следующие:
1 b-fame SSIM 75.28
3 b-fame SSIM 74.43
16 b-fame SSIM 75.01
Проверяю уже не в первый раз. Цифры могут менятся но тенденция сохраняется, изменения как правило незначительны и не в положительную сторону

настройки следующие:
"x264.exe" --pass 2 --bitrate 692 --stats ".stats" --no-fast-pskip --bframes 1 --subme 6 --weightb --analyse all --8x8dct --qpmax 35 --direct none --me umh --progress --no-psnr --output "" ""
остальные поумолчанию поскольку их изменение как правило ни к чему хорошему не ведут
Вопрос следующий. Что вы такое делаете, что результат меняется на прямо противоположный и SSIM вдруг начинает возростать с увеличением b-fame
nitri
Старшина 2ой статьи
Старшина 2ой статьи
 
Сообщения: 141
Зарегистрирован: Пн июн 20, 2005 2:07 pm

Сообщение MuTeK » Пн дек 26, 2005 1:41 pm

Apache2
А почему такая лажа с мульти-проц в x264?
Неужели нельзя было сделать нормальную слайс-обработку?, например.. чтобы данные поиска движения и т.п. между собой контактировали? ведь оперативная память одна, и не кодировались отдельно как 4 квадрата.


придумай лучше :lol:, а вообще-то в x264 и у атема стоит нормальная слайс обработка. Энкодер разбивает картинку на слайсы, и количество слайсов равну количество процов. Это самый простой и действующий метод, когда скорость практически линейно растет с увеличением процов.

Igor_D писал(а):Видели что х264 вышел победителем на думе9. Мне не обидно за то кто из кодеков стандарта Н.264 займёт в сравнении первое место. Даже наоборот рад за х264. :)
Только это неправда.


видели :wink:, После основного раунда, когда нас не пропустили в финал сразу стало ясно почему выбрали таких финалистов и кто будет победитель.
MuTeK
Лейтенант
Лейтенант
 
Сообщения: 498
Зарегистрирован: Пт сен 17, 2004 12:09 pm
Откуда: г. Томск

Сообщение Vitaly » Пн дек 26, 2005 4:51 pm

Решил таки попробовать кодировать х264
Закодировал одну сцену - неплохо.
Решил пожать фильм целиком.
Забил задачу в 3 прохода. Утром смотрю - качество зашибись, но всё вверх ногами!!! :evil:

Не ребята, пошел я обратно на Xvid пока до ума не доведут x264 и им нормально пользоваться можно будет.
Vitaly
Лейтенант
Лейтенант
 
Сообщения: 447
Зарегистрирован: Ср ноя 05, 2003 1:21 pm
Откуда: Луганск

Сообщение MuTeK » Пн дек 26, 2005 6:43 pm

nitri писал(а):Вопрос следующий. Что вы такое делаете, что результат меняется на прямо противоположный и SSIM вдруг начинает возростать с увеличением b-fame

это ты спроси у кого SSIM растет.
Обычно SSIM хорошо растет до 2-х B фреймов, если ставить 3, то желательно включать референсы на B фреймах. от 4 и выше пользы 0.
MuTeK
Лейтенант
Лейтенант
 
Сообщения: 498
Зарегистрирован: Пт сен 17, 2004 12:09 pm
Откуда: г. Томск

Сообщение Igor_D » Пн дек 26, 2005 8:08 pm

MuTeK писал(а):Apache2
видели :wink:, После основного раунда, когда нас не пропустили в финал сразу стало ясно почему выбрали таких финалистов и кто будет победитель.


А ведь немцы, ещё демократами себя считают. :cry:
Igor_D
Лейтенант
Лейтенант
 
Сообщения: 633
Зарегистрирован: Сб сен 11, 2004 9:10 am

Сообщение nitri » Пн дек 26, 2005 8:09 pm

MuTeK писал(а):
nitri писал(а):Вопрос следующий. Что вы такое делаете, что результат меняется на прямо противоположный и SSIM вдруг начинает возростать с увеличением b-fame

это ты спроси у кого SSIM растет.
Обычно SSIM хорошо растет до 2-х B фреймов, если ставить 3, то желательно включать референсы на B фреймах. от 4 и выше пользы 0.


Это вполне укладывается в мои представления (про референсы кстати тоже не забываю), но я неоднократно видел здесь советы ставить 3 b-frame, а также утверждение что при 16 показания метрических тестов возрастают (без визуального улучшения)
Мой вопрос направлен к Apache2 чью цитату я и привел или к любому кто знает ответ
nitri
Старшина 2ой статьи
Старшина 2ой статьи
 
Сообщения: 141
Зарегистрирован: Пн июн 20, 2005 2:07 pm

Сообщение RBF » Пн дек 26, 2005 9:39 pm

Vitaly
пошел я обратно на Xvid пока до ума не доведут x264

Так ты хочешь, чтобы до твоего ума довели? Тогда лет через 10 :D
А если серьезно, то переворачивание картинки ни у кого еще не встречалось :roll: .

nitri
Мой вопрос направлен к Apache2 чью цитату я и привел или к любому кто знает ответ

Да вроде кроме Apache2 ни у кого SSIM не отрастает :D
RBF
Капитан-Лейтенант
Капитан-Лейтенант
 
Сообщения: 1355
Зарегистрирован: Пт дек 19, 2003 2:42 pm

Сообщение Apache2 » Пн дек 26, 2005 9:46 pm

Igor_D:
Да, Апаче, а ну ка покажи как на бейсике спецы програмируют (в сводное время от работы, консерватории,а/в копресии и мало ещё чего). Это вам не Билл Гейтс со своим С/С++ . Да и все а/в кодеки сегодня написаны на С/С++ но это ни о чём не говорит, неправда ли? . И вся элетронника просто не существовала бы сегодня без с/с++ + ассемблер. Но кому это важно, не правда ли?


Вообще-то сейчас модно на VB .NET 2005 клепать программы..
Язык имеет теперь все восможности языка высокого уровня+преждняя простота.

Кстати, MeGui тоже написан на студии .NET 2005


а вот что форум начинает глючить на 50 странице и это не могут исправить - это уже кому-то на пенсию нужно.. или меньше пить:)

Я очень попрошу, раз такое дело VicoNT-а, чтобы он отредактировал своё первое сообщение и вставил ссылку предыдущего форума.. для чайников, кто сюда попал.. и не видел начала..

Сейчас разберусь ещё раз с B-frames, проведу доп. тесты.. и напишу подробные результаты..
Apache2
Старшина 2ой статьи
Старшина 2ой статьи
 
Сообщения: 186
Зарегистрирован: Пн май 02, 2005 11:38 pm

Сообщение Igor_D » Пн дек 26, 2005 10:17 pm

Если кто-то (а именно Апаче :) ) протестировал на одном отрывке видео что би-фреймы >3 увеличивают SSIM. Это мало что доказывает. Может быть источник был короткий и статистическим.

По теории вероятности (извените что так замудренно но иначе нельзя)
количество тестирумых отрывков должно быть не меньше 8, а для научных опытов как минимум 16. В случае с бифреймами длительность видео также имеет значение. Тут я могу ошибиться (уж слишком зависит от источника) но надо тестировать от 1,5-10 минут и выше.

Я бы протестировал так. По нарастащей один и тот же источник, который бы содержал в себе все виды движения high, low motion, zoom, глобальное движение итд. Другими словами
1 тест : 1,5 минут , 2 тест - 2-3 мин ........ 8 тест - 10 мин.

Знаю что неохота, ну зато будут правдивые результаты.
Хотя с би-фреймами и так ясно. 2 би- фрейма - норма. 3 - ещё может быть прирост. У Хвида более 2 би-фреймов только на мультфильмах.
Igor_D
Лейтенант
Лейтенант
 
Сообщения: 633
Зарегистрирован: Сб сен 11, 2004 9:10 am

Сообщение RBF » Пн дек 26, 2005 11:57 pm

Apache2
У меня тут такой появился актуальный вопрос, на счёт загрузки процессора при воспроизведении клипов x264: Чем можно нормально воспроизводить им такие фильмы, когда не хватает 5-20% процессорного времени?

Тут на думе на этот счет интересная идея появилась. Пережимать в уже закодированном клипе CABAC в CAVLC, который быстрее разжимается. Эта операция происходит без потерь. Проги пока нет.
Закодируй одно и тоже с CABAC и CAVLC и проверь, насколько быстрее декодирование.
RBF
Капитан-Лейтенант
Капитан-Лейтенант
 
Сообщения: 1355
Зарегистрирован: Пт дек 19, 2003 2:42 pm

Сообщение Apache2 » Вт дек 27, 2005 1:45 am

А почему такая лажа с мульти-проц в x264?
Неужели нельзя было сделать нормальную слайс-обработку?, например.. чтобы данные поиска движения и т.п. между собой контактировали? ведь оперативная память одна, и не кодировались отдельно как 4 квадрата.


придумай лучше , а вообще-то в x264 и у атема стоит нормальная слайс обработка. Энкодер разбивает картинку на слайсы, и количество слайсов равну количество процов. Это самый простой и действующий метод, когда скорость практически линейно растет с увеличением процов.


У меня есть способ по-лучше реализации многоядерности и не один:

1) При личном программировании замечаю, что в любом коде есть ряд операторов-функций, которые друг-сдругом не находяться в прямой зависимости.
т.е. порядок их выполнения может быть не последовательный.
и их можно направить на 2-а и более потоков процессоров.

И вообще, зачем программа должна считать сколько у компа камней стоит??
Конечный вариант:
сгруппировать последовательные и непоследовательные места кода x264
и где код может выполняться непоследовательно - с этой точки разделять потоки на Х количество, может получиться до 100 программный потоков, которые должны могут выполняться одновременно.

А система.. скажем Windows сама решит, какой поток на какой процессор положить, чем больше процессоров - тем быстрее будет молоть потоки:)


2) Можно разбить видео на временные куски скажем 4-ядра - 4клипа из одного.
1-й проход сбор статистики: одновременно в один файл-базу данных
2-й проход кодирование видео: тоже самое.. только в промежуточный формат.. который потом объединяеться в один файл
недостаток 2-го способа - комьютеру нужен больший запас оперативной памяти.
Apache2
Старшина 2ой статьи
Старшина 2ой статьи
 
Сообщения: 186
Зарегистрирован: Пн май 02, 2005 11:38 pm

Сообщение Apache2 » Вт дек 27, 2005 1:49 am

Кстати, вот моя рабочая строчка для кодирования видео в 2-а прохода(704 x 384, 43секудны длит.):
"x264.exe" --pass 2 --bitrate 800 --stats ".stats" --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --nf --subme 6 --b-rdo --weightb --trellis 2 --analyse all --8x8dct --ratetol 99.0 --progress --no-psnr


Помню шёл разговор о медлительности..
тестировал новую сейчас версию - скорость у меня составила 2 fps!! (на Атлоне 1900), вместо предыдущей 1,4-1,5
ускорились они однако.

SSIM получился Average SSIM= 75.06 (вместо предыдущего 75.05)

Далее как рекомендовал Игорь отключил би-пирамид, чтобы видео могло воспроизводиться декодерами Неро
Но тесты делаю на декодере ffddshow! без каких-либо пост обратоток, которые в Неро делаються автоматически.
Скорость вообще не изменилась.. от отключения опции би-пирамид


Качество: Average SSIM= 75.25
ну ничего себе!!

посмотрел размеры файла.. ага.. с би-пирамид-4244кб и без би-пирамид-4351кб!!
это на 3% больше размер файла.. не удивительно из-за чего SSIM поднялся..

Решил выяснить до конца, что даёт эта опция на практике.
и ещё хочу выяснить что она делает с B-fr при кодировании?? Кто объяснит?

Специально подогнал битрейт с --b-pyramid, чтобы был равен 4351кб, а точнее получилось: 4350кб (на 1 кб меньше)

и Сделал SSIM тест, кто кого..:
Оп-ля-ля: Average SSIM= 75.37 против 75.25
так что чистый прирост би-пирамид даёт 0,17 SSIM (это больше чем 3-й проход!:)
но требует ffddshow декодер, который на 15-20% медленнее Nero


Едем дальше, выясняем что на практике дают кол-ва B-frames:

строка для кодирования:
"x264.exe" --pass 2 --bitrate 800 --stats ".stats" --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --nf --subme 6 --b-rdo --weightb --trellis 2 --analyse all --8x8dct --ratetol 99.0 --progress --no-psnr

менял только кол B-frames:
16b = Average SSIM= 75.25 (4244кб)
8b = Average SSIM= 74.97 (4211кб)
4b = Average SSIM= 74.94 (4195кб)
2b = Average SSIM= 74.75 (4173кб)

Везде скорость почти не менялась! в ределах 0.05 fps

как видите, с уменьшением B-fr - SSIM падает.. но также незначительно падает размер файлов.. что делает сравнение довольно необъективным.
Ради справедливости подогнал битрейт 16b к размеру файла 2b (4173кб) и сравнил SSIM:

Получилось два файла с одинаковыми размерами (отличия пару байт:)
один 2b - Average SSIM= 74.75
другой 16b - Average SSIM= 74.86

Так что смело дерзайте! Закрываю этот вопрос.
B-frames увеличиват SSIM и нисколько не заметляет скорость кодирования.
Но B-frames=16 нужно использовать с другими опциями, относящимися к B.
Apache2
Старшина 2ой статьи
Старшина 2ой статьи
 
Сообщения: 186
Зарегистрирован: Пн май 02, 2005 11:38 pm

Сообщение Apache2 » Вт дек 27, 2005 2:14 am

Решил таки попробовать кодировать х264
Закодировал одну сцену - неплохо.
Решил пожать фильм целиком.
Забил задачу в 3 прохода. Утром смотрю - качество зашибись, но всё вверх ногами!!!

Не ребята, пошел я обратно на Xvid пока до ума не доведут x264 и им нормально пользоваться можно будет.


Не знаю кто это написал.. но хоть пишут, что х264 экспериментальный енкодер, но на самом деле он таких ошибок никогда не выдавал..
я не знаю что у тебя случилось.. ты сам где-то ошибся..
Люди достаточно тестировали x264 и ни у кого откровенных глюков никогда не было.


Если кто-то (а именно Апаче ) протестировал на одном отрывке видео что би-фреймы >3 увеличивают SSIM. Это мало что доказывает. Может быть источник был короткий и статистическим.


43 секунды.. 704 x 384
источник нормальный DVD -файл
сцена - содердит как оч динамические сцены, полу-динамику.. и чуть статику. где-то 5-7 смен панорам.. хорошая яркость, есть светлые и небольшой тёмный эпизод, содержит оч. слабый шум.. ну как впрочем большинство дисков DVD и типичный сюжет из большинства фильмов.

отличный тестовый файл со всем набором.


Я бы протестировал так. По нарастащей один и тот же источник, который бы содержал в себе все виды движения high, low motion, zoom, глобальное движение итд. Другими словами


Я как раз об этом!!


Всё это касалось предыдущего моего теста.
Так же раньше тестил кол-B-frames и на других фильмах.. и на мультиках.. длительность везде была от 40 сек - до 1:10
результат одинаковый. было 4 клипа и везде один результат.


Я бы протестировал так. По нарастащей один и тот же источник, который бы содержал в себе все виды движения high, low motion, zoom, глобальное движение итд. Другими словами
1 тест : 1,5 минут , 2 тест - 2-3 мин ........ 8 тест - 10 мин.


Не вопрос, сча возьму другой источник и закодирую мин 10.
и сделаю тест.

У меня тут такой появился актуальный вопрос, на счёт загрузки процессора при воспроизведении клипов x264: Чем можно нормально воспроизводить им такие фильмы, когда не хватает 5-20% процессорного времени?

RBF
Тут на думе на этот счет интересная идея появилась. Пережимать в уже закодированном клипе CABAC в CAVLC, который быстрее разжимается. Эта операция происходит без потерь. Проги пока нет.
Закодируй одно и тоже с CABAC и CAVLC и проверь, насколько быстрее декодирование.


а как закодировать в CAVLC ??
раньше помню была птичка над CABAC, а теперь её нигде нет:((
Apache2
Старшина 2ой статьи
Старшина 2ой статьи
 
Сообщения: 186
Зарегистрирован: Пн май 02, 2005 11:38 pm

Сообщение Igor_D » Вт дек 27, 2005 2:33 am

Apache2 писал(а):один 2b - Average SSIM= 74.75
другой 16b - Average SSIM= 74.86


А где 3b? Тестер ты наш. Тот детский прирост в +0.11 и есть за счёт 3-го бифрейма. Ты посмотри в файле pass.log .... там же наверно на всё видео один раз может быть проскочат 3 би-фрейма в последовательности. 4 би-фрейма это уже будет феномен.

1 bframes - high motion
2 bfrmaes - нормальное медленное движение
3 bframes - практически нет движения

4 bframes - не возможно для реального фильма.
Igor_D
Лейтенант
Лейтенант
 
Сообщения: 633
Зарегистрирован: Сб сен 11, 2004 9:10 am

Сообщение RBF » Вт дек 27, 2005 4:48 am

Apache2
раньше помню была птичка над CABAC, а теперь её нигде нет

А поставить руками в командной строке, что не позволяет? Да и галка вроде на месте.
Так же раньше тестил кол-B-frames и на других фильмах

А деблокинг то зачем совсем отключаешь, да еще на битрейте 800? :roll:

Igor_D
Да, самое большое колличество бифреймов, которые я обнаружил в клипе закодированном с --bframes 16, это 5, но очень редко, в основном 2-3 :wink:
RBF
Капитан-Лейтенант
Капитан-Лейтенант
 
Сообщения: 1355
Зарегистрирован: Пт дек 19, 2003 2:42 pm

Сообщение Apache2 » Вт дек 27, 2005 5:12 am

А где 3b? Тестер ты наш. Тот детский прирост в +0.11 и есть за счёт 3-го бифрейма. Ты посмотри в файле pass.log .... там же наверно на всё видео один раз может быть проскочат 3 би-фрейма в последовательности. 4 би-фрейма это уже будет феномен.


Пожалуйста:
3b - Average SSIM= 74.93 (4194кб)
16b - Average SSIM= 74.94 (4195кб специально подогнал размер файла)

Хм.. ты прав достаточно указать 3-5 B-frames, и это предел.
Конечно, от 16 худо не бывает.. но зачем? В след раз буду ставить не более 5 :)
Apache2
Старшина 2ой статьи
Старшина 2ой статьи
 
Сообщения: 186
Зарегистрирован: Пн май 02, 2005 11:38 pm

След.

Вернуться в Софт: описание работы с пакетами, кодеками. Вопросы и ответы

Кто сейчас на конференции

Сейчас этот форум просматривают: Bing [Bot] и гости: 1