|
|
|
monkalex
Стаж: 16 лет Сообщений: 576
|
monkalex ·
27-Авг-12 04:55
(13 лет назад)
Наркоманы, что вы тут на 60 страниц растянули, если анимешники смотрят как получится эти 10бит а остальным пофигу? 
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
27-Авг-12 10:44
(спустя 5 часов)
degifly писал(а):
Хотите скрины в виде 10-битного 4:2:0 изображения? Сколько человек сможет правильно декодировать и сравнить
oneoneleven писал(а):
как связано 10 битное видео и сжатие PNG восьмибитных скриншотов?
В общем для сжатых PNG, чем более трудносжимаем материал, тем тяжелее выходит скрин и глупо кому-либо втыкать истину о том, что при сравнении скринов со значительной разницей в весе, более тяжелый имеет лучшие градиенты (столь незначительные, елезаметные) на цветовых переходах.
Подобно выполненное сравнение не несет в своей базе какого-либо соревновательного характера "слона и моськи" и применение его под большим вопросом, даже информационно сложно принять данное сравнение ко вниманию, неговоря уже о каком-либо доказательном характере.
degifly писал(а):
Этой теле-радио-whatever технике сигнал поступает 10-битный? Нет? Или может быть их постпроцессинг сравнится с тем, что тут на трекере делают?
oneoneleven писал(а):
Там 8bit+A-FRC и ни слова про 10битное видео. Т.е. 8битный сигнал дизерится до 10 бит дисплеем и отображается им в псевдо 10 бит.
Никакой "цепочки многобитной обработки" там нет.
С битностью декодируемого источника там все в порядке, как и положенно 8 bit и с многобитной обработкой сигнала, значительно более чем 16bit см. x.v.Colour (xvYCC+Deep Color), тоже полный "феншуй", разве, что вывод пока на честную или не совсем 10bit-ую матрицу TV.
Этап осмысления и нахождения программных решений преобразования 8bit => многобитная обработка + дизер => 10bit ведущими производителями бытовой техники, на аппаратном уровне, был пройден много лет назад и на сегодня уже хорошо реализован.
Мне хватит мозгов, чтобы не рассуждать чей постпроцессинг лучше, т.к. провести корректное сравнение не представляется возможным, во всяком случае мне.
|
|
|
|
oneoneleven
Стаж: 15 лет 9 месяцев Сообщений: 620
|
oneoneleven ·
27-Авг-12 11:31
(спустя 47 мин., ред. 27-Авг-12 11:31)
Tim68 писал(а):
54893784Подобно выполненное сравнение не несет в своей базе какого-либо соревновательного характера "слона и моськи" и применение его под большим вопросом, даже информационно сложно принять данное сравнение ко вниманию, неговоря уже о каком-либо доказательном характере.
Щито? Можете расшифровать для глупых семиклассников?
Tim68 писал(а):
54893784многобитной обработкой сигнала, значительно более чем 16bit см. x.v.Colour (xvYCC+Deep Color)
Deep Color это как раз-таки 10/12/16 бит на канал. А xvYCC к битности никакого отношения не имеет.
Tim68 писал(а):
54893784Этап осмысления и нахождения программных решений преобразования 8bit => многобитная обработка + дизер => 10bit ведущими производителями бытовой техники, на аппаратном уровне, был пройден много лет назад и на сегодня уже хорошо реализован.
Интересно, что там за "многобитная обработка". Классические шарп, подкрутка цветов? "Многобитный" деблок? Или в устройствах ведущих производителей бытовой техники появился дебанд?
Какое вообще отношение имеет аппаратный дитер 8 бит -> 10 бит на телевизорах к (нередко вручную) обработанному в 16бит и последующему закодированному в 10 бит видео?
|
|
|
|
degifly
Стаж: 15 лет Сообщений: 951
|
degifly ·
27-Авг-12 14:41
(спустя 3 часа, ред. 27-Авг-12 14:41)
Tim68 писал(а):
54893784В общем для сжатых PNG, чем более трудносжимаем материал, тем тяжелее выходит скрин
Шум - трудносжимаем. В 10-битном видео шума нет. Но он повляется при рендеринге в 8 бит - как результат дизеринга.
А в 8-битном видео шум есть, но его меньше - т.к. его энкодер режет ради уменьшения битрейта. А отсюда - бандота.
understand?
Tim68 писал(а):
54893784имеет лучшие градиенты (столь незначительные, елезаметные) на цветовых переходах.
В сравнении tp7 тоже все елезаметно?
Tim68 писал(а):
54893784Подобно выполненное сравнение не несет в своей базе какого-либо соревновательного характера "слона и моськи" и применение его под большим вопросом, даже информационно сложно принять данное сравнение ко вниманию, неговоря уже о каком-либо доказательном характере.
Вы адекватны?
Это скриншоты с реального видео, для которого указан битрейт. Какая нафиг разница сколько скрины весят?
oneoneleven писал(а):
8битный сигнал дизерится до 10 бит
8 бит нельзя отдизерить до 10...
Tim68 писал(а):
54893784с многобитной обработкой сигнала, значительно более чем 16bit
При выводе в 8 бит внутренняя точность более 16 бит бесполезна. Ну и уже ответили про этот бред.
Tim68 писал(а):
54893784Этап осмысления и нахождения программных решений преобразования 8bit => многобитная обработка + дизер => 10bit ведущими производителями бытовой техники, на аппаратном уровне, был пройден много лет назад и на сегодня уже хорошо реализован.
Покажите мне встроенный дебанд, я жду. А еще встроенный АА, а также умный деинтерлейсер который автоматически умеет исправлять все косяки наркоманов-японцев.
Tim68 писал(а):
54893784Мне хватит мозгов, чтобы не рассуждать чей постпроцессинг лучше, т.к. провести корректное сравнение не представляется возможным, во всяком случае мне.
Запустите ремукс и посмотрите. Лично у меня в топовом самсунге (UE55ES8007) весь постпроцессинг превращает аниме в дерьмо. Как и в свое время (года 2 назад) топовый Philips (модель не помню уже).
Даже апскейлит madVR лучше, с недавним появлением антизвона
Единственное что в телеках хорошее (кроме матрицы) - интерполяция. Но для аниме она бесполезна. А, еще и триде неплохо (и это тоже не про аниме) выглядит, хотя в аймаксе все равно круче.
|
|
|
|
oneoneleven
Стаж: 15 лет 9 месяцев Сообщений: 620
|
oneoneleven ·
27-Авг-12 16:24
(спустя 1 час 42 мин., ред. 27-Авг-12 16:24)
degifly писал(а):
548968098 бит нельзя отдизерить до 10...
Ну не дизер, а что там происходит когда 8битная картинка на 8 + FRC дисплей поступает? Если ничего, то смысл пихать 8 + FRC дисплей вместо просто 8битного. Неужто банальный маркетинг, лол.
Насчёт рендеров в линуксах:
MPlayer2 2.0-590-g01d067d (Gentoo)
[Yousei-raws] Steins;Gate 01 [BDrip 1920x1080 x264 FLAC].mkv ~14:01
mediainfo '[Yousei-raws] Steins;Gate 01 [BDrip 1920x1080 x264 FLAC].mkv'
General
Unique ID : 241267554279163989712257665131510055341 (0xB58270D44E51B8F0BE81AE43E3E941AD)
Complete name : [Yousei-raws] Steins;Gate 01 [BDrip 1920x1080 x264 FLAC].mkv
Format : Matroska
Format version : Version 2
File size : 1.87 GiB
Duration : 23mn 56s
Overall bit rate mode : Variable
Overall bit rate : 11.2 Mbps
Encoded date : UTC 2011-08-22 16:23:55
Writing application : mkvmerge v4.9.1 ('Ich will') сборка от Jul 11 2011 23:53:15
Writing library : libebml v1.2.1 + libmatroska v1.1.1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 10@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 23mn 56s
Nominal bit rate : 10.6 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.213
Writing library : x264 core 116 r2057 0ba8a9c
Encoding settings : cabac=1 / ref=4 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=0.90:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=0 / bitrate=10576 / ratetol=1.0 / qcomp=0.70 / qpmin=16 / qpmax=56 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=30000 / vbv_bufsize=40000 / nal_hrd=none / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.90
Language : Japanese
Default : No
Forced : No
Audio
ID : 2
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 23mn 56s
Bit rate mode : Variable
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)
Language : Japanese
Default : Yes
Forced : No
GL.......................................................... VDPAU.................................................... XV..........................................................
Кто-нибудь, сделайте, пожалуйста, скрины через MadVR, EVR, Haali и прочие виндовые, хочется сравнить по части бандинга и цвета.
Сэмпл (прям первый кадр)
+ AvsP (ffvideosource(+10bithack)+ditherpost(6)) наверняка что-то неправильно делаю, лол
|
|
|
|
degifly
Стаж: 15 лет Сообщений: 951
|
degifly ·
27-Авг-12 16:29
(спустя 5 мин.)
oneoneleven писал(а):
54898138Ну не дизер, а что там происходит когда 8битная картинка на 8 + FRC дисплей поступает?
Эм...
Временой дизеринг работает примерно так: есть пиксель, который должен иметь цвет 2,5 (в какой-нибудь компоненте). Половину времени он будет показывать "2", а половину - "3". Если же он должен показывать просто "2"- то он эти "2" и будет показывать.
oneoneleven писал(а):
54898138Если ничего, то смысл пихать 8 + FRC дисплей вместо просто 8битного. Неужто банальный маркетинг, лол.
Смысл - при 10-битном источнике сигнала.
oneoneleven писал(а):
54898138Кто-нибудь, сделайте, пожалуйста, скрины через MadVR, EVR, Haali и прочие виндовые, хочется сравнить по части бандинга и цвета.
madVR http://2.firepic.org/2/images/2012-08/27/ae3pyd60roy7.png
EVR на Intel HD http://2.firepic.org/2/images/2012-08/27/fj3unwx12hxh.png
EVR на ATI http://2.firepic.org/2/images/2012-08/27/knszp13ypcft.png
HaaliVR http://4.firepic.org/4/images/2012-08/27/ipovp51b6qs1.png
Декодер везде LAV (он не только же декодирует, но и конвертирует цветовые пространства из-за неподдерживания P010 всем, кроме madVR)
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
27-Авг-12 17:31
(спустя 1 час 1 мин., ред. 27-Авг-12 17:31)
degifly писал(а):
Шум - трудносжимаем. В 10-битном видео шума нет.... А в 8-битном видео шум есть, но его меньше
Вы уж решите в какую сторону вас понесло. При многобитной обработке дизеринг присутствует как при выводе в 8 bit так и в 10bit.
degifly писал(а):
54896809Это скриншоты с реального видео, для которого указан битрейт. Какая нафиг разница сколько скрины весят?
Относительный вес скрина характеризует относительную сжимаемость материала. Если скрин значительно тяжелее - значить на то есть причины: шум, зерно и т.д., что как раз в первую очередь и маскирует градиенты. Как можно сравнивать скрины с весовым соотношением 1:3 на предмет плохих градиентов? Никак.
degifly писал(а):
54896809При выводе в 8 бит внутренняя точность более 16 бит бесполезна. Ну и уже ответили про этот бред.
Читайте внимательно. Я говорил об обработке более 16bit на канал, deep color (supports 30/36/48/64-bit for three RGB colors) в TV с поддержкой технологии x.v.Colour (xvYCC+Deep Color) при выводе 10bit на матрицу.
degifly писал(а):
54896809Покажите мне встроенный дебанд, я жду.
Вопрос не ко мне. Аппаратная многобитная обработка с дизером при выводе в 10 bit привелегия производителей.
Против наркоманов-японцев существуют только наркоманы-анимешники.
degifly писал(а):
54896809Запустите ремукс и посмотрите. Лично у меня в топовом самсунге (UE55ES8007) весь постпроцессинг превращает аниме в дерьмо.
Никакой ремукс эффекта не даст. Необходимо, чтобы на телек по HDMI не ниже v.1.3 пришел сигнал формата xvYCC, т.е. на входе аппаратного декодера должно быть 8-ми bit-ное полнодиапазонное видео соответствующее требованиям формата AVCHD, т.к. только для него описан xvYCC.
Я не могу у себя это проверить т.к. у моего TV на выходе 8bit и отсутствует поддержка x.v.Colour.
Что касается сверх шарпящего скалера и в моем BD плеере я уже где-то отписывался, а старенькая TV лыжа имеет нейтральный.
degifly писал(а):
54898494Смысл - при 10-битном источнике сигнала.
Уточнение - при выводе 10-битного сигнала на матрицу.
|
|
|
|
degifly
Стаж: 15 лет Сообщений: 951
|
degifly ·
27-Авг-12 17:52
(спустя 21 мин., ред. 27-Авг-12 17:52)
Tim68 писал(а):
54899148При многобитной обработке дизеринг присутствует как при выводе в 8 bit так и в 10bit.
При таких квантайзерах, что используют в 10-битном видео - в 10 битном видео шума нет.
Tim68 писал(а):
54899148Как можно сравнивать скрины с весовым соотношением 1:3 на предмет плохих градиентов? Никак.
Okay, все 8-битные раздачи дерьмо, т.к. там скрины весят в 3 раза меньше. Вы это сами сказали 
Tim68 писал(а):
54899148Читайте внимательно.
Чего читать то? Покажите мне калькулятор, который при делении 48 на 3 даст число большее 16
Кстати, 64 бита на три канала - это ваша фантазия. Сами читайте свои википедию внимательнее.
Tim68 писал(а):
54899148Против наркоманов-японцев существуют только наркоманы-анимешники.
Чтож вы тут забыли? У вас есть своя ветка, где вам нравится общаться с самим собой и доказывать всякий бред Возвращайтесь туда.
Tim68 писал(а):
54899148Никакой ремукс эффекта не даст. Необходимо, бла-бла-бла
У телика есть свой декодер, умеет с флешки и по сети видео играть.
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
27-Авг-12 18:14
(спустя 21 мин., ред. 27-Авг-12 18:27)
degifly писал(а):
54899759в 10 битном видео шума нет.
- наивность порой не знает границ;
degifly писал(а):
54899759Возвращайтесь туда.
- но и хамство тоже;
degifly писал(а):
54899759Вы это сами сказали
- врать некрасиво;
degifly писал(а):
54899759Сами читайте свои википедию внимательнее.
- посылать тоже плохо.
Похоже вам обидно, но поверьте мне тоже обидно за японцев.
Пост расчитан не на вас а на людей заходящих сюда, а они сами сделают вывод.
|
|
|
|
GlintBeer
Стаж: 16 лет Сообщений: 222
|
GlintBeer ·
27-Авг-12 18:48
(спустя 33 мин., ред. 27-Авг-12 18:48)
degifly писал(а):
Временой дизеринг работает примерно так: есть пиксель, который должен иметь цвет 2,5 (в какой-нибудь компоненте). Половину времени он будет показывать "2", а половину - "3". Если же он должен показывать просто "2"- то он эти "2" и будет показывать.
Можо проще сказать, хотя и немого из другой оперы  Не можете вы отображать жёлтый берёте и "мешаете" зелёный с красным и как бы жёлтый получаете. Примерно так большинство ЖК мониторов из 18 получают 24.
Tim68 писал(а):
Я говорил об обработке более 16bit на канал, deep color (supports 30/36/48/64-bit for three RGB colors) в TV с поддержкой технологии x.v.Colour (xvYCC+Deep Color) при выводе 10bit на матрицу.
Путаете тёплое с мягким. xvYCC здесь вообще не причём, да и не нужено оно. БД в нём не делают.
Tim68 писал(а):
наивность порой не знает границ
А зачем там дитер? Закос под 16битное видео делать?
Tim68 писал(а):
врать некрасиво
Ваши слова можно интерпретирровать именно так. Вообще не понятно, почему вы так в вес упёрлись. В PNG жмётся без потерь, так что всё в порядке.
Tim68 писал(а):
Похоже вам обидно, но поверьте мне тоже обидно за японцев.
А нефиг порой всякую жесть на БД делать.
|
|
|
|
Lenchik
Стаж: 19 лет 2 месяца Сообщений: 853
|
Lenchik ·
27-Авг-12 19:01
(спустя 13 мин.)
GlintBeer писал(а):
54900349А зачем там дитер? Закос под 16битное видео делать?
Dithering делается для имитации в менее битном отображении более битного. Идейно-математически пофиг имитируем мы в 8 битах 10 бит или же в 10 битах 16 бит. Вот в абсолютных значениях величин там могут быть нюансы.
|
|
|
|
GlintBeer
Стаж: 16 лет Сообщений: 222
|
GlintBeer ·
27-Авг-12 19:21
(спустя 19 мин., ред. 27-Авг-12 20:02)
Lenchik писал(а):
54901039Dithering делается для имитации в менее битном отображении более битного. Идейно-математически пофиг имитируем мы в 8 битах 10 бит или же в 10 битах 16 бит. Вот в абсолютных значениях величин там могут быть нюансы.
Вы видео тоже идейно смотрите?  Я к тому, что можно дитерить, вот только зачем? Польза от "настоящего" увеличения битности с 8 до 10 бесспорна и дитер там не особо нужен.
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
27-Авг-12 19:31
(спустя 10 мин.)
GlintBeer писал(а):
54900349Путаете тёплое с мягким. xvYCC здесь вообще не причём, да и не нужено оно. БД в нём не делают.
xvYCC имеет прямое отношение к Deep Color, технологии создавались для совместного использования, маркетинговое название x.v.Colour. Хоть к BD это и никакого отношения не имеет, но это имеет прямое отношение к AVCHD, своего рода такой Rip, только с некиеми ограничениями. Пленка имеет весма широкий диапазон, поэтому при оцифровке принудительно изображение загоняют в диапазон описываемый тем или иным форматом, в данном случае форматом Blu-Ray. Что бы так сказать восстановить справедливость будет правельным сделать обратное преобразование, а именно расжать его. Но как потом передать это? Да просто сжать согласно требований формата AVCHD и все.
GlintBeer писал(а):
54900349Вообще не понятно, почему вы так в вес упёрлись. В PNG жмётся без потерь, так что всё в порядке.
Да не уперся Я, просто стараюсь пояснить, что делать подобные сравнения некорректно.
|
|
|
|
GlintBeer
Стаж: 16 лет Сообщений: 222
|
GlintBeer ·
27-Авг-12 20:07
(спустя 35 мин., ред. 27-Авг-12 20:07)
Tim68 писал(а):
54901624xvYCC имеет прямое отношение к Deep Color, технологии создавались для совместного использования, маркетинговое название x.v.Colour. Хоть к BD это и никакого отношения не имеет, но это имеет прямое отношение к AVCHD, своего рода такой Rip, только с некиеми ограничениями.
xvYCC - думаю, что вы не хуже меня знаете, что это просто цветовое простраство, модифицированное YCC. Там также может быть по 8 бит на элемент. Но и 10бит может "выдваться" в других цветовых пространствах.
Смысл поддержки xvYCC в той моели телевизора, что вы превели как пример, в том, что некоторые корейские и японские каналы (за остальных не знаю) применяют AVCHD в телевевещании.
Tim68 писал(а):
54901624Пленка имеет весма широкий диапазон, поэтому при оцифровке принудительно изображение загоняют в диапазон описываемый тем или иным форматом, в данном случае форматом Blu-Ray. Что бы так сказать восстановить справедливость будет правельным сделать обратное преобразование, а именно расжать его. Но как потом передать это? Да просто сжать согласно требований формата AVCHD и все.
Я правильно понял, что вы хотите "разжать" видеопоток сжатый с потерями в исходник? Потом сжать его согласно стандарту AVCHD (который кстати для кодирования видео использует h264/avc) и передать для воспроизведения?
Tim68 писал(а):
54901624Да не уперся Я, просто стараюсь пояснить, что делать подобные сравнения некорректно.
Вес значения не имеет, алгоритм один и тот же, потерь при сжатии нет  проблем в сравнении нет. Вот как раз сравнивать по размеру (а также битрейту и тп) совсем некорректно.
|
|
|
|
user456
Стаж: 13 лет 1 месяц Сообщений: 142
|
user456 ·
27-Авг-12 20:21
(спустя 13 мин., ред. 31-Май-13 14:59)
|
|
|
|
Dyavlik
Стаж: 16 лет 2 месяца Сообщений: 849
|
Dyavlik ·
27-Авг-12 21:26
(спустя 1 час 5 мин., ред. 27-Авг-12 21:26)
LAV audio же поддерживает ac3, true hd? Почему-то именно с ними он не загружается. Сплиттер - haali.
Но тут хотя бы звук есть.
А вот с truehd его нет вообще:
В чем может быть проблема?
P.s.
|
|
|
|
Mac312
Стаж: 15 лет 7 месяцев Сообщений: 69
|
Mac312 ·
27-Авг-12 21:35
(спустя 8 мин.)
Dyavlik
Вы выводите звук на ресивер/телик? Если нет, зачем тогда галки на битстриме?
А для TrueHD нужно положить dtsdecoderdll.dll в папку с LAV если не ошибаюсь.
|
|
|
|
Dyavlik
Стаж: 16 лет 2 месяца Сообщений: 849
|
Dyavlik ·
27-Авг-12 21:50
(спустя 15 мин.)
Mac312
Благодарю.
Галки убрал, половина проблемы решилась. LAV audio подгружается, но звука с trueHD по прежнему нет.
>dtsdecoderdll.dll
Это я уже сделал до этого. Не помогло.
|
|
|
|
Mac312
Стаж: 15 лет 7 месяцев Сообщений: 69
|
Mac312 ·
27-Авг-12 22:18
(спустя 27 мин., ред. 27-Авг-12 22:18)
Dyavlik
Смените сплиттер. Только что проверил:
LAVSplitter + LAVAudio = есть звук;
Haali Splitter + LAVAudio = нет звука.
P.S.: dtsdecoderdll.dll нужен только для DTS-HD как выяснилось.
|
|
|
|
AceLighting
Стаж: 16 лет 4 месяца Сообщений: 173
|
AceLighting ·
27-Авг-12 22:50
(спустя 31 мин.)
Помогите преобразовать 10bit в 8bit. Сделал всё по инструкции с preset veryfast, в итоге на входе нормальный 10,5 Гб файл, на выходе получаю файл 2 с лишним Гб и он зависает, когда перещёлкиваешь сразу на середину. MPC показывает в это время внизу buffering и медленно-медленно бегут проценты.
Может быть кто-нибудь знает в чём причина?
|
|
|
|
Acid_House
Стаж: 16 лет 10 месяцев Сообщений: 44
|
Acid_House ·
27-Авг-12 23:41
(спустя 50 мин.)
Подскажите пожалуйста какой тогда лучше использовать сплиттер как при 10 битном видео,так и 8? AV Splitter или LAV Splitter или все же старый,проверенный Haali??
Хочу поставить что то на КМП плеер.
|
|
|
|
TurboPascal7
Стаж: 16 лет 5 месяцев Сообщений: 667
|
TurboPascal7 ·
28-Авг-12 00:23
(спустя 41 мин., ред. 28-Авг-12 00:23)
Лучше - Haali. Баги его рядовым юзерам редко заметны, а вот AV никем слишком активно, как я понимаю, не тестировался.
AceLighting писал(а):
54905627на выходе получаю файл 2 с лишним Гб и он зависает, когда перещёлкиваешь сразу на середину. MPC показывает в это время внизу buffering и медленно-медленно бегут проценты.
Вы забыли добавить звук. Пересоберите контейнер со звуком в mkvmerge и всё будет ок.
|
|
|
|
Acid_House
Стаж: 16 лет 10 месяцев Сообщений: 44
|
Acid_House ·
28-Авг-12 00:35
(спустя 12 мин.)
TurboPascal7 писал(а):
54906968Лучше - Haali. Баги его рядовым юзерам редко заметны, а вот AV никем слишком активно, как я понимаю, не тестировался.
Спасибо большое. И если б вы еще ответили на мое сообщение в ЛС,было б вообще прекрасно!)))
|
|
|
|
oneoneleven
Стаж: 15 лет 9 месяцев Сообщений: 620
|
oneoneleven ·
28-Авг-12 03:56
(спустя 3 часа, ред. 28-Авг-12 11:42)
degifly писал(а):
54898494Смысл - при 10-битном источнике сигнала.
Никто не спорит. Но в этих йоба телевизорах 99.(9)% сигнала 8 бит
Спасибо.
А я тут понял что mplayer2 (конкретно swscaler) плохо снимает скрины.
GL (через принтскрин)
XV (через принтскрин)
Итого GL лучше, цвета оно не корёжит (т.к. конверсия yuv420p10le -> rgb напрямую через opengl, а не yuv420p10le -> yuv420p swscaler'ом и yuv420p -> rgb рендером). Ещё там можно скейлить хрому/люму бикубиком, в отличие от. А ещё у меня внезапно заиграл без дропов NCOP Steins;Gate (Hi10P 22.8 Mbps), это на Core 2 Duo E4700 (2,6 GHz).
MPlayer2 2.0-590-g01d067d (git) / ffmpeg N-43891-g65b552c (git)
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
28-Авг-12 11:06
(спустя 7 часов, ред. 28-Авг-12 12:02)
GlintBeer писал(а):
xvYCC - думаю, что вы не хуже меня знаете, что это просто цветовое простраство, модифицированное YCC. Там также может быть по 8 бит на элемент. Но и 10бит может "выдваться" в других цветовых пространствах.
Смысл поддержки xvYCC в той моели телевизора, что вы превели как пример, в том, что некоторые корейские и японские каналы (за остальных не знаю) применяют AVCHD в телевевещании.
Вот как Sony, одна из правообладателей на данную технологию, описывает xvYCC, наиболее информативно см. раздел Technical Description of xvYCC Color Space. Действительно (Definitions over 8 bits are also used to support precise gradation.), но в единственном поддерживающем xvYCC формате AVCHD описан только 8 bit-ный вариант.
В телевещании AVCHD не применяется, формат исключительно описан для оптических и магнитных носителей, кстати единственный формат описывающий компрессию видеоданных в H.264/AVC (MPEG4 Part 10) для магнитных носителей, форматы Blu-Ray Disk и DVD Disk описанны только для оптических носителей.
В телевещании HDTV действительно используется компрессия видеоданных в H.264/AVC, более того к концу 2015 года все это должно иметь место на всей территории Российской Федерации.
GlintBeer писал(а):
Я правильно понял, что вы хотите "разжать" видеопоток сжатый с потерями в исходник?
Нет неправильно. Сжатый с потерями видеопоток вернуть в исходник невозможно, но разжать TV диапазон до исходно полного (0-255) не составляет труда. Долее по тексту: "Потом сжать его согласно....."
GlintBeer писал(а):
Вес значения не имеет, алгоритм один и тот же, потерь при сжатии нет проблем в сравнении нет.
При сохранении в PNG материал имеющий разную степень сжатия будет иметь разный результирующий размер.
Проверить просто, нужно сделать пару скринов с изначально очень шумного источника, первый с оригинала, второй после сильной зачистки шума.
Для большей информативности, как эталон сжимаемости, создайте пустой черный (R=0, G=0, B=0) или белый (R=255, G=255, B=255) прямоугольник того же разрешения и тоже сохраните.
oneoneleven писал(а):
54908132Но в этих йоба телевизорах 99.(9)% сигнала 8 бит
В этих й..а телевизорах имеется своя аппаратная многобитная обработка сигнала с выводом в 10bit на матрицу.
|
|
|
|
TurboPascal7
Стаж: 16 лет 5 месяцев Сообщений: 667
|
TurboPascal7 ·
28-Авг-12 12:02
(спустя 56 мин.)
|
|
|
|
Tim68
Стаж: 15 лет 7 месяцев Сообщений: 712
|
Tim68 ·
28-Авг-12 12:14
(спустя 12 мин., ред. 28-Авг-12 13:17)
TurboPascal7
скрытый текст
спасибо за конструктивное предложение
Устал, ну честное слово устал. Переключаюсь в режим созерцания.
Ну если что....
|
|
|
|
monkalex
Стаж: 16 лет Сообщений: 576
|
monkalex ·
28-Авг-12 12:58
(спустя 43 мин.)
Tim68
всяко конструктивнее вашего. переливаете из пустого в порожнее.
|
|
|
|
xandpa
Стаж: 17 лет 5 месяцев Сообщений: 2501
|
xandpa ·
28-Авг-12 22:36
(спустя 9 часов)
И как со всей этой мутью можно включить в плеере использование DXVA? Или я сейчас что-то совсем непотребное ляпнул?
|
|
|
|
degifly
Стаж: 15 лет Сообщений: 951
|
degifly ·
28-Авг-12 22:43
(спустя 6 мин.)
Последнее. Видеокарт с аппаратным декодерованием 10-битного видео не существует.
|
|
|
|
