Daniel5555

I enjoyed reading your post. Thank you so much for it. I haven't seen this done before with this game, so it was really interesting. I played Dreamcast version using an emulator and I remember well how easy the battles with Angels were. They were kind of useless honestly. The little nude version of Rei was really weird design choice from my point of view. I guess it was supposed to be cute, but I'm not sure it worked :)

Долго придется ждать. До двадцатого года все забито. Да и вроде у Дауни контракт в очередной раз закончился и он его не продлил. Не факт, что увидим его вообще) Я не особо слежу за новостями, но вроде как у Marvell планируется использовать одну и ту же команду до конца "Мстителей". Вроде как в планах не было фильма про Iron Man'а, но я почему-то всегда предполагал, что он полюбому будет. Хотя сейчас читаю про Дауни, я так понимаю, что он не хочет больше сниматься в этой роли... Это у него, наверное, синдром Birdman'а (ну, вы смотрели этот фильм, я надеюсь?). Хотя последние новости, похоже, говорят про четвертую часть: http://www.ew.com/article/2014/10/07/iron-man-4-robert-downey , но ничего конкретного.

Да, третий. Протупил малость. Я просто про Iron man'а смотрел только этот третий фильм, первый и второй не смотрел еще. У него самая длинная серия фильмов, поэтому я почему-то решил, что их три уже вышло до того, как я посмотрел последний фильм. Да, я тоже его жду со скепсисом. С другой стороны, Марвел сейчас плохого не снимает и уже долгое время... Так что должно выйти что-то хорошее, но вот как про такого героя можно интересно снять, для меня тоже вопрос.

Я не разбираюсь в фазах, но по-моему все фильмы между "большими" с командой были вполне себе ничего. Может и не шедевры, но как хорошие экшены "Тор 1"/"Тор 2", "Железный человек 4", все фильмы про Капитана Америку, меня очень даже порадовали. А вообще он присутствует в фильме в каком-либо качестве?

С нетерпением жду этого фильма. В Испании он выйдет на следующей неделе. Вообще у меня лично возникали раньше определенные сомнения по поводу сюжета: гражданская война с участием Капитана Америки против Железного Человека в комиксах, это, гм, полная лажа. С другой стороны, они не берут сюжеты целиком из комиксов, а очень сильно их меняют, что, в данном случае, ну просто отлично. Посмотрим. Я думаю сделать плохой фильм они в принципе не могут, так что все будет отлично. Ну и вообще я влюблен в этот сериал с того момента, как я посмотрел первого "Тора". Даже завидуешь современным детям... Хотя не, своих героев я бы все равно не поменял.

Сейчас я, наконец-то, напишу вторую часть списка моих размышлений по поводу того, как можно улучшить систему образования. Все никак руки не доходили. 13. В рамках изучения иностранного языка, а так же в целом изучения мира, должна быть введена программа обмена учащимися с другими странами. Естественно, что это стоит недешево, поэтому доступна она будет далеко не всем, а только наилучшим ученикам. Чтобы обеспечить более-менее равные шансы, должно быть несколько квот, например для учащихся столиц, учащихся в регионах, и учащихся в сельской местности (не именно три квоты на всю страну, квоты должны зависить от количества населения в регионе и других параметров). Между собой они не должны конкурировать. В идеале у каждого должен быть шанс попасть в участники этой программы. Чем больше стран будет задействовано, тем лучше. В случае России, скорее всего, кандидатами номер один будут Китай и страны СНГ, но, в принципе, там могут быть и США, и Япония, и что угодно. Вообще такие программы уже есть на уровне отдельных школ, даже есть обмен с той же Японией, но это все их собственные инициативы. Должна быть инициатива на национальном уровне. Находясь за рубежом, школьники должны жить в комфортных условиях, обучаться с местными или в международной группе (в зависимости от изучаемого языка, например если это английский и страна англоязычная, то необходимо учиться с местными плюс будет еще пара-тройка "обменных", если страна не англоязычная, то в междунардоной группе). Необходимо, чтобы они не только учились там, но и имели возможность отдохнуть там во время каникул, ну и, конечно, чтобы была культурная программа. Эта инициатива так же должна поднять престиж тех, кто хорошо учится. Им будет, что показать и о чем рассказать по возвращении. 14. Но ездить за рубеж это, конечно, одно. А между тем, конкретно в случае России, могла бы иметь не меньший успех другая инициатива - обмен не с зарубежными школами, а внутренний по стране. Я не знаю почему, но я наблюдаю такую ситуцию в последнее время, что многие россияне не знают собственной страны, особенно москвичи и питерцы. Они, бывает, лучше знают Европу или какой-нибудь Тайланд, чем российские регионы. А в России, между тем, полно интересного, поэтому было бы здорово, если бы некоторые школьники могли часть учебного года проучиться вдалеке от родного города, а заодно пообщаться с местными, посетить местные достопримечательности, ведущие научные центры и так далее. Естественно, что это было бы гораздо доступнее, чем поездка за рубеж. В идеале, любой хорошист должен претендовать на участие в такой программе. 15. Опять же, в рамках изучения иностранного языка. Не всех можно отправить за рубеж, но можно сделать совместную практику со школьниками из других стран. Например, необходимо написать совместную работу, причем это можно сделать только совместно, так как у каждого своя специализация. Непосредственно совместная работа происходит через общение в скайпе, е-мейлы, чаты, и так далее. Опять же, это популярный способ работы во многих фирмах, где уже обычное дело регулярно говорить с коллегами, находящимися на другом конце света. От этого есть целых два положительных эффекта: Во-первых, практикуется язык и совместная работа с малознакомыми людьми с совершенно другим бэкграундом. Во-вторых, благодаря этому, скажем, европейцы смогли бы воочию убедиться, что русские это не одни алкаши и коммунисты, а русские что европейцы не все пидоры. Естественно, если общение понравится и выяснится, что есть общие интересы, никто не запрещает продолжить общение уже после практики. 16. Продолжение пункта 11 первой части списка. Должен быть новый предмет о науке в целом, я бы его назвал "Фундамент науки". Его смысл заключается в том, чтобы объяснить нынешнее состояние человеческих знаний в целом и научный метод. Конкретнее, это должен быть предмет, который дает основу вообще во всем (математика, физика, химия, биология, астрономия) для всех (то есть он обязательный), но на популярном уровне. Иначе говоря, там должны давать концепты, но не должны "мучить" школьников математикой. Формулы и выведения должны быть представлены, но у школьников ни в какой момент не должны требовать непосредсвенно вывести что-то из формулы или провести расчет. Достаточно просто показать, что из этого выходит вот это и это логично обоснованно, но не обязательно раскрывать детали. Такая постановка предмета должна сделать его доступным для абсолютно всех и в тоже время позволит внести в него основы всего или почти всего. Более конкретно (то есть уже с деталями) эти знания будут раскрыты на других предметах, часть из которых обязательные (математика, физика, биология), а часть опциональные (химия, астрономия, и так далее). 17. Должен быть предмет, который раскрывает такую тему, как медицина, но не с той точки зрения, чтобы быть врачом, а чтобы быть правильным пациентом, то есть знать основы, уметь правильно описать свои симптомы и знать вообще, как работает медицина и мед. учреждения. Как показывает практика и уже регулярно происжодящие медийные "пандемии", тема медицины является очень актуальной и будет являться в дальнейшем. Так же я считаю, хотя это весьма спорно, что в рамках этого предмета перед школьниками должен быть поставлен вопрос ценности жизни. К сожалению, очень многие люди мало задумываются о смерти и вообще о крайне ограниченном сроке нашего общего существования. Задумываются об этом тогда, когда узнают, что кто-то в 15 лет болеет неизлечимой болезнью или в других подобных случаях, но не тогда, когда все еще здоровы и делают необдуманные решения по поводу своей дальнейшей жизни. Конечно, никаких ответов давать не надо, но я думаю, что об этом будет полезно подумать, особенно в рамках отношения к другим людям. Пока это все :)

Именно. Стандарт перекладывает эти разбиения на плечи компилятора. В случае if(pointer && pointer->bool) постоянное вычесление правого значения это постоянное разменовывание разыменовывание NULL. С учетом того, что это общеупотребительный прием сомневаюсь, что это оптимизируется Это не должно оптимизироваться, конечно. Обычные компиляторы всегда будут выдавать две развилки здесь. Но есть исключения, о которых я уже говорил :)

В стандарте С++ заявлено что правое выражение не вычисляется если левое ложно, что имеет смысл так позволяет не разбивать 1 проверку в несколько вложенных условий. Гарантированное же вычисление особых плюшек не дает Ты что-то все путаешь. Если применять со 100% соответствием C++ (и C) стандарты, то во всех проверках, где более одного условия, будет несколько инструкций типа JE на уровне ассемблера. То есть, if (condition1 and condition2) { ... эквивалентно if (condition1) { if (condition2) { ... в ассемблере всегда. Это выглядит приблизительно так: cmpq $0, -8(%rbp) je .L2 movq -8(%rbp), %rax movl (%rax), %eax cmpl $5, %eax jle .L2 Но компиляторы (в том числе gcc) не всегда это делают, чтобы избежать неверных предсказаний на каждой развилке. Эффект от неверного предсказания чувствительный. Если условие оценивается пару раз в коде - то да, конечно его не заметишь, но если это происходит миллионы раз и с достаточным количеством неверных предсказаний, то ситуация уже будет совсем другой. Вот здесь компилятор провел оптимизацию в обход стандарта: http://stackoverflow.com/questions/7355414/short-circuiting-on-boolean-operands-without-side-effects Что касается моего предыдущего поста - есть особо одаренные компиляторы, а так же процессоры, которые позволяют это делать постоянно, в обход не только стандарта C, но и норм архитектуры.

Я бы не назвал это хаком по определению. Это скорее средства улучшить картинку, в которых нет ничего грязного, разве что утверждается, что метод отрисовки совершенно другой. Тогда о чем разговор вообще? Мы и говорим, что сейчас (да и тогда) компьютеры были мощнее, чем next-gen консоли и эту разницу в мощности железа никакие оптимизации уже не перекроют. Остальное уже вопрос кому что больше нравится, что выгоднее, что удобнее и так далее.

Причем тут семейства видеокарт? Есть изначально кросс-платформенные игры, есть оптимизированные для приставок и есть оптимизированные для ПК. Дальше этого идти не нужно. Хотя, можно, конечно, оптимизировать для AMD и NVIDIA, и глубже, но в это необязательно лезть. Аналогичная система это компьютер с 8 гигабайтами памяти и видеокартой среднего уровня. Как говорил Вейдер, это зависит. Но вообще вряд ли. GTA V на ПК с видеокартой среднего уровня (GTX 960 2GB) выдает почти в 2 раза больше FPS, чем PS4 на таких же настройках (52 средних против 30 средних - http://www.gamersnexus.net/game-bench/1905-gta-v-pc-fps-benchmark-graphics-cards ). Это не 15-20%. Я не знаю этих игр и вообще я мало что знаю об играх сейчас. Но ты, в любом случае, сравниваешь ПК в виде консоли против просто ПК. Там нет никакой особой разницы, кроме того, что нынешний средний игровой ПК мощнее. Если это консольные эксклюзивы, их можно было бы портировать без потерь на ПК. Если есть ПК версии, они либо идентичные, либо в них выше FPS. Никаких грязных хаков сейчас не должны вносить в принципе. Сейчас не времена NES. Если кто-то вносит грязные хаки для чего-то, то это что-то банально плохо спроектировано. Все необходимое для использования особенностей архитектуры консолей должно быть в API операционной системы/драйверов. Ну и выигрыш сейчас от хаков такого типа минимален, разве что API кошмарное. Компьютер с 8 гигабайтами памяти и видеокартой уровня GTX760 с 4 гигабайтами памяти. Стоимость где-то около 650€ (если брать недорогой процессор и диск) против 370€ PS4.

Да, это действительно так. Я неверно выразился :)

Это не всегда можно сделать. Пример:if(p && p->field) Я думаю, что это можно сделать технически, но это не имеет смысла в конктексте стандартов и современных операционных систем. Нормальный компилятор, конечно, будет оценивать по отдельности переменные в выражениях такого типа. Некоторые процессоры позволяют исполнять на себе код с включенным branch prediction и выключенным MMU. В таком случае, если компилятор оценит обе переменные, то это не вызовет segmentation fault :)

Архитектурно приставки нового поколения идентичны ПК, так что их можно сравнивать напрямую. Правда, оптимизация для них есть - например, GDDR-память (она обычно стоит в видеокартах) не такая, как обычная DDR (обычная оперативная память), она способна быстро передавать большие блоки данных, но у нее проблемы с маленькими блоками, поэтому она лучше подходит для прорисовки графики (но хуже подходит для общих задач, для которых используется обычная оперативная память). За счет этих небольших архитектурных различий приставки несколько быстрее в отдельных конкретных случаях, чем компьютеры аналогичной конфигурации. Возможно это объясняет проблемы с портированием некоторых игр - менеджер GDDR памяти нельзя использовать на DDR, это будет жутко неэффективно. Тоже самое происходит с 32-мегабайтовым кэшем - в определенных ситуациях эти архитектурные добавления дают очень заметный прирост к производительности. Но вообще это особой погоды не делает и конкретно у этих консолей гораздо меньше такого потенциала, чем у консолей прошлого поколения. К тому же если оптимизировать программу для ПК, то есть правильно убрать все то, что программно зависит от этих архитектурных улучшений, то с ростом мощности конкретного ПК будет достигнут такой же уровень производительности. Ну и все эти архитектурные решения имеют свои недостатки. Использовать одно только GDDR (PS4) вместо DDR + GDDR (XO) может сильно ограничить некоторые игры в плане использования оперативной памяти, хотя для графики такой вариант сильнее, чем XO. Но они оба слабее, чем ПК с 8 гигабайтами DDR и топовой видеокартой, причем в разы. Операционные системы там используются вполне общего назначения. На XO Windows, на PS4 - BSD. Они мало чем отличаются в плане архитектуры от обычных систем. У них просто отсутствуют многие сервисы, там работает гораздо меньше задач и там, явно, специализированные драйвера. Это тоже поднимает производительность системы для игр, но вряд ли существенно. В целом, уже сейчас на топовых ПК графика лучше, чем на этих консолях и на ранних демонстрациях игры работали на ПК, а не на реальном железе. Так что архитектурно они полностью совместимы и портирование должно быть простым (хотя в случае с PS4 там больше проблем, чем с XO, но нет ничего особенного, в отличии от PS3).

Сами космонавты и не слышат никогда абсолютной тишины. Всегда на фоне есть какие-то работающие приборы и прочее. В художественном смысле да, могла бы быть тишина, но именно реалистичности бы это вряд ли добавило.

Большую часть фильмов снимают в формате 2.40-2.35:1. Это исторически киношный формат, с которого никто не хочет слезать, и почти все студийные фильмы сняты именно в нем. Например, последние три фильма, которые я смотрел - Chappie, Ex-machina, Fast and furious 7, все сняты в 2.35:1. Всякие там Хоббиты, Мстители и прочие, тоже сняты в 2.35:1. Есть фильмы, снятые в формате 1.85:1, который стоит близко к стандарту 16:9 (стандарту для компьютеров и телевиденья), типа Pacific Rim, но это скорее исключение, а не правило.

Поздравляю! Ощущение должно быть невероятное, конечно)

Да похоже с оптимизацией накосячил гдето в подсознании обобщив логическую оптимизацию до арифмитической. Но это не отменяет тот факт, что через такое умножение можно сделать неоптимальное ветвление :) Окей, только я, на всякий случай, уточню две вещи: 1. Оптимизацию делает компилятор, а не процессор. 2. Когда речь идет о простом коде, типа if (condition1 and (condition2 or condition3)) { ... } в таком случае, чаще всего, скомпилированный код такой, что (condition2 or condition3) исполняется всегда. Это происходит ради того, чтобы избежать все тех же неверных предсказаний. Если сделать отдельную оценку condition1 и переход на позицию после блока if в случае если condition1 равен falsе, то в итоге у нас получается, по сути, два блока if, которые будут видны в ассемблерe. Так как все процессоры сейчас преисполняют инструкции, то оптимальнее произвести оценку всех переменных, чем по отдельности condition1 и затем (condition2 or condition3), и получить сильную задержку в случае неверного предсказания результата оценки condition1.

Что такое "оптимизация умножения"? Если процессор встречает переменную равную нулю, которую нужно умножить на другую переменную, он просто выполнит умножение. Он не проверяет равна она нулю или нет, а ALU все равно, на что умножать, это операция занимает одинаковое время, независимо от значений переменных. Компилятор если видит, что часть кода не может быть исполнена, вроде if (false) { ... } , скорее всего, уберет целиком блок и выставит warning. Еще если есть выражение вида if (condition1 and (condition2 or (getCondition3())) { ... } , то скомпилированный код не будет исполнять "(condition2 or (getCondition3())" если condition1 равно false, но это зависит от настроек оптимизации. В коде рекомендуется использовать поменьше if-else, потому что это позволяет избежать потери времени в случае неверного предсказания того, какой блок будет исполняться (из-за досрочного исполнения инструкций, это происходит в обычных процессорах) и это иногда позволяет немного уменьшить размер кода, если это критично. Но это почти никак не влияет на проблему, которую я описал. Для видеокарт в одном блоке все ядра вынуждены выполнять одну и ту же инструкцию. Разница только в том, имеет ли ценность ее результат, и в качестве переменных используются локальные переменные на уровне ядра. Еще имеется небольшая задержка для изменения контекста ядра (при переходе из if в else), но она не должна играть роли на современных видеокартах.

Для этого есть замечательный сервис:http://screenshotcomparison.com/comparison/121009 http://screenshotcomparison.com/comparison/121011 Спасибо, не знал о нем)

Я сделал версию с CRF=28 с того же оригинала и такими же параметрами, какие представлены в первом посте: ref=6:bframes=5:b-adapt=2:direct=auto:me=tesa:subme=10:merange=64:analyse=all:trellis=2:no-dct-decimate=1 Размер файла составляет 140 мегабайт. Линк: https://mega.co.nz/#!thcRULha!jSOhBuE0GHHmVn537QhEoT_CP6c4gDLgDNWv8pD45WU Как и ожидалось, там есть падение качества за счет уменьшения размера, однако меня удивило качество видео в движении. Разница заметна, но не настолько чтобы понять, что размер видео уменьшился на половину. Этот результат весьма интересен. Обычно CRF рекомендуют в значениях от 28 до 18. Эмпирически, у меня есть ощущение, что CRF=23 должно хватать любому видео, но мне нужно проверить с оригиналом гораздо лучшего качества, чем мой нынешний. Разница между видео в скриншотах: Скорее всего, CRF=23 для моего оригинала это слишком много из-за его низкого качества. По логике, скорее всего следующий тест следует провести с CRF=25, но было бы интересно посмотреть на разницу во всех вариантах между CRF=23 и CRF=28. Если у кого-то есть время и/или мощный процессор, был бы признателен. в контексте вычислений это на самом деле не проблема result = condition * (...) + !condition * (...) стандартная задачка для собеседований) Аюп там перед одной скобкой умножение на 0 всегда, выражение в скобках вычисляться не будет. Это какая-то ерунда. В блоках ядер видеокарт они все исполняют одну и ту же инструкцию в один момент времени. У них нет отдельного планировщика на ядро, только на целый блок. Более конкретно, если имеется код вида if (array[threadIdx.x] > 10) { ... } else { ... } Если блок состоит из 32 ядер и array[0..15] содержит числа >10, а п array[16..31] числа =<10, весь блок ядер выполнит как вариант if, так и блок else. Половина блока ядер выполнит по-настоящему инструкции блока if, в то время как другая половина выполнит те же самые инструкции, просто их результат будет автоматически выброшен. Затем тоже самое произойдет с блоком else. В твоем варианте result = (array[threadIdx.x] > 10)*(...) + (!(array[threadIdx.x] > 10))*(...) произойдет тоже самое. Все ядра выполнят все инструкции, просто они выполнят умножение на ноль в первой или во второй части.

В испанских мейнстримовых магазинах есть. Насчет России не знаю. Вот, если интересно: http://www.amazon.co.uk/Hannspree-SNNPDI1B-Quadcore-1-83GHz-Windows/dp/B00S655KPG/ref=sr_1_1?s=computers&ie=UTF8&qid=1428443282&sr=1-1&keywords=Hannspree Еще под маркой MeeGo его продают.

Процессор 64-битный. Система, может, и нет, но ее можно переустановить.

Девайс очень интересный, только, к сожалению, все никак не выйдет в продажу. Он еще в марте должен был. Если кому-то очень надо, то уже есть китайские копии, которые почти идентичные по характеристикам, тоже с Windows 8.

Идиоты. С такой ерундой весь процесс должен быть: зашел-вышел. Какая еще запись? Идиотизм. Что касается ушей, я не знаю как в России, но в Испании продают такие замечательные штуки: Очень сильный затор, они, возможно, и не пробьют, но если их применять регулярно, а для этого их и делали, то вероятность возникновения такого затора равна нулю. Посмотри в аптеках. Это должно решить эту проблему.

Это нужно проверять на практике. Но, с моей точки зрения, от многопроходного кодирования со строгим анализом пользы нет. По сути по время первого прохода алгоритм грубо прикидывает, сколько информации нужно выделить какой сцене, то есть он задает аналог CRF. Второй проход просто кодирует видео используя этот параметр с теми настройками анализа, которые были заданы пользователем. В моем случае CRF задает сам пользователь. Если CRF задан плохо, то от этого будут проблемы, но если CRF задает компьютер, то это тоже не будет идеальным вариантом (к тому же пользователь все равно задаст лимит, просто это будет битрейт вместо CRF). Если же проход только один и анализ строгий, то он будет анализировать достаточное число кадров и достаточно хорошо, чтобы прийти к таким же результатам, как при двухпроходном варианте. Причем однопроходной вариант при этом будет быстрее, если настройки анализа такие же, так как мы не тратим время на первый проход, который всего лишь задает аналог CRF. Трехпроходной анализ, естественно, тем более не имеет смысла. Loren Merritt писал уже много лет назад (в 2007 вроде) на форумах, что, вообще говоря, в итоге (по состоянию результата) нет разницы между двухпроходным и однопроходным кодированием. Это просто два разных подхода, через которые можно прийти к одним и тем же результатам. В итоге, вроде как, получается что однопроходной вариант является самым разумным, хотя в то время сторонников двухпроходного кодирования было больше. Не знаю, как сейчас. Причем тогда x264 не был таким хорошим, как сейчас. Сейчас у них анализ гораздо более строгий и эффективный. Я слышал об этом, но я не видел результатов. Если это так, то у меня есть две версии на этот счет: 1. Это связано не столько с софтом, сколько с ограничением оборудования. Ядра видеокарт являются очень простыми по сравнению с ядрами процессоров. Их очень много и поэтому они хороши в некоторых задачах, но анализ видео, скорее всего, для них является слишком сложной задачей. Например, для видеокарт не существует flow control на уровне отдельного ядра, только на уровне блока. То есть если имеется код типа if (condition) { ... } else { ... } То весь блок произведет операции находящиеся как в if, так и в else, если есть хоть одно ядро в треде у которого значение condition отличается от значения в тредах других ядер. Возможно, что даже если такого треда нет, то блок все равно будет исполнен. У этих ядер очень маленький кэш и так далее. То есть, когда говорят про низкое качество кодирования, я думаю в первую очередь об архитектурных ограничениях видеокарт. Одно дело просто умножить две матрицы, и другое дело это проводить сложный анализ достаточно большой структуры. Видеокарты хорошо служат для быстрого кодирования видео, но вряд ли они хорошо служат для кодирования с высоким качеством. Хотя я не знаю нынешней ситуации, возможно это поменялось. 2. Можно вспомнить ту самую формулу, которая гласит, что с увеличением числа процессоров падает качество, но по-моему это ерунда, если честно. Это зависит от настроек энкодера, то есть с какими настройками алгоритма был скодирован файл. Например, мои настройки создают файлы, которые, насколько я знаю, не совместимы с Apple TV. Я точно не помню почему, но, в качестве примера, у специализированного устройства, будь то телек, или какая-нибудь приставка, может быть лимит на ref=3, то есть если этих reference фреймов в видео больше, то оно не сможет его раскодировать, потому что у него недостаточно памяти или еще по какой причине. Если я кодирую с ref=6, то не означает автоматически, что там будет именно 6 reference фреймов, так как алгоритм всегда старается сделать, чтоб их было как можно меньше, так что, в зависимости от видео, может и не будет нигде ситуации, где reference фреймов будет больше 3, и тогда файл будет совместим. Но если окажется, что их будет больше, а так, скорее всего, и будет, то файл будет нечитаемым на таком устройстве. Для компьютеров это неактуально, так как у нас универсальные и достаточно мощные процессоры, и много памяти, так что все упирается в софт. Для телеков и других устройств обычно существуют строгие ограничения на то, как именно должен быть сделан файл для того, что гарантировать его воспроизведение. Кодек при этом один и тот же, так как кодек это просто спецификация того, что есть и может быть в файле (что такое все эти reference фреймы и прочее), но конкретное количество задается про создании файла и в итоге файл может быть как очень простым, так и очень сложным по структуре (и, соответственно, разным по качеству и агрессивности сжатия).