Важная информация

User Tag List

Страница 1 из 7 12345 ... ПоследняяПоследняя
Показано с 1 по 10 из 66

Тема: Апогей - воспроизведение видео

  1. #1
    Member Аватар для hitomi2500
    Регистрация
    05.10.2018
    Адрес
    г. Москва
    Сообщений
    48
    Благодарностей: 27
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию Апогей - воспроизведение видео

    Всем добрый день.

    ----------

    Последние рабочие сборки:
    Исходники кодера и декодера (плеера): https://github.com/hitomi2500/avi2pseudo
    Сборка кодера с видеофайлами : https://yadi.sk/d/n4C5_N8vzHGMnA

    Как это выглядит:
    Видео 1:https://www.youtube.com/watch?v=jTkKTztZx_I
    Видео 2:https://www.youtube.com/watch?v=CLyV-c9ORko
    Видео 3: (со знакогенератором РК) https://www.youtube.com/watch?v=qH7zHXyE41g

    ----------

    Вздумалось мне попробовать прикрутить к Апогею видеоплеер. В качестве носителя выбрана карта через SD-интерфейс Алексея Морозова (vinxru), потому как альтернатив попросту нет (либо я про них не знаю). Конвертер набросан на коленке в Qt, он формирует полные видеобуферы и записывает их в файл подряд, а программа на КР580 попросту копирует сразу в видеопамять. Используется штатный режим Алексея 3A с разрешением 75(64)х51, с дополнительным апогеевским знакогенератором получается 192х102. Размер видеобуфера 3840 байт. Для отображения "обычного" видео разрешения конечно маловато, но специфическое видео с малым количеством деталей и/или с силуэтами выглядит нормально.

    https://www.youtube.com/watch?v=vIcsYGBrFI4

    Основной проблемой, как и ожидалось, оказалась производительность. Скорость следования кадров порядка 1.5 Гц, т.е. средняя скорость приёма данных порядка 6 килобайт в секунду. Судя по моему беглому анализу кода, биос Алексея использует какие-то хендшейки с микроконтроллером. Для сравнения, скорость работы мониторовской "R" около 9 килобайт в секунду, в целом немногим больше.

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

    Судя по исходникам "R", она выставляет адрес, теоретически на этом можно сэкономить, но немного. Также можно многократно продублировать группу команд чтение порта - запись в память - инкремент, на этом можно ещё сэкономить. Возможно при этом рассинхронизируется микроконтроллер, пока непонятно.

    Может кто-нибудь сталкивался с задачей ускорения ввода в Апогей или другую машину из семейства?
    Последний раз редактировалось hitomi2500; 28.10.2018 в 00:11.

  2. Эти 3 пользователя(ей) поблагодарили hitomi2500 за это полезное сообщение:
    cy6 (31.10.2018), marinovsoft (08.10.2018), Ратмир (08.11.2018)

  3. #1
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  4. #2
    Guru
    Регистрация
    24.01.2008
    Адрес
    Уфа
    Сообщений
    3,324
    Благодарностей: 994
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  5. #3
    Member Аватар для hitomi2500
    Регистрация
    05.10.2018
    Адрес
    г. Москва
    Сообщений
    48
    Благодарностей: 27
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

  6. #4
    Guru
    Регистрация
    24.01.2008
    Адрес
    Уфа
    Сообщений
    3,324
    Благодарностей: 994
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  7. #5
    Member Аватар для hitomi2500
    Регистрация
    05.10.2018
    Адрес
    г. Москва
    Сообщений
    48
    Благодарностей: 27
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

  8. #6
    Guru Аватар для svofski
    Регистрация
    20.06.2007
    Адрес
    С.-Петербург
    Сообщений
    2,368
    Благодарностей: 825
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от b2m Посмотреть сообщение
    Самое простое - смещение,длина,данные.
    Если всего два цвета, то достаточно смещения и длины.
    Больше игр нет

  9. #7
    Guru
    Регистрация
    07.08.2008
    Адрес
    г. Уфа
    Сообщений
    3,405
    Благодарностей: 1004
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от svofski Посмотреть сообщение
    Если всего два цвета, то достаточно смещения и длины.
    Вряд ли целесообразно заморачиваться побитными изменениями, а на уровне байтов данные все же нужны.

  10. #8
    Guru
    Регистрация
    24.01.2008
    Адрес
    Уфа
    Сообщений
    3,324
    Благодарностей: 994
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

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

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

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

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

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

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

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

  11. #9
    Member Аватар для hitomi2500
    Регистрация
    05.10.2018
    Адрес
    г. Москва
    Сообщений
    48
    Благодарностей: 27
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

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

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

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

  12. #10
    Member Аватар для hitomi2500
    Регистрация
    05.10.2018
    Адрес
    г. Москва
    Сообщений
    48
    Благодарностей: 27
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Ради статистики решил проверить размер дельты в Bad Apple (видео так называется), средняя дельта равна примерно половине кадра (1964 байта), если считать по псевдографике. Это многовато, особенно учитывая что на представление такой большой дельты уйдёт ещё куча обрамления. Видимо на предобработке надо добавить какие-то пространственные и временные сглаживающие фильтры, чтобы сузить спектр сигнала, тогда потеряются мелкие детали, но дельта должна сильно уменьшиться.
    Нажмите на изображение для увеличения. 

Название:	bad_apple_delta.jpg 
Просмотров:	91 
Размер:	20.8 Кб 
ID:	66519

Страница 1 из 7 12345 ... ПоследняяПоследняя

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Ответов: 17
    Последнее: 09.06.2018, 12:21
  2. Апогей-БК01 и Апогей-БК01Ц: Обсуждение
    от Mick в разделе Радио-86РК
    Ответов: 344
    Последнее: 08.06.2018, 19:41
  3. Апогей-БК01 и Апогей-БК01Ц: Внешний ROM диск
    от vinxru в разделе Радио-86РК
    Ответов: 417
    Последнее: 07.06.2018, 14:39
  4. Апогей-БК01 и Апогей-БК01Ц: Ремонт
    от ROMка в разделе Радио-86РК
    Ответов: 171
    Последнее: 01.10.2016, 14:20
  5. Апогей-БК01: Доработка до Апогей-БК01Ц
    от vinxru в разделе Радио-86РК
    Ответов: 14
    Последнее: 30.04.2012, 08:50

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •