We have been using Wowza primarily to transcode and mux from RTMP to HLS. We've noticed for a while that when stopping the encoder, the stream will be cut off in the player. This seems to happen because the player will be so many .ts files behind "live" and there may be 3 or 4 left in the chunklist when the encoder disconnects, but when the encoder disconnects and Wowza starts cleaning up, it immediately destroys the packetizers. This means that the chunklist and all of the available .ts files in the current sliding window evaporate from under the player, before it has actually fetched all of the stream.
Recently we have noticed a (I think) related phenomenon. Sometimes due to network issues, the encoder might not be able to get any data to Wowza for a significant amount of time, say 20 seconds. There is never an unPublish event in the log, so it appears that the session is maintained during this period (another indicator is that when data is again received, it gets appended to the same .mp4 file when using live-record). However, after something like 15 seconds the log shows "Destroy live stream packetizer: cupertinostreamingpacketizer" for every transcoded stream. It seems like this also causes the current chunklist and .ts files to evaporate, so that when data is again received, it's like the .m3u8 is started from scratch. This causes significant issues with our player, as we would expect that the player would be able to keep getting data (remember it's probably 40 seconds or so behind) until it gets to where the encoder quit sending. In a lot of cases, if the network issue is temporary, the encoder may have caught back up by then - so this seems like a needless interruption.
So, for our needs the packetizer should never be destroyed if the stream it's packetizing still exists. It would also be nice if we could control how long it persists even after the stream is unPublished, to allow players to finish playing the available data.
My question is, is there a way to alter the timeout for the Cupertino packetizer?