Сообщения abgluck

Как уже выше написали, чтобы не было ресемплинга и интерлейсинга - достаточно правильно согласовать входной и выходной потоки.

@"KNlGHT":
upd: но если снимаешь в максимальном разрешении, то лучше вообще ничего не обрезать, смысла мало.
Обрезать имеет смысл вместо рисования черных полосок. Кроме случая, когда полоска одна и используется для комментов. Максимальное разрешение - понятие растяжимое, есть и 30" мониторы.

@Лазурчик:
Музыка на фоне вставок всегда приглушается минимум в двое.
Маловато будет (с)

Я прекрасно тебя понимаю. А я пытаюсь тебе показать, что и ужимать и увеличивать - плохо.
Посмотри <!-- m --><a class="postlink" href="http://narod.ru/disk/17655396000/woe_06.02.10.avi.html">http://narod.ru/disk/17655396000/woe_06.02.10.avi.html</a><!-- m -->
видео от бук. Там именно обрезано лишнее, без растягивания как у тебя.

Ты не хочешь меня понимать. Я пишу, что нельзя ужимать/растягивать картинку без потери четкости, а ты приводишь пример, почему это делать нельзя. Я предлагаю вместо этого ее обрезать, оставив оригинальный масштаб, а ты упорно продолжаешь ужимать и писать что это плохо.
Да, ужимать - хуже чем растягивать, но растягивать - хуже чем не трогать.
Наглядный пример того, как правильно обрезать лишнее - мувики id by baka
Так же можешь посмотреть последние мувики бук от биоса, там исходник такой же, как и у тебя, 1024768, только проект не растянут до 1280800, а оставлен 1024590. Если смотреть его на мониторе 1280800 в полноэкранном режиме - он будет выглядеть точно так же как твой (а скорее всего даже лучше, т.к. меньше артефактов при перекодировании), но при этом можно посмотреть и без искажений. Да и четкость выше при меньшем битрейте.

@"KNlGHT":
abgluck, одна фигня серавно разность между тем, что ты повторно выложил и 2-ым есть и размазанность.

720480 это режим просмотра, что ты сделаешь 1024768 что 1280*800 одна фигня.

720480 - это не режим просмотра, это св-ва проекта - то, что будет в итоговом видео. Режим просмотра у тебя там стоял 1038761, т.е. картинка сначала ужимается до 720480, а потом растягивается до 1038761. В своих скриншотах я специально сделал размер превью таким же как результат, чтобы в превью показывалось именно то, что получится в итоге.
Между первым и вторым разницы в четкости нет. Открой его тем же пэинтом, сделай максимальное увеличение - "Blessing" написано одинаково, с точностью до пикселя, так же как выглядит на экране во время игры, и ни разу не размыто. Даже артефактов jpeg не видно.=)

@"KNlGHT":

Посмотри, как на твоем видео выглядит иконка каста, какой размер у нее в пикселях и четкость отрисовки, и сравни с нормальным (твоим же) скриншотом/видео Серого Кота/исходником во фрапсе. У тебя на видео она на 20% больше и раза в 2 размытее. Причем эта размытость не из-за кодека/битрейта, а именно из-за того, что ты растягиваешь исходные 1024 до 1280...
Да, с этим я не спорю, но рамытие из-за увеличения картинки там ничтожно и почти незаметно, основная потеря качества идет из-за битрейта и и размытия при движении. При рендеринге в большее разрешение картинка принудительно увеличивается, качество конечно теряется, но поверь если если сжимать , к примеру, из 16801050 в 1280800 будет еще хуже.
Кот, на скока я понимаю, снимает в стандартном разрешении и сжимает в него же, я тоже раньше так делал, но на широкоформатном монике гораздо приятнее смотреть видео на полный экран.
Я не предлагаю сжимать большую катринку до меньшего разрешения, я предлагаю ее обрезать. При этом качество никак не теряется. А образать вы все равно все обрезаете для убирания чата/эквипа/етц. На ш/ф мониторе с разрешением 1280800 видео, снятое в 12801024 и обрезанное до 1280800 будет смотреться намного четче чем 1024768, обрезанное до ~1024600 и растянутое после этого до 1280800 (то, как делаешь ты). С тем же успехом можно было просто обрезать лишнее до ~1024*600, а растягивание до размеров монитора оставить плееру юзера. И битрейт бы съэкономил, и возможность увидеть все четко оставил...

У тебя на обоих скринах картинка ужата до 720*480. Естественно если ужимать с большего разрешения - будет смотреться хуже, но и там и там порнография.
С первым скриншотом где-то накосячил, видимо, пока туда-сюда размеры менял, должно было быть вот так:](link)
Размеры все совпадают пиксель в пиксель. В том и суть - чтобы не было ресемплинга как класса.
Посмотри, как на твоем видео выглядит иконка каста, какой размер у нее в пикселях и четкость отрисовки, и сравни с нормальным (твоим же) скриншотом/видео Серого Кота/исходником во фрапсе. У тебя на видео она на 20% больше и раза в 2 размытее. Причем эта размытость не из-за кодека/битрейта, а именно из-за того, что ты растягиваешь исходные 1024 до 1280...

Нет, это ты меня опять не понял.
Примеры:

1. исходный материал 12801024, проект 1280800:
   ](link)
2. исходный материал 1024768, проект 1280800, без растягивания до размеров проекта:
   ](link)
3. исходный материал 1024768, проект 1280800, с растягиванием до размеров проекта:
   ](link)

В 1 и 2 размер текста, иконок, карты и т.п. одинаковый и видно все максимально четко. В 3 - все это увеличено, чуть-чуть расплывчато (при растягивании картинки это не так заметно как при ужимании, конечно, но все равно видно, особенно в движении), и возможны искажения геометрии в случае если пропорции вырезанного отличаются от пропорций проекта.
Ты же пытаешься сравнивать (3) с совсем страшным вариантом, когда
4. исходный материал 12801024, проект 1280800, исходная картинка ужата до размеров проекта:
](link)
При том доводя его до абсурда, используя еще большую степень ужимания картинки (в (4) ужато только по вертикали, если разница в разрешении будет еще и по горизонтали - будет еще хуже).

upd: поправил косяк с первым скриншотом.

Возьми любой скриншот 1024768, растяни его до 1280800 в любом граф.редакторе и сравни результат с исходной картинкой (смотреть, естественно, в родном для монитора разрешении и без растягивания/ужимания картинки средствами просмотрщика картинок).
Потеря четкости на лицо. А вот если взять 12801024, обрезать (не ужать, а именно отрезать лишнее) его тем же редактором до тех же 1280800, и сравнить аналогичным образом - потерь четкости нет, и размер всех элементов интерфейса неизменен.
В случае с видео этот эффект усугубляется более сильным сжатием и динамикой картинки.

Тут ты не прав, размер чата/букв в нем/окошек с эквипом/етц никак не зависит от того, в каком разрешении снимаешь, а после кропа до такого же разрешения качество картинки при том же битрейте будет ровно таким же. Если ты снимаешь в 1024768, а результат делаешь в 1280800 - либо о четкости картинки можно забыть (из-за растягивания картинки), либо будут полосы со всех сторон.

Есть 2 совршенно разные ситуации:

1. полоски в самом видео, и как ни крути - не обрезая картинку от них не избавиться на любом разрешении.
2. полоски, рисуемые плеером при несоответствии пропорций видео с пропорциями монитора, чтобы избежать искажений.
   Для обрезания лишнего ИМХО лучше снимать в чуть большем разрешении, и делать ему crop до разрешения итогового видео. Типа снимаешь в 12801024, а видео делаешь 1280800 - обрезаемого хватит как раз на чат/эквип.

<!-- m --><a class="postlink" href="http://openfile.ru/505535/">http://openfile.ru/505535/</a><!-- m -->

Хм, у меня в mplayerc нормально св-ва потока отображаются...
Video: MPEG4 Video (H264) 1024x768 30.00fps [GPAC ISO Video Handler]
Audio: MPEG Audio Layer 3 44100Hz stereo 192Kbps [GPAC ISO Audio Handler] >! General

! Format : MPEG-4
! Format profile : Base Media
! Codec ID : isom
! File size : 286 MiB
! Duration : 14mn 6s
! Overall bit rate : 2 836 Kbps
! Encoded date : UTC 2010-01-16 21:29:43
! Tagged date : UTC 2010-01-16 21:29:43
! Writing application : Yamb 2.1.0.0 [http://yamb.unite-video.com]
!
! Video
! ID : 1
! Format : AVC
! Format/Info : Advanced Video Codec
! Format profile : High@L4.1
! Format settings, CABAC : Yes
! Format settings, ReFrames : 3 frames
! Codec ID : avc1
! Codec ID/Info : Advanced Video Coding
! Duration : 14mn 6s
! Bit rate mode : Variable
! Bit rate : 2 641 Kbps
! Maximum bit rate : 6 535 Kbps
! Width : 1 024 pixels
! Height : 768 pixels
! Display aspect ratio : 4/3
! Frame rate mode : Constant
! Frame rate : 30.000 fps
! Resolution : 24 bits
! Colorimetry : 4:2:0
! Scan type : Progressive
! Bits/(Pixel*Frame) : 0.112
! Stream size : 266 MiB (93%)
! Writing library : x264 core 75 r1259 dd026f2
! Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=2641 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=20000 / vbv_bufsize=8000 / ip_ratio=1.40 / aq=1:1.00
! Encoded date : UTC 2010-01-16 20:34:16
! Tagged date : UTC 2010-01-16 21:29:58
!
! Audio
! ID : 2
! Format : MPEG Audio
! Format version : Version 1
! Format profile : Layer 3
! Codec ID : 6B
! Duration : 14mn 6s
! Bit rate mode : Constant
! Bit rate : 192 Kbps
! Maximum bit rate : 201 Kbps
! Channel(s) : 2 channels
! Sampling rate : 44.1 KHz
! Resolution : 16 bits
! Stream size : 19.4 MiB (7%)
! Encoded date : UTC 2010-01-16 21:29:57
! Tagged date : UTC 2010-01-16 21:29:58
!

50/60 исторически брались в телевидении исходя из частоты переменного тока в розетке, соответственно в Америке было 60 (302), у нас - 50(252). 24 - минимум, незаметный глазу (кино), 15 - просто экономия битрейта.

Сделай одинаковой глубину цвета РО (по умолчанию 16бит) и рабочего стола (по умолчанию 32бит). Т.е. либо в реестре увеличить для РО либо в св-вах экрана уменьшить для рабочего стола. Ну и разрешение должно быть одинаковым в случае полноэкранного режима.

-doss-
Параметр, на который умножается текущий деф замка при расчете дамага, по умолчанию 100%.
Даже при castle_defense_rate=99 и 100 дефа баррикада биться будет уже всем, впрочем настолько слабо, что теми же двумя пристами в браге отхиляется...
Какое значение посчитать адекватным - решать администрации.

@"Hypno-Damage":

@"Zeno":
Есть мысль, что именно так и будет. А еще возможно такое же будет с гвардами и растенями химиков из гильдии владельца замка.
Администрация считает, что так и должно быть и оставит этот момент без изменений? В стандартной еА так и есть.
В стандартной еафине есть замечательный параметр конфига castle_defense_rate, позволяющий избежать такой ситуации.

80 инт не означают отсутствия вит. Они означают только отсутствие 90+декс, что ИМХО не сильно критично. Ну и замесы как бы не только с атакующей стороны идут, в дефе мясо может непрерывно длиться дольше чем висит 5-й линк, не то что 1-2, да и "досрочно" рекаст линка тоже нужен - диспел / возврат после смерти. Не говоря уже про постоянное поддержание kaupe и kaite на всех союзниках в поле зрения.

Ну если подходить к линкеру, как к чару, который должен на респе что-то накастовать на всех и успокоится - то ты прав. А если линкер занимается активной поддержкой в мясе - инта нужна по любому. Не 99 как у пвм линкеров, конечено, но около 80 имхо быть должно...

Есть еще такое ИМХО - один линкер в поле не воин, в смысле что их должно быть минимум 2, чтоб линки друг другу кидать. А в этом случае ничто не мешает распределить остальные используемые линки между ними, прокачав до максимума. Вариант же кидания 1-х(да и 2-х тоже) линков/ка-магии безинтовым линкером вообще ни о чем, у профов есть намного более полезные занятия чем заливание сп каждые 3 секунды...