State | Parked |
Date | 2007-06-04 |
Proposed by | ct |
DataBackend
Describe the DataBackend functionality.
Description
This just starts as braindump, I will refine it soon:
-
handle all files lumiera uses at runtime (media, edl, temp data)
-
manage filehandles, lumiera might use more more files than available filehandles
-
manage temporary data
-
do caching
-
io will be blocked where the backend tells the core where it can expect the data (not read()/write() like)
-
kindof garbage collector
-
do prefetching
-
no/low latency for the core the prefetcher and other things ensure that data is available in time
-
translate any input into a format which the lumiera core understands (demux, decode)
-
same for encoding to output formats
-
offer a plugin API for encoders/decoders
-
maybe network backend for serving data to distributed rendernodes
-
can do some load control or management (trigger adaptive rendering if system is idle etc)
-
pull based arch
-
ichthyo wrote also some ideas on Architecture and a sketch/draft about things possible in the middle layer
Parked
The underlying principles remain valid, yet development took another direction during the last years. Special frameworks for high-performance asynchronous IO will be used for dedicated use cases.
- Ichthyostega
-
2023-10-24 <prg@ichthyostega.de>
Comments
Sounds fairly complete to me — Ichthyostega
Developement takes place in the repo now — ct
Development took another direction over the last years; the former »Backend« layer is restructured — Ichthyostega
Back to Lumiera Design Process overview