|
| class | ChunkedSampleTableStore< T, ChunkSize > |
| | RAM-backed like RamSampleTableStore, but grows by allocating additional fixed-size chunks instead of reallocating and copying one single growing array. More...
|
| |
| class | FileSeekableSource< FileT, WriterT > |
| | Adapts a single concrete file/stream (Arduino's File, or anything else exposing position(), seek(size_t) and a readBytes(size_t) overload) to SeekableSource, and also drives feeding that same file's bytes into a DemuxerMP4 (or any other AudioWriter with a setSeekSource(SeekableSource&) method) via copy() - replacing the separate CodecCopy/StreamCopy a sketch would otherwise need, and letting this class use just one File for everything instead of requiring two independent handles (one for sequential forward reads, one for the out-of-band seeks SourceSeekSampleTableStore performs). More...
|
| |
| class | FileSpoolStorage< FileT > |
| | Adapts any concrete file/stream type to SpoolStorage - same role as FileSeekableSource, just adding write(). This is the one place the concrete file type appears for spool-backed storage. More...
|
| |
| class | HasQuickStart< T > |
| |
| class | RamSampleTableStore< T > |
| | Keeps every entry in RAM (a plain Vector<T>) - the simplest and fastest option, but scales with the track's total sample/chunk count (e.g. ~4.5MB total for a 102-minute movie's stsz+stco tables). Default if no other SampleTableStore is configured. More...
|
| |
| class | SampleTableStore< T > |
| | Sequential-access storage for one MP4 sample table (e.g. stsz sample sizes, stco chunk offsets, or the raw stsc/stts RLE entries). Every real access pattern in DemuxerMP4 is append-only while parsing 'moov', then forward-cursor reads while consuming 'mdat' - this interface intentionally only supports that (no random-access mutation, no delete), which is what keeps all three implementations below simple and correct. More...
|
| |
| class | SeekableSource |
| | Minimal seek+read interface a SourceSeekSampleTableStore needs from "the original MP4 source" - kept deliberately tiny (no write, no generic Stream surface) and non-templated, so classes that only need to hold/pass a source around (like DemuxerMP4 itself) don't have to become templates just to support this one storage strategy. More...
|
| |
| class | SourceSeekSampleTableStore< T > |
| | Discards every value right after appending it, keeping only the file offset of the first entry - get() seeks back into the original MP4 source and re-reads the entry directly (entries are fixed-size and contiguous on disk, so entry N sits at start_offset + N*sizeof(T)), trading RAM for repeated small seeks. More...
|
| |
| class | SpoolFileSampleTableStore< T > |
| | Writes every entry to a caller-provided scratch file as it's appended, instead of keeping it in RAM - get() seeks that file and reads the entry back. Unlike SourceSeekSampleTableStore this needs no knowledge of (or seekability in) the original MP4 source - it works even when that source is a live, non-seekable stream, since it's writing its own local, sequential copy as data streams past. The tradeoff is disk I/O (both a write during parsing and a seek+read during playback) instead of a pure RAM cost. More...
|
| |
| class | SpoolStorage |
| | Minimal seek+read+write interface a SpoolFileSampleTableStore needs from its scratch file - SeekableSource plus write(), kept non-templated for the same reason as SeekableSource (see its comment): so DemuxerMP4/SpoolStorageFactory don't need to become templates just to hold/pass one of these around. More...
|
| |
| class | SpoolStorageFactory |
| | Factory DemuxerMP4 calls once per table, per track, to obtain a SpoolStorage for spool-backed sample table storage - needed (rather than a single shared file/setter, the way setSeekSource() works) because up to two tracks (video + audio) times four tables means up to eight distinct spool regions are needed, and DemuxerMP4 doesn't know how many tracks a file has, or which kind each one is, until it's actually parsing 'moov' - implement this to open/return whatever files or regions your storage scheme uses (e.g. one file per call, named by trackKind+tableKind). More...
|
| |
