Двач.hk не отвечает.
Вы видите копию треда, сохраненную 22 декабря 2018 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 22 декабря 2018 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
![f793262e9822825e48b40d31860bb15fdetails[1].png](https://2ch.hk//s/src/2389520/15372560568710.png)
356 Кб, 493x600Я обрабатываю много видео в 1080р. Поэтому возник вопрос обновить комп. Вот я думаю - видеоконвертер, скажем, FormatFactory, сможет загрузить полностью 6ти-ядерный Xeon с HyperThreading'ом (то есть 12 виртуальных ядер). И вообще, имеет смысл этот HyperThreading включить или выключить?
234 Кб, 570x740>>389520 (OP)
Вопрос ужасно неконкретный.
Ты же купил техподдержку! Обратись в неё! Не теряй свои деньги!
> сможет загрузить полностью 6ти-ядерный Xeon с HyperThreading'ом (то есть 12 виртуальных ядер). И вообще, имеет смысл этот HyperThreading включить или выключить?
Вопрос ужасно неконкретный.
> Вот я думаю - видеоконвертер, скажем, FormatFactory, сможет
Ты же купил техподдержку! Обратись в неё! Не теряй свои деньги!
>>389534
А если нужен высококачественный видеоматериал? А тоже хотел предложить, но ОП что-то не разъясняет, что там ему конкретно нужно. Вместо этого он там про важность и объёмы работ что-то рассказал. Что за современное воспитание?
> CUDA
А если нужен высококачественный видеоматериал? А тоже хотел предложить, но ОП что-то не разъясняет, что там ему конкретно нужно. Вместо этого он там про важность и объёмы работ что-то рассказал. Что за современное воспитание?
![x2430116416407805226414898350976794567709820n.jpg.pagespeed[...].jpg](https://2ch.hk//s/src/2389520/15372603724590.jpg)
128 Кб, 781x960>>389538
Да я у тебя её и спрашивал, кстати полгода назад. А вот вчера у себя в коллекции такую же нашёл. За номер, само собой не скажу, но там даты файлов должны быть очень несвежие.
Просто я двачую преимущественно с работы, а коллекция картинок дома, т.к. NSFW. А не ты со мной одну и ту же пасту про PowerDVD сохранил, случаем?
Да я у тебя её и спрашивал, кстати полгода назад. А вот вчера у себя в коллекции такую же нашёл. За номер, само собой не скажу, но там даты файлов должны быть очень несвежие.
Просто я двачую преимущественно с работы, а коллекция картинок дома, т.к. NSFW. А не ты со мной одну и ту же пасту про PowerDVD сохранил, случаем?
>>389523
Ну не знаю как объяснить проще.
Сколько ядер может загрузить видеоконвертер?
Если ядра виртуальные, то это повлияет на их максимально возможную загрузку?
И отсюда следует следующий вопрос:
Конвертация видео будет быстрее если HyperThreading включить или выключить?
Я скачал крэк с рутора.
>Вопрос ужасно неконкретный.
Ну не знаю как объяснить проще.
Сколько ядер может загрузить видеоконвертер?
Если ядра виртуальные, то это повлияет на их максимально возможную загрузку?
И отсюда следует следующий вопрос:
Конвертация видео будет быстрее если HyperThreading включить или выключить?
>Ты же купил техподдержку! Обратись в неё! Не теряй свои деньги!
Я скачал крэк с рутора.
374 Кб, 1600x1214>>389558
Ну, ты понел, кто ты такой.
Давай я попробую тебе помочь, но не просто так. Расскажешь мне прохладную, как ты до такой жизни докатился.
Какой исходный материал. Какой целевой стандарт сжатия? Какие параметры видеоряда: разрешение, цветовое пространство, дискретизация по каналам, частота кадров и прочее. Что за видеоматериал: содомский ниггерский анальный жопотрах, балет, онемэ, игрострим, свдьбы, корпоративы, стас михайлов?
Зависит от конкретной реализации (в виде программы или в кремнии). Её ты выбираешь, когда покупаешь затычку для слота от невидии, или когда устанавливаешь всекие мокренькие писеньки.
Если чисто программное кодирование, то повлияет только на метрики в мониторе ресурсов. Ну, может быть, качество чуток упадёт, но это зависит.
От этой перделки не должна. Она не для этого сделана.
> Я скачал крэк с рутора.
Ну, ты понел, кто ты такой.
Давай я попробую тебе помочь, но не просто так. Расскажешь мне прохладную, как ты до такой жизни докатился.
> Ну не знаю как объяснить проще.
Какой исходный материал. Какой целевой стандарт сжатия? Какие параметры видеоряда: разрешение, цветовое пространство, дискретизация по каналам, частота кадров и прочее. Что за видеоматериал: содомский ниггерский анальный жопотрах, балет, онемэ, игрострим, свдьбы, корпоративы, стас михайлов?
> Сколько ядер может загрузить видеоконвертер?
Зависит от конкретной реализации (в виде программы или в кремнии). Её ты выбираешь, когда покупаешь затычку для слота от невидии, или когда устанавливаешь всекие мокренькие писеньки.
> Если ядра виртуальные, то это повлияет на их максимально возможную загрузку?
Если чисто программное кодирование, то повлияет только на метрики в мониторе ресурсов. Ну, может быть, качество чуток упадёт, но это зависит.
> Конвертация видео будет быстрее если HyperThreading включить или выключить?
От этой перделки не должна. Она не для этого сделана.
![10997135913762131[1].jpg](https://2ch.hk//s/src/2389520/15372650867840.jpg)
88 Кб, 1074x794>>389534
Вообще-то я спрашивал про HyperThreading
Вообще-то я спрашивал про HyperThreading
![igor15-201117183232323[1].jpg](https://2ch.hk//s/src/2389520/15372656299350.jpg)
107 Кб, 800x691>>389563
>Ну, ты понел, кто ты такой.
>Давай я попробую тебе помочь, но не просто так. Расскажешь мне прохладную, как ты до такой жизни докатился.
>Какой исходный материал. Какой целевой стандарт сжатия? Какие параметры видеоряда: разрешение, цветовое пространство, дискретизация по каналам, частота кадров и прочее. Что за видеоматериал: содомский ниггерский анальный жопотрах, балет, онемэ, игрострим, свдьбы, корпоративы, стас михайлов?
>Зависит от конкретной реализации (в виде программы или в кремнии). Её ты выбираешь, когда покупаешь затычку для слота от невидии, или когда устанавливаешь всекие мокренькие писеньки.
>Если чисто программное кодирование, то повлияет только на метрики в мониторе ресурсов. Ну, может быть, качество чуток упадёт, но это зависит.
>От этой перделки не должна. Она не для этого сделана.
294 Кб, 680x491>>389569
Я тебя читать не заставляю. Вот картинки даже подобраны, чтобы ты пропускать мог. Я могу ему помогать, могу нахуй послать, а могу сразу в >>2302860 (OP)! И вообще, мне на оперативку к двум по Москве. Она закончится хуй когда. А потом не факт, что я возьмусь.
Или сам помоги человеку! Хули ты такой знаток и не помогаешь?
Я тебя читать не заставляю. Вот картинки даже подобраны, чтобы ты пропускать мог. Я могу ему помогать, могу нахуй послать, а могу сразу в >>2302860 (OP)! И вообще, мне на оперативку к двум по Москве. Она закончится хуй когда. А потом не факт, что я возьмусь.
Или сам помоги человеку! Хули ты такой знаток и не помогаешь?
14 Кб, 277x182Пошёл на оперативку, посоны. Вернусь не скоро.
https://video.stackexchange.com/questions/14656/why-processor-is-better-for-encoding-than-gpu
читай.
И еще, если найду скину, анализ свежий 2018 года ffmpeg и кодирования \ акселерации с помощью GPU.
Кратко вывод: раньше все было хуёво, сейчас в новых нвидия картах и новых ffmpegах, а так же CUDA и так далее нашли алгоритмы которые позволяют иметь такое же качество как и на CPU, отсюда CPU кодирование нахуй не нужно, ибо оно намного медленнее чем на GPU, при аналогичном качестве (идентичном) и относительно одинаковых размерах файла.
Думай сам.
читай.
И еще, если найду скину, анализ свежий 2018 года ffmpeg и кодирования \ акселерации с помощью GPU.
Кратко вывод: раньше все было хуёво, сейчас в новых нвидия картах и новых ffmpegах, а так же CUDA и так далее нашли алгоритмы которые позволяют иметь такое же качество как и на CPU, отсюда CPU кодирование нахуй не нужно, ибо оно намного медленнее чем на GPU, при аналогичном качестве (идентичном) и относительно одинаковых размерах файла.
Думай сам.
779 Кб, 1620x2174>>389587
Вот я бы послушал, ибо пахнет пиздежом.
> нашли алгоритмы которые позволяют иметь такое же качество как и на CPU
Вот я бы послушал, ибо пахнет пиздежом.
232 Кб, 620x623Бля, совещаение закончилось.
>>389587
Бро! Не томи! Куда ты так со своей куда-чуда-юдой пропал???
Вот это: https://video.stackexchange.com/questions/14656/why-processor-is-better-for-encoding-than-gpu
Согласуется с моим представлением об хуёвой эффективности решения оптимизационных задач на слотовых затычках и Прямо противоречит тому, что ты говоришь ниже:
>>389587
Бро! Не томи! Куда ты так со своей куда-чуда-юдой пропал???
Вот это: https://video.stackexchange.com/questions/14656/why-processor-is-better-for-encoding-than-gpu
Согласуется с моим представлением об хуёвой эффективности решения оптимизационных задач на слотовых затычках и Прямо противоречит тому, что ты говоришь ниже:
> Кратко вывод: раньше все было хуёво, сейчас в новых нвидиях... а так же CUDA и так далее... такое же качество как и на CPU... CPU кодирование нахуй не нужно
>>389587
Пруф или пидарас.
>отсюда CPU кодирование нахуй не нужно, ибо оно намного медленнее чем на GPU
Пруф или пидарас.
69 Кб, 696x522>>389650
Да вообще, блджад, охуел он! Дал ссылку, которая опровергает его трёп.
Да вообще, блджад, охуел он! Дал ссылку, которая опровергает его трёп.
66 Кб, 1280x720>>389707
Лол. Там написано вкратце... Бла-бла-бла даже у современных слотовых затычек невидии скорость кодирования относительно современных процов амуде/штеуд при одинаково плохом качестве картинки, если и выше, то не сильно. Бла-бла-бла... но если надо качество картинки оторвать ото дна, то у слотовых затычек невидии зрада, а вот x264 молодца, хорошо на свежих CPU от штеуд/амуде бегает. Бла-бла-бла... следующий пост от 2015 года.
Как-то так так с кратким содержанием.
Лол. Там написано вкратце... Бла-бла-бла даже у современных слотовых затычек невидии скорость кодирования относительно современных процов амуде/штеуд при одинаково плохом качестве картинки, если и выше, то не сильно. Бла-бла-бла... но если надо качество картинки оторвать ото дна, то у слотовых затычек невидии зрада, а вот x264 молодца, хорошо на свежих CPU от штеуд/амуде бегает. Бла-бла-бла... следующий пост от 2015 года.
Как-то так так с кратким содержанием.
>>389540
Он с FHD работает. Пусть себе ноувидию купит и не выебывается.
>А если нужен высококачественный видеоматериал?
Он с FHD работает. Пусть себе ноувидию купит и не выебывается.
262 Кб, 768x1032>>389748
Объяснение можно услышать или твоё дело советовать, а не объяснять?
Объяснение можно услышать или твоё дело советовать, а не объяснять?
>>389752
качество такое же, скорость у GPU ЗНАЧИТЕЛЬНО выше
дали же ссылку на стакэксчейнж, первые два ответа прочти там
качество такое же, скорость у GPU ЗНАЧИТЕЛЬНО выше
дали же ссылку на стакэксчейнж, первые два ответа прочти там
383 Кб, 1304x976>>389757
Ну, хорошо. Немного уроков на тему «Сосач образовательный — понимаем прочитанное».
Итак, интересное начинается со слов
Т.е. даётся ответ не по форме, а по содержанию вопроса, т.к. вопрошающий был недостаточно компетентен. Далее автор ссылается на цитату с doom9, в которой Dark Shikari поясняет по хардкору для мамкиных сжимальщиков.
Здесь говориться, о том, что в рамках разработки реализации x264 с исполнением вычислений на слотовой затычке, реализуемы почти все компоненты кодера по отдельности: в частности CABAC (который сразу не про парралельность), начальная (упрощённо-убогая, т.е.) реализация поиска и компенсации движения (с кратными и дробными векторами), потом, может быть, мог бы быть и оптимизатор, но с заместителем CABAC (в спецификации CABAC, в поток данных на выходе уйдёт CABAC, а для оптимизации мало того, что будет использоваться упрощённый критерий, так ещё и ширина потока будет оцениваться по заменителю, который используют только потому, что от слотовой затычки для CABAC толку нет из-за внутренних особенностей архитектуры слотовых затычек).
Т.е. имеем: реализация x264 на слотовой затычке обязательно будет альтернативной, в лучшем случае (после отладки и многолетней доработки) будет по эффективности сжатия лишь приближаться к программному сжатию ванильной libx264.
Это причина, следствием является пассаж:
Здесь сказано, что нормального исполнения того кода, который действительно даёт тот самый шикарный результат не вышло, а современные аппаратно ускоренные перделки являются просто встроенными аппаратными кодерами с жёсткой логикой и настройками.
Т.е. всё как я сказал. Числодробилка слотовой затычки настолько своеобразна что для численного решения на ней оптимизационную задачу нужно предварительно сильно искалечить, пожертвовав не только вычислительной производительностью но и сразу рассчитывать только на сильно субоптимальное решение.
А знаю. Это тяжело. Сам был бы рад, чтобы слотовые затычки оказывались полезными в куда большем числе случаев (сам использую куду-чуду-юду для ЦОС и турбо-кодов). Но это не так. Вот так устроена слотовая затычка, что некоторые задачки ей не по зубам.
Ну, хорошо. Немного уроков на тему «Сосач образовательный — понимаем прочитанное».
Итак, интересное начинается со слов
> To answer your actual question:
Т.е. даётся ответ не по форме, а по содержанию вопроса, т.к. вопрошающий был недостаточно компетентен. Далее автор ссылается на цитату с doom9, в которой Dark Shikari поясняет по хардкору для мамкиных сжимальщиков.
> Actually, basically everything can be reasonably done on the GPU except CABAC (which could be done, it just couldn't be parallelized).
> x264 CUDA will implement a fullpel and subpel ME algorithm initially; later on we could do something like RDO with a bit-cost approximation instead of CABAC.
Здесь говориться, о том, что в рамках разработки реализации x264 с исполнением вычислений на слотовой затычке, реализуемы почти все компоненты кодера по отдельности: в частности CABAC (который сразу не про парралельность), начальная (упрощённо-убогая, т.е.) реализация поиска и компенсации движения (с кратными и дробными векторами), потом, может быть, мог бы быть и оптимизатор, но с заместителем CABAC (в спецификации CABAC, в поток данных на выходе уйдёт CABAC, а для оптимизации мало того, что будет использоваться упрощённый критерий, так ещё и ширина потока будет оцениваться по заменителю, который используют только потому, что от слотовой затычки для CABAC толку нет из-за внутренних особенностей архитектуры слотовых затычек).
Т.е. имеем: реализация x264 на слотовой затычке обязательно будет альтернативной, в лучшем случае (после отладки и многолетней доработки) будет по эффективности сжатия лишь приближаться к программному сжатию ванильной libx264.
Это причина, следствием является пассаж:
> AFAIK, this CUDA project didn't pan out. There is support for using OpenCL to offload some work from the lookahead thread (quick I/P/B decision, not a high quality final encode of the frame).
Здесь сказано, что нормального исполнения того кода, который действительно даёт тот самый шикарный результат не вышло, а современные аппаратно ускоренные перделки являются просто встроенными аппаратными кодерами с жёсткой логикой и настройками.
Т.е. всё как я сказал. Числодробилка слотовой затычки настолько своеобразна что для численного решения на ней оптимизационную задачу нужно предварительно сильно искалечить, пожертвовав не только вычислительной производительностью но и сразу рассчитывать только на сильно субоптимальное решение.
А знаю. Это тяжело. Сам был бы рад, чтобы слотовые затычки оказывались полезными в куда большем числе случаев (сам использую куду-чуду-юду для ЦОС и турбо-кодов). Но это не так. Вот так устроена слотовая затычка, что некоторые задачки ей не по зубам.
383 Кб, 1304x976>>389757
Ну, хорошо. Немного уроков на тему «Сосач образовательный — понимаем прочитанное».
Итак, интересное начинается со слов
Т.е. даётся ответ не по форме, а по содержанию вопроса, т.к. вопрошающий был недостаточно компетентен. Далее автор ссылается на цитату с doom9, в которой Dark Shikari поясняет по хардкору для мамкиных сжимальщиков.
Здесь говориться, о том, что в рамках разработки реализации x264 с исполнением вычислений на слотовой затычке, реализуемы почти все компоненты кодера по отдельности: в частности CABAC (который сразу не про парралельность), начальная (упрощённо-убогая, т.е.) реализация поиска и компенсации движения (с кратными и дробными векторами), потом, может быть, мог бы быть и оптимизатор, но с заместителем CABAC (в спецификации CABAC, в поток данных на выходе уйдёт CABAC, а для оптимизации мало того, что будет использоваться упрощённый критерий, так ещё и ширина потока будет оцениваться по заменителю, который используют только потому, что от слотовой затычки для CABAC толку нет из-за внутренних особенностей архитектуры слотовых затычек).
Т.е. имеем: реализация x264 на слотовой затычке обязательно будет альтернативной, в лучшем случае (после отладки и многолетней доработки) будет по эффективности сжатия лишь приближаться к программному сжатию ванильной libx264.
Это причина, следствием является пассаж:
Здесь сказано, что нормального исполнения того кода, который действительно даёт тот самый шикарный результат не вышло, а современные аппаратно ускоренные перделки являются просто встроенными аппаратными кодерами с жёсткой логикой и настройками.
Т.е. всё как я сказал. Числодробилка слотовой затычки настолько своеобразна что для численного решения на ней оптимизационную задачу нужно предварительно сильно искалечить, пожертвовав не только вычислительной производительностью но и сразу рассчитывать только на сильно субоптимальное решение.
А знаю. Это тяжело. Сам был бы рад, чтобы слотовые затычки оказывались полезными в куда большем числе случаев (сам использую куду-чуду-юду для ЦОС и турбо-кодов). Но это не так. Вот так устроена слотовая затычка, что некоторые задачки ей не по зубам.
Ну, хорошо. Немного уроков на тему «Сосач образовательный — понимаем прочитанное».
Итак, интересное начинается со слов
> To answer your actual question:
Т.е. даётся ответ не по форме, а по содержанию вопроса, т.к. вопрошающий был недостаточно компетентен. Далее автор ссылается на цитату с doom9, в которой Dark Shikari поясняет по хардкору для мамкиных сжимальщиков.
> Actually, basically everything can be reasonably done on the GPU except CABAC (which could be done, it just couldn't be parallelized).
> x264 CUDA will implement a fullpel and subpel ME algorithm initially; later on we could do something like RDO with a bit-cost approximation instead of CABAC.
Здесь говориться, о том, что в рамках разработки реализации x264 с исполнением вычислений на слотовой затычке, реализуемы почти все компоненты кодера по отдельности: в частности CABAC (который сразу не про парралельность), начальная (упрощённо-убогая, т.е.) реализация поиска и компенсации движения (с кратными и дробными векторами), потом, может быть, мог бы быть и оптимизатор, но с заместителем CABAC (в спецификации CABAC, в поток данных на выходе уйдёт CABAC, а для оптимизации мало того, что будет использоваться упрощённый критерий, так ещё и ширина потока будет оцениваться по заменителю, который используют только потому, что от слотовой затычки для CABAC толку нет из-за внутренних особенностей архитектуры слотовых затычек).
Т.е. имеем: реализация x264 на слотовой затычке обязательно будет альтернативной, в лучшем случае (после отладки и многолетней доработки) будет по эффективности сжатия лишь приближаться к программному сжатию ванильной libx264.
Это причина, следствием является пассаж:
> AFAIK, this CUDA project didn't pan out. There is support for using OpenCL to offload some work from the lookahead thread (quick I/P/B decision, not a high quality final encode of the frame).
Здесь сказано, что нормального исполнения того кода, который действительно даёт тот самый шикарный результат не вышло, а современные аппаратно ускоренные перделки являются просто встроенными аппаратными кодерами с жёсткой логикой и настройками.
Т.е. всё как я сказал. Числодробилка слотовой затычки настолько своеобразна что для численного решения на ней оптимизационную задачу нужно предварительно сильно искалечить, пожертвовав не только вычислительной производительностью но и сразу рассчитывать только на сильно субоптимальное решение.
А знаю. Это тяжело. Сам был бы рад, чтобы слотовые затычки оказывались полезными в куда большем числе случаев (сам использую куду-чуду-юду для ЦОС и турбо-кодов). Но это не так. Вот так устроена слотовая затычка, что некоторые задачки ей не по зубам.
108 Кб, 768x558Читаем дальше ИМХУ:
По его (комментатора) скромному (и близкому к верному) мнению, на ЦП возможна реализация более продвинутого, и сложного алгоритма поиска движения с ранним прекращением итераций, т. е. фактически ебические вычислительные мощности слотовой затычки будут израсходованы впустую на итерации, вычисление которых на ЦП даже не потребуется. Но это, конечно, для более-менее точного поиска и компенсации, когда интересует высокое качество (на самом деле автор лукавит, если интересно могу пояснить на пальцах).
Далее:
Здесь даются практические рекомендации о том, что по эффективности сжатия аппаратные кодеры могут сравниться лишь с профилем ultrafast ванильного x264, и вот тут уже аппаратные решения конкурентоспособны, но не против хорошенького i7, который с большой вероятностью уже на профиле superfast будет сравнимо быстрым и существенно выигрышным по коэффициенту сжатия.
Ну, и финалочка:
Здесь говорится о том, что если нужно действительно хорошего качества видео, для которого используют оптимизируемые решения по компенсации движения (rate-distortion optimization, RDO), то выбрать следует ванильный x264, и со слотовыми затычками не баловаться.
Ну, есть ещё послесловие.
> the search space for video encoding is SO big that smart heuristics for early-termination of search paths on CPUs beat the brute-force GPUs bring to the table, at least for high quality encoding.
По его (комментатора) скромному (и близкому к верному) мнению, на ЦП возможна реализация более продвинутого, и сложного алгоритма поиска движения с ранним прекращением итераций, т. е. фактически ебические вычислительные мощности слотовой затычки будут израсходованы впустую на итерации, вычисление которых на ЦП даже не потребуется. Но это, конечно, для более-менее точного поиска и компенсации, когда интересует высокое качество (на самом деле автор лукавит, если интересно могу пояснить на пальцах).
Далее:
> It's only compared to -preset ultrafast where you might reasonably choose HW encoding over x264... On a fast CPU (i7 quad core with hyperthreading... x264 superfast is probably going to be as fast, and look better (at the same bitrate).
Здесь даются практические рекомендации о том, что по эффективности сжатия аппаратные кодеры могут сравниться лишь с профилем ultrafast ванильного x264, и вот тут уже аппаратные решения конкурентоспособны, но не против хорошенького i7, который с большой вероятностью уже на профиле superfast будет сравнимо быстрым и существенно выигрышным по коэффициенту сжатия.
Ну, и финалочка:
> If you're making an encode where rate-distortion (quality per file size)...
Здесь говорится о том, что если нужно действительно хорошего качества видео, для которого используют оптимизируемые решения по компенсации движения (rate-distortion optimization, RDO), то выбрать следует ванильный x264, и со слотовыми затычками не баловаться.
Ну, есть ещё послесловие.
Дибилоиды. Засуньте свой GPU себе в одно место. Я спрашивал сколько ядер может загрузить видеоконвертер и как на загрузку повлияет HyperThreading?
116 Кб, 768x573
![Dolboslavi[1].jpg](https://2ch.hk//s/src/2389520/15373563754290.jpg)
366 Кб, 892x1200>>390093
Неужели так сложно ответить на простые вопросы и получить консультацию? Уже достаточно времени прошло, чтобы ты понял, что что пересечение множества пользователей мокрой писечки (Format Factory), множества разбирающихся в кодеках с компенсацией движения, и множества тех, кому на тебя не похуй здесь, скорее всего даёт пустое множество.
Я же не издевательсва ради тебя спрашиваю. Я помочь хочу. Кроме шуток. Но ты что-то уклоняешься от сотрудничества, как будто это что-то опасное.
Неужели так сложно ответить на простые вопросы и получить консультацию? Уже достаточно времени прошло, чтобы ты понял, что что пересечение множества пользователей мокрой писечки (Format Factory), множества разбирающихся в кодеках с компенсацией движения, и множества тех, кому на тебя не похуй здесь, скорее всего даёт пустое множество.
Я же не издевательсва ради тебя спрашиваю. Я помочь хочу. Кроме шуток. Но ты что-то уклоняешься от сотрудничества, как будто это что-то опасное.
>>390102
mp4 с GoPro Hero 3 Black
разрешение: 1080p битрейт: 20Mbit/sec 30FPS
1080h
?
?
30FPS
Видео с руфинга и дигга.
Тогда что ты посоветуешь?
То есть, неважно, будет ли 12 виртуальных ядер или 6 реальных? Хм. Интересно.
>Какой исходный материал.
mp4 с GoPro Hero 3 Black
разрешение: 1080p битрейт: 20Mbit/sec 30FPS
>Какой целевой стандарт сжатия? Какие параметры видеоряда: разрешение,
1080h
>цветовое пространство,
?
>дискретизация по каналам,
?
>частота кадров и прочее.
30FPS
>Что за видеоматериал: содомский ниггерский анальный жопотрах, балет, онемэ, игрострим, свдьбы, корпоративы, стас михайлов?
Видео с руфинга и дигга.
>> Сколько ядер может загрузить видеоконвертер?
>Зависит от конкретной реализации (в виде программы или в кремнии). Её ты выбираешь, когда покупаешь затычку для слота от невидии, или когда устанавливаешь всекие мокренькие писеньки.
Тогда что ты посоветуешь?
>> Если ядра виртуальные, то это повлияет на их максимально возможную загрузку?
>Если чисто программное кодирование, то повлияет только на метрики в мониторе ресурсов. Ну, может быть, качество чуток упадёт, но это зависит.
>> Конвертация видео будет быстрее если HyperThreading включить или выключить?
>От этой перделки не должна. Она не для этого сделана.
То есть, неважно, будет ли 12 виртуальных ядер или 6 реальных? Хм. Интересно.
>>390107
Быстрофикс 1080h -> 1080p
Быстрофикс 1080h -> 1080p
273 Кб, 1000x830>>390107
Зависит от конкретной реализации библиотеки кодера.
Для libx264, например, прирост производительности в лучшем случае около 20%.
http://forum.doom9.org/showthread.php?t=162103
HyperThreading нужен для планировщика многозадачной операционной системы. Заметный профит даёт для независимых вычислительных потоков. В libx264, например, и так из доступных исполнительных устройств всё выжато, что можно, а потоки кодера там не то, чтобы совсем независимые.
см. также http://forum.doom9.org/showthread.php?t=155585
Ну, надо ещё подумать.
Шум, нестабильная камера. Картина для компенсации движения сложноватая. Сжимаешь в архив или чтобы через сеть на ютуб залить, например?
Не плохо. Хотелось бы чуть подробнее. Отчёт (тот, который стеной текста) mediainfo подойдёт (можно на pastebin положить). Оно тут: https://mediaarea.net/en/MediaInfo
(Автор этого поста был предупрежден.)
> То есть, неважно, будет ли 12 виртуальных ядер или 6 реальных? Хм. Интересно.
Зависит от конкретной реализации библиотеки кодера.
Для libx264, например, прирост производительности в лучшем случае около 20%.
http://forum.doom9.org/showthread.php?t=162103
HyperThreading нужен для планировщика многозадачной операционной системы. Заметный профит даёт для независимых вычислительных потоков. В libx264, например, и так из доступных исполнительных устройств всё выжато, что можно, а потоки кодера там не то, чтобы совсем независимые.
см. также http://forum.doom9.org/showthread.php?t=155585
> Тогда что ты посоветуешь?
Ну, надо ещё подумать.
> Видео с руфинга и дигга.
Шум, нестабильная камера. Картина для компенсации движения сложноватая. Сжимаешь в архив или чтобы через сеть на ютуб залить, например?
> mp4 с GoPro Hero 3 Black
Не плохо. Хотелось бы чуть подробнее. Отчёт (тот, который стеной текста) mediainfo подойдёт (можно на pastebin положить). Оно тут: https://mediaarea.net/en/MediaInfo
(Автор этого поста был предупрежден.)
>>390114
Ну какого-то особого дрожания там нет, если только у того кто снимает нет тремора или эпилепсии. Что касается шумов в темноте, то их практически нет. Для этого именно эта камера и выбиралась. Почему-то именно Hero 3 Black выдаёт наилучшие результаты в условиях низкой освещённости.
Выкладываю на ютуб в качестве 20Мбит/с. Пробовал сжимать до 16Мбит/с, есть некоторая потеря качества. Вот последний ролик 14 мин, 1,9Гб выкладывался на ютуб 5-6 часов. У меня скорость на отдачу 0,75Мбит/с. Час видео, наверно будет выкладываться на ютуб сутки.
https://pastebin.com/Mz2bp35H
>> Видео с руфинга и дигга.
>Шум, нестабильная камера. Картина для компенсации движения сложноватая.
Ну какого-то особого дрожания там нет, если только у того кто снимает нет тремора или эпилепсии. Что касается шумов в темноте, то их практически нет. Для этого именно эта камера и выбиралась. Почему-то именно Hero 3 Black выдаёт наилучшие результаты в условиях низкой освещённости.
>Сжимаешь в архив или чтобы через сеть на ютуб залить, например?
Выкладываю на ютуб в качестве 20Мбит/с. Пробовал сжимать до 16Мбит/с, есть некоторая потеря качества. Вот последний ролик 14 мин, 1,9Гб выкладывался на ютуб 5-6 часов. У меня скорость на отдачу 0,75Мбит/с. Час видео, наверно будет выкладываться на ютуб сутки.
>Не плохо. Хотелось бы чуть подробнее. Отчёт (тот, который стеной текста) mediainfo подойдёт
https://pastebin.com/Mz2bp35H
704 Кб, 1024x576>>390284
Давай небольшой ликбез сначала. Я расскажу всё, но по порядку. Если нужны ссылки на литературу, то тоже можно добавить.
Для компенсатора движения нет дрожания — это когда камера жёстко закреплена к 50-тонной гранитной плите, лол. Там немного движения есть — и компенсатор уже вектора нашёл. Если очень приблизительно, то поиск и компенсация движения вместе со сжатием работают примерно так:
1. каждый кадр режется на макроблоки (16×16 точек, например);
2. в компенсируемом по движению кадре для каждого такого макроблока ищется очень похожая кучка 16×16 точек, но из предыдущего кадра;
3. от найденной кучки к исходному макроблоку строится вектор движения с координатами, соответствующими смещению по вертикали и горизонтали;
4. между кучкой точек и исходным макроблоком находится поэлементная разница, в виде трёх (на каждую цветовую компоненту) таблиц чисел (каждая, допустим, размером тоже 16×16 элементов);
5. затем числа из таблицы пересчитываются через дискретное преобразование Фурье (позволяет перевести некоторое количество чисел из пространственной области определения в частотную), для более компактного описания пространственных колебаний значений в таблице; результатом тоже будут три таблицы коэффициентов преобразования с числами размером 16×16 элементов, но для естественных изображений числа эти с увеличением номера столбца и строки будут убывать и довольно быстро;
6. наименьшие числа из таблиц коэффициентов преобразования просто заменяются нулями, чтобы не передавать много информации, здесь происходит та самая потеря информации, в темринах стандартов это называется удалением избыточности из изображения; на практике обнуляется большинство коэффициентов;
7. далее координаты векторов движения и последовательно (по определённой схеме, обеспечивающей) считанные из таблиц коэффициенты передаются в поток данных на вход энтропийного кодировщика;
8. энтропийный кодировщик использует, например, специальный словарь, он сопоставляет наиболее часто встречающиеся последовательности символов на входе с наиболее короткими последовательностями символов на выходе; таким образом, на поток данных на выходе энтропийного кодировщика (а на входе, я напомню, большая часть потока — это длинные последовательности нулей) имеет существенно меньшую ширину; так и достигается сжатие.
Т.е. чем больше разнонаправленных векторов движения в картинке нашёл компенсатор, тем хуже у энтропийного кодировщика будет коэффициент сжатия. Вот, например, на первой картинке изображение равномерно перемещяется вниз, что заметил компенсатор и нашёл вектора (показаны стрелочками); на второй тело персонажа перемещается медленно, а лицо быстро, что отражено в картине векторов; на третьей картинке несколько объектов перемещаются в разных направлениях и с разной скоростью, что тоже видно по распределению векторов. Соответственно, ширина потока возрастает в точках от первой картинки к третьей.
Что касается «практически нет», то это на глаз определить не очень просто.
Даже небольшой шум может порождать сложную картину разнонаправленных векторов движения, современные кодеки умеют очищать картину векторов движения от такого мусора, но тогда он будет разгонять ширину выходного потока данных энтропийного кодировщика за счёт более медленного спада частотных коэффициентов, т.к. частотный спектр шума не спадающий, а равномерный.
Давай небольшой ликбез сначала. Я расскажу всё, но по порядку. Если нужны ссылки на литературу, то тоже можно добавить.
> Ну какого-то особого дрожания там нет
Для компенсатора движения нет дрожания — это когда камера жёстко закреплена к 50-тонной гранитной плите, лол. Там немного движения есть — и компенсатор уже вектора нашёл. Если очень приблизительно, то поиск и компенсация движения вместе со сжатием работают примерно так:
1. каждый кадр режется на макроблоки (16×16 точек, например);
2. в компенсируемом по движению кадре для каждого такого макроблока ищется очень похожая кучка 16×16 точек, но из предыдущего кадра;
3. от найденной кучки к исходному макроблоку строится вектор движения с координатами, соответствующими смещению по вертикали и горизонтали;
4. между кучкой точек и исходным макроблоком находится поэлементная разница, в виде трёх (на каждую цветовую компоненту) таблиц чисел (каждая, допустим, размером тоже 16×16 элементов);
5. затем числа из таблицы пересчитываются через дискретное преобразование Фурье (позволяет перевести некоторое количество чисел из пространственной области определения в частотную), для более компактного описания пространственных колебаний значений в таблице; результатом тоже будут три таблицы коэффициентов преобразования с числами размером 16×16 элементов, но для естественных изображений числа эти с увеличением номера столбца и строки будут убывать и довольно быстро;
6. наименьшие числа из таблиц коэффициентов преобразования просто заменяются нулями, чтобы не передавать много информации, здесь происходит та самая потеря информации, в темринах стандартов это называется удалением избыточности из изображения; на практике обнуляется большинство коэффициентов;
7. далее координаты векторов движения и последовательно (по определённой схеме, обеспечивающей) считанные из таблиц коэффициенты передаются в поток данных на вход энтропийного кодировщика;
8. энтропийный кодировщик использует, например, специальный словарь, он сопоставляет наиболее часто встречающиеся последовательности символов на входе с наиболее короткими последовательностями символов на выходе; таким образом, на поток данных на выходе энтропийного кодировщика (а на входе, я напомню, большая часть потока — это длинные последовательности нулей) имеет существенно меньшую ширину; так и достигается сжатие.
Т.е. чем больше разнонаправленных векторов движения в картинке нашёл компенсатор, тем хуже у энтропийного кодировщика будет коэффициент сжатия. Вот, например, на первой картинке изображение равномерно перемещяется вниз, что заметил компенсатор и нашёл вектора (показаны стрелочками); на второй тело персонажа перемещается медленно, а лицо быстро, что отражено в картине векторов; на третьей картинке несколько объектов перемещаются в разных направлениях и с разной скоростью, что тоже видно по распределению векторов. Соответственно, ширина потока возрастает в точках от первой картинки к третьей.
> Что касается шумов в темноте, то их практически нет.
Что касается «практически нет», то это на глаз определить не очень просто.
Даже небольшой шум может порождать сложную картину разнонаправленных векторов движения, современные кодеки умеют очищать картину векторов движения от такого мусора, но тогда он будет разгонять ширину выходного потока данных энтропийного кодировщика за счёт более медленного спада частотных коэффициентов, т.к. частотный спектр шума не спадающий, а равномерный.
704 Кб, 1024x576>>390284
Давай небольшой ликбез сначала. Я расскажу всё, но по порядку. Если нужны ссылки на литературу, то тоже можно добавить.
Для компенсатора движения нет дрожания — это когда камера жёстко закреплена к 50-тонной гранитной плите, лол. Там немного движения есть — и компенсатор уже вектора нашёл. Если очень приблизительно, то поиск и компенсация движения вместе со сжатием работают примерно так:
1. каждый кадр режется на макроблоки (16×16 точек, например);
2. в компенсируемом по движению кадре для каждого такого макроблока ищется очень похожая кучка 16×16 точек, но из предыдущего кадра;
3. от найденной кучки к исходному макроблоку строится вектор движения с координатами, соответствующими смещению по вертикали и горизонтали;
4. между кучкой точек и исходным макроблоком находится поэлементная разница, в виде трёх (на каждую цветовую компоненту) таблиц чисел (каждая, допустим, размером тоже 16×16 элементов);
5. затем числа из таблицы пересчитываются через дискретное преобразование Фурье (позволяет перевести некоторое количество чисел из пространственной области определения в частотную), для более компактного описания пространственных колебаний значений в таблице; результатом тоже будут три таблицы коэффициентов преобразования с числами размером 16×16 элементов, но для естественных изображений числа эти с увеличением номера столбца и строки будут убывать и довольно быстро;
6. наименьшие числа из таблиц коэффициентов преобразования просто заменяются нулями, чтобы не передавать много информации, здесь происходит та самая потеря информации, в темринах стандартов это называется удалением избыточности из изображения; на практике обнуляется большинство коэффициентов;
7. далее координаты векторов движения и последовательно (по определённой схеме, обеспечивающей) считанные из таблиц коэффициенты передаются в поток данных на вход энтропийного кодировщика;
8. энтропийный кодировщик использует, например, специальный словарь, он сопоставляет наиболее часто встречающиеся последовательности символов на входе с наиболее короткими последовательностями символов на выходе; таким образом, на поток данных на выходе энтропийного кодировщика (а на входе, я напомню, большая часть потока — это длинные последовательности нулей) имеет существенно меньшую ширину; так и достигается сжатие.
Т.е. чем больше разнонаправленных векторов движения в картинке нашёл компенсатор, тем хуже у энтропийного кодировщика будет коэффициент сжатия. Вот, например, на первой картинке изображение равномерно перемещяется вниз, что заметил компенсатор и нашёл вектора (показаны стрелочками); на второй тело персонажа перемещается медленно, а лицо быстро, что отражено в картине векторов; на третьей картинке несколько объектов перемещаются в разных направлениях и с разной скоростью, что тоже видно по распределению векторов. Соответственно, ширина потока возрастает в точках от первой картинки к третьей.
Что касается «практически нет», то это на глаз определить не очень просто.
Даже небольшой шум может порождать сложную картину разнонаправленных векторов движения, современные кодеки умеют очищать картину векторов движения от такого мусора, но тогда он будет разгонять ширину выходного потока данных энтропийного кодировщика за счёт более медленного спада частотных коэффициентов, т.к. частотный спектр шума не спадающий, а равномерный.
Давай небольшой ликбез сначала. Я расскажу всё, но по порядку. Если нужны ссылки на литературу, то тоже можно добавить.
> Ну какого-то особого дрожания там нет
Для компенсатора движения нет дрожания — это когда камера жёстко закреплена к 50-тонной гранитной плите, лол. Там немного движения есть — и компенсатор уже вектора нашёл. Если очень приблизительно, то поиск и компенсация движения вместе со сжатием работают примерно так:
1. каждый кадр режется на макроблоки (16×16 точек, например);
2. в компенсируемом по движению кадре для каждого такого макроблока ищется очень похожая кучка 16×16 точек, но из предыдущего кадра;
3. от найденной кучки к исходному макроблоку строится вектор движения с координатами, соответствующими смещению по вертикали и горизонтали;
4. между кучкой точек и исходным макроблоком находится поэлементная разница, в виде трёх (на каждую цветовую компоненту) таблиц чисел (каждая, допустим, размером тоже 16×16 элементов);
5. затем числа из таблицы пересчитываются через дискретное преобразование Фурье (позволяет перевести некоторое количество чисел из пространственной области определения в частотную), для более компактного описания пространственных колебаний значений в таблице; результатом тоже будут три таблицы коэффициентов преобразования с числами размером 16×16 элементов, но для естественных изображений числа эти с увеличением номера столбца и строки будут убывать и довольно быстро;
6. наименьшие числа из таблиц коэффициентов преобразования просто заменяются нулями, чтобы не передавать много информации, здесь происходит та самая потеря информации, в темринах стандартов это называется удалением избыточности из изображения; на практике обнуляется большинство коэффициентов;
7. далее координаты векторов движения и последовательно (по определённой схеме, обеспечивающей) считанные из таблиц коэффициенты передаются в поток данных на вход энтропийного кодировщика;
8. энтропийный кодировщик использует, например, специальный словарь, он сопоставляет наиболее часто встречающиеся последовательности символов на входе с наиболее короткими последовательностями символов на выходе; таким образом, на поток данных на выходе энтропийного кодировщика (а на входе, я напомню, большая часть потока — это длинные последовательности нулей) имеет существенно меньшую ширину; так и достигается сжатие.
Т.е. чем больше разнонаправленных векторов движения в картинке нашёл компенсатор, тем хуже у энтропийного кодировщика будет коэффициент сжатия. Вот, например, на первой картинке изображение равномерно перемещяется вниз, что заметил компенсатор и нашёл вектора (показаны стрелочками); на второй тело персонажа перемещается медленно, а лицо быстро, что отражено в картине векторов; на третьей картинке несколько объектов перемещаются в разных направлениях и с разной скоростью, что тоже видно по распределению векторов. Соответственно, ширина потока возрастает в точках от первой картинки к третьей.
> Что касается шумов в темноте, то их практически нет.
Что касается «практически нет», то это на глаз определить не очень просто.
Даже небольшой шум может порождать сложную картину разнонаправленных векторов движения, современные кодеки умеют очищать картину векторов движения от такого мусора, но тогда он будет разгонять ширину выходного потока данных энтропийного кодировщика за счёт более медленного спада частотных коэффициентов, т.к. частотный спектр шума не спадающий, а равномерный.
>>390284
Вторая и третья картинки. Мне тут бан выдали хрен знает за что. Может быть, и не мне, но я испытываю кое-какие трудности.
Вторая и третья картинки. Мне тут бан выдали хрен знает за что. Может быть, и не мне, но я испытываю кое-какие трудности.
>>390284
Теперь про то, что в этой стане теста видно.
Непосредственно к твоим вопросам отношения не имеет, но, может быть, пригодится.
Итак
Это формат контейнера и его соответствие стандарту. Контейнер — это способ размещения данных видео, звука, субтитров и служебной информации в файле или потоке данных, путём добавления к чередующимся фрагментам полезных данных дополнительной информации, обеспечивающей разметку. Разметка позволяет реализовать навигацию (читай — перемотку), разделять потоки видео звука и пр. при воспроизведении, вычленять метаданные (отношение сторон, информацию о языке и главах и т.п.) и всякое такое, что не имеет для воспроизведения вспомогательное значение. JVT — это подразделение ISO, которая работает под эгидой ООН, лол.
см.
https://en.wikipedia.org/wiki/MPEG-4_Part_14
https://en.wikipedia.org/wiki/ISO_base_media_file_format
В начале секции, описывающей поток видео указывается стандарт и формат сжатия. В данном случае используется H.264.
Далее указывается профиль стандарта — High; и уровень — 4.1.
Уровни и профили нудны для ранжирования по сложности и доступным вычислительным ресурсам воспроизводящих поток H.264 устройств и обеспечения совместимости кодировщика и дохлыми или мощными декодерами. Для каждого профиля ограничивается набор приёмов сжатия и соответствующих им примитивов, используемых при воспроизведении, например, наличие или отсутствие двунаправленной компенсации движения, разных моделей представления цвета, способов деления макроблока, видов энтропийного кодирования и всякого такого.
см. https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles
https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
Здесь опции потока данных: использование энтропийного кодировщика CABAC, число ссылочных кадров (в стандарте H.264 ссылочным считается кадр, который нужно предварительно восстановить и использовать элементы его изображения для воспроизведения текущего кадра), параметры группы кадров (группой кадров считается независимая последовательность кадров, между которыми есть ссылки, компенсирующие движение). ReFrames=1 означает, что в потоке макроблоки любого отдельно взятого кадра ссылаются на изображения из других кадров, число которых не превышает единицу.
M=1 — расстояние между опорными кадрами (I или P-типа), единица означает, что в потоке нет B-кадров, двойка, что друг за другом могут следовать не более одного B-кадра, тройка — не более двух и т.д.
N=15 — максимальная длина группы кадров.
Касательно терминов стандарта H.264 могу сказать следующее:
- есть intra-карды и inter-кадры, т.е. внутренние (B и P) и внешние (I) по отношению в группе кадров;
- inter-кадры состоят только из i-макроблоков, т.е. макроблоков, которые не ссылаются ни на какие другие кадры (не имеют векторов движения);
- P-кадры состоят из i-макроблоков и из p-макроблоков; p-макроблок может иметь только прямую ссылку, т.е. вектор движения может указывать только на кадры, предшествующие по времени появления;
- B-кадры состоят из макроблоков i, p и b типов; b-макроблок имеет как прямую так и обратную ссылку, т.е. определяется парой векторов движения, указывающих как на предшествующие, так и на последующие кадры;
- ни один макроблок не ссылается за пределы своей группы кадров.
см. https://en.wikipedia.org/wiki/Context-adaptive_binary_arithmetic_coding
https://en.wikipedia.org/wiki/Group_of_pictures
https://en.wikipedia.org/wiki/Video_compression_picture_types
Наибольшую эффективность сжатия имеют кодировщики с двунаправленной компенсацией движения, т.к. за счёт двух векторов движения вычисляется разность не между текущим макроблоком и ссылочным фрагментом, а между текущим макроблоком и интерполяцией двух ссылочных. С учётом непрерывности движения при правильном нахождении пары векторов, значение разностного макроблока получаются малыми и коэффициенты его преобразования будут околонулевыми (т.е. не будут содержать значимой информации).
Т.о. при медленном согласованном движении или для статичной картинки с увеличением допустимого числа последовательных B-кадров быстро растёт коэффициент сжатия. В обобщённом случае, т.е. для разнообразного движения в кадре, рост эффективности сжатия прекращается уже после 2 или 3 последовательных B-кадров.
В твоём исходном потоке нет B-кадров вообще, т.к. двунаправленная компенсация движения — это много вычислительных ресурсов, а камере надо батарейку пожалеть.
Здесь указана номинальная ширина потока данных и номинальное физическое соотношение длин сторон кадра. Последняя строчка указывает тип развёртки — построчный (progressive) или чересстрочный (interlaced). Тип развёртки определяет, в каком геометрическом порядке электрические импульсы с матрицы фоториёмника считывались. Все элементы матрицы фотоприёмника состоят из источника фототока, пропорционального освещённости элемента, и конденсатора, заражающегося за период экспозиции этим током. Напряжение на конденсаторе в момент считывания пропорционально интегралу от освещённости за все моменты времени в периоде экспозиции. После считывания, конденсатор разряжен. В результате того, что считывание изображения с матрицы происходит не мгновенно, получается, что все точки растра (прямоугольная таблица точек, хранящих плоское изображение) зафиксировали немного разные фазы движения, т.е. истинная картинка (как на фотоплёнке) из элементов растра не получается. Причём, за счёт разности фаз движения между первой считанной строкой и последней может возникать очень большое геометрическое искажение просто потому, что объект двигался. По этому, порядок считывания строк важен. В 30-х годах прошлого века придумали хитрый костыль — чересстрочную развёртку: сначала читают чётные строки, потом нечётные, т.о. разность фаз движения между геометрически удалёнными друг от друга строками сокращалась и искажения, вызванные разностью снижались. Современные компьютерные мониторы имеют строго построчную развёртку и напрямую не совместимы с чересстрочной, о чём можно прочесть в статье.
см. https://en.wikipedia.org/wiki/Display_aspect_ratio
https://en.wikipedia.org/wiki/Progressive_scan
https://en.wikipedia.org/wiki/Interlaced_video
Длина и ширина растра в точках. Флаг частоты развёртки — постоянная или переменная. Номинальное значение частоты развёртки. Для совместимости с компьютерными мониторами и системами телевидения, частота развёртки должна быть строго постоянной. Переменное значение порождает проблемы, которые лучше всего не пытаться решать. Дешёвые микросхемы кодировщиков в планшетах и телефонах не редко генерировали видеоряд с переменной частотой развёртки. Это Адъ!
Дальше будет ещё немного ликбеза.
Теперь про то, что в этой стане теста видно.
Непосредственно к твоим вопросам отношения не имеет, но, может быть, пригодится.
Итак
> Format: MPEG-4
> Format profile: JVT
Это формат контейнера и его соответствие стандарту. Контейнер — это способ размещения данных видео, звука, субтитров и служебной информации в файле или потоке данных, путём добавления к чередующимся фрагментам полезных данных дополнительной информации, обеспечивающей разметку. Разметка позволяет реализовать навигацию (читай — перемотку), разделять потоки видео звука и пр. при воспроизведении, вычленять метаданные (отношение сторон, информацию о языке и главах и т.п.) и всякое такое, что не имеет для воспроизведения вспомогательное значение. JVT — это подразделение ISO, которая работает под эгидой ООН, лол.
см.
https://en.wikipedia.org/wiki/MPEG-4_Part_14
https://en.wikipedia.org/wiki/ISO_base_media_file_format
> Video
> Format/Info: Advanced Video Codec
> Format profile: High@L4.1
В начале секции, описывающей поток видео указывается стандарт и формат сжатия. В данном случае используется H.264.
Далее указывается профиль стандарта — High; и уровень — 4.1.
Уровни и профили нудны для ранжирования по сложности и доступным вычислительным ресурсам воспроизводящих поток H.264 устройств и обеспечения совместимости кодировщика и дохлыми или мощными декодерами. Для каждого профиля ограничивается набор приёмов сжатия и соответствующих им примитивов, используемых при воспроизведении, например, наличие или отсутствие двунаправленной компенсации движения, разных моделей представления цвета, способов деления макроблока, видов энтропийного кодирования и всякого такого.
см. https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles
https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
> Format settings, CABAC: Yes
> Format settings, ReFrames: 1 frame
> Format settings, GOP: M=1, N=15
Здесь опции потока данных: использование энтропийного кодировщика CABAC, число ссылочных кадров (в стандарте H.264 ссылочным считается кадр, который нужно предварительно восстановить и использовать элементы его изображения для воспроизведения текущего кадра), параметры группы кадров (группой кадров считается независимая последовательность кадров, между которыми есть ссылки, компенсирующие движение). ReFrames=1 означает, что в потоке макроблоки любого отдельно взятого кадра ссылаются на изображения из других кадров, число которых не превышает единицу.
M=1 — расстояние между опорными кадрами (I или P-типа), единица означает, что в потоке нет B-кадров, двойка, что друг за другом могут следовать не более одного B-кадра, тройка — не более двух и т.д.
N=15 — максимальная длина группы кадров.
Касательно терминов стандарта H.264 могу сказать следующее:
- есть intra-карды и inter-кадры, т.е. внутренние (B и P) и внешние (I) по отношению в группе кадров;
- inter-кадры состоят только из i-макроблоков, т.е. макроблоков, которые не ссылаются ни на какие другие кадры (не имеют векторов движения);
- P-кадры состоят из i-макроблоков и из p-макроблоков; p-макроблок может иметь только прямую ссылку, т.е. вектор движения может указывать только на кадры, предшествующие по времени появления;
- B-кадры состоят из макроблоков i, p и b типов; b-макроблок имеет как прямую так и обратную ссылку, т.е. определяется парой векторов движения, указывающих как на предшествующие, так и на последующие кадры;
- ни один макроблок не ссылается за пределы своей группы кадров.
см. https://en.wikipedia.org/wiki/Context-adaptive_binary_arithmetic_coding
https://en.wikipedia.org/wiki/Group_of_pictures
https://en.wikipedia.org/wiki/Video_compression_picture_types
Наибольшую эффективность сжатия имеют кодировщики с двунаправленной компенсацией движения, т.к. за счёт двух векторов движения вычисляется разность не между текущим макроблоком и ссылочным фрагментом, а между текущим макроблоком и интерполяцией двух ссылочных. С учётом непрерывности движения при правильном нахождении пары векторов, значение разностного макроблока получаются малыми и коэффициенты его преобразования будут околонулевыми (т.е. не будут содержать значимой информации).
Т.о. при медленном согласованном движении или для статичной картинки с увеличением допустимого числа последовательных B-кадров быстро растёт коэффициент сжатия. В обобщённом случае, т.е. для разнообразного движения в кадре, рост эффективности сжатия прекращается уже после 2 или 3 последовательных B-кадров.
В твоём исходном потоке нет B-кадров вообще, т.к. двунаправленная компенсация движения — это много вычислительных ресурсов, а камере надо батарейку пожалеть.
> Bit rate: 20.0 Mbps
> Display aspect ratio: 16:9
> Scan type: Progressive
Здесь указана номинальная ширина потока данных и номинальное физическое соотношение длин сторон кадра. Последняя строчка указывает тип развёртки — построчный (progressive) или чересстрочный (interlaced). Тип развёртки определяет, в каком геометрическом порядке электрические импульсы с матрицы фоториёмника считывались. Все элементы матрицы фотоприёмника состоят из источника фототока, пропорционального освещённости элемента, и конденсатора, заражающегося за период экспозиции этим током. Напряжение на конденсаторе в момент считывания пропорционально интегралу от освещённости за все моменты времени в периоде экспозиции. После считывания, конденсатор разряжен. В результате того, что считывание изображения с матрицы происходит не мгновенно, получается, что все точки растра (прямоугольная таблица точек, хранящих плоское изображение) зафиксировали немного разные фазы движения, т.е. истинная картинка (как на фотоплёнке) из элементов растра не получается. Причём, за счёт разности фаз движения между первой считанной строкой и последней может возникать очень большое геометрическое искажение просто потому, что объект двигался. По этому, порядок считывания строк важен. В 30-х годах прошлого века придумали хитрый костыль — чересстрочную развёртку: сначала читают чётные строки, потом нечётные, т.о. разность фаз движения между геометрически удалёнными друг от друга строками сокращалась и искажения, вызванные разностью снижались. Современные компьютерные мониторы имеют строго построчную развёртку и напрямую не совместимы с чересстрочной, о чём можно прочесть в статье.
см. https://en.wikipedia.org/wiki/Display_aspect_ratio
https://en.wikipedia.org/wiki/Progressive_scan
https://en.wikipedia.org/wiki/Interlaced_video
> Width: 1 920 pixels
> Height: 1 080 pixels
> Frame rate mode: Constant
> Frame rate: 29.970 fps
Длина и ширина растра в точках. Флаг частоты развёртки — постоянная или переменная. Номинальное значение частоты развёртки. Для совместимости с компьютерными мониторами и системами телевидения, частота развёртки должна быть строго постоянной. Переменное значение порождает проблемы, которые лучше всего не пытаться решать. Дешёвые микросхемы кодировщиков в планшетах и телефонах не редко генерировали видеоряд с переменной частотой развёртки. Это Адъ!
Дальше будет ещё немного ликбеза.
>>390284
Теперь про то, что в этой стане теста видно.
Непосредственно к твоим вопросам отношения не имеет, но, может быть, пригодится.
Итак
Это формат контейнера и его соответствие стандарту. Контейнер — это способ размещения данных видео, звука, субтитров и служебной информации в файле или потоке данных, путём добавления к чередующимся фрагментам полезных данных дополнительной информации, обеспечивающей разметку. Разметка позволяет реализовать навигацию (читай — перемотку), разделять потоки видео звука и пр. при воспроизведении, вычленять метаданные (отношение сторон, информацию о языке и главах и т.п.) и всякое такое, что не имеет для воспроизведения вспомогательное значение. JVT — это подразделение ISO, которая работает под эгидой ООН, лол.
см.
https://en.wikipedia.org/wiki/MPEG-4_Part_14
https://en.wikipedia.org/wiki/ISO_base_media_file_format
В начале секции, описывающей поток видео указывается стандарт и формат сжатия. В данном случае используется H.264.
Далее указывается профиль стандарта — High; и уровень — 4.1.
Уровни и профили нудны для ранжирования по сложности и доступным вычислительным ресурсам воспроизводящих поток H.264 устройств и обеспечения совместимости кодировщика и дохлыми или мощными декодерами. Для каждого профиля ограничивается набор приёмов сжатия и соответствующих им примитивов, используемых при воспроизведении, например, наличие или отсутствие двунаправленной компенсации движения, разных моделей представления цвета, способов деления макроблока, видов энтропийного кодирования и всякого такого.
см. https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles
https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
Здесь опции потока данных: использование энтропийного кодировщика CABAC, число ссылочных кадров (в стандарте H.264 ссылочным считается кадр, который нужно предварительно восстановить и использовать элементы его изображения для воспроизведения текущего кадра), параметры группы кадров (группой кадров считается независимая последовательность кадров, между которыми есть ссылки, компенсирующие движение). ReFrames=1 означает, что в потоке макроблоки любого отдельно взятого кадра ссылаются на изображения из других кадров, число которых не превышает единицу.
M=1 — расстояние между опорными кадрами (I или P-типа), единица означает, что в потоке нет B-кадров, двойка, что друг за другом могут следовать не более одного B-кадра, тройка — не более двух и т.д.
N=15 — максимальная длина группы кадров.
Касательно терминов стандарта H.264 могу сказать следующее:
- есть intra-карды и inter-кадры, т.е. внутренние (B и P) и внешние (I) по отношению в группе кадров;
- inter-кадры состоят только из i-макроблоков, т.е. макроблоков, которые не ссылаются ни на какие другие кадры (не имеют векторов движения);
- P-кадры состоят из i-макроблоков и из p-макроблоков; p-макроблок может иметь только прямую ссылку, т.е. вектор движения может указывать только на кадры, предшествующие по времени появления;
- B-кадры состоят из макроблоков i, p и b типов; b-макроблок имеет как прямую так и обратную ссылку, т.е. определяется парой векторов движения, указывающих как на предшествующие, так и на последующие кадры;
- ни один макроблок не ссылается за пределы своей группы кадров.
см. https://en.wikipedia.org/wiki/Context-adaptive_binary_arithmetic_coding
https://en.wikipedia.org/wiki/Group_of_pictures
https://en.wikipedia.org/wiki/Video_compression_picture_types
Наибольшую эффективность сжатия имеют кодировщики с двунаправленной компенсацией движения, т.к. за счёт двух векторов движения вычисляется разность не между текущим макроблоком и ссылочным фрагментом, а между текущим макроблоком и интерполяцией двух ссылочных. С учётом непрерывности движения при правильном нахождении пары векторов, значение разностного макроблока получаются малыми и коэффициенты его преобразования будут околонулевыми (т.е. не будут содержать значимой информации).
Т.о. при медленном согласованном движении или для статичной картинки с увеличением допустимого числа последовательных B-кадров быстро растёт коэффициент сжатия. В обобщённом случае, т.е. для разнообразного движения в кадре, рост эффективности сжатия прекращается уже после 2 или 3 последовательных B-кадров.
В твоём исходном потоке нет B-кадров вообще, т.к. двунаправленная компенсация движения — это много вычислительных ресурсов, а камере надо батарейку пожалеть.
Здесь указана номинальная ширина потока данных и номинальное физическое соотношение длин сторон кадра. Последняя строчка указывает тип развёртки — построчный (progressive) или чересстрочный (interlaced). Тип развёртки определяет, в каком геометрическом порядке электрические импульсы с матрицы фоториёмника считывались. Все элементы матрицы фотоприёмника состоят из источника фототока, пропорционального освещённости элемента, и конденсатора, заражающегося за период экспозиции этим током. Напряжение на конденсаторе в момент считывания пропорционально интегралу от освещённости за все моменты времени в периоде экспозиции. После считывания, конденсатор разряжен. В результате того, что считывание изображения с матрицы происходит не мгновенно, получается, что все точки растра (прямоугольная таблица точек, хранящих плоское изображение) зафиксировали немного разные фазы движения, т.е. истинная картинка (как на фотоплёнке) из элементов растра не получается. Причём, за счёт разности фаз движения между первой считанной строкой и последней может возникать очень большое геометрическое искажение просто потому, что объект двигался. По этому, порядок считывания строк важен. В 30-х годах прошлого века придумали хитрый костыль — чересстрочную развёртку: сначала читают чётные строки, потом нечётные, т.о. разность фаз движения между геометрически удалёнными друг от друга строками сокращалась и искажения, вызванные разностью снижались. Современные компьютерные мониторы имеют строго построчную развёртку и напрямую не совместимы с чересстрочной, о чём можно прочесть в статье.
см. https://en.wikipedia.org/wiki/Display_aspect_ratio
https://en.wikipedia.org/wiki/Progressive_scan
https://en.wikipedia.org/wiki/Interlaced_video
Длина и ширина растра в точках. Флаг частоты развёртки — постоянная или переменная. Номинальное значение частоты развёртки. Для совместимости с компьютерными мониторами и системами телевидения, частота развёртки должна быть строго постоянной. Переменное значение порождает проблемы, которые лучше всего не пытаться решать. Дешёвые микросхемы кодировщиков в планшетах и телефонах не редко генерировали видеоряд с переменной частотой развёртки. Это Адъ!
Дальше будет ещё немного ликбеза.
Теперь про то, что в этой стане теста видно.
Непосредственно к твоим вопросам отношения не имеет, но, может быть, пригодится.
Итак
> Format: MPEG-4
> Format profile: JVT
Это формат контейнера и его соответствие стандарту. Контейнер — это способ размещения данных видео, звука, субтитров и служебной информации в файле или потоке данных, путём добавления к чередующимся фрагментам полезных данных дополнительной информации, обеспечивающей разметку. Разметка позволяет реализовать навигацию (читай — перемотку), разделять потоки видео звука и пр. при воспроизведении, вычленять метаданные (отношение сторон, информацию о языке и главах и т.п.) и всякое такое, что не имеет для воспроизведения вспомогательное значение. JVT — это подразделение ISO, которая работает под эгидой ООН, лол.
см.
https://en.wikipedia.org/wiki/MPEG-4_Part_14
https://en.wikipedia.org/wiki/ISO_base_media_file_format
> Video
> Format/Info: Advanced Video Codec
> Format profile: High@L4.1
В начале секции, описывающей поток видео указывается стандарт и формат сжатия. В данном случае используется H.264.
Далее указывается профиль стандарта — High; и уровень — 4.1.
Уровни и профили нудны для ранжирования по сложности и доступным вычислительным ресурсам воспроизводящих поток H.264 устройств и обеспечения совместимости кодировщика и дохлыми или мощными декодерами. Для каждого профиля ограничивается набор приёмов сжатия и соответствующих им примитивов, используемых при воспроизведении, например, наличие или отсутствие двунаправленной компенсации движения, разных моделей представления цвета, способов деления макроблока, видов энтропийного кодирования и всякого такого.
см. https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles
https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
> Format settings, CABAC: Yes
> Format settings, ReFrames: 1 frame
> Format settings, GOP: M=1, N=15
Здесь опции потока данных: использование энтропийного кодировщика CABAC, число ссылочных кадров (в стандарте H.264 ссылочным считается кадр, который нужно предварительно восстановить и использовать элементы его изображения для воспроизведения текущего кадра), параметры группы кадров (группой кадров считается независимая последовательность кадров, между которыми есть ссылки, компенсирующие движение). ReFrames=1 означает, что в потоке макроблоки любого отдельно взятого кадра ссылаются на изображения из других кадров, число которых не превышает единицу.
M=1 — расстояние между опорными кадрами (I или P-типа), единица означает, что в потоке нет B-кадров, двойка, что друг за другом могут следовать не более одного B-кадра, тройка — не более двух и т.д.
N=15 — максимальная длина группы кадров.
Касательно терминов стандарта H.264 могу сказать следующее:
- есть intra-карды и inter-кадры, т.е. внутренние (B и P) и внешние (I) по отношению в группе кадров;
- inter-кадры состоят только из i-макроблоков, т.е. макроблоков, которые не ссылаются ни на какие другие кадры (не имеют векторов движения);
- P-кадры состоят из i-макроблоков и из p-макроблоков; p-макроблок может иметь только прямую ссылку, т.е. вектор движения может указывать только на кадры, предшествующие по времени появления;
- B-кадры состоят из макроблоков i, p и b типов; b-макроблок имеет как прямую так и обратную ссылку, т.е. определяется парой векторов движения, указывающих как на предшествующие, так и на последующие кадры;
- ни один макроблок не ссылается за пределы своей группы кадров.
см. https://en.wikipedia.org/wiki/Context-adaptive_binary_arithmetic_coding
https://en.wikipedia.org/wiki/Group_of_pictures
https://en.wikipedia.org/wiki/Video_compression_picture_types
Наибольшую эффективность сжатия имеют кодировщики с двунаправленной компенсацией движения, т.к. за счёт двух векторов движения вычисляется разность не между текущим макроблоком и ссылочным фрагментом, а между текущим макроблоком и интерполяцией двух ссылочных. С учётом непрерывности движения при правильном нахождении пары векторов, значение разностного макроблока получаются малыми и коэффициенты его преобразования будут околонулевыми (т.е. не будут содержать значимой информации).
Т.о. при медленном согласованном движении или для статичной картинки с увеличением допустимого числа последовательных B-кадров быстро растёт коэффициент сжатия. В обобщённом случае, т.е. для разнообразного движения в кадре, рост эффективности сжатия прекращается уже после 2 или 3 последовательных B-кадров.
В твоём исходном потоке нет B-кадров вообще, т.к. двунаправленная компенсация движения — это много вычислительных ресурсов, а камере надо батарейку пожалеть.
> Bit rate: 20.0 Mbps
> Display aspect ratio: 16:9
> Scan type: Progressive
Здесь указана номинальная ширина потока данных и номинальное физическое соотношение длин сторон кадра. Последняя строчка указывает тип развёртки — построчный (progressive) или чересстрочный (interlaced). Тип развёртки определяет, в каком геометрическом порядке электрические импульсы с матрицы фоториёмника считывались. Все элементы матрицы фотоприёмника состоят из источника фототока, пропорционального освещённости элемента, и конденсатора, заражающегося за период экспозиции этим током. Напряжение на конденсаторе в момент считывания пропорционально интегралу от освещённости за все моменты времени в периоде экспозиции. После считывания, конденсатор разряжен. В результате того, что считывание изображения с матрицы происходит не мгновенно, получается, что все точки растра (прямоугольная таблица точек, хранящих плоское изображение) зафиксировали немного разные фазы движения, т.е. истинная картинка (как на фотоплёнке) из элементов растра не получается. Причём, за счёт разности фаз движения между первой считанной строкой и последней может возникать очень большое геометрическое искажение просто потому, что объект двигался. По этому, порядок считывания строк важен. В 30-х годах прошлого века придумали хитрый костыль — чересстрочную развёртку: сначала читают чётные строки, потом нечётные, т.о. разность фаз движения между геометрически удалёнными друг от друга строками сокращалась и искажения, вызванные разностью снижались. Современные компьютерные мониторы имеют строго построчную развёртку и напрямую не совместимы с чересстрочной, о чём можно прочесть в статье.
см. https://en.wikipedia.org/wiki/Display_aspect_ratio
https://en.wikipedia.org/wiki/Progressive_scan
https://en.wikipedia.org/wiki/Interlaced_video
> Width: 1 920 pixels
> Height: 1 080 pixels
> Frame rate mode: Constant
> Frame rate: 29.970 fps
Длина и ширина растра в точках. Флаг частоты развёртки — постоянная или переменная. Номинальное значение частоты развёртки. Для совместимости с компьютерными мониторами и системами телевидения, частота развёртки должна быть строго постоянной. Переменное значение порождает проблемы, которые лучше всего не пытаться решать. Дешёвые микросхемы кодировщиков в планшетах и телефонах не редко генерировали видеоряд с переменной частотой развёртки. Это Адъ!
Дальше будет ещё немного ликбеза.
Не надо пугаться! Ликбез нужен просто, чтобы ты понимал приблизительно, как оно устроено вообще, и о чём я говорю.
Далее:
Здесь речь о внутреннем представлении цвета. Конкретно по порядку указано: модель представления цветовой информации (YUV), способ прореживания отсчётов цветоразностных составляющих (4:2:0) и размерность (глубина квантования 8 бит) каждого отсчёта. Естественное для человека восприятие цвета для иллюзии изображения, создаваемого светящимся источником соответствует аддитивной модели RBG (Red, Green, Blue), причём, к пространственным колебаниям яркости света зрение будет более чувствительно, чем к пространственным колебаниям цветового тона. По этому для цветного телевидения (а также для целей обратной совместимости и ч/б телевидением) аддитивная модель (в ней иллюзия цвета создаётся путём пространственного наложения трёх отличающихся длиной волны излучений в определённых соотношениях интенсивности), представления дополняется цветоразностной схемой (YUV), где триада сигналов R, G и B путём линейного преобразования (формулы см. в статье) преобразуется в триаду сигналов, состоящую из интенсивности и двух цветоразностных сигналов.
После линейного преобразования RGB->YUV, цветоразностные составляющие, как правило, передаются с меньшим пространственным разрешением. Последнее достигается путём прореживания отсчётов, так, чтобы одному из пары отсчётов цветоразности геометрически соответствовало два или четыре отсчёта яркости. Так для схемы прореживания 4:2:0 растр яркостной составляющей (интенсивности) будет у тебя 1920×1080, а для каждой из цветоразностных — 960×540 точек.
Про глубину квантования подробно написано с примерами и иллюстрациями в статье, а я скажу кратко, что пр итвоей размерности в 8 бит возможно обеспечить на каждую из цветовых составляющих по 255 возможных уровней интенсивности (и ещё нулевой, да). Как правило, 255 ненулевых равномерно распределённых уровней достаточно для создания качественной иллюзии пространственных переходов полутонов в изображении.
см. https://en.wikipedia.org/wiki/YUV
https://en.wikipedia.org/wiki/Chroma_subsampling
https://en.wikipedia.org/wiki/Additive_color
https://en.wikipedia.org/wiki/Color_depth
https://en.wikipedia.org/wiki/Quantization_(signal_processing)
Здесь содержаться метаданные о колориметрических характеристиках изображения. Фактически это ссылка на номер телевизионного стандарта, в котором определены коэффициенты линейного преобразования между пространствами RGB и YUV. Требуется для правильной цветопередачи при воспроизведении. Можно раскрыть, конечно, подробнее с описанием кишков камеры, но оно тебе надо?
см. https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/International_Commission_on_Illumination
https://en.wikipedia.org/wiki/CIE_1931_color_space
https://en.wikipedia.org/wiki/CIELAB_color_space
Это, так сказать, конец основного ликбеза.
Далее:
> Color space: YUV
> Chroma subsampling: 4:2:0
> Bit depth: 8 bits
Здесь речь о внутреннем представлении цвета. Конкретно по порядку указано: модель представления цветовой информации (YUV), способ прореживания отсчётов цветоразностных составляющих (4:2:0) и размерность (глубина квантования 8 бит) каждого отсчёта. Естественное для человека восприятие цвета для иллюзии изображения, создаваемого светящимся источником соответствует аддитивной модели RBG (Red, Green, Blue), причём, к пространственным колебаниям яркости света зрение будет более чувствительно, чем к пространственным колебаниям цветового тона. По этому для цветного телевидения (а также для целей обратной совместимости и ч/б телевидением) аддитивная модель (в ней иллюзия цвета создаётся путём пространственного наложения трёх отличающихся длиной волны излучений в определённых соотношениях интенсивности), представления дополняется цветоразностной схемой (YUV), где триада сигналов R, G и B путём линейного преобразования (формулы см. в статье) преобразуется в триаду сигналов, состоящую из интенсивности и двух цветоразностных сигналов.
После линейного преобразования RGB->YUV, цветоразностные составляющие, как правило, передаются с меньшим пространственным разрешением. Последнее достигается путём прореживания отсчётов, так, чтобы одному из пары отсчётов цветоразности геометрически соответствовало два или четыре отсчёта яркости. Так для схемы прореживания 4:2:0 растр яркостной составляющей (интенсивности) будет у тебя 1920×1080, а для каждой из цветоразностных — 960×540 точек.
Про глубину квантования подробно написано с примерами и иллюстрациями в статье, а я скажу кратко, что пр итвоей размерности в 8 бит возможно обеспечить на каждую из цветовых составляющих по 255 возможных уровней интенсивности (и ещё нулевой, да). Как правило, 255 ненулевых равномерно распределённых уровней достаточно для создания качественной иллюзии пространственных переходов полутонов в изображении.
см. https://en.wikipedia.org/wiki/YUV
https://en.wikipedia.org/wiki/Chroma_subsampling
https://en.wikipedia.org/wiki/Additive_color
https://en.wikipedia.org/wiki/Color_depth
https://en.wikipedia.org/wiki/Quantization_(signal_processing)
> Color primaries: BT.709
> Transfer characteristics: BT.709
> Matrix coefficients: BT.709
Здесь содержаться метаданные о колориметрических характеристиках изображения. Фактически это ссылка на номер телевизионного стандарта, в котором определены коэффициенты линейного преобразования между пространствами RGB и YUV. Требуется для правильной цветопередачи при воспроизведении. Можно раскрыть, конечно, подробнее с описанием кишков камеры, но оно тебе надо?
см. https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/International_Commission_on_Illumination
https://en.wikipedia.org/wiki/CIE_1931_color_space
https://en.wikipedia.org/wiki/CIELAB_color_space
Это, так сказать, конец основного ликбеза.
Не надо пугаться! Ликбез нужен просто, чтобы ты понимал приблизительно, как оно устроено вообще, и о чём я говорю.
Далее:
Здесь речь о внутреннем представлении цвета. Конкретно по порядку указано: модель представления цветовой информации (YUV), способ прореживания отсчётов цветоразностных составляющих (4:2:0) и размерность (глубина квантования 8 бит) каждого отсчёта. Естественное для человека восприятие цвета для иллюзии изображения, создаваемого светящимся источником соответствует аддитивной модели RBG (Red, Green, Blue), причём, к пространственным колебаниям яркости света зрение будет более чувствительно, чем к пространственным колебаниям цветового тона. По этому для цветного телевидения (а также для целей обратной совместимости и ч/б телевидением) аддитивная модель (в ней иллюзия цвета создаётся путём пространственного наложения трёх отличающихся длиной волны излучений в определённых соотношениях интенсивности), представления дополняется цветоразностной схемой (YUV), где триада сигналов R, G и B путём линейного преобразования (формулы см. в статье) преобразуется в триаду сигналов, состоящую из интенсивности и двух цветоразностных сигналов.
После линейного преобразования RGB->YUV, цветоразностные составляющие, как правило, передаются с меньшим пространственным разрешением. Последнее достигается путём прореживания отсчётов, так, чтобы одному из пары отсчётов цветоразности геометрически соответствовало два или четыре отсчёта яркости. Так для схемы прореживания 4:2:0 растр яркостной составляющей (интенсивности) будет у тебя 1920×1080, а для каждой из цветоразностных — 960×540 точек.
Про глубину квантования подробно написано с примерами и иллюстрациями в статье, а я скажу кратко, что пр итвоей размерности в 8 бит возможно обеспечить на каждую из цветовых составляющих по 255 возможных уровней интенсивности (и ещё нулевой, да). Как правило, 255 ненулевых равномерно распределённых уровней достаточно для создания качественной иллюзии пространственных переходов полутонов в изображении.
см. https://en.wikipedia.org/wiki/YUV
https://en.wikipedia.org/wiki/Chroma_subsampling
https://en.wikipedia.org/wiki/Additive_color
https://en.wikipedia.org/wiki/Color_depth
https://en.wikipedia.org/wiki/Quantization_(signal_processing)
Здесь содержаться метаданные о колориметрических характеристиках изображения. Фактически это ссылка на номер телевизионного стандарта, в котором определены коэффициенты линейного преобразования между пространствами RGB и YUV. Требуется для правильной цветопередачи при воспроизведении. Можно раскрыть, конечно, подробнее с описанием кишков камеры, но оно тебе надо?
см. https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/International_Commission_on_Illumination
https://en.wikipedia.org/wiki/CIE_1931_color_space
https://en.wikipedia.org/wiki/CIELAB_color_space
Это, так сказать, конец основного ликбеза.
Далее:
> Color space: YUV
> Chroma subsampling: 4:2:0
> Bit depth: 8 bits
Здесь речь о внутреннем представлении цвета. Конкретно по порядку указано: модель представления цветовой информации (YUV), способ прореживания отсчётов цветоразностных составляющих (4:2:0) и размерность (глубина квантования 8 бит) каждого отсчёта. Естественное для человека восприятие цвета для иллюзии изображения, создаваемого светящимся источником соответствует аддитивной модели RBG (Red, Green, Blue), причём, к пространственным колебаниям яркости света зрение будет более чувствительно, чем к пространственным колебаниям цветового тона. По этому для цветного телевидения (а также для целей обратной совместимости и ч/б телевидением) аддитивная модель (в ней иллюзия цвета создаётся путём пространственного наложения трёх отличающихся длиной волны излучений в определённых соотношениях интенсивности), представления дополняется цветоразностной схемой (YUV), где триада сигналов R, G и B путём линейного преобразования (формулы см. в статье) преобразуется в триаду сигналов, состоящую из интенсивности и двух цветоразностных сигналов.
После линейного преобразования RGB->YUV, цветоразностные составляющие, как правило, передаются с меньшим пространственным разрешением. Последнее достигается путём прореживания отсчётов, так, чтобы одному из пары отсчётов цветоразности геометрически соответствовало два или четыре отсчёта яркости. Так для схемы прореживания 4:2:0 растр яркостной составляющей (интенсивности) будет у тебя 1920×1080, а для каждой из цветоразностных — 960×540 точек.
Про глубину квантования подробно написано с примерами и иллюстрациями в статье, а я скажу кратко, что пр итвоей размерности в 8 бит возможно обеспечить на каждую из цветовых составляющих по 255 возможных уровней интенсивности (и ещё нулевой, да). Как правило, 255 ненулевых равномерно распределённых уровней достаточно для создания качественной иллюзии пространственных переходов полутонов в изображении.
см. https://en.wikipedia.org/wiki/YUV
https://en.wikipedia.org/wiki/Chroma_subsampling
https://en.wikipedia.org/wiki/Additive_color
https://en.wikipedia.org/wiki/Color_depth
https://en.wikipedia.org/wiki/Quantization_(signal_processing)
> Color primaries: BT.709
> Transfer characteristics: BT.709
> Matrix coefficients: BT.709
Здесь содержаться метаданные о колориметрических характеристиках изображения. Фактически это ссылка на номер телевизионного стандарта, в котором определены коэффициенты линейного преобразования между пространствами RGB и YUV. Требуется для правильной цветопередачи при воспроизведении. Можно раскрыть, конечно, подробнее с описанием кишков камеры, но оно тебе надо?
см. https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/International_Commission_on_Illumination
https://en.wikipedia.org/wiki/CIE_1931_color_space
https://en.wikipedia.org/wiki/CIELAB_color_space
Это, так сказать, конец основного ликбеза.
>>390284
Теперь ближе к делу.
Надеюсь, ты в курсе, что youtube берёт ffmpeg и пережимает твоё видео в то, что соответствует спецификациям его сервиса. Автоматически. Я так понимаю, настройки пользователю сервиса не предоставляются.
Youtube всё равно ужмёт грубее. Я полагаю, что для libx264 с профилем high@4.1 и предустановками slower или veryslow будет вполне достаточно 10 Мбит/с. Чтобы уже при просмотре с youtube не бросалась в глаза разница.
Без примера оригинального видео сказать сложно, но скорее всего будет так.
Можно попробовать библиотеку libx265, там, при не бросающемся в глаза снижении качества, можно добиться уменьшения потока до 6...8 Мбит/с для FullHD.
Теперь пару слов про кодеки и качество:
- книга про x264 — Ричардсон, Ян. Видеокодирование. H.264 и MPEG-4-стандарты нового поколения
- книга про качество — Christian Keimel. Design of Video Quality Metrics with Multi-Way Data Analysis
- рекомендуемая метрика качества (чтобы на глаз не оценивать) — SSIM и связанные.
см. https://en.wikipedia.org/wiki/Structural_similarity
Опять же вопрос, сколько ты времени готов отдать на кодирование, обеспечивающее тебе терпимое время загрузки?
Теперь ближе к делу.
> Выкладываю на ютуб в качестве 20Мбит/с.
Надеюсь, ты в курсе, что youtube берёт ffmpeg и пережимает твоё видео в то, что соответствует спецификациям его сервиса. Автоматически. Я так понимаю, настройки пользователю сервиса не предоставляются.
> Пробовал сжимать до 16Мбит/с, есть некоторая потеря качества.
Youtube всё равно ужмёт грубее. Я полагаю, что для libx264 с профилем high@4.1 и предустановками slower или veryslow будет вполне достаточно 10 Мбит/с. Чтобы уже при просмотре с youtube не бросалась в глаза разница.
Без примера оригинального видео сказать сложно, но скорее всего будет так.
Можно попробовать библиотеку libx265, там, при не бросающемся в глаза снижении качества, можно добиться уменьшения потока до 6...8 Мбит/с для FullHD.
Теперь пару слов про кодеки и качество:
- книга про x264 — Ричардсон, Ян. Видеокодирование. H.264 и MPEG-4-стандарты нового поколения
- книга про качество — Christian Keimel. Design of Video Quality Metrics with Multi-Way Data Analysis
- рекомендуемая метрика качества (чтобы на глаз не оценивать) — SSIM и связанные.
см. https://en.wikipedia.org/wiki/Structural_similarity
> У меня скорость на отдачу 0,75Мбит/с.
Опять же вопрос, сколько ты времени готов отдать на кодирование, обеспечивающее тебе терпимое время загрузки?
Ну, и про Format Factory.
Устанавливать я её не буду, конечно. Но хотелось бы скриншоты увидеть на предмет имеющихся настроек.
Кстати, хотелось бы узнать, какие тебе доступны видеоадаптеры (видеокарты), чтобы оценить возможности аппаратного кодирования.
На вопросы отвечать буду, если что.
Устанавливать я её не буду, конечно. Но хотелось бы скриншоты увидеть на предмет имеющихся настроек.
Кстати, хотелось бы узнать, какие тебе доступны видеоадаптеры (видеокарты), чтобы оценить возможности аппаратного кодирования.
На вопросы отвечать буду, если что.
Алсо, аноны, кому интересно, могут конспектировать.
Вот примеры подготовки под YouTube для ffmpeg:
https://trac.ffmpeg.org/wiki/Encode/YouTube#BasicExamples
https://trac.ffmpeg.org/wiki/Encode/YouTube#BasicExamples
К вопросу о том, что для кодирования видео использует YouTube на серверах Гугеля:
https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html
https://multimedia.cx/eggs/googles-youtube-uses-ffmpeg/
https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html
https://multimedia.cx/eggs/googles-youtube-uses-ffmpeg/
>>390567
Вот моё видео из подземелий, которое я выкладывал в качестве 1080p и весило 1,9Гб , после обработки на ютубе при качестве 720p (доступно только скачивание с таким качеством) стало весить 138Мб. Конечно, это похоже на стрельбу из пушки по воробьям, но зато никаких артефактов сжатия.
Ну вот я и спрашиваю, какие есть кодировщики, и сколько ядер они могут загрузить?
Я перепробовал много видеоконвертеров, и каждый из них был плох по своему. Когда-то я задал такой вопрос на одном из форумов: Почему бывает видео, вроде бы небольшое, и с приличным качеством, а бывает и файл большой и качество низкое. Мне ответили, что это зависит от конвертера. Тогда я спросил, какой посоветуете? Мне ответили, попробуй для начала Format Factory, вот с тех пор я им и пользуюсь.
>Надеюсь, ты в курсе, что youtube берёт ffmpeg и пережимает твоё видео в то, что соответствует спецификациям его сервиса.
Вот моё видео из подземелий, которое я выкладывал в качестве 1080p и весило 1,9Гб , после обработки на ютубе при качестве 720p (доступно только скачивание с таким качеством) стало весить 138Мб. Конечно, это похоже на стрельбу из пушки по воробьям, но зато никаких артефактов сжатия.
>Youtube всё равно ужмёт грубее. Я полагаю, что для libx264 с профилем high@4.1 и предустановками slower или veryslow будет вполне достаточно 10 Мбит/с. Чтобы уже при просмотре с youtube не бросалась в глаза разница.
>Можно попробовать библиотеку libx265, там, при не бросающемся в глаза снижении качества, можно добиться уменьшения потока до 6...8 Мбит/с для FullHD.
Ну вот я и спрашиваю, какие есть кодировщики, и сколько ядер они могут загрузить?
Я перепробовал много видеоконвертеров, и каждый из них был плох по своему. Когда-то я задал такой вопрос на одном из форумов: Почему бывает видео, вроде бы небольшое, и с приличным качеством, а бывает и файл большой и качество низкое. Мне ответили, что это зависит от конвертера. Тогда я спросил, какой посоветуете? Мне ответили, попробуй для начала Format Factory, вот с тех пор я им и пользуюсь.
>>390580
Почему никто не создаст видеоредактор основанный на ffmpeg? Это типа того, как Ubuntu основан на Debian
>https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html
Почему никто не создаст видеоредактор основанный на ffmpeg? Это типа того, как Ubuntu основан на Debian
>>391016
Ну, вполне. Осталось скачанное скормить mediainfo и посмотреть, в чём может быть секрет. А ещё можно дать исходное мне и я могу у себя попрактиковаться с настройками кодировщиков. Я просто уже семь-восемь лет, как не в теме. И своих любимых настроек не помню. Расскажу тебе, что там по чём, и какие коэффициенты сжатия можно выдавить из какой библиотеки.
Сложно сказать, что прямо-таки никаких. Из видео удалено столько избыточности, что наверняка от текстур осталось только смутное воспоминание.
См. рисунок. На ней результаты моего исследования пятилетней давности, я сравнивал типовых представителей кодировщиков популярных стандартных и интересных нестандартных. Все кодировщики программные. Кривые получены безотносительно компромисса между скоростью кодирования (т.е. в некоторых случаях из библиотек выжималось почти всё, на что они способны). Область под каждой кривой соответствует субоптимальным решениям, т.е. таким настройкам той же самой библиотеке кодера, которые обеспечивают меньший коэффициент сжатия при том же качестве.
Картика старая, но поскольку библиотеки кодировщиков были уже довольно зрелых версий, то для них, скорее всего, ничего не поменялось. С другой стороны сегодня есть несколько библиотек, реализующих новый стандарт H.265 и три библиотеки, реализующие кодировщик VP9. Говорят, что предельные степени сжатия у кодировщиков (libx265, libvpx) в 1,2...2 раза выше, чем у x265, но скорость кодирования уступает очень существенно (в 10 и более раз, вроде).
Я пробовал libx264 в деле и могу заключить пока, что это кодер будущего, сравнительно далёкого, а сейчас практичнее рабочая лошадка — x264.
см. https://en.wikipedia.org/wiki/VP9
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
Вообще, если свести большинство подходящих тебе решений к разумному перечислению, то из библиотек программного кодирования можно попробовать:
- libvpx (VP9),
- libx264 (H.264).
из аппаратных можно попробовать платформы (в зависимости от поддерживающего оборудования):
- NVENC (H.264, H.265),
- AMF (h264_amf, hevc_amf),
- QSV (H.264, H.265).
см. https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
https://github.com/obsproject/obs-amd-encoder/wiki/Hardware-Support
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
https://trac.ffmpeg.org/wiki/HWAccelIntro
Конкретно за аппаратные кодеры не скажу, т.к. не пользуюсь, и не горю желанием выяснять совместимость оборудования, которым располагаю я. Но если кто-то из анонимусов имеет хороший годный опыт, то можно и попробовать. Хотя судя по отчётам, упомянутым в этом треде, качество там сильно неважное.
Предлагаю остановиться на чисто программных.
От этого в первую очередь, вернее, от библиотеки кодировщика (т.к. одна и таже библиотека или, например одна и та же микросхема) может использоваться в нескольких разных конвертерах и давать там одинаковый результат. Во-вторых, как я уже сказал, процесс кодирования с компенсацией движения — это процесс в котором кодировщик пытается приблизительно определить входной материал относительно своих примитивов (макроблоки, вектора движения и пр.); выходной поток данных при этом содержит параметры построения видеоряда, похожего на исходный, из предусмотренных стандартом примитивов. Примерно как мы с тобой составляем слова из букв, а предложения из слов. Причём сама задача определения видеоряда относительно примитивов ставится как оптимизационная, и имеет и критарии оптимальности и много разнообразный параметров, доступных через настройки.Вот от настроек кодировщика очень сильно зависит коэффициент сжатия.
Нравится? Что он там может-то? Какие стандарты кодирования видео поддерживает? Какие может использовать собственные или внешние библиотеки?
> Вот моё видео из подземелий, которое я выкладывал в качестве 1080p и весило 1,9Гб, после обработки на ютубе при качестве 720p (доступно только скачивание с таким качеством) стало весить 138Мб.
Ну, вполне. Осталось скачанное скормить mediainfo и посмотреть, в чём может быть секрет. А ещё можно дать исходное мне и я могу у себя попрактиковаться с настройками кодировщиков. Я просто уже семь-восемь лет, как не в теме. И своих любимых настроек не помню. Расскажу тебе, что там по чём, и какие коэффициенты сжатия можно выдавить из какой библиотеки.
> Конечно, это похоже на стрельбу из пушки по воробьям, но зато никаких артефактов сжатия.
Сложно сказать, что прямо-таки никаких. Из видео удалено столько избыточности, что наверняка от текстур осталось только смутное воспоминание.
> Ну вот я и спрашиваю, какие есть кодировщики, и сколько ядер они могут загрузить?
См. рисунок. На ней результаты моего исследования пятилетней давности, я сравнивал типовых представителей кодировщиков популярных стандартных и интересных нестандартных. Все кодировщики программные. Кривые получены безотносительно компромисса между скоростью кодирования (т.е. в некоторых случаях из библиотек выжималось почти всё, на что они способны). Область под каждой кривой соответствует субоптимальным решениям, т.е. таким настройкам той же самой библиотеке кодера, которые обеспечивают меньший коэффициент сжатия при том же качестве.
Картика старая, но поскольку библиотеки кодировщиков были уже довольно зрелых версий, то для них, скорее всего, ничего не поменялось. С другой стороны сегодня есть несколько библиотек, реализующих новый стандарт H.265 и три библиотеки, реализующие кодировщик VP9. Говорят, что предельные степени сжатия у кодировщиков (libx265, libvpx) в 1,2...2 раза выше, чем у x265, но скорость кодирования уступает очень существенно (в 10 и более раз, вроде).
Я пробовал libx264 в деле и могу заключить пока, что это кодер будущего, сравнительно далёкого, а сейчас практичнее рабочая лошадка — x264.
см. https://en.wikipedia.org/wiki/VP9
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
Вообще, если свести большинство подходящих тебе решений к разумному перечислению, то из библиотек программного кодирования можно попробовать:
- libvpx (VP9),
- libx264 (H.264).
из аппаратных можно попробовать платформы (в зависимости от поддерживающего оборудования):
- NVENC (H.264, H.265),
- AMF (h264_amf, hevc_amf),
- QSV (H.264, H.265).
см. https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
https://github.com/obsproject/obs-amd-encoder/wiki/Hardware-Support
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
https://trac.ffmpeg.org/wiki/HWAccelIntro
Конкретно за аппаратные кодеры не скажу, т.к. не пользуюсь, и не горю желанием выяснять совместимость оборудования, которым располагаю я. Но если кто-то из анонимусов имеет хороший годный опыт, то можно и попробовать. Хотя судя по отчётам, упомянутым в этом треде, качество там сильно неважное.
Предлагаю остановиться на чисто программных.
> Почему бывает видео, вроде бы небольшое, и с приличным качеством, а бывает и файл большой и качество низкое.
От этого в первую очередь, вернее, от библиотеки кодировщика (т.к. одна и таже библиотека или, например одна и та же микросхема) может использоваться в нескольких разных конвертерах и давать там одинаковый результат. Во-вторых, как я уже сказал, процесс кодирования с компенсацией движения — это процесс в котором кодировщик пытается приблизительно определить входной материал относительно своих примитивов (макроблоки, вектора движения и пр.); выходной поток данных при этом содержит параметры построения видеоряда, похожего на исходный, из предусмотренных стандартом примитивов. Примерно как мы с тобой составляем слова из букв, а предложения из слов. Причём сама задача определения видеоряда относительно примитивов ставится как оптимизационная, и имеет и критарии оптимальности и много разнообразный параметров, доступных через настройки.Вот от настроек кодировщика очень сильно зависит коэффициент сжатия.
> Мне ответили, попробуй для начала Format Factory, вот с тех пор я им и пользуюсь.
Нравится? Что он там может-то? Какие стандарты кодирования видео поддерживает? Какие может использовать собственные или внешние библиотеки?
>>391016
Ну, вполне. Осталось скачанное скормить mediainfo и посмотреть, в чём может быть секрет. А ещё можно дать исходное мне и я могу у себя попрактиковаться с настройками кодировщиков. Я просто уже семь-восемь лет, как не в теме. И своих любимых настроек не помню. Расскажу тебе, что там по чём, и какие коэффициенты сжатия можно выдавить из какой библиотеки.
Сложно сказать, что прямо-таки никаких. Из видео удалено столько избыточности, что наверняка от текстур осталось только смутное воспоминание.
См. рисунок. На ней результаты моего исследования пятилетней давности, я сравнивал типовых представителей кодировщиков популярных стандартных и интересных нестандартных. Все кодировщики программные. Кривые получены безотносительно компромисса между скоростью кодирования (т.е. в некоторых случаях из библиотек выжималось почти всё, на что они способны). Область под каждой кривой соответствует субоптимальным решениям, т.е. таким настройкам той же самой библиотеке кодера, которые обеспечивают меньший коэффициент сжатия при том же качестве.
Картика старая, но поскольку библиотеки кодировщиков были уже довольно зрелых версий, то для них, скорее всего, ничего не поменялось. С другой стороны сегодня есть несколько библиотек, реализующих новый стандарт H.265 и три библиотеки, реализующие кодировщик VP9. Говорят, что предельные степени сжатия у кодировщиков (libx265, libvpx) в 1,2...2 раза выше, чем у x265, но скорость кодирования уступает очень существенно (в 10 и более раз, вроде).
Я пробовал libx264 в деле и могу заключить пока, что это кодер будущего, сравнительно далёкого, а сейчас практичнее рабочая лошадка — x264.
см. https://en.wikipedia.org/wiki/VP9
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
Вообще, если свести большинство подходящих тебе решений к разумному перечислению, то из библиотек программного кодирования можно попробовать:
- libvpx (VP9),
- libx264 (H.264).
из аппаратных можно попробовать платформы (в зависимости от поддерживающего оборудования):
- NVENC (H.264, H.265),
- AMF (h264_amf, hevc_amf),
- QSV (H.264, H.265).
см. https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
https://github.com/obsproject/obs-amd-encoder/wiki/Hardware-Support
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
https://trac.ffmpeg.org/wiki/HWAccelIntro
Конкретно за аппаратные кодеры не скажу, т.к. не пользуюсь, и не горю желанием выяснять совместимость оборудования, которым располагаю я. Но если кто-то из анонимусов имеет хороший годный опыт, то можно и попробовать. Хотя судя по отчётам, упомянутым в этом треде, качество там сильно неважное.
Предлагаю остановиться на чисто программных.
От этого в первую очередь, вернее, от библиотеки кодировщика (т.к. одна и таже библиотека или, например одна и та же микросхема) может использоваться в нескольких разных конвертерах и давать там одинаковый результат. Во-вторых, как я уже сказал, процесс кодирования с компенсацией движения — это процесс в котором кодировщик пытается приблизительно определить входной материал относительно своих примитивов (макроблоки, вектора движения и пр.); выходной поток данных при этом содержит параметры построения видеоряда, похожего на исходный, из предусмотренных стандартом примитивов. Примерно как мы с тобой составляем слова из букв, а предложения из слов. Причём сама задача определения видеоряда относительно примитивов ставится как оптимизационная, и имеет и критарии оптимальности и много разнообразный параметров, доступных через настройки.Вот от настроек кодировщика очень сильно зависит коэффициент сжатия.
Нравится? Что он там может-то? Какие стандарты кодирования видео поддерживает? Какие может использовать собственные или внешние библиотеки?
> Вот моё видео из подземелий, которое я выкладывал в качестве 1080p и весило 1,9Гб, после обработки на ютубе при качестве 720p (доступно только скачивание с таким качеством) стало весить 138Мб.
Ну, вполне. Осталось скачанное скормить mediainfo и посмотреть, в чём может быть секрет. А ещё можно дать исходное мне и я могу у себя попрактиковаться с настройками кодировщиков. Я просто уже семь-восемь лет, как не в теме. И своих любимых настроек не помню. Расскажу тебе, что там по чём, и какие коэффициенты сжатия можно выдавить из какой библиотеки.
> Конечно, это похоже на стрельбу из пушки по воробьям, но зато никаких артефактов сжатия.
Сложно сказать, что прямо-таки никаких. Из видео удалено столько избыточности, что наверняка от текстур осталось только смутное воспоминание.
> Ну вот я и спрашиваю, какие есть кодировщики, и сколько ядер они могут загрузить?
См. рисунок. На ней результаты моего исследования пятилетней давности, я сравнивал типовых представителей кодировщиков популярных стандартных и интересных нестандартных. Все кодировщики программные. Кривые получены безотносительно компромисса между скоростью кодирования (т.е. в некоторых случаях из библиотек выжималось почти всё, на что они способны). Область под каждой кривой соответствует субоптимальным решениям, т.е. таким настройкам той же самой библиотеке кодера, которые обеспечивают меньший коэффициент сжатия при том же качестве.
Картика старая, но поскольку библиотеки кодировщиков были уже довольно зрелых версий, то для них, скорее всего, ничего не поменялось. С другой стороны сегодня есть несколько библиотек, реализующих новый стандарт H.265 и три библиотеки, реализующие кодировщик VP9. Говорят, что предельные степени сжатия у кодировщиков (libx265, libvpx) в 1,2...2 раза выше, чем у x265, но скорость кодирования уступает очень существенно (в 10 и более раз, вроде).
Я пробовал libx264 в деле и могу заключить пока, что это кодер будущего, сравнительно далёкого, а сейчас практичнее рабочая лошадка — x264.
см. https://en.wikipedia.org/wiki/VP9
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
Вообще, если свести большинство подходящих тебе решений к разумному перечислению, то из библиотек программного кодирования можно попробовать:
- libvpx (VP9),
- libx264 (H.264).
из аппаратных можно попробовать платформы (в зависимости от поддерживающего оборудования):
- NVENC (H.264, H.265),
- AMF (h264_amf, hevc_amf),
- QSV (H.264, H.265).
см. https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
https://github.com/obsproject/obs-amd-encoder/wiki/Hardware-Support
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
https://trac.ffmpeg.org/wiki/HWAccelIntro
Конкретно за аппаратные кодеры не скажу, т.к. не пользуюсь, и не горю желанием выяснять совместимость оборудования, которым располагаю я. Но если кто-то из анонимусов имеет хороший годный опыт, то можно и попробовать. Хотя судя по отчётам, упомянутым в этом треде, качество там сильно неважное.
Предлагаю остановиться на чисто программных.
> Почему бывает видео, вроде бы небольшое, и с приличным качеством, а бывает и файл большой и качество низкое.
От этого в первую очередь, вернее, от библиотеки кодировщика (т.к. одна и таже библиотека или, например одна и та же микросхема) может использоваться в нескольких разных конвертерах и давать там одинаковый результат. Во-вторых, как я уже сказал, процесс кодирования с компенсацией движения — это процесс в котором кодировщик пытается приблизительно определить входной материал относительно своих примитивов (макроблоки, вектора движения и пр.); выходной поток данных при этом содержит параметры построения видеоряда, похожего на исходный, из предусмотренных стандартом примитивов. Примерно как мы с тобой составляем слова из букв, а предложения из слов. Причём сама задача определения видеоряда относительно примитивов ставится как оптимизационная, и имеет и критарии оптимальности и много разнообразный параметров, доступных через настройки.Вот от настроек кодировщика очень сильно зависит коэффициент сжатия.
> Мне ответили, попробуй для начала Format Factory, вот с тех пор я им и пользуюсь.
Нравится? Что он там может-то? Какие стандарты кодирования видео поддерживает? Какие может использовать собственные или внешние библиотеки?
>>391022
Я не видел (не считая скриншотов, конечно) Ubuntu уже 12 лет. Неужели она так радикально отличается от Debian?
Многие свободные редакторы используют инфраструктуру библиотек, предоставляемых ffmpeg. Для многих видеоредакторов есть модули поддержки ffmpeg. В коммерческое ПО поддержку ffmpeg не завозят, скорее всего из-за патентных ограничений (большинство поддерживаемых ffmpeg кодеров и декодеров закрыты патентами).
Сам ffmpeg — это набор инструментов для кодирования/декодирования и постобработки мультимедиа файлов и потоков. Я например, частенько им пользуюсь, но без графических оболочек. Но я бы не сказал, что ffmpeg может работать как полноценный нелинейный композиционный редактор видео. Для этого есть другое ПО. Редактор видео я тебе уже не могу порекомендовать, т.к. у меня очень специфические представления об эргономике. Сам я использовал avisynth.
> Это типа того, как Ubuntu основан на Debian
Я не видел (не считая скриншотов, конечно) Ubuntu уже 12 лет. Неужели она так радикально отличается от Debian?
> Почему никто не создаст видеоредактор основанный на ffmpeg?
Многие свободные редакторы используют инфраструктуру библиотек, предоставляемых ffmpeg. Для многих видеоредакторов есть модули поддержки ffmpeg. В коммерческое ПО поддержку ffmpeg не завозят, скорее всего из-за патентных ограничений (большинство поддерживаемых ffmpeg кодеров и декодеров закрыты патентами).
Сам ffmpeg — это набор инструментов для кодирования/декодирования и постобработки мультимедиа файлов и потоков. Я например, частенько им пользуюсь, но без графических оболочек. Но я бы не сказал, что ffmpeg может работать как полноценный нелинейный композиционный редактор видео. Для этого есть другое ПО. Редактор видео я тебе уже не могу порекомендовать, т.к. у меня очень специфические представления об эргономике. Сам я использовал avisynth.
>>391099
А какой-то линукс вообще друг от друга отличается?
>Неужели она так радикально отличается от Debian?
А какой-то линукс вообще друг от друга отличается?
>>391090
Там, на самом деле, большую часть видео фонарь выхватывает из темноты может 1/6 - 1/8 экрана. Вот поэтому такое сжатие.
>Сложно сказать, что прямо-таки никаких. Из видео удалено столько избыточности, что наверняка от текстур осталось только смутное воспоминание.
Там, на самом деле, большую часть видео фонарь выхватывает из темноты может 1/6 - 1/8 экрана. Вот поэтому такое сжатие.
>>389520 (OP)
у h264 насколько я помню вообще нету ограничения на загрузку ядер, может зависить от программы( через premiere оч туго шло раньше 6+ ядер, сейчас вроде ситуация изменилась но где то до 14 ядер)
ht сам по себе ничего тебе не дает, вообще, нужно смотреть на реальную производительность железа
по цена качество из нового это райзен,но трейдриперы шли нахуй, кусок гавна, имеет смысл взять х8\16 2700 на b350 чипсете и сосунг память под разгон на 3600мгц
перформанс проца общий смотри по cpu.userbenchmark.com
у h264 насколько я помню вообще нету ограничения на загрузку ядер, может зависить от программы( через premiere оч туго шло раньше 6+ ядер, сейчас вроде ситуация изменилась но где то до 14 ядер)
ht сам по себе ничего тебе не дает, вообще, нужно смотреть на реальную производительность железа
по цена качество из нового это райзен,но трейдриперы шли нахуй, кусок гавна, имеет смысл взять х8\16 2700 на b350 чипсете и сосунг память под разгон на 3600мгц
перформанс проца общий смотри по cpu.userbenchmark.com
>>389520 (OP)
можешь в зеон тред заглянуть если денег мало, про потоки забудь
на бенче подбираешь себе то, на что денег хватит
можешь в зеон тред заглянуть если денег мало, про потоки забудь
на бенче подбираешь себе то, на что денег хватит
>>392577
Что сказать-то хотел.
Алсо,
http://mewiki.project357.com/wiki/X264_Settings
>>392578
Дядя бегает по крышам и подвалам с экшон-камерой за 30 к.р. У него, небось в снаряжение деньги уже вложены. Я ты предлагаешь ему потратить ещё, твёрдо при этом зная, что цена отнюдь не пропорциональна производительности.
> у h264 насколько я помню вообще нету ограничения на загрузку ядер
Что сказать-то хотел.
Алсо,
> The quality loss from multiple threads is mostly negligible unless using very high numbers of threads (say, above 16).
http://mewiki.project357.com/wiki/X264_Settings
>>392578
Дядя бегает по крышам и подвалам с экшон-камерой за 30 к.р. У него, небось в снаряжение деньги уже вложены. Я ты предлагаешь ему потратить ещё, твёрдо при этом зная, что цена отнюдь не пропорциональна производительности.
>>389813
нет, нет нет и еще раз нет.
Это очень старая инфа, хуй пойми от кого, хуй пойми зачем, я так же это читал.
Я тебе написал выше, что нужно найти ссылку на современное январское или февральское иследование, с примерами на одном из крупных порталоблогах от какой-то конторы, вроде на медиуме, а вроде и нет, я просто забыл.
Я помню твердо и четко следующее:
- овердохуя текста, доков, формул, картинок, сранений.
И вывод: с этим алгоритмом CPU для кодирования канет в небытиё. Там об алгоритме, который просто охуенно паралелится, что и является сильной стороной карты.
Загугли, я не буду гуглить за тебя и искать по закладкам. Но инфа точная, и свежая, и выводы не перепутаны.
нет, нет нет и еще раз нет.
Это очень старая инфа, хуй пойми от кого, хуй пойми зачем, я так же это читал.
Я тебе написал выше, что нужно найти ссылку на современное январское или февральское иследование, с примерами на одном из крупных порталоблогах от какой-то конторы, вроде на медиуме, а вроде и нет, я просто забыл.
Я помню твердо и четко следующее:
- овердохуя текста, доков, формул, картинок, сранений.
И вывод: с этим алгоритмом CPU для кодирования канет в небытиё. Там об алгоритме, который просто охуенно паралелится, что и является сильной стороной карты.
Загугли, я не буду гуглить за тебя и искать по закладкам. Но инфа точная, и свежая, и выводы не перепутаны.
>>393350
Инфа соточка, пруфов не будет, да?[/spoiler]
Ты принёс сюда какие-то сплетни, ты и ищешь пруфы. Это обычная и правильная практика. И вот ещё что. Результаты любого исследование должны быть проверяемыми. Даже если ты найдёшь ссылку на бложик Навального тот бложик, которому ты веришь на слово, то если у меня или других каких-то оппонентов верифицировать не получится, то там написана хуйня вне зависимости от того, как заебись выглядят иллюстрации.
> Но инфа точная, и свежая, и выводы не перепутаны.
Инфа соточка, пруфов не будет, да?[/spoiler]
Ты принёс сюда какие-то сплетни, ты и ищешь пруфы. Это обычная и правильная практика. И вот ещё что. Результаты любого исследование должны быть проверяемыми. Даже если ты найдёшь ссылку на бложик Навального тот бложик, которому ты веришь на слово, то если у меня или других каких-то оппонентов верифицировать не получится, то там написана хуйня вне зависимости от того, как заебись выглядят иллюстрации.
>>392312
Да тут запостишь ссылку - в комменты набегут тролли, так что я побаиваюсь. А ключиками что открывать собрался?
>>392577
Вот что я и хотел узнать. Кстати, когда Format Factory перекодирует видео, в диспетчере задач в списке процессов появляются процессы с названием ffmpeg *32, в количестве равном количеству ядер.
>>393249
Я купил б/ушный GoPro Hero 3 Black за 7т.р. Цены правда, начинались с 5т.р., но я не стал мелочиться. Сейчас последний GoPor Hero 7, вот он действительно стоит 35т.р. Меня мой, тот что я купил, вполне устраивает. Выдаёт 1080р 30fps. Качество для поставленной задачи вполне устраивает.
>Ну, так ты ролик-то исходный дашь, чтобы я для тебя ключики подобрал?
Да тут запостишь ссылку - в комменты набегут тролли, так что я побаиваюсь. А ключиками что открывать собрался?
>>392577
>у h264 насколько я помню вообще нету ограничения на загрузку ядер, может зависить от программы( через premiere оч туго шло раньше 6+ ядер, сейчас вроде ситуация изменилась но где то до 14 ядер)
Вот что я и хотел узнать. Кстати, когда Format Factory перекодирует видео, в диспетчере задач в списке процессов появляются процессы с названием ffmpeg *32, в количестве равном количеству ядер.
>>393249
>Дядя бегает по крышам и подвалам с экшон-камерой за 30 к.р.
Я купил б/ушный GoPro Hero 3 Black за 7т.р. Цены правда, начинались с 5т.р., но я не стал мелочиться. Сейчас последний GoPor Hero 7, вот он действительно стоит 35т.р. Меня мой, тот что я купил, вполне устраивает. Выдаёт 1080р 30fps. Качество для поставленной задачи вполне устраивает.
>>393646
Неплохо.
А траснфокация (zoom) есть у него? Для дома-семьи (не порно, конечно) не подойдёт, я так понимаю?
А я-то думал, что у них своё что-то. Как говорится, сначала они не воспринимают тебя всерьёз (некоторые сертифицированные клоуны уровня /s/, у которых Штульман вызывает смехуёчки до сих пор на первой стадии), потом они с тобой борются, а топом ты побеждаешь.
Я думаю, что это как декодер используется. Прочем, не ручаюсь. А вообще было бы забавно, если бы Format Factory оказался платным набором нарисованных кнопочек, в который обёрнут обыкновенный ffmpeg.
Очень странно. В списке процессов каждый поток отдельной строчкой что ли?
Ключиками иногда любовно называют аргументы, которые передаются программе при запуске, вводятся они путём перечисления через пробел в командной строке.
Я предлагаю тебе фактически, чтобы я за тебя все параметры кодировщика подобрал и дал тебе готовую к употреблению строчку с комментариями. Так было бы быстрее, я думаю.
Тут есть два варианта:
- ты бросишь мне ссылку на 10-минутный почтовый ящик или другой одноразовый ящик;
- ты прикинешь на глаз, какое видео из тестовых последовательностей больше похоже на то, что ты пытаешься зажать.
Тестовые последовательности есть такие:
https://media.xiph.org/ldv/pub/test_sequences/1080p/
https://media.xiph.org/svt/
http://www.testvid.com/all-test-material/4k-media/84-test-4k-quad-hd-usa-europe-asia-video-t2v041
http://medialab.sjtu.edu.cn/web4k/index.html
http://ultravideo.cs.tut.fi/#testsequences
> Я купил б/ушный GoPro Hero 3 Black за 7т.р.
Неплохо.
> Качество для поставленной задачи вполне устраивает.
А траснфокация (zoom) есть у него? Для дома-семьи (не порно, конечно) не подойдёт, я так понимаю?
> Format Factory перекодирует видео, в диспетчере задач... ffmpeg *32
А я-то думал, что у них своё что-то. Как говорится, сначала они не воспринимают тебя всерьёз (некоторые сертифицированные клоуны уровня /s/, у которых Штульман вызывает смехуёчки до сих пор на первой стадии), потом они с тобой борются, а топом ты побеждаешь.
Я думаю, что это как декодер используется. Прочем, не ручаюсь. А вообще было бы забавно, если бы Format Factory оказался платным набором нарисованных кнопочек, в который обёрнут обыкновенный ffmpeg.
> в количестве равном количеству ядер.
Очень странно. В списке процессов каждый поток отдельной строчкой что ли?
> А ключиками что открывать собрался?
Ключиками иногда любовно называют аргументы, которые передаются программе при запуске, вводятся они путём перечисления через пробел в командной строке.
Я предлагаю тебе фактически, чтобы я за тебя все параметры кодировщика подобрал и дал тебе готовую к употреблению строчку с комментариями. Так было бы быстрее, я думаю.
> Да тут запостишь ссылку - в комменты набегут тролли, так что я побаиваюсь.
Тут есть два варианта:
- ты бросишь мне ссылку на 10-минутный почтовый ящик или другой одноразовый ящик;
- ты прикинешь на глаз, какое видео из тестовых последовательностей больше похоже на то, что ты пытаешься зажать.
Тестовые последовательности есть такие:
https://media.xiph.org/ldv/pub/test_sequences/1080p/
https://media.xiph.org/svt/
http://www.testvid.com/all-test-material/4k-media/84-test-4k-quad-hd-usa-europe-asia-video-t2v041
http://medialab.sjtu.edu.cn/web4k/index.html
http://ultravideo.cs.tut.fi/#testsequences
>>393646
Неплохо.
А траснфокация (zoom) есть у него? Для дома-семьи (не порно, конечно) не подойдёт, я так понимаю?
А я-то думал, что у них своё что-то. Как говорится, сначала они не воспринимают тебя всерьёз (некоторые сертифицированные клоуны уровня /s/, у которых Штульман вызывает смехуёчки до сих пор на первой стадии), потом они с тобой борются, а топом ты побеждаешь.
Я думаю, что это как декодер используется. Прочем, не ручаюсь. А вообще было бы забавно, если бы Format Factory оказался платным набором нарисованных кнопочек, в который обёрнут обыкновенный ffmpeg.
Очень странно. В списке процессов каждый поток отдельной строчкой что ли?
Ключиками иногда любовно называют аргументы, которые передаются программе при запуске, вводятся они путём перечисления через пробел в командной строке.
Я предлагаю тебе фактически, чтобы я за тебя все параметры кодировщика подобрал и дал тебе готовую к употреблению строчку с комментариями. Так было бы быстрее, я думаю.
Тут есть два варианта:
- ты бросишь мне ссылку на 10-минутный почтовый ящик или другой одноразовый ящик;
- ты прикинешь на глаз, какое видео из тестовых последовательностей больше похоже на то, что ты пытаешься зажать.
Тестовые последовательности есть такие:
https://media.xiph.org/ldv/pub/test_sequences/1080p/
https://media.xiph.org/svt/
http://www.testvid.com/all-test-material/4k-media/84-test-4k-quad-hd-usa-europe-asia-video-t2v041
http://medialab.sjtu.edu.cn/web4k/index.html
http://ultravideo.cs.tut.fi/#testsequences
> Я купил б/ушный GoPro Hero 3 Black за 7т.р.
Неплохо.
> Качество для поставленной задачи вполне устраивает.
А траснфокация (zoom) есть у него? Для дома-семьи (не порно, конечно) не подойдёт, я так понимаю?
> Format Factory перекодирует видео, в диспетчере задач... ffmpeg *32
А я-то думал, что у них своё что-то. Как говорится, сначала они не воспринимают тебя всерьёз (некоторые сертифицированные клоуны уровня /s/, у которых Штульман вызывает смехуёчки до сих пор на первой стадии), потом они с тобой борются, а топом ты побеждаешь.
Я думаю, что это как декодер используется. Прочем, не ручаюсь. А вообще было бы забавно, если бы Format Factory оказался платным набором нарисованных кнопочек, в который обёрнут обыкновенный ffmpeg.
> в количестве равном количеству ядер.
Очень странно. В списке процессов каждый поток отдельной строчкой что ли?
> А ключиками что открывать собрался?
Ключиками иногда любовно называют аргументы, которые передаются программе при запуске, вводятся они путём перечисления через пробел в командной строке.
Я предлагаю тебе фактически, чтобы я за тебя все параметры кодировщика подобрал и дал тебе готовую к употреблению строчку с комментариями. Так было бы быстрее, я думаю.
> Да тут запостишь ссылку - в комменты набегут тролли, так что я побаиваюсь.
Тут есть два варианта:
- ты бросишь мне ссылку на 10-минутный почтовый ящик или другой одноразовый ящик;
- ты прикинешь на глаз, какое видео из тестовых последовательностей больше похоже на то, что ты пытаешься зажать.
Тестовые последовательности есть такие:
https://media.xiph.org/ldv/pub/test_sequences/1080p/
https://media.xiph.org/svt/
http://www.testvid.com/all-test-material/4k-media/84-test-4k-quad-hd-usa-europe-asia-video-t2v041
http://medialab.sjtu.edu.cn/web4k/index.html
http://ultravideo.cs.tut.fi/#testsequences
Не буду скрывать, статью я нашёл сам.
Вот она http://downloads.hindawi.com/journals/sp/2017/1431574.pdf
Можно при желании разобрать, что там конкретно написано, но у выводов статьи и кукареков >>393350-куна выводы расходятся. В деталях, правда расходятся, в принципиальных.
>>393586-хуй
Вот она http://downloads.hindawi.com/journals/sp/2017/1431574.pdf
Можно при желании разобрать, что там конкретно написано, но у выводов статьи и кукареков >>393350-куна выводы расходятся. В деталях, правда расходятся, в принципиальных.
>>393586-хуй
>>392577
Adobe Premiere поддерживает 14 ядер? Интересно, интересно...
>>393697
А траснфокация (zoom) есть у него? Для дома-семьи (не порно, конечно) не подойдёт, я так понимаю?
Zoom'а нет. Объектив "рыбий глаз", но его можно заменить. Подойдёт и для дома.
Ну да.
Видео содержит разнотипные сцены, и плохой и хорошей освещёности, чёрно-белые и полноцветные, медленные и рывки. Так что не думаю что там можно что-то сильно ужать.
>через premiere оч туго шло раньше 6+ ядер, сейчас вроде ситуация изменилась но где то до 14 ядер
Adobe Premiere поддерживает 14 ядер? Интересно, интересно...
>>393697
> Качество для поставленной задачи вполне устраивает.
А траснфокация (zoom) есть у него? Для дома-семьи (не порно, конечно) не подойдёт, я так понимаю?
Zoom'а нет. Объектив "рыбий глаз", но его можно заменить. Подойдёт и для дома.
>> в количестве равном количеству ядер.
>Очень странно. В списке процессов каждый поток отдельной строчкой что ли?
Ну да.
>> А ключиками что открывать собрался?
>Ключиками иногда любовно называют аргументы, которые передаются программе при запуске, вводятся они путём перечисления через пробел в командной строке.
Видео содержит разнотипные сцены, и плохой и хорошей освещёности, чёрно-белые и полноцветные, медленные и рывки. Так что не думаю что там можно что-то сильно ужать.
>>394426
Ну смотри. Предложение в силе. Файлообменники подходящие знаешь?
> Видео содержит разнотипные сцены, и плохой и хорошей освещёности, чёрно-белые и полноцветные, медленные и рывки. Так что не думаю что там можно что-то сильно ужать.
Ну смотри. Предложение в силе. Файлообменники подходящие знаешь?
>>394486
Я смотрю Adobe Premiere сжимает видео раз в 6-8 быстрее чем Format Factory. Наверно на этом и остановлюсь.
>Ну смотри. Предложение в силе. Файлообменники подходящие знаешь?
Я смотрю Adobe Premiere сжимает видео раз в 6-8 быстрее чем Format Factory. Наверно на этом и остановлюсь.
232 Кб, 720x486>>396181
Вот и хорошо. Я рад, что ты нашёл подходящий тебе инструмент. Спасибо за ответы! Удачной работы тебе!
> Наверно на этом и остановлюсь.
Вот и хорошо. Я рад, что ты нашёл подходящий тебе инструмент. Спасибо за ответы! Удачной работы тебе!
Могу, кстати из этого треда попробовать статью слепить для >>2396260 (OP).
Оно кому-нибудь надо?
Оно кому-нибудь надо?
>>399954
Конкретизируй, пожалуйста!
Конкретизируй, пожалуйста!
>>397980
Было бы здорово. У тебя нет времени обновить таблицу сравнения SSIM/коэф. сжатия для h.265 и VP9? Интуитивно понятно, что их отсчет будет начинаться чуть правее предшественников.
Было бы здорово. У тебя нет времени обновить таблицу сравнения SSIM/коэф. сжатия для h.265 и VP9? Интуитивно понятно, что их отсчет будет начинаться чуть правее предшественников.
>>399962
Нет. Сейчас нет. Там надо ключиков попробовать очень много. А эти два формата ещё и по вычислительным мощностям сильно тяжёлые. Плюс я так понимаю, что h.265 и VP9 следует пробовать уже не на PAL-последовательности, а на FHD, или даже UHD. Тут ещё пораскинуть мозгами надо. Эксперимент спланировать. Попробую как-нибудь до конца года.
Начнётся правее, вопрос в том, где пересечётся. Посмотрим, может быть, и сделаю.
> У тебя нет времени обновить таблицу сравнения SSIM/коэф. сжатия для h.265 и VP9?
Нет. Сейчас нет. Там надо ключиков попробовать очень много. А эти два формата ещё и по вычислительным мощностям сильно тяжёлые. Плюс я так понимаю, что h.265 и VP9 следует пробовать уже не на PAL-последовательности, а на FHD, или даже UHD. Тут ещё пораскинуть мозгами надо. Эксперимент спланировать. Попробую как-нибудь до конца года.
> Интуитивно понятно, что их отсчет будет начинаться чуть правее предшественников.
Начнётся правее, вопрос в том, где пересечётся. Посмотрим, может быть, и сделаю.
>>399967
У меня вопрос менее научный,
https://mattgadient.com/x264-vs-x265-vs-vp8-vs-vp9-examples/
В оригинале тон кожи у Форда как у пропитого пьяницы, если напрямую сравнивать с равным битрейтом x265 против VP9, то последний к оригиналу ближе. SSIM это должен учитывать, верно?
И в чем может быть причина поведения? Конкретный энкодер?
У меня вопрос менее научный,
https://mattgadient.com/x264-vs-x265-vs-vp8-vs-vp9-examples/
В оригинале тон кожи у Форда как у пропитого пьяницы, если напрямую сравнивать с равным битрейтом x265 против VP9, то последний к оригиналу ближе. SSIM это должен учитывать, верно?
И в чем может быть причина поведения? Конкретный энкодер?
>>399977
Интересное сравнение. Погляжу, если руки дойдут.
Твою тонкую метафору не могу уловить, если честно. Предпочтительно, чтобы ты указал в направлении какого цвета оттенок смещён.
Насколько помню, анализируется только яркостная составляющая, цветоразности игнорируются. Не факт, что покажет.
Вообще, кодеры не должны давать постоянного смещения в какой-либо составляющей — это должно раздувать сумму штрафа на очень ранней стадии. Возможно, ты поймал баг в libx265. Но всё-таки попробуй сравнить картинки не на вёб-странице, а на том же самом месте на мониторе чередованием!
> https://mattgadient.com/x264-vs-x265-vs-vp8-vs-vp9-examples/
Интересное сравнение. Погляжу, если руки дойдут.
> В оригинале тон кожи у Форда как у пропитого пьяницы
Твою тонкую метафору не могу уловить, если честно. Предпочтительно, чтобы ты указал в направлении какого цвета оттенок смещён.
> SSIM это должен учитывать, верно?
Насколько помню, анализируется только яркостная составляющая, цветоразности игнорируются. Не факт, что покажет.
> И в чем может быть причина поведения? Конкретный энкодер?
Вообще, кодеры не должны давать постоянного смещения в какой-либо составляющей — это должно раздувать сумму штрафа на очень ранней стадии. Возможно, ты поймал баг в libx265. Но всё-таки попробуй сравнить картинки не на вёб-странице, а на том же самом месте на мониторе чередованием!
>>399981
Поправлюсь:
Цветоразности тоже сравнивает. Подсмотрел в исходник, да.
Поправлюсь:
> Насколько помню, анализируется только яркостная составляющая, цветоразности игнорируются. Не факт, что покажет.
Цветоразности тоже сравнивает. Подсмотрел в исходник, да.
>>399981
Оттенок в оригинале красноватый (и в других сценах смотрится естественнее), смотрел только в браузере. Владелец сайта удалил сэмплы с видео, к сожалению (или я плохо искал), остались лишь скрины.
Видел исследовательские работы из стен МГУ на тему сравнения кодеков, свежие работы у них платные, в открытом доступе статьи за 2003 год. Не удивлюсь, если окажется, что здесь сидят причастные к этим работам.
>Предпочтительно, чтобы ты указал в направлении какого цвета оттенок смещён.
Оттенок в оригинале красноватый (и в других сценах смотрится естественнее), смотрел только в браузере. Владелец сайта удалил сэмплы с видео, к сожалению (или я плохо искал), остались лишь скрины.
Видел исследовательские работы из стен МГУ на тему сравнения кодеков, свежие работы у них платные, в открытом доступе статьи за 2003 год. Не удивлюсь, если окажется, что здесь сидят причастные к этим работам.
>>400018
Да, злонамеренно удалил.
Знаем таких.
Ну, по сравнениям кодеков есть бесплатные версии с тезисами. Этого более, чем достаточно для энтузиастов.
Регаешься здесь
http://compression.ru/video/codec_comparison/hevc_2018/#download_main_report_form
и получаешь ссылку на скачивание.
А вот я бы очень удивился.
> Владелец сайта удалил сэмплы с видео, к сожалению (или я плохо искал), остались лишь скрины.
> It originally used about 145 GB of space on a dedicated server for all the images and video clips. This expense was a little hard to justify for one page, so I recently dropped all the video but kept the images (about 9GB). For reference, the entirety of mattgadient.com is about 1 GB if you exclude this page.
Да, злонамеренно удалил.
> Видел исследовательские работы из стен МГУ на тему сравнения кодеков
Знаем таких.
> свежие работы у них платные
Ну, по сравнениям кодеков есть бесплатные версии с тезисами. Этого более, чем достаточно для энтузиастов.
Регаешься здесь
http://compression.ru/video/codec_comparison/hevc_2018/#download_main_report_form
и получаешь ссылку на скачивание.
> Не удивлюсь, если окажется, что здесь сидят причастные к этим работам.
А вот я бы очень удивился.
Что я могу дополнить к тому что я писал ранее. Adobe Premiere Pro CC может и кодирует быстрее в 6-8 раз чем Format Factory, но только если не ставить галочку "наилучшее качество визуализации", а без неё качество видео не ахти. Для обработки видео я остановился на комбинации Adobe Premiere Pro CC + Format Factory. Для нарезки видео интерфейс Adobe Pr какой-то неудобный. Рабочие окна маленькие. Такого себе даже старенький WinDVD Creator не позволял. Я с помощью Format Factory разрезаю видео на отрезки, потом им же склеиваю. Недостатки такие: приходится ждать конца энкодинга чтобы посмотреть, что получилось. Плюс редактирование времени начала и конца отрезка идёт в формате ЧЧ/ММ/СС/сотые доли СС. Да именно сотые доли секунды а не номер кадра от начала секунды, как сделано в Pr или том же WinDVD Creator'е. В общем каждая программа плоха по своему. В дополнение ко всему я использую Adobe PhotoShop и Audition.
>>417728
Я сам использую Avisynth для предобработки, монтажа, композиции и постобработки (наверное, я уже говорил об этом). В перспективе буду переползать на VapourSynth. Но, скорее всего, тебе не подходит ни то, ни другое, т. к. это скриптовые нелинейные видеоредакторы, т. е. все монтажные операции определяются путём написания на специальной языке программы-сценария. Кодирую потом всё через ffmpeg.
Цепочка преобразования такая:
[Исходные файлы с видео, звуком и субтитрами, avisynth-скрипт] -> {Декодирование через ffmpeg по запросу из avisynth} -> [Готовая последовательность кадров] -> {вывод потока данных через avs2yuv на вход ffmpeg} -> [Результат]
Для визуализации использую avspmod.
От перечисленных тобой проблем такое решение свободно. Хотя, вне всякого сомнения, имеет свои.
Я сам использую Avisynth для предобработки, монтажа, композиции и постобработки (наверное, я уже говорил об этом). В перспективе буду переползать на VapourSynth. Но, скорее всего, тебе не подходит ни то, ни другое, т. к. это скриптовые нелинейные видеоредакторы, т. е. все монтажные операции определяются путём написания на специальной языке программы-сценария. Кодирую потом всё через ffmpeg.
Цепочка преобразования такая:
[Исходные файлы с видео, звуком и субтитрами, avisynth-скрипт] -> {Декодирование через ffmpeg по запросу из avisynth} -> [Готовая последовательность кадров] -> {вывод потока данных через avs2yuv на вход ffmpeg} -> [Результат]
Для визуализации использую avspmod.
От перечисленных тобой проблем такое решение свободно. Хотя, вне всякого сомнения, имеет свои.
>>390483
Блоки chroma обычно в 4 раза меньше.
Максимальный transform block в H.264 это 8x8.
DCT обычно.
Не просто, используется матрица квантования.
Удаление избыточности это motion prediction, квантование именно теряет информацию.
Арифметический энкодер не так работает.
Вам не зачёт, приходите ещё раз.
>в виде трёх (на каждую цветовую компоненту) таблиц чисел (каждая, допустим, размером тоже 16×16 элементов)
Блоки chroma обычно в 4 раза меньше.
>результатом тоже будут три таблицы коэффициентов преобразования с числами размером 16×16 элементов
Максимальный transform block в H.264 это 8x8.
>через дискретное преобразование Фурье
DCT обычно.
>просто заменяются нулями
Не просто, используется матрица квантования.
>в темринах стандартов это называется удалением избыточности из изображения
Удаление избыточности это motion prediction, квантование именно теряет информацию.
>энтропийный кодировщик использует, например, специальный словарь, он сопоставляет наиболее часто встречающиеся последовательности символов на входе с наиболее короткими последовательностями символов на выходе
Арифметический энкодер не так работает.
Вам не зачёт, приходите ещё раз.
>>393646
32-х битный ffmpeg это пиздец. Значительно медленнее 64-х битного. Там вроде часть асма под x86 вообще не задействуется.
Почему на виндоузе всё так плохо с 64 битами?
>появляются процессы с названием ffmpeg *32
32-х битный ffmpeg это пиздец. Значительно медленнее 64-х битного. Там вроде часть асма под x86 вообще не задействуется.
Почему на виндоузе всё так плохо с 64 битами?
>>423263
В любом дистрибутиве?
На виндоузе у зераное тоже нормальные билды так-то, просто авторы мокрописек выпускают 32-х битное, потому что на виндоузе так принято.
В любом дистрибутиве?
На виндоузе у зераное тоже нормальные билды так-то, просто авторы мокрописек выпускают 32-х битное, потому что на виндоузе так принято.
>>423197
Не еби человеку мозги! У него кое-как работает, его результат, в основном, устраивает — ну и хуй с ним, можем за него порадоваться.
>>423263
Вне всякого сомнения.
>>423184
Не сказал бы, что прямо таки серьёзно (ну, на 25%, например) медленнее.
>>423264
Подтверждаю.
Совершенно верно.
>>423167
Ты, как жопочтец не заметил слова «допустим». В результате, ты не понял, что сие есть намеренное упрощение. А то так не долго и до объяснения спектральной чувствительности зрения дойти. Тут не научная литература, сынок! Тут от сотворения мира начинать не надо — здесь надо общую картину пояснить. Тем паче, что на более подробную информацию я ссылки точные дал. Здесь не прав ты.
И что? А в MPEG-2 16×16.
Частный случай. Если кто-то интересуется свойствами этого самого интегрального преобразования, то правильнее искать именно от этого. А само ДКП — это вариант, более удобный для программизма.
Тогда, уж, матрица квантователя. А ещё там есть зона нечувствительности. А ещё он разная для цветоразности и яркости. Пояснения должны пояснять с предупреждением, а не запутывать окончательно. Кому это действительно интересно, так, милости прошу — я ссылки дал и на книжку Ричардсона. Тут, таки снова прав не ты.
Вот тут я соглашусь, если ты точную цитату из стандарта дашь. Но что-то мне подсказывает (возможно, воспоминания о тексте стандарта), что не дашь.
VLC, например, работает именно так. Тут снова не прав ты. Я умышленно не рассказываю про более сложные варианты вроде того же CABAC, чтобы не запутывать людей.
Русский язык подучи, не забудь!
Хуй соси! Губой тряси! Я не студенту объясняю, а простому человеку.
Что я могу тебе, >>423167, сказать. Да, замечания есть, но вот конкретно тебе бы стоило придержать всё это при себе, поскольку ты пытаешься казаться умным там, где тебе нужно было бы сохранять молчание, чтобы не развеивать все сомнения.
Не еби человеку мозги! У него кое-как работает, его результат, в основном, устраивает — ну и хуй с ним, можем за него порадоваться.
>>423263
Вне всякого сомнения.
>>423184
Не сказал бы, что прямо таки серьёзно (ну, на 25%, например) медленнее.
>>423264
> На виндоузе у зераное тоже нормальные билды так-то
Подтверждаю.
> авторы мокрописек выпускают 32-х битное, потому что на виндоузе так принято.
Совершенно верно.
>>423167
> Блоки chroma обычно в 4 раза меньше.
Ты, как жопочтец не заметил слова «допустим». В результате, ты не понял, что сие есть намеренное упрощение. А то так не долго и до объяснения спектральной чувствительности зрения дойти. Тут не научная литература, сынок! Тут от сотворения мира начинать не надо — здесь надо общую картину пояснить. Тем паче, что на более подробную информацию я ссылки точные дал. Здесь не прав ты.
> Максимальный transform block в H.264 это 8x8.
И что? А в MPEG-2 16×16.
> DCT обычно.
Частный случай. Если кто-то интересуется свойствами этого самого интегрального преобразования, то правильнее искать именно от этого. А само ДКП — это вариант, более удобный для программизма.
> Не просто, используется матрица квантования.
Тогда, уж, матрица квантователя. А ещё там есть зона нечувствительности. А ещё он разная для цветоразности и яркости. Пояснения должны пояснять с предупреждением, а не запутывать окончательно. Кому это действительно интересно, так, милости прошу — я ссылки дал и на книжку Ричардсона. Тут, таки снова прав не ты.
> Удаление избыточности это motion prediction, квантование именно теряет информацию.
Вот тут я соглашусь, если ты точную цитату из стандарта дашь. Но что-то мне подсказывает (возможно, воспоминания о тексте стандарта), что не дашь.
> Арифметический энкодер не так работает.
VLC, например, работает именно так. Тут снова не прав ты. Я умышленно не рассказываю про более сложные варианты вроде того же CABAC, чтобы не запутывать людей.
> энкодер
Русский язык подучи, не забудь!
> Вам не зачёт, приходите ещё раз.
Хуй соси! Губой тряси! Я не студенту объясняю, а простому человеку.
Что я могу тебе, >>423167, сказать. Да, замечания есть, но вот конкретно тебе бы стоило придержать всё это при себе, поскольку ты пытаешься казаться умным там, где тебе нужно было бы сохранять молчание, чтобы не развеивать все сомнения.
>>423197
Не еби человеку мозги! У него кое-как работает, его результат, в основном, устраивает — ну и хуй с ним, можем за него порадоваться.
>>423263
Вне всякого сомнения.
>>423184
Не сказал бы, что прямо таки серьёзно (ну, на 25%, например) медленнее.
>>423264
Подтверждаю.
Совершенно верно.
>>423167
Ты, как жопочтец не заметил слова «допустим». В результате, ты не понял, что сие есть намеренное упрощение. А то так не долго и до объяснения спектральной чувствительности зрения дойти. Тут не научная литература, сынок! Тут от сотворения мира начинать не надо — здесь надо общую картину пояснить. Тем паче, что на более подробную информацию я ссылки точные дал. Здесь не прав ты.
И что? А в MPEG-2 16×16.
Частный случай. Если кто-то интересуется свойствами этого самого интегрального преобразования, то правильнее искать именно от этого. А само ДКП — это вариант, более удобный для программизма.
Тогда, уж, матрица квантователя. А ещё там есть зона нечувствительности. А ещё он разная для цветоразности и яркости. Пояснения должны пояснять с предупреждением, а не запутывать окончательно. Кому это действительно интересно, так, милости прошу — я ссылки дал и на книжку Ричардсона. Тут, таки снова прав не ты.
Вот тут я соглашусь, если ты точную цитату из стандарта дашь. Но что-то мне подсказывает (возможно, воспоминания о тексте стандарта), что не дашь.
VLC, например, работает именно так. Тут снова не прав ты. Я умышленно не рассказываю про более сложные варианты вроде того же CABAC, чтобы не запутывать людей.
Русский язык подучи, не забудь!
Хуй соси! Губой тряси! Я не студенту объясняю, а простому человеку.
Что я могу тебе, >>423167, сказать. Да, замечания есть, но вот конкретно тебе бы стоило придержать всё это при себе, поскольку ты пытаешься казаться умным там, где тебе нужно было бы сохранять молчание, чтобы не развеивать все сомнения.
Не еби человеку мозги! У него кое-как работает, его результат, в основном, устраивает — ну и хуй с ним, можем за него порадоваться.
>>423263
Вне всякого сомнения.
>>423184
Не сказал бы, что прямо таки серьёзно (ну, на 25%, например) медленнее.
>>423264
> На виндоузе у зераное тоже нормальные билды так-то
Подтверждаю.
> авторы мокрописек выпускают 32-х битное, потому что на виндоузе так принято.
Совершенно верно.
>>423167
> Блоки chroma обычно в 4 раза меньше.
Ты, как жопочтец не заметил слова «допустим». В результате, ты не понял, что сие есть намеренное упрощение. А то так не долго и до объяснения спектральной чувствительности зрения дойти. Тут не научная литература, сынок! Тут от сотворения мира начинать не надо — здесь надо общую картину пояснить. Тем паче, что на более подробную информацию я ссылки точные дал. Здесь не прав ты.
> Максимальный transform block в H.264 это 8x8.
И что? А в MPEG-2 16×16.
> DCT обычно.
Частный случай. Если кто-то интересуется свойствами этого самого интегрального преобразования, то правильнее искать именно от этого. А само ДКП — это вариант, более удобный для программизма.
> Не просто, используется матрица квантования.
Тогда, уж, матрица квантователя. А ещё там есть зона нечувствительности. А ещё он разная для цветоразности и яркости. Пояснения должны пояснять с предупреждением, а не запутывать окончательно. Кому это действительно интересно, так, милости прошу — я ссылки дал и на книжку Ричардсона. Тут, таки снова прав не ты.
> Удаление избыточности это motion prediction, квантование именно теряет информацию.
Вот тут я соглашусь, если ты точную цитату из стандарта дашь. Но что-то мне подсказывает (возможно, воспоминания о тексте стандарта), что не дашь.
> Арифметический энкодер не так работает.
VLC, например, работает именно так. Тут снова не прав ты. Я умышленно не рассказываю про более сложные варианты вроде того же CABAC, чтобы не запутывать людей.
> энкодер
Русский язык подучи, не забудь!
> Вам не зачёт, приходите ещё раз.
Хуй соси! Губой тряси! Я не студенту объясняю, а простому человеку.
Что я могу тебе, >>423167, сказать. Да, замечания есть, но вот конкретно тебе бы стоило придержать всё это при себе, поскольку ты пытаешься казаться умным там, где тебе нужно было бы сохранять молчание, чтобы не развеивать все сомнения.
>>423453
И какой смысл при объяснении на пальцах рассматривать сложный случай 4:4:4, тогда как в его и 99% других случаев будет 4:2:0? Не надо было тогда вообще про сабсэмплинг упоминать.
Оставим за скобками твою юношескую пылкость и стремление выдачи быстрых, но неверных ответов. В следующий раз думай лучше и не надо цитировать всё подряд. Я на такую хуйню отвечать не буду.
Неправильно.
Неправильно.
Опять неправильно. Ты путаешь Huffman coding, VLC и arithmetic coding. Зачитывание википедией до добра не доведёт.
Который основной.
О, вот это серьёзная ошибка!
И это пишет человек, весь тред выпендривающийся википедийными знаниями. В других сообщениях тоже полно косяков, лень было всё читать.
Короче, попробуй читать что-нибудь сложнее википедии. Того же Ричардсона, хорошая книжка. И меньше выпендривайся, пока что у тебя каша в голове вместо знаний. А уж за стиль демагога и оверквотинг вообще по ебалу надо давать.
>Ты, как жопочтец не заметил слова «допустим».
И какой смысл при объяснении на пальцах рассматривать сложный случай 4:4:4, тогда как в его и 99% других случаев будет 4:2:0? Не надо было тогда вообще про сабсэмплинг упоминать.
>И что? А в MPEG-2 16×16.
Оставим за скобками твою юношескую пылкость и стремление выдачи быстрых, но неверных ответов. В следующий раз думай лучше и не надо цитировать всё подряд. Я на такую хуйню отвечать не буду.
>Частный случай.
Неправильно.
>А само ДКП — это вариант, более удобный для программизма.
Неправильно.
>VLC, например, работает именно так.
Опять неправильно. Ты путаешь Huffman coding, VLC и arithmetic coding. Зачитывание википедией до добра не доведёт.
>более сложные варианты вроде того же CABAC
Который основной.
>Русский язык подучи, не забудь!
О, вот это серьёзная ошибка!
>ты пытаешься казаться умным там, где тебе нужно было бы сохранять молчание
И это пишет человек, весь тред выпендривающийся википедийными знаниями. В других сообщениях тоже полно косяков, лень было всё читать.
Короче, попробуй читать что-нибудь сложнее википедии. Того же Ричардсона, хорошая книжка. И меньше выпендривайся, пока что у тебя каша в голове вместо знаний. А уж за стиль демагога и оверквотинг вообще по ебалу надо давать.
>>423197
Ну а что не как у червя-пидора? Свободного времени мало, да и после работы уставший, но я стараюсь изучать Adobe Pr, возможно, когда-нибудь полностью на него перекачусь.
Ну а что не как у червя-пидора? Свободного времени мало, да и после работы уставший, но я стараюсь изучать Adobe Pr, возможно, когда-нибудь полностью на него перекачусь.
>>417941
Но ведь это как у меня, пока не перекодируется, результат не увидишь.
>От перечисленных тобой проблем такое решение свободно. Хотя, вне всякого сомнения, имеет свои.
Но ведь это как у меня, пока не перекодируется, результат не увидишь.
>>423707
Ричардсона читал. H.261, H.262, H.264 читал.
Не у меня, а у тебя. Я общую картину нарисовал. Источники профита указал. Общую мысль сформулировал. А ты?
У тебя же. Не у меня. Я тебе ясно указал, что уточнение, да. Но общности моих рассуждений и выводов уточнения не нарушают. В лучшем случае, они несущественны, а ты уточнениям придаёшь значимость, которой у них нет. Посему выпендриваешься ты, а не я.
Ты когда что-то существенное найдёшь, тогда кукарекай, а пока сиди и помалкивай.
Ты обосновать забыл.
Пруфы будут или как всегда?
Ух ты! Снова вскукареки. Как неожиданно-то.
Фантазии свои при себе оставь!
Ошибся, бывает. Это единственное, к чему ты прицепиться можешь. Не большой улов, да.
Он наиболее простой, так как не вводит дополнительную операцию.
Обоснование? Не, не слышали.
> Короче, попробуй читать что-нибудь сложнее википедии.
Ричардсона читал. H.261, H.262, H.264 читал.
> И меньше выпендривайся, пока что у тебя каша в голове вместо знаний.
Не у меня, а у тебя. Я общую картину нарисовал. Источники профита указал. Общую мысль сформулировал. А ты?
> А уж за стиль демагога
У тебя же. Не у меня. Я тебе ясно указал, что уточнение, да. Но общности моих рассуждений и выводов уточнения не нарушают. В лучшем случае, они несущественны, а ты уточнениям придаёшь значимость, которой у них нет. Посему выпендриваешься ты, а не я.
> В других сообщениях тоже полно косяков, лень было всё читать.
Ты когда что-то существенное найдёшь, тогда кукарекай, а пока сиди и помалкивай.
> Опять неправильно. Ты путаешь Huffman coding, VLC и arithmetic coding.
Ты обосновать забыл.
> Неправильно.
Пруфы будут или как всегда?
> Неправильно.
Ух ты! Снова вскукареки. Как неожиданно-то.
> юношескую пылкость
Фантазии свои при себе оставь!
> В следующий раз думай лучше и не надо цитировать всё подряд. Я на такую хуйню отвечать не буду.
Ошибся, бывает. Это единственное, к чему ты прицепиться можешь. Не большой улов, да.
> рассматривать сложный случай 4:4:4
Он наиболее простой, так как не вводит дополнительную операцию.
> Не надо было тогда вообще про сабсэмплинг упоминать.
Обоснование? Не, не слышали.
>>423707
Ричардсона читал. H.261, H.262, H.264 читал.
Не у меня, а у тебя. Я общую картину нарисовал. Источники профита указал. Общую мысль сформулировал. А ты?
У тебя же. Не у меня. Я тебе ясно указал, что уточнение, да. Но общности моих рассуждений и выводов уточнения не нарушают. В лучшем случае, они несущественны, а ты уточнениям придаёшь значимость, которой у них нет. Посему выпендриваешься ты, а не я.
Ты когда что-то существенное найдёшь, тогда кукарекай, а пока сиди и помалкивай.
Ты обосновать забыл.
Пруфы будут или как всегда?
Ух ты! Снова вскукареки. Как неожиданно-то.
Фантазии свои при себе оставь!
Ошибся, бывает. Это единственное, к чему ты прицепиться можешь. Не большой улов, да.
Он наиболее простой, так как не вводит дополнительную операцию.
Обоснование? Не, не слышали.
> Короче, попробуй читать что-нибудь сложнее википедии.
Ричардсона читал. H.261, H.262, H.264 читал.
> И меньше выпендривайся, пока что у тебя каша в голове вместо знаний.
Не у меня, а у тебя. Я общую картину нарисовал. Источники профита указал. Общую мысль сформулировал. А ты?
> А уж за стиль демагога
У тебя же. Не у меня. Я тебе ясно указал, что уточнение, да. Но общности моих рассуждений и выводов уточнения не нарушают. В лучшем случае, они несущественны, а ты уточнениям придаёшь значимость, которой у них нет. Посему выпендриваешься ты, а не я.
> В других сообщениях тоже полно косяков, лень было всё читать.
Ты когда что-то существенное найдёшь, тогда кукарекай, а пока сиди и помалкивай.
> Опять неправильно. Ты путаешь Huffman coding, VLC и arithmetic coding.
Ты обосновать забыл.
> Неправильно.
Пруфы будут или как всегда?
> Неправильно.
Ух ты! Снова вскукареки. Как неожиданно-то.
> юношескую пылкость
Фантазии свои при себе оставь!
> В следующий раз думай лучше и не надо цитировать всё подряд. Я на такую хуйню отвечать не буду.
Ошибся, бывает. Это единственное, к чему ты прицепиться можешь. Не большой улов, да.
> рассматривать сложный случай 4:4:4
Он наиболее простой, так как не вводит дополнительную операцию.
> Не надо было тогда вообще про сабсэмплинг упоминать.
Обоснование? Не, не слышали.
>>424029
Что стоит твоё кривое цитирование википедийных статей, если ты наделал дохуя фактических ошибок в их воспроизведении?
Ты думашь, кроме тебя никто не догадается зайти в википедию на https://en.wikipedia.org/wiki/Template:Compression_methods и попереходить по ссылочкам?
Ебать ты самоуверенный кретин. Моё последнее сообщение тебе.
>Я общую картину нарисовал. Источники профита указал. Общую мысль сформулировал.
Что стоит твоё кривое цитирование википедийных статей, если ты наделал дохуя фактических ошибок в их воспроизведении?
Ты думашь, кроме тебя никто не догадается зайти в википедию на https://en.wikipedia.org/wiki/Template:Compression_methods и попереходить по ссылочкам?
Ебать ты самоуверенный кретин. Моё последнее сообщение тебе.
>>424035
Упрощённая модель. Я об этом упоминаю. Ты не прав.
Обоснуешь, или вскукарек это обыкновенный?
На пересчёт пока не много вышло.
Как повлияло искажение на выводы, ты, конечно не расскажешь, да?
Не проецируй своё мироощущение на меня, няша. Ты лучше свои собственные вскукареки обоснуй. Но что-то мне подсказывает, что кроме нескольких неточностей у тебя замечаний даже нет, не то, что какой-либо критики. С таким багажом тебе действительно стоит свои мыслишечки при себе держать.
Я даю общую картину и прилагаю ссылки последовательно и тематически. Если ходить только по Википедии, то дерево ссылочек будет сильно избыточным. Видишь, чем моя позиция отличается от твоей? Ты просто набрасываешь, а у меня обоснование есть, ход рассуждений.
Кстати, что я не так с основной мыслью VLC передал?
> кривое цитирование
Упрощённая модель. Я об этом упоминаю. Ты не прав.
> википедийных статей
Обоснуешь, или вскукарек это обыкновенный?
> дохуя фактических ошибок
На пересчёт пока не много вышло.
> Что стоит твоё
Как повлияло искажение на выводы, ты, конечно не расскажешь, да?
> Ебать ты самоуверенный кретин.
Не проецируй своё мироощущение на меня, няша. Ты лучше свои собственные вскукареки обоснуй. Но что-то мне подсказывает, что кроме нескольких неточностей у тебя замечаний даже нет, не то, что какой-либо критики. С таким багажом тебе действительно стоит свои мыслишечки при себе держать.
> и попереходить по ссылочкам?
Я даю общую картину и прилагаю ссылки последовательно и тематически. Если ходить только по Википедии, то дерево ссылочек будет сильно избыточным. Видишь, чем моя позиция отличается от твоей? Ты просто набрасываешь, а у меня обоснование есть, ход рассуждений.
Кстати, что я не так с основной мыслью VLC передал?
>>424030
Ну какое-то превью, по которому можно судить, как видео склеилось, и как к нему применились другие операции.
Ну какое-то превью, по которому можно судить, как видео склеилось, и как к нему применились другие операции.
>>424202
avisynth — фреймсервер. Оно редактирует видео «на лету». Можно смотреть результат фильтрации и монтажа сразу, до кодирования. Например, в том же avspmod можно смотреть результат и дописывать скрипт, предварительный просмотр для некоторых фильтров также доступен. В этом avisynth как раз и крут, что у него можно запросить любой кадр из [предполагаемого] результата монтажных операций, и он произведёт все необходимые [и только необходимые] вычисления, чтобы тебе этот кадр предоставить.
avisynth — фреймсервер. Оно редактирует видео «на лету». Можно смотреть результат фильтрации и монтажа сразу, до кодирования. Например, в том же avspmod можно смотреть результат и дописывать скрипт, предварительный просмотр для некоторых фильтров также доступен. В этом avisynth как раз и крут, что у него можно запросить любой кадр из [предполагаемого] результата монтажных операций, и он произведёт все необходимые [и только необходимые] вычисления, чтобы тебе этот кадр предоставить.
>>424381
Ну так для этого нужен энкодинг в реальном времени. А для 1080р 30FPS 20Ь
Ну так для этого нужен энкодинг в реальном времени. А для 1080р 30FPS 20Ь
Извиняюсь.
>>424381
Ну так для этого нужен энкодинг в реальном времени. А для 1080р, 30FPS, 20Mbit/s, H.264 сколько ядер понадобятся?
>>424381
Ну так для этого нужен энкодинг в реальном времени. А для 1080р, 30FPS, 20Mbit/s, H.264 сколько ядер понадобятся?
>>424531
Нет, не нужен. Я же сказал, что можно посмотреть монтированный и отфильтрованный материал ДО кодирования. Т. е. можно увидеть то, что пойдёт потом прямо на кодировщих. Или тебе надо результат работы кодировщика видеть? Не знаю, зачем это нужно, но вдруг надо Так это можно файл, который кодировщик записывает, посмотреть почти любым основанным на ffmpeg плеером прямо во время записи. В том, что такое даст Windows, кстати, я не уверен. Там многие приложения при получении прав доступа на запись в файл, блокируют другим приложениям чтение из этого файла. Я Windows-ом уже очень много лет не пользуюсь, но должны же это дурь были когда-нибудь поправить!
Зависит от настроек libx264. Последний раз на моём i5-4460 давало больше 30 кадров/с кодирование примерно такого:
$ ffmpeg -i test.mkv \
-c:v libx264 \
-threads 4 \
-profile high -level 4.1 \
-b:v 0 \
-crf 18 \
-x264opts bframes=3:b-adapt=2:b-pyramid=normal:\
ref=3:\
deblock=-1,-1:\
aq-mode=2:\
psy-rd=1.0,0.15:trellis=2:\
8x8dct=yes:\
partitions=yes:\
direct=auto:weightp=2:me=umh:subme=7:\
no-fast-pskip=yes:no-dct-decimate=yes \
output.mp4 -y
> Ну так для этого нужен энкодинг в реальном времени.
Нет, не нужен. Я же сказал, что можно посмотреть монтированный и отфильтрованный материал ДО кодирования. Т. е. можно увидеть то, что пойдёт потом прямо на кодировщих. Или тебе надо результат работы кодировщика видеть? Не знаю, зачем это нужно, но вдруг надо Так это можно файл, который кодировщик записывает, посмотреть почти любым основанным на ffmpeg плеером прямо во время записи. В том, что такое даст Windows, кстати, я не уверен. Там многие приложения при получении прав доступа на запись в файл, блокируют другим приложениям чтение из этого файла. Я Windows-ом уже очень много лет не пользуюсь, но должны же это дурь были когда-нибудь поправить!
> H.264 сколько ядер понадобятся?
Зависит от настроек libx264. Последний раз на моём i5-4460 давало больше 30 кадров/с кодирование примерно такого:
$ ffmpeg -i test.mkv \
-c:v libx264 \
-threads 4 \
-profile high -level 4.1 \
-b:v 0 \
-crf 18 \
-x264opts bframes=3:b-adapt=2:b-pyramid=normal:\
ref=3:\
deblock=-1,-1:\
aq-mode=2:\
psy-rd=1.0,0.15:trellis=2:\
8x8dct=yes:\
partitions=yes:\
direct=auto:weightp=2:me=umh:subme=7:\
no-fast-pskip=yes:no-dct-decimate=yes \
output.mp4 -y
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 22 декабря 2018 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 22 декабря 2018 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.