|
|
|
dmitro770
Стаж: 14 лет 4 месяца Сообщений: 9
|
dmitro770 ·
02-Дек-10 00:13
(13 лет 11 месяцев назад)
Ang+
Скрин снят с Медиа плеер классик. А версия х264, мегуи 0.3.5.0 - так я понял
|
|
|
|
Pustovetov
Стаж: 17 лет Сообщений: 4255
|
Pustovetov ·
02-Дек-10 00:44
(спустя 30 мин., ред. 02-Дек-10 00:44)
TurboPascal7 писал(а):
Pustovetov писал(а):
Вон лежат несколько линкованных релизов от THORA
Вон лежат мои bakemonogatari, arakawa и amagami, в которых пара серий клеилась из кусков с разными crf, i/p-ratio, qpmin/max, aq, qcomp и еще тучей разных настроек. Ни одной жалобы на неправильное воспроизведение не видел (конечно, есть вариант, что их никто кроме меня и не смотрел, но я не хочу о нём думать). 
Из всего перечисленного только crf меняет заголовок. А дальше все зависит от качества сплиттера/декодера.
DreadMaster писал(а):
Осталось проверить, клеются ли crf и 2pass куски, хотя вряд ли.
Нет.
|
|
|
|
TurboPascal7
Стаж: 15 лет 7 месяцев Сообщений: 668
|
TurboPascal7 ·
02-Дек-10 01:22
(спустя 37 мин.)
Pustovetov
скрытый текст
[08:11:56] <tp7> hi, guys, question here. I have 2 files encoded with a different crf values, and I need to merge it into one file. Would I have any decode problems after such manipulation?
[08:12:21] <Eilafan> If they're otherwise encoded with close-enough settings they should be fine
[08:12:30] <Eilafan> just use mkvmerge to append 'em
[08:12:57] <Daemon404> why would the ratecontrol matter anyway
[08:13:44] <tp7> cuz it is writen in the sps
[08:13:45] <LobsterHime> i can't imagine any case where appending two files with different crfs screwing up decoding in ways that the separate files wouldn't
[08:13:49] <tp7> crf, I mean
[08:13:51] <LobsterHime> like, i dunno
[08:14:23] <LobsterHime> maybe different vbv settings could somehow break hardware decoders?
[08:14:36] <LobsterHime> but in that case i don't think mkvmerge would let you join them anyway?!
[08:14:38] <LobsterHime> not sure though
[08:15:11] <tp7> it works if I demux it to the raw stream before appending
[08:15:23] <tp7> just wondering about possibility
[08:16:05] <LobsterHime> in that case then yeah, i guess if you appended two .264 files with different levels/vbv settings it will break hardware decoders in some way, probably, maybe
[08:16:06] <Eilafan> The only problem I've seen with such files was when I was checking out some auto-encoded file on some re-encoding+'streaming' site
[08:16:10] <Eilafan> But otherwise...
[08:16:21] <Eilafan> haven't seen any problems
[08:17:05] <tp7> ok, thanks
Eilafan == JEEB. Можно, конечно, еще и DS-а помучить, или прямо парней с ffmpeg/haali, но хз, есть ли смысл.
P.S. Не обращайте внимания на мой англ, он плох. :Ь
|
|
|
|
Pustovetov
Стаж: 17 лет Сообщений: 4255
|
Pustovetov ·
02-Дек-10 02:00
(спустя 38 мин., ред. 02-Дек-10 02:00)
TurboPascal7 писал(а):
Eilafan == JEEB. Можно, конечно, еще и DS-а помучить, или прямо парней с ffmpeg/haali, но хз, есть ли смысл.
А причем тут JEEB и даже DS? Вот писунов сплитеров/декодеров мучать можно. И проблема там одна, по приходу нового заголовка надо принимать во внимание его содержимое, а не хреначить по старому. При рандомном перескоке в плеере на какой-то участок видео надо учитывать как закодирован этот участок (те перед проигрыванием надо из всего видео вытащить заголовки, а не довольствоваться одним самым первым)... Т.е. все конечно решаемо но товарищи сплитеро/декодеро писуны и не такие вещи решить не могут
p.s. Кстати если уж говорить о линках, то когда я последний раз я смотрел на линуксячие исходники цеплялки внешних сегментов, то там было сравнение заголовков и если они не совпадали то нафиг рубилась линковка от греха. Няшечки линуксоиды =)
p.p.s И самое подлое что няшечки проверяют заголовки всех дорожек, включая субтитровы. И достаточно в субтитрах допустить лишний пробел и привет.
|
|
|
|
Stanawa2
Стаж: 16 лет 7 месяцев Сообщений: 10188
|
Stanawa2 ·
02-Дек-10 02:05
(спустя 4 мин.)
Ang+ писал(а):
З.Ы. К тесту Stanawa2: http://sendfile.su/221894
Кто разбирал результаты, чирканите пару слов, пожалуйста =) А то самому сложно темное оценивать.
М-да, зачем надо было этот тестовый кусок давать? 
Никто толком ничего не разбирал, да и выходит разбирать нечего, иксу что не крути, он всё равно так же поступает с такими кадрами.
Вижу крутили во все боки, так же как я
Цитата:
me=tesa - и тесу использовали
psy_rd=1.20:0.50 даже вверх попробовали, когда рекомендуют опускать (бестолку кста)
mbtree=0 - выключили
ip_ratio=1.10 / pb_ratio=1.10 ип и пб опустили, как писал shellgen arkahan-у
aq=1:1.10 первый аг использовали
Но так же присутствуют в кадре те же темные и светлее квадраты, единственное что у вас они меньше по размеру и плюс детализация лучше, чем у меня или у shartm.
Бросьте уж эту тему, параметрами икса ничего полностью не решается с этим явлением 
|
|
|
|
Ang+
Стаж: 16 лет 7 месяцев Сообщений: 993
|
Ang+ ·
02-Дек-10 02:27
(спустя 21 мин., ред. 02-Дек-10 02:43)
Stanawa2, спасибо =) Ну, поковыряться в любом случае стоило)
Stanawa2 писал(а):
0.50 даже вверх попробовали, когда рекомендуют опускать
Из шапки:
shellgen писал(а):
Пояснения BugMaster
На самом деле он этот параметр влияет на то как trellis подбирает коэффициенты для разных частот. Чем больше тем он менее жесток (не обнуляет их, а все равно кодирует) к малым амплитудам высоких частот, а значит выкидывает меньше мелких деталей, хоть при этом и менее эффективно сжимает (в плане PSNR).
dmitro770, вот ответ на очень похожий вопрос: https://rutr.life/forum/viewtopic.php?p=40167873#40167873
К 3-му пункту добавлю, что артефакты в плеере могут быть, если декодером используете CoreAVC версии 1.9.5 и меньше ( https://rutr.life/forum/viewtopic.php?p=9255801#coreweightp).
Покажите avs-скрипт, который грузится в мегуи и отчет MediaInfo по рипу.
|
|
|
|
Pustovetov
Стаж: 17 лет Сообщений: 4255
|
Pustovetov ·
02-Дек-10 02:42
(спустя 15 мин.)
Stanawa2 писал(а):
Бросьте уж эту тему, параметрами икса ничего полностью не решается с этим явлением
И -q 0 не помогает? =)
|
|
|
|
Stanawa2
Стаж: 16 лет 7 месяцев Сообщений: 10188
|
Stanawa2 ·
02-Дек-10 03:04
(спустя 22 мин., ред. 02-Дек-10 03:04)
Pustovetov писал(а):
И -q 0 не помогает? =)
Смешно, но тема называтццо
Как выбрать оптимальный битрейт и ключевые параметры для рипа в x264 
|
|
|
|
Pustovetov
Стаж: 17 лет Сообщений: 4255
|
Pustovetov ·
02-Дек-10 03:13
(спустя 9 мин.)
Stanawa2 писал(а):
Pustovetov писал(а):
И -q 0 не помогает? =)
Смешно, но тема называтццо
Как выбрать оптимальный битрейт и ключевые параметры для рипа в x264
Т.е. помогает =) А может и crf 13 поможет? Значит вопрос в том что надо задавать больше битрейта и(или) как-то фильтровать чтобы маскировать такие места без засобачивания слишком большого количества битрейта. А не требовать от кодека чтобы он совсем уж как-то во всем сделал прекрасно и в 300 кбпс )
|
|
|
|
arkahan
Стаж: 16 лет 10 месяцев Сообщений: 978
|
arkahan ·
02-Дек-10 05:15
(спустя 2 часа 1 мин., ред. 02-Дек-10 05:59)
Pustovetov писал(а):
Цитата:
Всегда думал, что уж куски с разным битрейтом и одинаковыми остальными настройками клеить можно без проблем, ан нет, глючит после этого.
С разным битрейтом да. Пожатые с разным CRF нет...
Пожатые с разным CRF - да. http://multi-up.com/385807 - два гопа, пожатые с разным crf (crf18.264 и crf17.264), склеены в такой последовательности : crf18.264+crf17.264+crf18.264 без каких-либо сплиттеров. Окромя разного crf у гопов ещё есть различающиеся настройки:
скрытый текст
"--crf 18 --deblock -3:-3 --psy-rd 0.9:0.15 --subme 9 --qcomp 0.70 --aq-mode 2 --output "d:\crf18.264" "f:\1111.avs"
"--crf 17 --deblock -2:-2 --psy-rd 1:0.00 --subme 10 --qcomp 0.60 --aq-mode 1 --output "d:\crf17.264" "f:\2222.avs"
Протестировано на ffdshow, coreAVC и железке WD TV gen2.. Или я торможу и вообще не о том?
|
|
|
|
TurboPascal7
Стаж: 15 лет 7 месяцев Сообщений: 668
|
TurboPascal7 ·
02-Дек-10 06:01
(спустя 46 мин., ред. 02-Дек-10 06:01)
После непродолжительной беседы с парой разрабов, чтения стандарта и сорцев, вынужден признать, что Pustovetov был прав от начала и до конца.
CRF в рамках х264 пишется в PPS в виде
Код:
pps->i_pic_init_qp = param->rc.i_rc_method == X264_RC_ABR ? 26 + QP_BD_OFFSET : param->rc.i_qp_constant;
, где
Код:
h->param.rc.i_qp_constant = h->param.rc.f_rf_constant + QP_BD_OFFSET;
что в результате выливается в разные значения init_qp в различных файлах при разных crf. При декодировании потом это выливается в неправильные значения квантов для макроблоков, т.к.
Стандарт H.264 писал(а):
pic_init_qp_minus26 specifies the initial value minus 26 of SliceQPY for each slice. The initial value is modified at the
slice layer when a non-zero value of slice_qp_delta is decoded, and is modified further when a non-zero value of
mb_qp_delta is decoded at the macroblock layer. The value of pic_init_qp_minus26 shall be in the range of
−(26 + QpBdOffsetY ) to +25, inclusive.
Теоретически возможно, что декодер, наткнувшись на новые параметры при декодировании (ЕСЛИ наткнется и ЕСЛИ они будут находится в нужном месте после соединения 2х потоков), перенастроит себя на декодирование с новыми параметрами и будет воспроизводить файл правильно, но всё это "если", и в любом случае идет против стандарта H.264. Остается вопрос, можно ли изменить mb_qp_delta и значение init_qp непосредственно в потоке без его перекодирования, но это уже за рамками темы и трекера в общем.
Вывод - клеить с разными crf можно, но только если вы делаете это под определенные декодеры, на которых контент может быть протестирован. Зажатые с разным битрейтом файлы, тем не менее, имеют один заголовок и должны декодироваться нормально. Вопрос "а почему тогда не писать постоянное значение qp_init, как это сделано для битрейтов" имеет простой ответ - всё сделано ради экономии.
На сём /thread.
|
|
|
|
Tim68
Стаж: 14 лет 9 месяцев Сообщений: 712
|
Tim68 ·
02-Дек-10 12:54
(спустя 6 часов, ред. 02-Дек-10 12:54)
TurboPascal7 писал(а):
клеить с разными crf можно, но только если вы делаете это под определенные декодеры
Интересно, а как относятся железячные декодеры BD плееров к переходу между кусками с разным crf?
Еще вопросик. Чем может грозить в отчете икса "vbv underflow"?
|
|
|
|
Pustovetov
Стаж: 17 лет Сообщений: 4255
|
Pustovetov ·
02-Дек-10 15:23
(спустя 2 часа 29 мин.)
Tim68 писал(а):
Еще вопросик. Чем может грозить в отчете икса "vbv underflow"?
Тем что железяка, которая требовала именно такой параметер vbv, начнет лагать
|
|
|
|
Ang+
Стаж: 16 лет 7 месяцев Сообщений: 993
|
Ang+ ·
02-Дек-10 16:30
(спустя 1 час 6 мин.)
TurboPascal7
Pustovetov
То есть, подытоживая, безопасно клеить можно куски, полученные двухпроходным кодированием?
|
|
|
|
TurboPascal7
Стаж: 15 лет 7 месяцев Сообщений: 668
|
TurboPascal7 ·
02-Дек-10 16:31
(спустя 1 мин.)
Ang+ писал(а):
То есть, подытоживая, безопасно клеить можно куски, полученные двухпроходным кодированием?
Да. Или однопроходным ABR, если его кто-то вообще использует.
|
|
|
|
DreadMaster
Стаж: 16 лет Сообщений: 710
|
DreadMaster ·
02-Дек-10 16:56
(спустя 24 мин.)
arkahan
Попробуй этот. После запуска сразу отмотай на вторую половину.
http://rghost.ru/3455510
Haali Splitter+CoreAVC
на слишком коротких отрезках всё нормально бывает, на более длинных - вот такое.
|
|
|
|
gaidamak
Стаж: 18 лет Сообщений: 1155
|
gaidamak ·
02-Дек-10 23:41
(спустя 6 часов)
Народ, а чем протестить ts-файл c h.264 внутри на предмет возможных сбоев?
|
|
|
|
Tim68
Стаж: 14 лет 9 месяцев Сообщений: 712
|
Tim68 ·
03-Дек-10 11:31
(спустя 11 часов, ред. 03-Дек-10 11:31)
Pustovetov писал(а):
Тем что железяка, которая требовала именно такой параметер vbv, начнет лагать
Спасибо. Нужно-то как раз в пределах AVCHD, если в среднем битрейт плавает около 4000 kB/s, то местами плевки более 40000 kB/s, а жму в crf кусками и много, что трогать в настройках нельзя.
|
|
|
|
Jotnar
Стаж: 17 лет 3 месяца Сообщений: 1838
|
Jotnar ·
03-Дек-10 12:02
(спустя 30 мин.)
gaidamak писал(а):
Народ, а чем протестить ts-файл c h.264 внутри на предмет возможных сбоев?
mpeg2repair
|
|
|
|
shartm
Стаж: 15 лет 10 месяцев Сообщений: 2533
|
shartm ·
05-Дек-10 14:23
(спустя 2 дня 2 часа, ред. 05-Дек-10 14:23)
К вопросу о subme 10. Сейчас делаю рип Hairspray. Исходник очень своеобразный - больше похож на CG-анимацию, чем на film. Сплошные градиентные заливки и однотонные розово-персиковые рожи  Удолбался бороться с блочностью даже при crf 17 и deblock -1/-1. Опустился с tesa&subme10 на subme 9&umh - блочность исчезла 
|
|
|
|
Jotnar
Стаж: 17 лет 3 месяца Сообщений: 1838
|
Jotnar ·
05-Дек-10 14:27
(спустя 3 мин.)
shartm писал(а):
блочность исчезла
битрейт вырос
|
|
|
|
shartm
Стаж: 15 лет 10 месяцев Сообщений: 2533
|
shartm ·
05-Дек-10 18:52
(спустя 4 часа)
selanne писал(а):
shartm писал(а):
блочность исчезла
битрейт вырос
Ну и хрен с ним. Там его даже на DVD5 c большим запасом. Или, по-Вашему, максимально низкий битрейт важнее качества рипа?
|
|
|
|
Jotnar
Стаж: 17 лет 3 месяца Сообщений: 1838
|
Jotnar ·
05-Дек-10 19:47
(спустя 54 мин., ред. 05-Дек-10 19:47)
shartm писал(а):
Или, по-Вашему, максимально низкий битрейт важнее качества рипа?
Я к тому, что дело не в subme.
Кстати, чтоб получить нормальную картинку, приходилось crf и ниже 16 опускать.
|
|
|
|
shartm
Стаж: 15 лет 10 месяцев Сообщений: 2533
|
shartm ·
06-Дек-10 09:52
(спустя 14 часов)
selanne писал(а):
Я к тому, что дело не в subme.
Кстати, чтоб получить нормальную картинку, приходилось crf и ниже 16 опускать.
Ваша правда, скрутил crf до 16, с qp 0.65/tesa/subme10 удалось таки победить исходник 
|
|
|
|
DreadMaster
Стаж: 16 лет Сообщений: 710
|
DreadMaster ·
09-Дек-10 17:33
(спустя 3 дня)
Подскажите, пожалуйста, как посчитать общий средний битрейт.
Например, есть 2 куска:
1) 1000 фреймов, битрейт 4000
2) 3000 фреймов, битрейт 7000
Каков будет битрейт после объединения файлов ? Помидорами не закидывать, забыл математику средних классов, с кем не бывает
|
|
|
|
Toshik27162
Стаж: 16 лет 1 месяц Сообщений: 435
|
Toshik27162 ·
09-Дек-10 17:39
(спустя 6 мин.)
не вдаваясь в математику, если используете мегуй, то в нем есть хороший калькулятор битрейта-посчитаете размер одного+ размер другого.
|
|
|
|
Xenosag
Стаж: 16 лет 2 месяца Сообщений: 971
|
Xenosag ·
09-Дек-10 17:43
(спустя 3 мин.)
DreadMaster
задал задачку ~6300 где-то будет
|
|
|
|
DreadMaster
Стаж: 16 лет Сообщений: 710
|
DreadMaster ·
09-Дек-10 17:58
(спустя 14 мин.)
Toshik27162
Вроде не про размер спрашивал совсем...
Xenosag
6300 эт конечно хорошо, но мне бы понять, как считать
|
|
|
|
Toshik27162
Стаж: 16 лет 1 месяц Сообщений: 435
|
Toshik27162 ·
09-Дек-10 18:08
(спустя 10 мин., ред. 09-Дек-10 18:08)
DreadMaster
малясь невнимательно прочитал, извиняюсь. но задача от этого не меняется.6250 получилось у меня.
Если интересует методика-то я сделал следующим образом-считаем размер одного файла+размер другого, потом вбиваем в калькулятор продолжительность=4000 кадров и размер который получили ранее, прога посчитает средний битрейт под размер.
|
|
|
|
Xenosag
Стаж: 16 лет 2 месяца Сообщений: 971
|
Xenosag ·
09-Дек-10 18:27
(спустя 19 мин.)
(фр1 х битр1) + (фр2 х битр2)
_________________________
(фр1 + фр2)
|
|
|
|
