О прогрессиве, флагах и CCE

Да, конечно, возможно и такое. Но только в случае интегрированной системы, когда декодер знает, что именно стоит за ним в цепочке обработки, и что у него есть возможность работать быстрее реального времени.
А стандарт MPEG-2 прямо говорит, что он не содержит никаких предписаний насчёт того, что должно происходить с данными, выданными декодером.
И этот же стандарт указывает, с какой частотой декодер должен выдавать данные в буфер.
Представим себя на месте разработчика микросхемы - декодера MPEG-2. Просто автономного декодера, работающего по стандарту и не привязанного к какому-либо конкретному последующему железу. Как поступить: выдавать вовремя очередное поле и не трогать это место буфера в течение 1/50 секунды, чтобы стоящие дальше по конвейеру узла могли всё это время делать с данными то, что они хотят, или вознадеяться, что за 1/10000 секунды после выдачи данные будут перелиты в какое-то другое место и буфер опять станет полностью в нашем распоряжении?
(Между прочим, стандарт даже не нормирует время, за которое поле должно быть залито в буфер полностью. Там просто сказано, что поля должны выводиться с частотой, вдвое большей частоты кадров.) Но стандарт возлагает эту обязанность на декодер. (Там даже картинки есть, как оно должно выдаваться в зависимости от состояния разных флагов.) На аппаратном уровне для получения чересстрочной выдачи с прогрессивно заполненного буфера достаточно обменять местами два проводка. А для повторения одной и той же строки - один из этих проводков посадить навсегда на "0" (или на "1"). Потому и удивляет решение использовать для RFF кодирование не полями, а кадрами - потребность в памяти-то при этом в два раза больше. Напоминаю: выводить нужно поле, а чтобы его получить нужно кадр распаковывать. Если распаковываемый кадр никуда не записывать, а просто половину пикселов отправлять на выход, а половину терять, то потом для получения второго поля этот кадр опять распаковывать придётся. Это и потребность в производительности декодера удваивает, и требования к размеру буфера приёма увеличивает (кадр-то после первого декодирования из него удалять ещё нельзя). Программе передаётся именно буфер (со всем тем, что в нём содержится). Программы на современных компьютерах вообще имеют дело только с двумя сущностями: "порт ввода-вывода" и "область памяти". Работу программ захвата рассматривать не будем, а программы редактирования работают так: выделяют в памяти буфер определённого размера и говорят декодеру: "Распакуй сюда такой-то кадр" (способ указания, какой именно кадр распаковать, рассматривать тоже не будем). Декодер распаковывает. Но программа-то, чтобы потом с этим кадром работать, должна знать, что, где и как декодер в этом буфере расположил. Например, обнаружить пробелы или неточности в своих знаниях и представлениях. Разве не полезно? Во-первых, то, о чём я писал, к порядку следования кадров никакого отношения не имеет.
А во-вторых, Ваши соображения с равным успехом применимы и к этому самому порядку следования: при нынешней технике кадры вполне можно было бы передавать в порядке воспроизведения (возможностей декодеров вполне хватает, чтобы успевать распаковывать их вовремя). Но почему-то так не делают.

Не "возможно", а обязательно должно быть - в противном случае не получится устройство под названием DVD-плеер (невозможно прямо к буферу декодирования припаять несколько проводов и вывести это на RGB, композитный и звуковые "колокольчики").
Как Вы правильно заметили, задача декодера - декодировать. На декодирование одного кадра (двух полей) ему отводится максимум 1/30 сек (на самом деле меньше, так как ещё надо немного времени на прочтение этого буфера - скажем 10% от этой 1/30). Окончательное декодирование, зуммирование и прочая обработка с последующим переводом в аналог ложится на блок видеообрабоки и вывода. И вот единственное, что должно четко повторять движения луча по экрану - это аналоговые напряжения на контактах разъема, т.е. 100% синхронно передвижению луча должен работать ЦАП, а не декодер (декодирование же и цифровая видеобработка просто должны проходить со скоростью не менее 30 кадров в секунду). А вот для сглаживания "несинхронностей" цифровых алгоритмов внутри этой 1/30 память и нужна. В результате за 5/60 сек декодер успевает декодировать 2 кадра, а блок видеообработки и вывода прочитать, обработать и вывести на контакты аналоговые сигналы пяти полей... А то по Вашей "синхронной" логике получается, что как только декодер схавал первый байт нового кадра в Мпег2 и выплюнул первый байт результата, блок видеообработки уже должен начать что-то зуммировать, а луч уже что-то рисовать на экране...

Это шутка? Вы в курсе, почему для широкоэкранного варианта DVD было выбрано "16:9", а не что либо иное? (Ведь использовать реальный киношный формат кажется более логичным решением.) Ага. Но если ЦАП выбирает данные прямо из буфера декодера, то декодеру забегать вперёд него было бы весьма неосмотрительно. Вообще-то я писал, что в то время, пока из буфера выводится некая часть кадра, декодер может перезаписывать ту часть буфера, которая уже выведена, данными следующего кадра (т.е. идти не перед лучом, а за ним). Хотя Ваш вариант тоже технически возможно реализовать. Но уж слишком он чувствителен к задержкам доставки/обработки...

Т.е. блок видеообработки все преобразования (например, четырехкратный зумм) проводит в буфере декодера при том что полный кадр там присутствует в течении бесконечного малого промежутка времени, так как декодируется в реальном времени со скоростью движения луча? Откуда он узнает, о том, что будет в следующих "строчках", если они ещё "в реальном масштабе времени" не декодированы? Буфер декодера является единственной памятью, которую используют для своих нужд все, кому не лень? А как же тогда сам декодер будет им пользоваться? Что-то слишком много логических дыр и прямых противоречий описаниям плееров - устройство старых (только с аналоговыми выходами) DVD-плееров разных брендов описано в приведенной книге. Ни в одной модели такого не было указано. Напротив, говорится о наличии памяти, которая используется блоком видеобработки. И именно оттуда, а не из буфера декодера, выбирает данные ЦАП - например, оттуда он берет картинку меню плеера... Буфер декодера - он и есть буфер. Его главная цель - обеспечить бесперебойность снабжения данными блока видеообработки.
Т.е. Вы пытаетесь заставить работать бытовой DVD-плеер по системе JIT (с нулевым буфером), в то время как он работает по TOC (с кадровым буфером).

1. Эта функция в проигрывателе обязана быть?
2. Подобное увеличение (как и масштабирование до 16:9) отличается чрезвычайной простотой возможной аппаратной реализации - без затрагивания текущего содержимого буфера и без его копирования куда-либо (о качестве получающегося в этом случае результата говорить не будем).
3. Зачем зацикливаться на DVD-проигрывателях? Мы говорим об особенностях MPEG-2, а у него сфера применения чуть шире, чем DVD. И во времена, когда стандарт создавался, устройства воспроизведения разнообразной отсебятиной глаз зрителя не особо услаждали. Могу только отослать с своему предыдущему сообщению, где я особо отметил, что вся работа идёт с уже полностью декодированным изображением. Если "все" - это "все те, кто стоит в конвейере после декодера", то в простейшем случае - да, одного только этого буфера вполне достаточно. А как компьютер и видюшка умудряются одновременно пользоваться одной и той же памятью в случае UMA? (UMA, между прочим, используют все современные интегрированные в чипсет или процессор видюшки.) Я не пытаюсь. Напоминаю: стандарт MPEG-2 ничего не говорит о том, что будет происходить с содержимым буфера после того, как декодер его заполнил. Поэтому создатель декодера имеет право рассчитывать на худшее.

Речь не шла о том, чтобы из закодированного кадра выводить готовое поле.
Вы распаковкой называете декодирование? Может, мы разное имеем в виду под буфером? Я под буфером подразумеваю область памяти, в которую записывается полный декодированный кадр и из которой он затем выводится в оговоренной стандартом последовательности и периодичности. В этом смысле, в него действительно, нужно сначала записать декодированный кадр, а потом уже применить флаги, управляющие порядком вывода полей из него. Последовательность записи в такой буфер, конечно же отличается, от последовательности вывода (кадры на вход декодера поступают даже не в порядке показа). Но при декодировании в выходной буфер можно "распаковать" как поля, кодировавшиеся раздельно (field picture), так и кодировавшиеся в составе кадра (frame picture) - при PS=0.

В том конкретном месте речь шла именно об этом. Потому что обсуждался способ реализации RFF при наличии буфера только для одного кадра. Вы сказали, что в этом случае после повторного вывода поля первого кадра первое поле следующего кадра выводится "в поток". Да. Стандарт описывает наличие у декодера трёх буферов: два для опорных кадров (I- и P-) и один для текущего (распаковываемого в данный момент). Это как бы не запрещает иметь более одного буфера для "текущего кадра", но и не обязывает.

... и как тогда этот буфер подключать к ЦАП?
Я и говорю, что из описываемого Вами устройства А получится декодер, который только декодирует, то что закодировано (а закодировано 24 кадра). А потом это устройство надо подключить к другому устройству, которое превратит их в 60 полей. Хрен с ним с зуммом - подключим сразу к ЦАП и далее на разъем. Добавим в начало DVD-вертушку со своим буфером и получим устройство под названием "примитивный DVD-плеер". Только речь шла именно о DVD плеере и проблемах с "медленными" микросхемами декодеров, которым не хватает 1/60 сек, и дороговизной памяти...
Причем Вы постоянно прыгаете от устройства (пытаясь установить синхронность чтения мпег и "волнообразного" перезаписывания битов в буфер к движениям луча) к стандарту (в котором вряд ли прописана скорость прописывания отдельных битов в буфер).
Я так и не понимаю, почему не хватит времени на декодирование следующего кадра, если в буфере перед этим 1/60 секунды будет "висеть" одно поле предыдущего? То что там перед этим висело бы 1/30 секунды оба предыдущих поля (если бы не было вставленного интервала времени для повтора 1 поля) не мешало бы, а теперь будет мешать?

А в чём проблема? Ну, лежат там данные не в RGB или 4:4:4, а в 4:2:0 - так и ЦАП под это сконструирован. А что нам надо в простейшем случае? Декодер выдаёт данные в один из своих трёх буферов и переключает ЦАП на нужный буфер. ЦАП преобразует байты в аналоговый сигнал. Потом модулятор добавляет необходимые синхросигналы. Если нужно подать всё это на антенный вход - следом ставим ВЧ-модулятор. Всё, собственно. Преобразование в lettrebox/pan&scan/pillarbox элементарно реализуется прямо на ЦАП. Да, именно примитивный, но работающий. Так а если из-за отсутствия быстрых микросхем нет возможности реализовать более сложную обработку, то что ещё остаётся делать?
(Формат "16:9", а не более близкий к кинореалиям и тоже присутствующий в стандарте MPEG-2 "2,21:1", был выбран для DVD именно из-за возможности примитивной реализации letterbox.) Кто сказал, что 1/60 не хватит? Хватит. Но одно дело - распаковать за это время одно поле, а другое дело - распаковать за это же время целый кадр. Во втором случае объём работы вдвое больше, и, соответственно, нужна вдвое большая производительность процессора.
Писал чуть раньше: современных мощностей хватит, даже если кадры будут передаваться в порядке воспроизведения, а не "IPBB...". Но одно дело сейчас, а другое - начало 90-х годов.

Xpюша Так в конце 90-х (а не в начале) подобные узконаправленные процессоры демонстрировали в рамках своей функции на порядки более высокую производительность по сравнению с компьютерными. Не вижу особой проблемы - в конце 90-х мощи таких узкозаточенных процессоров должно было хватать. А даже если нет, то на первых DVD вполне мог быть исключительно хардтелесин без всяких флагов, а более качественный вариант в ширпотребе стал использоваться, когда подтянулось железо...
В любом случае разговор от "не рекомендуется ставить "прогрессивные настройки" и софт телесин" при изготовлении Кастом-раздач на рутрекере" ушел в "не рекомендуется ставить "прогрессивные настройки" и софт-телесин в 1997 году" под сомнительным предлогом нехватки в конце 90-х мощностей RISC процессоров для декодирования MPEG2. Пора завязывать...

Ну вот, и количество буферов размножилось, и порядок хранения уже имеет значения. Так правда и осталось непонятным, какое понимание может появиться от умозрительной дискуссии о состоянии электроники 20 лет назад. Именно так и было. Один из самых первых DVD, культовый "Blade runner", тихий ужос. Под названием "прогрессивный плеер". Разница в качестве воспроизведения фильмового материала была огромной, хотя эти флаговые плееры опять же были тихим ужосом по меркам сегодняшнего дня. Золотые слова. Инструкция из этой темы явно не проклюнется.