A problem we have been seeing with WM9 (ASF) encoder start/stop reliability.
Our scenario involves multiple encoders - running around 50-70% sustained
We run the encoders in an A/B mode, switching between them every (default)
30 mins to create chunked recordings, with an overlap of ~5 secs at the
transition point. This to provides manageable file sizes, and distributes
risk in the event of other component failure.
These systems run 24 x7 x365 - and seem to work quite well - except for....
(we originally used WME components - but have since moved to our own graphs
& filters in an attempt to eliminate the symptom I describe below.)
Continuous Audio and Video sources - into standard WM codecs (usually WM9
video and audio)
A script stream is injected to the multiplex every 200ms - containing HTML
tags that carry our 'metadata' and closed caption strings.
With this scenario, we have successful operation - except that
'occasionally' (perhaps between one and five times a day), an encoder will
not stop, or will not complete the start-up cycle - possibly due to an
earlier failed 'stop' cycle??. These conditions are not faulted in NET -
hence we can't trap them as exceptions - they occur deep in the encoder
The only way we can detect one of these failed encoders is to look at the
output archive file size, and respond when it doesn't grow as expected !
Fortunately, our A/B model supports this, and the outgoing encoder remains in
operation until the new incoming encoder is confirmed as operating properly.
In the event that we do indeed detect a 'dead encoder', the background task
destroys that process, and a new encoder is launched in its place - ready for
a new attempt at file changeover
HOWEVER... If we disable the script channel, we do not seem to have this
It's not enough to slow down or stop the script data injection; we must
disable the script channel in the encoding graph - to see the problem
With our attempts at fault isolation - the questionable component comes down
to ASF_WRITER, as this is the only common element between our original
efforts using WM components, and our home-grown discrete DX9 / WMF SDK
encoder graphs that we are now using. Unfortunately we can't easily rewrite
/ replace ASF_WRITER, as it is not in the public domain... so over to your
I suspect that the problem is somewhere between high-speed script (~200mS),
and continuous script injection... perhaps a buffer is not reinitialized
properly when stopped / restarting, or some other minor oversight like that.
I hope you can share this with some development / test gurus that can help
or discuss the issue. We are keen to remain with WM - as it gives us good
reach to the corporate desktops that use our client applications.