Videoforum - форум о видео и не только!


Вернуться   Videoforum - форум о видео и не только! > Видеосъёмка и монтаж. > Кодеки и кодеры, кодирование и конвертация.

Важная информация

Кодеки и кодеры, кодирование и конвертация. Тут обсуждаются вопросы изменения формата видео, качество работы кодировщиков, а так-же известные проблемы и решения соответствующие тематике раздела.

Ответ
 
Опции темы
Старый 13.07.2016, 17:53   #1
Жрец Нефтиды
Модератор
 
Аватар для Жрец Нефтиды
 
Регистрация: 15.07.2012
Адрес: Санкт-Петербург
Сообщений: 1,225
Сказал(а) спасибо: 274
Поблагодарили 391 раз(а) в 262 сообщениях
Вес репутации: 333
Жрец Нефтиды has a brilliant futureЖрец Нефтиды has a brilliant futureЖрец Нефтиды has a brilliant futureЖрец Нефтиды has a brilliant future
По умолчанию Сравнение кодеков XViD и h264

Эту тему можно также назвать "Качественное кодирование кодеком x264".
Скачиваем последнюю версию кодека x264.exe с авторского сайта. На день написания статьи это:
http://download.videolan.org/pub/videolan/x264/binaries/win32/
Программа x264.exe является самодостаточной DOS-программой. Для её запуска нужно написать "Блокнотом" bat-файл. Вначале пишем такой bat-файл:
x264.exe --fullhelp
pause
Запустив этот файл, мы увидим полный список оригинальных опций, их краткое описание, а в квадратных скобках – значение по умолчанию. Если ты планируешь освоить кодирование в h264, то рекомендую откопировать всё это добро в Word-файл.
Приступаем к сравнению. Для меня абсолютной истиной, не подлежащей никакому пересмотру, является кодирование на постоянном квантизёре, который должен быть одинаков для всех кадров: I, P и B. При таком подходе качество файлов h264 и XViD должно быть одинаковым (а так ли это на самом деле, мы посмотрим). Для оценки кодеков нужно сравнивать конечный объём файлов.
В x264 есть, кроме кодирования чисто на постоянном квантизёре, ещё некоторая промежуточная возможность – CRF. Что переводится как "Качество, основанное на переменном битрейте". В этом режиме включается оценка скорости движения. Более быстрые и динамичные сцены будут кодироваться с меньшим качеством, чем медленные, потому что в быстрых сценах, по мнению разработчиков данной функции, будто бы качество кодирования не столь заметно, как в медленных сценах. Я сразу и бесповоротно отметаю CRF: качество – всё, мелочная экономия – на помойку. У меня ты найдёшь только QP.
Кодированию могут предшествовать различные операции – деинтерлейсинг, обрезка, ресайз. Для меня также является непреложной истиной, что все эти операции нужно проводить какой-либо отличной от кодека программой, лучше всего Avisynth. На тяжкую долю кодека должен приходиться только собственно процесс кодирования, и ничего больше. Хотя бы потому, что в Avisynth мы можем выбирать и настраивать алгоритм всех этих операций.
В качестве исходника для сравнения кодеков я использовал мульт "По следам бременских музыкантов" Full HD.
Пишем скрипт:
LoadPlugin("ffms2.dll")
LoadPlugin("SplineResize.dll")
LoadPlugin("YCbCrChannelMixer.dll")
FFVideoSource("По следам.mkv", fpsnum=25000, fpsden=1000, seekmode=0)
AssumeFPS(25)
Spline144Resize(720, 576, 240, 0, -240, -0)
YCbCrChannelMixer(1., 0.0993116622408317, 0.191699549740832, -37.2494351336529, 0.989853808245085, -0.110652512296676, 15.4622341186036, -0.0724529613336014, 0.983397823259837, 11.3990576734419, 0, 255, 0, 255)
Про плагин YCbCrChannelMixer написано здесь:
http://www.videoforums.ru/showthread.php?t=6546
Как видим, в этом скрипте есть обрезка чёрных полос слева и справа и ресайз до 720x576.
При первом открытии этого скрипта будет произведена индексация файла-исходника, что займёт какое-то время. Поэтому первый раз я бы рекомендовал открывать скрипт Виртуал Дабом. Заодно и посмотреть, всё ли в порядке.
Подробно об открытии исходников скриптами такого типа описано в теме "Качественное конвертирование при помощи FFMPEG".
Важно! Когда я писал о сжатии кодеком XViD, то я рекомендовал подавать на кодек видео в формате RGB. Мелочный покадровый просмотр показал, что XViD даёт более точное соответствие исходнику, если мы подадим на него RGB. С кодеком x264.exe всё обстоит с точностью до наоборот. Для получения наиболее точного соответствия оригиналу на вход x264.exe следует подавать видео именно в планарном формате YV12. Ниже я приведу снимки, подтверждающие этот факт. Поэтому в скрипте мы не видим строки ConvertToRGB24.
Большинство исходников находятся в планарном формате YV12. Если нам нужно провести какие-либо операции, например, деинтерлейсинг, ресайз, обрезку, удаление шума и т.д., то нужно стремиться проводить эти операции именно в формате YV12, без преобразования формата. Подавляющее большинство плагинов Avisynth работают именно с планарными форматами. Но если всё-таки нам почему-либо потребовалось преобразовать планарный формат в RGB, то перед подачей на x264.exe я очень рекомендую преобразовать его в YV12.
Немножко теории. Если подаваемое на x264.exe видео находится в формате, отличном от YV12, например, в RGB, то по умолчанию x264.exe вначале преобразует его в YV12 по алгоритму 601, потом будет сжимать. В процессе преобразования RGB в YV12 на некоторых участках изображения могут произойти искажения исходной геометрии. Незначительные, но всё-таки неприятно. Если мы подадим на вход YV12, то x264.exe сразу начнёт его сжимать. В этом случае никаких искажений геометрии не произойдёт.
Мы можем определённой опцией заставить x264.exe кодировать в RGB, но тогда объём возрастёт иногда раза в 2, а качество практически не улучшится. Поэтому будем считать, что кодирование по умолчанию в YV12 есть наилучший вариант.
Следует понимать, что если мы подали на вход кодера x264.exe изображение в формате YV12, то кодер будет его просто, не рассуждая, в упор, кодировать, не производя никаких преобразований форматов. Кодер не может знать, по какому алгоритму – 601 или 709 – закодирован пришедший к нему со стороны YV12. Он сразу же начнёт его, как он есть, сжимать в h264. Наш тестовый исходник после прохождения через YCbCrChannelMixer находится в 601. Поэтому при просмотре его нужно декодировать по 601. Если бы мы не вставили в скрипт YCbCrChannelMixer, то при просмотре нам нужно было бы декодировать по 709.
Таким образом, в любом случае, каким бы способом и (или) какой бы программой ты ни сжимал, следует обстряпать дело так, чтобы на вход x264.exe изображение подавалось в формате YV12. Все мои разработки с этого форума по конвертированию можно применить, как они есть, к x264.exe, с одной существенной разницей: в скриптах не должно быть ConvertToRGB24, а заканчиваться скрипт должен YCbCrChannelMixer.
Итак, предварительные операции завершены. Приступаем к кодированию.
Кодировать в h264 будем таким bat-файлом:
x264.exe -b 16 --b-adapt 2 --no-deblock -q 18 --ipratio 1 --pbratio 1 --no-psy --trellis 1 --no-fast-pskip --no-dct-decimate --deadzone-inter 0 --deadzone-intra 0 -m 9 --sar 4:3 -o wq.mkv ffmpeg.avs
pause
Объяснение опций:
-b 16 – задаёт максимальное количество B-кадров, которое кодер может пустить подряд. Установлено максимально возможное значение для данной опции. "Может" здесь не означает "обязан": в зависимости от содержания кадров кодер может пустить подряд от 0 до 16 кадров.
--b-adapt 2 – включение самого продвинутого алгоритма определения того, сколько же на самом деле нужно в каждом конкретном месте фильма пустить подряд B-кадров, чтобы получить наилучшее сжатие.
Опции -b 16 и --b-adapt 2 в совокупности дают уменьшение объёма конечного файла где-то в районе 1%, а время кодирования увеличивают раза в два. На качество полученного изображения не влияют. Так что их, в принципе, можно опустить.
--no-deblock – отключение деблокинга. Деблокинг мажет мелкие детали, и на этапе кодирования я рекомендую его всегда отключать.
-q 18 – включение кодирования на постоянном квантизёре = 18. Квантизёр 18 в h264 соответствует квантизёру 2 в XViD-е.
--ipratio 1 --pbratio 1 – заставляет кодировать P-кадры и B-кадры с тем же самым квантизёром, что и I-кадры. Одинаковый квантизёр для всех кадров – это для меня такая древнеегипетская святыня, которая не обсуждается. Очень рекомендую всегда делать именно так и не слушать всяких там мелочных битрейтных жмотов.
--no-psy – отключение всех психо визуальных прибамбасов. Мой добрый жреческий совет: всегда отключай все психо визуальные алгоритмы, что бы по этому поводу кто ни гнусавил. Психо визуальные алгоритмы искажают оригинальное изображение в угоду мелочному битрейтному жмотству. Например, потери чёткости тонких прожилок растений вызваны этим вредоносным алгоритмом.
--trellis 1 – включение треллиса для макроблоков, как это и произошло бы по умолчанию. Макроблок – это кусок изображения размером 16x16 пикселей. Trellis равномерно размазывает имеющееся мелкое зерно и шумы по всему макроблоку. По сути, Trellis является, в некотором смысле слова, шумодавом. Притом весьма хорошим: не создаёт ни радужности, ни призраков. Особенно его действие заметно на тёмных зазернённых сценах. Исследуя эту функцию, я практически не нашёл таких полезных объектов, которые бы Trellis размазывал. Только зерно и шумы. Интересное наблюдение: с включённым Trellis размер тёмных средне зазернённых сцен получается раза в 2 меньше, чем без него. К слову, Trellis есть и в XViD. Но там он не работает с Custom-матрицами.
--no-fast-pskip – отключение паскудненького ускорителя для кодирования P-кадров. Все мерзости, которые хоть на долю процента ухудшают качество, должны быть безжалостно отключены!
--no-dct-decimate – отключение коэффициента пороговой обработки для P-кадров. В руководствах пишется, что если эту функцию отключить, то увеличится размер конечного файла при незначительном улучшении видео. На каком месте растут глаза у тех, кто пишет о "незначительном улучшении"? Если эту функцию не отключать, то детализация ухудшится очень даже значительно. Это особенно заметно на чётких кадрах с большим разрешением. Однозначно отключаем.
--deadzone-inter 0 --deadzone-intra 0 – отключение ещё одной скупердяйской мерзости. Мёртвые зоны экономят чуть-чуть битрейта на мало изменяемых участках, ухудшая тем самым качество. На помойку!
-m 9 – улучшение полупиксельной точности. 9 означает продвинутый алгоритм для всех кадров. Включение этой опции слегка увеличивает соответствие закодированного кадра исходнику, в особенности на тёмных и туманных кадрах.
--sar 4:3 – задание соотношения сторон для конечного видео, подобно тому, как мы это делали при кодировании XViD-ом.
-o wq.mkv – имя выходного файла.
И заканчиваются опции именем входного файла, который пишется без всяких знаков. В нашем примере это скрипт ffmpeg.avs.
Есть ещё несколько опций, которые для процессора – надорвись, а реальное уменьшение объёма конечного файла от которых ничтожное. Например, -A all – разрешает кодеру производить дополнительный поиск всех допустимых размеров макроблоков, или --me esa – режим оценки движения "исчерпывающий". Я их не включил в командную строку, и тебе не рекомендую.
Поехали. Запускаем bat-файл, и спокойно ждём.
Вот сжатие завершено.
Теперь нам для сравнения нужно этот же самый поток кадров, выходящий со скрипта и находящийся в формате YV12, напрямую подать на XViD. Делаем это так. Открываем этот же самый скрипт в Виртуал Дабе. "Video" – точка у "Fast recompress". Задаём все параметры XViD-а, как описано в моей статье про кодирование в XViD. Кодируем. Конечно, при таком подходе на XViD мы подаём не RGB, а планарный YV12, но для объективности сделаем именно так. Тем более что для XViD разница при подаче на него RGB и YV12 на самом деле очень незначительна.
Сравниваем.
Если за базу сравнения взять XViD, то получаем экономию объёма 27%.
Если провести подобные исследования на фильмах, то получим экономию такого же порядка – 25-30%.
Ух ты, как здорово!
Теперь исследуем самый главный древнеегипетский параметр – качество, которое есть всё и по отношению к которому всё остальное есть ничто.
Вначале определимся с термином "исходник". Под исходником я понимаю изображение, подаваемое со скрипта на кодер. А не что-то другое. Открываем скрипт в Виртуал Дабе. Выходим на интересующий нас кадр. Сохраняем его в формате bmp. Это будет "Исходник.bmp".
Разжимаем полученный h264. Для получения объективной картины в декодере нужно отключить деблокинг и любую другую постобработку. В ffdshow это сделать элементарно. Я сравнил кадры при разжатии ffdshow и при разжатии очень не бесплатным CoreAVC_3.0.1 Professional Edition. Результаты получились идентичными, чего и следовало ожидать. Получили кадр "h264 YV12.bmp".
Разжимаем файл avi, сжатый кодеком XViD. Тоже отключаем в декодере деблокинг. Этот файл нужно декодировать до RGB по алгоритму 601. Потому что на вход XViD-а мы подали YV12, закодированный по 601. Получили кадр "XViD.bmp".
Удалим из скрипта YCbCrChannelMixer, а на его место впишем ConvertToRGB24(matrix="rec709", interlaced=false)
Снова запустим кодирующий bat-файл. Получим h264 файл, в котором при кодировании видео было подано на кодер в формате RGB. Разжав этот файл, получим кадр "h264 RGB.bmp".
Архив с полученными кадрами лежит здесь:
https://yadi.sk/d/Db5JFE8htGUvb
Начинаем сравнивать. Для получения объективного изображения в просмотровщике типа "Быстрый камень" отключаем сглаживание.
Начинаем с кадра 7650. Видим, что в "h264 RGB.bmp" контуры огня под котлом слегка играют по отношению к исходнику. В кадре 7680 такая игра особенно заметна на платье принцессы. Этого вполне достаточно для подтверждения выдвинутого в начале статьи тезиса о том, что не следует подавать на вход кодера x264.exe видео в формате RGB. Больше с RGB экспериментировать не будем.
Сравниваем "h264 YV12.bmp" и "Исходник.bmp". Разницу видишь? Я вижу: у "h264 YV12.bmp" слегка меньше зерна на стенке котла, что даже лучше.
Теперь сравним "h264 YV12.bmp" и "XViD.bmp". Разница почти не заметна. Всё-таки XViD со жреческими настройками хорошая штука. Но всё же приглядимся внимательно. На туманных частях кадра 7850 – это где поверхность холма, и на тёмных кадрах, некоторая разница имеется. "h264 YV12.bmp" точнее соответствует "Исходник.bmp", чем "XViD.bmp".
Вот мы и получили долгожданный математически точный результат сравнения: при правильных – я подчёркиваю, при правильных! – настройках x264.exe получается видео, чуть более точно приближенное к исходнику, чем видео, сжатое XViD-ом. А объём h264-файла получается на 25-30% меньше, чем объём XViD-файла.
Данную тему можно считать реквиемом XViD-у. Так помянем XViD: хорошая была софтинушка. Бесплатная. Свою статью про качественное кодирование в XViD я не буду убирать с этого форума: пусть висит, как памятник.
В этой статье логически точно, без общих разглагольствований о "современном" и "устаревшем" софте было доказано превосходство одной программы над другой. Все бы темы так писались, в особенности где сравниваются операционки.
Предвижу, сравнение кодеков заинтересует многих, и могут появиться альтернативные варианты исследований. Форум = демократия. Во избежание лишней переписи: лично я буду отвечать только на те посты, в которых рассматриваются способы, позволяющие добраться абсолютно до всех настроек кодера. Я оставляю без внимания просьбы разобраться в каких-либо других способах сравнения, особенно написанных на языках, отличных от русского.
Зато с удовольствием обсужу иные опции bat-файла, позволяющие достигнуть ещё лучшего качества.

Последний раз редактировалось Жрец Нефтиды; 20.08.2016 в 11:22.
Жрец Нефтиды вне форума   Ответить с цитированием Вверх
5 пользователя(ей) сказали cпасибо:
DmitryKz (08.09.2016), Prtava (13.07.2016), rococo795 (14.07.2016), vg_3000 (13.08.2016), Милослав (15.07.2016)
Реклама на форуме
Старый 13.07.2016, 18:47   #2
Prtava
Гуру
 
Регистрация: 05.09.2015
Сообщений: 170
Сказал(а) спасибо: 4
Поблагодарили 29 раз(а) в 25 сообщениях
Вес репутации: 77
Prtava has a spectacular aura about
По умолчанию

Цитата:
Сообщение от Жрец Нефтиды Посмотреть сообщение
В этой статье математически точно, без общих разглагольствований о "современном" и "устаревшем" софте было доказано превосходство одной программы над другой. Все бы темы так писались, в особенности где сравниваются операционки
Очень хорошая, грамотная статья и исследование проведено скурупулезное и действительно математически точно доказано преимущество одного кодека над другим.
Но. мое маленькое имхо - в современных реалиях оборудования оцифровать какой-нибудь архив домашнего видео с VHS, хоть иксвидом хоть 264 - это стоящее дело (хотя для качества vhs домашнего видео по моему без разницы чем кодировать), но зачем сейчас что то конвертировать при качестве разрешения современных форматом и всеядности средств просмотра - воткнул в любой современный TV флешку и все -enjoy, да хоть тот же DVD - лучше он не станет, хоть до 4К его разбухать тем же 264 современешим или старым софтом, хоть на ХР, хоть на 10, а если не нужна дивидишная "пена" - меню и пр, просто взять видео и нужный звук и в другой контейнер и не в наколенный не сертифицированный mkv, а в его родной контейнер m2ts.
Prtava вне форума   Ответить с цитированием Вверх
Пользователь сказал cпасибо:
rococo795 (14.07.2016)
Старый 13.07.2016, 22:21   #3
Жрец Нефтиды
Модератор
 
Аватар для Жрец Нефтиды
 
Регистрация: 15.07.2012
Адрес: Санкт-Петербург
Сообщений: 1,225
Сказал(а) спасибо: 274
Поблагодарили 391 раз(а) в 262 сообщениях
Вес репутации: 333
Жрец Нефтиды has a brilliant futureЖрец Нефтиды has a brilliant futureЖрец Нефтиды has a brilliant futureЖрец Нефтиды has a brilliant future
По умолчанию

Я давно уже не конвертирую, всё храню в исходном качестве. Данная же статья -- плацдарм для исследования опций кодека x264. Это нужно мне не для того, чтобы пережимать, а вот для чего:
[Для просмотра данной ссылки нужно зарегистрироваться]
Жрец Нефтиды вне форума   Ответить с цитированием Вверх
Старый 14.07.2016, 05:32   #4
rococo795
Мыслитель
 
Регистрация: 23.09.2012
Возраст: 36
Сообщений: 827
Сказал(а) спасибо: 47
Поблагодарили 137 раз(а) в 109 сообщениях
Вес репутации: 260
rococo795 is a name known to allrococo795 is a name known to all
По умолчанию

Цитата:
Сообщение от Жрец Нефтиды Посмотреть сообщение
В этой статье математически точно, без общих разглагольствований о "современном" и "устаревшем" софте было доказано превосходство одной программы над другой
про математически - это сильно сказано.... этим тут и не пахнет.... я понимаю под "математически" - это когда ты взял строго ограниченное количество пикселей (часть кадра - слайс там или как его правильно кличут-давно интересовался, забыл)... показал числовую зависимость этого участка оригинальным кодером... потом ТОТ ЖЕ участок - показал зависимость в хвиде.... потом ТОТ ЖЕ участок - показал зависимость в 264..... обосновал что числовая зависимость (алгоритм сжатия) ближе к оригиналу у 264, чем числовая зависимость (описывающая цвет этого участка) у хвида.... ТОГДА можно говорить о математической точности..... а то что я увидел в этой статье - сравнение чисто "на глаз"....
rococo795 вне форума   Ответить с цитированием Вверх
Старый 14.07.2016, 16:07   #5
rococo795
Мыслитель
 
Регистрация: 23.09.2012
Возраст: 36
Сообщений: 827
Сказал(а) спасибо: 47
Поблагодарили 137 раз(а) в 109 сообщениях
Вес репутации: 260
rococo795 is a name known to allrococo795 is a name known to all
По умолчанию

Но труд не напрасен... И полезен...
rococo795 вне форума   Ответить с цитированием Вверх
Старый 15.07.2016, 17:10   #6
Жрец Нефтиды
Модератор
 
Аватар для Жрец Нефтиды
 
Регистрация: 15.07.2012
Адрес: Санкт-Петербург
Сообщений: 1,225
Сказал(а) спасибо: 274
Поблагодарили 391 раз(а) в 262 сообщениях
Вес репутации: 333
Жрец Нефтиды has a brilliant futureЖрец Нефтиды has a brilliant futureЖрец Нефтиды has a brilliant futureЖрец Нефтиды has a brilliant future
По умолчанию

Вот размеры-то конечных файлов сравнены очень даже математически.
Что касается соответствия сжатого изображения исходнику. Да, есть программы числового сравнения. Вот только они не показывают, что именно различается. Если исчез шум и зерно, то это даже плюс. Если полезные детали -- то минус. Если исказилась геометрия, то это вообще безобразие.
Утверждал и буду утверждать: сравнивать исходный и сжатый кадр следует только соколиным глазом.
Что касается нужности этой темы. Вот тут
[Для просмотра данной ссылки нужно зарегистрироваться]
в посте №2 Алекс подкинул хорошую мысль. Буду подыскивать Панасоник рав или прорезь. И тогда по данным настройкам сжимать в h264 самое то, что надо. RAW ависинтом можно отрезать с точностью до кадра перед сжатием.
Жрец Нефтиды вне форума   Ответить с цитированием Вверх
Старый 16.07.2016, 07:08   #7
rococo795
Мыслитель
 
Регистрация: 23.09.2012
Возраст: 36
Сообщений: 827
Сказал(а) спасибо: 47
Поблагодарили 137 раз(а) в 109 сообщениях
Вес репутации: 260
rococo795 is a name known to allrococo795 is a name known to all
По умолчанию

Цитата:
Сообщение от Жрец Нефтиды Посмотреть сообщение
Вот размеры-то конечных файлов сравнены очень даже математически.
Этот аспект - да... Не спорю...


Цитата:
Сообщение от Жрец Нефтиды Посмотреть сообщение
Утверждал и буду утверждать: сравнивать исходный и сжатый кадр следует только соколиным глазом

как сказать... частенько (особенно раньше) заходил на один форум в ветку про звук... так там аудиофилы - слышат явно разницу в двух файлах, которые абсолютно одинаковы..... на моё предложение проделать слепой тест (я нарежу куски из 2 файлов, перемешаю их, вылажу за 1 час на сервер - список, какой кусок какому файлу принадлежит, и вылажу сами куски....) Сравните говорю... и если вы их разложите по своим файлам (ведь явно всё слышат) - то обзову себя дураком... и напишу им какую нить маленькую но полезную прогу - в знак благодарности за их исключительный слух)... предлагал это год назад... и щас недавно.... - Не хотят... Вывод ясен... Они нулевые...
Говорю для чего.... На глаз - можно и ошибиться... Глаз замыливается моментально... Когда ищешь параметры функций скрипта, для более качественной картинки - минут через 10-15... более качественное кажется худшим и наоборот.... - тем более в кадре надо сравнивать одинаковые места кадра во многих кадрах.... и тут думаю начнётся ералашь... не будет постоянной превалирующей во всех кадрах для одного кодера.... что то будет лучше там а что то здесь.... но это очень кропотливо......
когда то давно я сравнивал два кодировщика... CCE и ещё какой то (забыл).... так вот на общий взгляд ССЕ - был лучше и чётче.... на местах где быстрое движение - другой... а потом ваще хрень.... на быстрых местах - то там лучше то тут.... я плюнул на это дело (слабоват я для таких обоснований).... быстрое движение было - птицы взлетали с веток...
Так что вот так ... думаю...
rococo795 вне форума   Ответить с цитированием Вверх
Старый 16.07.2016, 07:11   #8
rococo795
Мыслитель
 
Регистрация: 23.09.2012
Возраст: 36
Сообщений: 827
Сказал(а) спасибо: 47
Поблагодарили 137 раз(а) в 109 сообщениях
Вес репутации: 260
rococo795 is a name known to allrococo795 is a name known to all
По умолчанию

Цитата:
Сообщение от Жрец Нефтиды Посмотреть сообщение
RAW ависинтом можно отрезать с точностью до кадра перед сжатием
ну наверно так можно отрезать всё что угодно, если данные лежат тупо в файле физически, а не образуются путём просчёта предыдущего и последующего кадров... вполне возможно я могу без всяких ависинтов вынуть любой кадр в таком именно случае... если я правильно понял смысл..
rococo795 вне форума   Ответить с цитированием Вверх
Старый 17.07.2016, 12:43   #9
aleks_nsk
Модератор
 
Регистрация: 05.07.2010
Возраст: 50
Сообщений: 1,694
Сказал(а) спасибо: 658
Поблагодарили 814 раз(а) в 489 сообщениях
Вес репутации: 496
aleks_nsk has a reputation beyond reputealeks_nsk has a reputation beyond reputealeks_nsk has a reputation beyond reputealeks_nsk has a reputation beyond reputealeks_nsk has a reputation beyond reputealeks_nsk has a reputation beyond reputealeks_nsk has a reputation beyond repute
По умолчанию

Цитата:
Сообщение от Жрец Нефтиды Посмотреть сообщение
RAW ависинтом можно отрезать с точностью до кадра перед сжатием.
Вот тебе [Для просмотра данной ссылки нужно зарегистрироваться] 6К с камеры Red Dragon, попробуй
aleks_nsk на форуме   Ответить с цитированием Вверх
Старый 18.07.2016, 22:13   #10
Жрец Нефтиды
Модератор
 
Аватар для Жрец Нефтиды
 
Регистрация: 15.07.2012
Адрес: Санкт-Петербург
Сообщений: 1,225
Сказал(а) спасибо: 274
Поблагодарили 391 раз(а) в 262 сообщениях
Вес репутации: 333
Жрец Нефтиды has a brilliant futureЖрец Нефтиды has a brilliant futureЖрец Нефтиды has a brilliant futureЖрец Нефтиды has a brilliant future
По умолчанию

Алекс, спасибо за файл: теперь я точно не буду покупать ред. Этот замороченный формат даже Super не жрёт.
Жрец Нефтиды вне форума   Ответить с цитированием Вверх
Ответ

Опции темы

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход

Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Качественное кодирование кодеком XViD Жрец Нефтиды Кодеки и кодеры, кодирование и конвертация. 110 09.04.2015 23:12
Метод объективной оценки качества аудио кодеков Жрец Нефтиды Кодеки и кодеры, кодирование и конвертация. 1 05.10.2012 19:27


Часовой пояс GMT +1, время: 17:25.




Powered by vBulletin® Version 3.8.3
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd. Перевод: zCarot






Реклама на форуме ICQ: 288-413-254