| 12345678910111213141516171819202122232425262728293031323334 |
- Windows Media works in an asynchronous manner.
- The WM Decompressor (IWMReader) requires that you provide a class
- deriving from IWMReader (and, optionally, IWMReaderAdvanced) to receive information
- Each delivery of uncompressed media arrives in an OnSample method
- Status messages arrive in an OnStatus method.
- The main difficulty that arrives from this approach is that ALL messages funnel through
- a single function. Audio data and Video data arrive in the same function.
- Even worse, status messages for file opened, clock error, http buffering, and DRM requirements all arrive in the same function!
- In order to handle this properly, a "chain of event handlers" class was developed (WMHandler)
- Any object wishing to receive data or status messages can derive from the WMHandler. All unhandled
- messages are automatically passed to the next handler in the chain. Messages that are handled can be
- passed or not passed based on programming requirements.
- The main object sets up the chain. The >> operator has been convienently defined to faciliate the chaining.
- The left side of the >> line must be the source (WMCallback)
- (e.g. callback >> clock >> drm >> video >> audio >> wait >> this;)
- Handlers may create their own mini-chains (which will get added in-whole) using the WMHandler::Inject() method.
- Threading
- ------
- 7 basic threads
- 1. Main (Windows) thread
- 2. Callback/OnStatus thread
- 3. Audio Decoder thread
- 4. Video Decoder thread
- 5. Audio buffering thread (ours)
- 6. Video buffering thread (ours)
- 7. Buffering-percent status thread (ours)
- There might be additional threads (created in another module) calling in, for functions like getextendedfileinfo
|
