Качественное кодирование кодеком XViD - Страница 6 - Videoforum

DmitryKz · 06.11.2013, 18:00

Жрец, подскажи, пожалуйста, по такому моменту:
В сводке MediaInfo о некоем mpg-файле есть такие строки:
Color primaries : BT.601 NTSC
Transfer characteristics : BT.601
Matrix coefficients : BT.601

Означает ли это, что разжимать до RGB нужно именно по 601-му алгоритму? Ты упоминал, что цвет в mpg-файлах закодирован с применением 709-го алгоритма. А с этим что делать? Я ради интереса проверил некоторые другие mpg-файлы - таких строк/параметров нет в них. Это единственный такой попался.

Жрец Нефтиды · 07.11.2013, 16:12

Вот, Дмитрий, вопрос вопросов. Я с этим сталкивался несколько раз, причём именно в NTSC. Медиаинфо здесь не истина в последней инстанции. Пробуя разжать по 601 и 709, я всегда убеждался, что 709 для MPEG2 даёт более естественную цветовую гамму. Один раз нашёл этому вот какое подтверждение. Фильм "Елена троянская". Релиз NTSC выдавал через Медиаинфо 601. Я скачал также и ПАЛ релиз, который точно по 709, даже Медиаинфо в нём 709 выдал. Разжал NTSC по 601 и по 709 и сравнил бээмпэшки с теми же кадрами из ПАЛ-а, разжатыми по 709. Однозначно вышло, что для соответствия цветовой гаммы нужно NTSC по 709. Так что перекидывай в матрёшку, смотри по 709, ну а если что, всегда можно переключиться на 601. Главное – не конвертируй.

DmitryKz · 16.11.2013, 06:43

Жрец, приветствую!
Назрела пара вопросов. Во-первых, возвращаясь к разжатию цветовых гамм по различным алгоритмам, я тут подумал, а есть ли смысл в строках типа СolorMatrix(mode="Rec.709->Rec.601"..., ConvertToRGB24(matrix="rec709"... и проч., когда мы используем связку LoadPlugin("DGDecode.dll") MPEG2Source("1.d2v")? Возможно, я не разобрался до конца, но DGDecode.dll это уже декодер mpeg2-потока. Не будет ли он сам разжимать видео по алгоритму, который обозначен в строке Colorimetry (например, там может быть BT.470-2 B, G, что является аналогом BT.601) программы DGIndex, и тогда наши строчки в скрипте, указывающие алгоритм разжатия, будут производить кашу?

И второй вопрос - возвращаясь к явлению "остаточная интерлейсность". Что это такое? Откуда она берется? В чем она проявляется? В каких видеопотоках она может быть? Как можно более-менее однозначно (лучше бы, конечно, однозначно, без "более-менее") определить наличие такой гребенчатости в видеопотоке? То есть понять, что мы имеем дело не с интерлейсом, а именно с его остатками.

Вот сейчас даже третий вопрос родился: говоря об интерлейсности она может быть или чистой интерлейсностью или остаточной интерлейсностью? Какие-то другие типы/виды интерлейсности еще могут быть? То есть я понимаю, что изначально это была именно интерлейснось/черезстрочность в чистом виде. Но тот материал, который доходит до нас через Бог знает какие руки, он порой приобретает свойства, ничего общего не имеющие с исходным. И после этих приключений с ним, что происходит с интерлейсностью? В твоей статье о деинтерлейсинге все хорошо изложено, но вот ты произнес слова "остаточная гребенчатость" и я сейчас стал задумываться о том, какой интерлейс в том или ином потоке.

Вообще, сталкиваясь с таким разнообразием кривосозданных потоков, действительно приходишь к выводу, что лучше ничего не конвертировать, а паковать потоки в ремуксы. Но если у тебя будет желание ответить подробно на мои вопросы, буду весьма и весьма благодарен!

aleks_nsk · 26.11.2013, 03:47

Цитата:

Сообщение от Жрец Нефтиды

Реально поток записан с fps=25, в этом можно убедиться по числу кадров и длине аудио дорожки. Но в самом потоке камерой вписано fps=50. Чтобы этого не происходило впредь, желательно поковыряться в настройках камеры. Скорее всего, частота выставлена не собственно 25, а что-то типа 25/50.

Интерлейсное видео состоит 50 полукадров

Жрец Нефтиды · 26.11.2013, 14:08

Это и так, и не так. Я вот что имел ввиду. Раньше всегда перекидывал интерлейсное видео fps=25 в матрёшку, задав fps=25, и никаких проблем. Но конкретно с этим файлом вышел вот какой казус. Делаю так же. Но при просмотре в Хоумсинема "Свойства" выдаёт частоту 50. Хотя всегда раньше в таких случаях выдавал 25. И эта путаница сбивает процесс воспроизведения. А вот если при помощи tsMuxerGUI перебросить в контейнер ts, тоже задав 25, то всё в порядке. Надо спросить того парня, не против ли он выложить ссылку на файл здесь: случай-то очень нетипичный.

aleks_nsk · 26.11.2013, 15:45

А это оригинальный камерный файл или после монтажки?

aleks_nsk · 26.11.2013, 16:08

Чёта ссылка не та, она на "Вход в почту"

aleks_nsk · 26.11.2013, 16:33

Обычный камерный файл, ни чего подозрительного не увидел,
обычно в этом формате пишут Sony и Panasonic

Жрец Нефтиды · 26.11.2013, 17:00

Не скажи. Раньше все с кодеком h264 прекрасно шли через DGAVCIndex, а этот, если гнать через DGAVCIndex, -- с кучей артефактов.

aleks_nsk · 26.11.2013, 17:42

Возможно это из-за контейнера .MTS, просто этот контейнер для служебного использования внутри камеры,
дело в том что, камеры на SD карту записывают файл размером 1,99ГБ (это 12мин. с копейками),
тоесть каждые 12мин. камера режет файл, если не прерывная запись скажем 20мин. тогда получаем 2 файла,
а чтобы их склеить с камерами идёт софт, который клеит да и просто сохраняет файлы в формате .m2ts,
собственно с ним и рекомендуют работать

06.11.2013, 18:00	#51
DmitryKz Ученик Регистрация: 15.09.2013 Возраст: 50 Сообщений: 16 Сказал(а) спасибо: 24 Поблагодарили 7 раз(а) в 7 сообщениях Вес репутации: 0	Жрец, подскажи, пожалуйста, по такому моменту: В сводке MediaInfo о некоем mpg-файле есть такие строки: Color primaries : BT.601 NTSC Transfer characteristics : BT.601 Matrix coefficients : BT.601 Означает ли это, что разжимать до RGB нужно именно по 601-му алгоритму? Ты упоминал, что цвет в mpg-файлах закодирован с применением 709-го алгоритма. А с этим что делать? Я ради интереса проверил некоторые другие mpg-файлы - таких строк/параметров нет в них. Это единственный такой попался.

07.11.2013, 16:12	#52
Жрец Нефтиды Модератор Регистрация: 15.07.2012 Адрес: Санкт-Петербург Сообщений: 1,395 Сказал(а) спасибо: 344 Поблагодарили 539 раз(а) в 368 сообщениях Вес репутации: 623	Вот, Дмитрий, вопрос вопросов. Я с этим сталкивался несколько раз, причём именно в NTSC. Медиаинфо здесь не истина в последней инстанции. Пробуя разжать по 601 и 709, я всегда убеждался, что 709 для MPEG2 даёт более естественную цветовую гамму. Один раз нашёл этому вот какое подтверждение. Фильм "Елена троянская". Релиз NTSC выдавал через Медиаинфо 601. Я скачал также и ПАЛ релиз, который точно по 709, даже Медиаинфо в нём 709 выдал. Разжал NTSC по 601 и по 709 и сравнил бээмпэшки с теми же кадрами из ПАЛ-а, разжатыми по 709. Однозначно вышло, что для соответствия цветовой гаммы нужно NTSC по 709. Так что перекидывай в матрёшку, смотри по 709, ну а если что, всегда можно переключиться на 601. Главное – не конвертируй.

16.11.2013, 06:43	#53
DmitryKz Ученик Регистрация: 15.09.2013 Возраст: 50 Сообщений: 16 Сказал(а) спасибо: 24 Поблагодарили 7 раз(а) в 7 сообщениях Вес репутации: 0	Жрец, приветствую! Назрела пара вопросов. Во-первых, возвращаясь к разжатию цветовых гамм по различным алгоритмам, я тут подумал, а есть ли смысл в строках типа СolorMatrix(mode="Rec.709->Rec.601"..., ConvertToRGB24(matrix="rec709"... и проч., когда мы используем связку LoadPlugin("DGDecode.dll") MPEG2Source("1.d2v")? Возможно, я не разобрался до конца, но DGDecode.dll это уже декодер mpeg2-потока. Не будет ли он сам разжимать видео по алгоритму, который обозначен в строке Colorimetry (например, там может быть BT.470-2 B, G, что является аналогом BT.601) программы DGIndex, и тогда наши строчки в скрипте, указывающие алгоритм разжатия, будут производить кашу? И второй вопрос - возвращаясь к явлению "остаточная интерлейсность". Что это такое? Откуда она берется? В чем она проявляется? В каких видеопотоках она может быть? Как можно более-менее однозначно (лучше бы, конечно, однозначно, без "более-менее") определить наличие такой гребенчатости в видеопотоке? То есть понять, что мы имеем дело не с интерлейсом, а именно с его остатками. Вот сейчас даже третий вопрос родился: говоря об интерлейсности она может быть или чистой интерлейсностью или остаточной интерлейсностью? Какие-то другие типы/виды интерлейсности еще могут быть? То есть я понимаю, что изначально это была именно интерлейснось/черезстрочность в чистом виде. Но тот материал, который доходит до нас через Бог знает какие руки, он порой приобретает свойства, ничего общего не имеющие с исходным. И после этих приключений с ним, что происходит с интерлейсностью? В твоей статье о деинтерлейсинге все хорошо изложено, но вот ты произнес слова "остаточная гребенчатость" и я сейчас стал задумываться о том, какой интерлейс в том или ином потоке. Вообще, сталкиваясь с таким разнообразием кривосозданных потоков, действительно приходишь к выводу, что лучше ничего не конвертировать, а паковать потоки в ремуксы. Но если у тебя будет желание ответить подробно на мои вопросы, буду весьма и весьма благодарен!

26.11.2013, 14:08	#55
Жрец Нефтиды Модератор Регистрация: 15.07.2012 Адрес: Санкт-Петербург Сообщений: 1,395 Сказал(а) спасибо: 344 Поблагодарили 539 раз(а) в 368 сообщениях Вес репутации: 623	Это и так, и не так. Я вот что имел ввиду. Раньше всегда перекидывал интерлейсное видео fps=25 в матрёшку, задав fps=25, и никаких проблем. Но конкретно с этим файлом вышел вот какой казус. Делаю так же. Но при просмотре в Хоумсинема "Свойства" выдаёт частоту 50. Хотя всегда раньше в таких случаях выдавал 25. И эта путаница сбивает процесс воспроизведения. А вот если при помощи tsMuxerGUI перебросить в контейнер ts, тоже задав 25, то всё в порядке. Надо спросить того парня, не против ли он выложить ссылку на файл здесь: случай-то очень нетипичный.

26.11.2013, 15:45	#56
aleks_nsk Модератор Регистрация: 05.07.2010 Возраст: 57 Сообщений: 2,445 Сказал(а) спасибо: 722 Поблагодарили 1,039 раз(а) в 676 сообщениях Вес репутации: 852	А это оригинальный камерный файл или после монтажки?

26.11.2013, 16:08	#57
aleks_nsk Модератор Регистрация: 05.07.2010 Возраст: 57 Сообщений: 2,445 Сказал(а) спасибо: 722 Поблагодарили 1,039 раз(а) в 676 сообщениях Вес репутации: 852	Чёта ссылка не та, она на "Вход в почту"

26.11.2013, 16:33	#58
aleks_nsk Модератор Регистрация: 05.07.2010 Возраст: 57 Сообщений: 2,445 Сказал(а) спасибо: 722 Поблагодарили 1,039 раз(а) в 676 сообщениях Вес репутации: 852	Обычный камерный файл, ни чего подозрительного не увидел, обычно в этом формате пишут Sony и Panasonic

26.11.2013, 17:00	#59
Жрец Нефтиды Модератор Регистрация: 15.07.2012 Адрес: Санкт-Петербург Сообщений: 1,395 Сказал(а) спасибо: 344 Поблагодарили 539 раз(а) в 368 сообщениях Вес репутации: 623	Не скажи. Раньше все с кодеком h264 прекрасно шли через DGAVCIndex, а этот, если гнать через DGAVCIndex, -- с кучей артефактов.

26.11.2013, 17:42	#60
aleks_nsk Модератор Регистрация: 05.07.2010 Возраст: 57 Сообщений: 2,445 Сказал(а) спасибо: 722 Поблагодарили 1,039 раз(а) в 676 сообщениях Вес репутации: 852	Возможно это из-за контейнера .MTS, просто этот контейнер для служебного использования внутри камеры, дело в том что, камеры на SD карту записывают файл размером 1,99ГБ (это 12мин. с копейками), тоесть каждые 12мин. камера режет файл, если не прерывная запись скажем 20мин. тогда получаем 2 файла, а чтобы их склеить с камерами идёт софт, который клеит да и просто сохраняет файлы в формате .m2ts, собственно с ним и рекомендуют работать