blob: ef2ee41f59329e69da9697447694d797a0fdecf2 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
#pragma once
#include <al/types.h>
#include "handle.h"
#include "backing.h"
#include "handler.h"
/*
Types to consider:
- file
- http
- hls
- http index?
- archive
- cue + single file
- cue + multiple files
- dvd/bluray (drive or iso)
- live source (radio antenna)
- remote resource
Chapters:
- Potential resources with chapters:
- Single wav with cue.
- Multiple wav with cue.
- Single mp4 with chapters in metadata.
- DVD iso image.
- DVD/CD drive.
- Chapter as seek or node per chapter?
- Node per chapter definitely seems to make the most sense. Maybe we could
have a "ignore chapters" flag for single containers like mp4.
Other considerations:
- Chapter priority (disc drive)
- For now 1 user and 1 list owns the drive totally.
- Scan list from current down on order change to create priority.
- DVD's have a runtime
- We will minimially have to pass inputs to the handler.
- Resource has to support being networked at a point before a liana server node.
- Networked backing?
- Is a liana "node handler" necessary?
Flow of a resource:
- Entry:
- Holds the data but as of now doesn't read metadata.
- Server:
- Informs clients about entry metadata.
- Liana node:
- Only place currently setup to block for reading duration.
- Disc drive resources need to block to read chapters as well.
- File open could likely benefit from being non-blocking/threaded.
- Fit into server list_callback()? Could be as simple as replacing lia_node_get_duration().
- Any catches to moving duration retrival to the cache entry?
- Cache objects? (Disc drive)
- Handles it's own state on demand.
- Re-evaluate list behavior without duration.
Cache/liana refactor:
[x] get/set_size() no longer make sense.
[x] // @TODO: Unknown size is unhandled in backings.
- Handle keeps reading but will eventually have a wait cut short after a backing finalize.
[ ] Expanding list entry.
- How to handle unload?
- Disc drive can trigger unload.
- Make sure we can skip around in list while an entry load is pending.
- Also cancel load requests on unload.
- Consider pitfalls in the idea of having a "cd object" in the list that can be unloaded
and loaded with different cds.
[ ] Separate cch_handler from cch_entry.
- Move waits to entry?
- Pick first entry in order as the unloaded entry, remove every other entry.
- Create cache entry with argument like file, cue, http, hls, etc.
- Handlers created internally, and run on different step.
[ ] Maybe rename cch_handler.
[ ] Rethink liana field on handler.
- Data format hint on backing (codec or raw+description).
- Codec hints (priority)?
- Cue handling.
- How to specify what type of file we are working with on cch_handler_file_create().
- Scan for file(s) in backing or server?
[ ] get_handle() takes chapter as a arugment.
[ ] On creation, the handler can create multiple backings and chapters.
[ ] Chapters include index into array of backings.
[ ] Method of requesting a unique file backing.
*/
struct cch_chapter {
off_t start;
off_t end;
};
struct cch_entry {
array(struct cch_chapter) chapters;
struct cch_chapter *chapter;
struct cch_backing *backing;
struct cch_handler *handler;
};
bool cch_entry_get_handle(struct cch_entry *entry, struct cch_handle *handle);
str *cch_entry_get_handler(struct cch_entry *entry);
s32 cch_entry_guess_format(struct cch_entry *entry);
void cch_entry_return_handle(struct cch_entry *entry, struct cch_handle *handle);
void cch_entry_free(struct cch_entry **entry);
|