The device can only handle one stream at a time. Your best bet is to grab .jpg files from the other cameras in a round-robin fashion and display those in liu of the stream, until the user focuses on another camera, at which point you replace its stream with a .jpg image and display the newly selected stream in the new location instead of the .jpg image.
I don't think there has ever been an intention that more than one roVideoPlayer could exist simultaneously. I would say the documentation should simply say that this is not supported. I don't think there's any real reason to do this anyway -- certainly you can't play more than one stream at once, so why have an idle videoplayer sitting around? You can create it when you need it.
On a side note, does Roku support MJPEG in any shape or form?
I am clueless about the format - isn't it just an intraframe-only MPEG?
By "[only] one stream at a time", do you mean that's a hardware limitation
Roku support MJPEG in any shape or form?
I've filed an enhancement request for a native support of MJPEG streams (and .gif animation), hopefully someone will have time to implement this in the future. My idea is that it should be a "dynamic bitmap" type where you treat it like any other bitmap, that way you could have as many MJPEG "streams" on the screen as the device performance and bandwidth would allow.
One issue with MJPEG is that there are a lot of variations in the implementation of MJPEG so the metadata between each frame may differ from one MJPEG to another. There are however some after-the-fact standards established, that include ways to handle the major variants.
contents = createChunkByteArray()
for each chunk from continuosChunkStream
if isMJPEGBoundry(chunk) Then
bitmap = decodeJpegByteArray(contents)
HTTP/1.0 200 OK
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Content-Type: multipart/x-mixed-replace; boundary=myboundary