Апогей - воспроизведение видео

[b2m]

программа на КР580 попросту копирует сразу в видеопамять

При воспроизведении видео давно уже используется разница с предыдущим кадром. Ключевые кадры (полные) записываются, когда изменений много. Я думаю, тут можно раз в 10 ускорить, не меняя SD-интерфейс.

[Advertiser]

[hitomi2500]

При воспроизведении видео давно уже используется разница с предыдущим кадром. Ключевые кадры (полные) записываются, когда изменений много. Я думаю, тут можно раз в 10 ускорить, не меняя SD-интерфейс.

Про ключевые кадры я как-то даже не подумал, спасибо. Конечно на ключевых кадрах будет тормозить, но если сделать буферизацию, то есть шансы выйти на более-менее равномерный поток.

Вопрос только в том, как кодировать дельту. Решения от взрослых кодеков не подойдут, каждый такт на счету. Первое что мне приходит в голову это проверять дельту по строкам и по столбцам, и передавать только нужные строки/столбцы с битовой картой, для столбцов это всего 8 байт, для строк 7. Надо будет попробовать.

[b2m]

Вопрос только в том, как кодировать дельту.

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

[hitomi2500]

Самое простое - смещение,длина,данные. .

Это будет хорошо работать при относительно малом числе изменений, но если их много, и они по 1-2 символа, на обрамление больше уйдёт, чем на данные. Хотя вариант со строками не лучше себя поведёт. Думаю что все указанные подходы можно объединить, и при кодировании совмещать их так, чтобы получить минимальный размер кадра (и неплохо бы ещё оптимизацию по тактам КР580 сделать, если получится).

Время можно синхронизировать с одним из каналов таймера (если запрограммировать на режим делитель частоты, а частоту самую низкую выбрать, думаю слышно не будет).

За идею спасибо, если получится поток разогнать до приемлемого, видимо так и сделаю.

[b2m]

если их много, и они по 1-2 символа, на обрамление больше уйдёт, чем на данные

А как тебе такой вариант для дельты:
- перед каждой группой теоретически изменённых 512 байт идёт один байт, показывающий, было ли изменение в подгруппе из 64 байт (т.е. один байт на 512 байт данных)
- если изменений в подгруппе нет, то её и в потоке нет, а если есть, то перед подгруппой опять байт, показывающий, было ли изменение в подподгруппе из 8 байт (один байт на 64 байта данных), ну и наконец перед самими байтами данных (один байт на 8 байт данных)
То есть такая 3х уровневая битовая карта наличия данных. Ключевой кадр, конечно же, без карты, только данные. Можно ограничиться 2х уровневой картой для дельты, но тогда на весь кадр будет минимум 60 байт, даже если ничего не изменилось, а с 3х уровневой всего 8.

- - - Добавлено - - -

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

- - - Добавлено - - -

Кстати, плюс этого метода ещё в том, что можно поделить видео на чётные и нечётные кадры, и формировать поток отдельно для чётных и нечётных кадров. "Битрейт" упадёт в 2 раза.

- - - Добавлено - - -

Не то хотел сказать: для чётных и нечётных байт!

- - - Добавлено - - -

Вобщем в чётном кадре чётные байты, и наоборот. Тогда и служебных байт будет в 2 раза меньше.

[hitomi2500]

Если всего два цвета, то достаточно смещения и длины.

Даже если исходное видео было бы оптимизировано под такой подход, для трансформации в псевдографику пришлось бы сильно напрягать КР580.

- перед каждой группой теоретически изменённых 512 байт идёт один байт, показывающий, было ли изменение в подгруппе из 64 байт...

Бинарное дерево это дельная мысль. Оптимальней конечно бы разбить кадр на двумерные кусочки, но сколько это сожрёт на декодировании боюсь представить. Проще работать с одномерным представлением.

Кстати, плюс этого метода ещё в том, что можно поделить видео на чётные и нечётные кадры, и формировать поток отдельно для чётных и нечётных кадров. "Битрейт" упадёт в 2 раза.

А интерлейсинг это ещё более дельная мысль. Правда артефакты будут видны, минимальный блок всё-таки 3х2, но экономия налицо. Опять же, на стадии упаковки можно задать порог, и если артефакты интерлейсинга сильно выпирают, давать прогрессивный кадр.

Ещё около 15% можно (и нужно) сэкономить на бордерах, которые пока для простоты были встроены в поток.

Может получиться весьма неплохое ускорение, если всё посчитать. Вечером доберусь до железа, поэкспериментирую.

[svofski]

Самое простое - смещение,длина,данные.

Если всего два цвета, то достаточно смещения и длины.

[ivagor]

Если всего два цвета, то достаточно смещения и длины.

Вряд ли целесообразно заморачиваться побитными изменениями, а на уровне байтов данные все же нужны.