Видео фото рамка с большим экраном

Делаю для себя. Я пытаюсь подключить приятелей, но, пока не видят полуконечного результата сложновато.
я не зря писал в начале , что правами обладают автор/авторы.
Мне это коммерция с распространением не подходит , да и для широкой публики есть более вкусные разработки (облока, автообновления, управлением для включения тематического показа: природа, Ню, дети, абстракция, класика........ )
Есть проработки (закрытый код) с малым функционалом, а за денюжку широкий (в штатах).
Есть проработки с открытым кодом, но я не справлюсь с допиливанием...
За бугром эта тема вообще очень развита, видимо люди больше наслаждаются

понятно, что можно использовать готовое и это есть, но мне важно это (из ТЗ):
....Иметь возможность: остановить просмотр, вернуться ......., посмотреть файлы в тематической папке остановленного файла .....

 

Очень жаль, что модератор стер половину. На подобный вопрос отвечал развернутого. У всех свои тараканы

 

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

 

Одной малинкой здесь точно не обойтись.
Хотелки быстро появятся, так что , как уже писал, нужен еще один контроллер , а малинка должна заниматься только списком файлов и их воспроизведением , остальное делает другой контроллер и бросает малинке соответствующие команды, а малинка в свою очередь контроллеру. Вот так они дружно и живут.
Тема знакома, ищите программера на малинку , осталное на контроллере сделаю без проблем.
Могу подсказать , где взять готовое и в течении часа другого настроить систему , при условии что малинка уже понимает команды от контроллера. Или вместо малинки взять другой плеер, но там как правило нет управления файлами воспроизведения, а он для вас желателен.

 

Спасибо.С моей стороны хотелок не предвидится
Вопрос "новичка". Я понимаю, что нужны независимые процессы: просмотр, пульт, датчик, таймер сторожевик. Процессы должны посылать сигналы между собой. Вы хотите сказать, что процесс , например, от пульта будет жрать ресурсы и, например, видео будет дергаться?
Было давно, но раньше это решал прерываниями. Уверены, что в малинке этого нет?

 

Из описания
Механизм прерываний был добавлен в библиотеку RPi.GPIO начиная с версии 0.5.0а, появились новые доступные функции:
add_event_detect();

• remove_event_detect();
• add_event_callback();
• wait_for_edge().

Каждый пин GPIO в Raspberry Pi, установленный в режиме входа (input), может сконфигурирован как источник для вызова прерывания.

по крайней мере для Python и это есть
Threaded callback (обратная связь в потоке) - специальная функция, которая выполняется в отдельном потоке и следит за наступлением ожидаемого события. ( в функции осуществляется обратная связь (callback) и обмен данными между двумя потоками, причем работа программы в первом потоке не блокируется в момент выполнения функции во втором.)

 

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

 

Ни в коем случае я не собираюсь противоречить. Только собираю информацию. Любое предупреждение о подводных камнях важно.
У меня периодически появляется мысли привлечь студента для проверки его способностей перед принятием на работу. Вот и задачка для подразделения микроконтроллеров . Но я должен понимать уровень сложности перед постановкой задачи.

 

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

Раз хотелки появились после первой эксплуатации - они обязательно появятся и в этом случае.
А потом сюда добавится хотелка включения подсветкиили чето в этом роде. Знаем - проходили.

 

Механизм прерываний там всегда был. Rpi.GPIO - это тормознутое фуфло.
Но даже если прерывания обслуживать на сях (реализовано через обратные вызовы), то между событием на пине и вызовом обработчика этого события проходит целая вечность. Все из-за того, что ось на ядре Linux не является RTOS.

 

вставлю свои "5 копеек"
- в Raspberry Pi мощи очень много и со стабильностью тоже все норм - зачем второй контроллер для чего либо непонятно
- в Linux GPIO на C пишется достаточно просто, и даже если не хочется "прокладкой" (библиотекой) пользоваться, можно написать службу которая пины будет опрашивать, сам писал на orange PI опрос сигналов от домофона - сигналы менее 50 микросекунд очень даже легко отлавливаются, для совсем параноиков можно драйвер самостоятельно написать и в ядро воткнуть
- отображение на экран через драйвер не сложно написать, недавно закончил отображение на экран framebuffer картинок jpg с видеокамер наблюдения, закачивал с FTP сервера. И декодеров потоков с файлов видео под linux тоже полно в сети
P.S. За проект браться не собираюсь - скучно. И да, 50000 маловато за пару тройку месяцев работы.

 

С проигрыванием звуковых файлов с малинки - все в норме.
При воспроизведении видео: если просто скормить список воспроизведения плееру - то проблем нет.

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

 

и служба эта будет тупо греть процессор бесполезными вызовами.

 

Сами сначала попробуйте, а потом говорите что там греется

 

Пробовал.

 

Пока не нашел спеца, но пытаюсь самообразоваться. Даже начинает захватывать -)))
Изучаю питон.Изучаю взаимодействие потоков.
Выдел материалы, примеры, тестирования времени обработки прерываний (пульт, датчик движения..). В моей задаче нет очень строгих временных рамок. Судя по публикациям, пульт (стандартные библиотеки) обрабатывается достаточно быстро. С кодировками пультов вообще нет проблем.
Для датчика движения вполне пойдет запаздывание пары секунд.
Датчик освещенности (если оставлю в конструкции) можно вообще раз в десятки секунд опрашивать.
Пока каша с сигналами потокам. В питоне пока не все понятно с управлением потоками, передачей сигналов и значений. Например, отправил видео (пока тоже каша, куда...OpenCV?) > нажал пульт или пришло время заснуть по датчику движения> сбросить показ видео и уйти в диспетчер.
Очень боязно ошибиться со "скелетом" .
Спасибо, что начали обсуждать техническую сторону.

 

ParovoZZ , я видел в статьях тесты, где задержка обработки прерываний десятки миллисекунд. Это похоже на правду?
В статье https://blablacode.ru/yadro-linux/543 исследователь получил задержки, максимум 40 мксек

 

что-то в тесте ни слова о том, запущен ли у автора видеоролик?

 

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