portier/source/requirements.txt

django==5.0.2
django-registration>=3.1
django-bootstrap4
django-guardian
django-fontawesome-5
django-celery-beat
django-filter
django-ninja
django-cors-headers
django-types
celery>=5.3
gunicorn>=20
psycopg2-binary
requests
redis
maintenance: update to Django 5, Redis 7, Postgres 16, add dev SRS 2024-02-25 11:24:42 +01:00			`django==5.0.2`
add very basic login/logout forms, stream management forms 2020-04-29 18:48:23 +02:00			`django-registration>=3.1`
add stub portal app with 'work in progress' message; configure template system 2020-04-26 04:46:44 +02:00			`django-bootstrap4`
add object permissions with guardian; users only have access to their own streams/restreamconfigs 2020-05-01 12:38:57 +02:00			`django-guardian`
fontawesome5;interfont;local frontend resources;languages 2020-05-01 21:40:43 +02:00			`django-fontawesome-5`
implement active srs sync and celery reworks the entire logic how active streams are being tracked. instead of keeping a counter by listening only to srs callback hooks, portier will now actively scrape the http api of known srs nodes to retrieve information about all currently existing streams on a srs node. this prevents portier from being wrong about active stream counts due to drift, and allows us to show more information about stream data to users in the future, as the srs api will also expose information about used codecs, stream resolution and data rates as seen by srs itself. to implement this, the previous remains of celery have been made active again, and it is now required to run exactly one celery beat instance and one or more celery workers beside portier itself. these will make sure that every 5 seconds all srs nodes are actively being scraped, on top of the scrape that is triggered by every srs callback hook. this keeps the data always superfresh. the celery beat function allows us to implement cron-based automation for many other functions (restream, pull, etc) in the future as well, so it's okay to pull in something more heavy here rather than just using a system cron and executing a custom management command all the time. 2024-02-29 18:33:52 +01:00			`django-celery-beat`
add django-rest-framework basic implementation 2020-05-31 18:35:30 +02:00			`django-filter`
replace DRF with django-ninja 2024-03-17 21:02:41 +01:00			`django-ninja`
implement pulls 2024-04-01 16:27:31 +02:00			`django-cors-headers`
			`django-types`
implement active srs sync and celery reworks the entire logic how active streams are being tracked. instead of keeping a counter by listening only to srs callback hooks, portier will now actively scrape the http api of known srs nodes to retrieve information about all currently existing streams on a srs node. this prevents portier from being wrong about active stream counts due to drift, and allows us to show more information about stream data to users in the future, as the srs api will also expose information about used codecs, stream resolution and data rates as seen by srs itself. to implement this, the previous remains of celery have been made active again, and it is now required to run exactly one celery beat instance and one or more celery workers beside portier itself. these will make sure that every 5 seconds all srs nodes are actively being scraped, on top of the scrape that is triggered by every srs callback hook. this keeps the data always superfresh. the celery beat function allows us to implement cron-based automation for many other functions (restream, pull, etc) in the future as well, so it's okay to pull in something more heavy here rather than just using a system cron and executing a custom management command all the time. 2024-02-29 18:33:52 +01:00			`celery>=5.3`
			`gunicorn>=20`
			`psycopg2-binary`
			`requests`
implement pulls 2024-04-01 16:27:31 +02:00			`redis`