Multiple roVideoPlayers behavior?

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.

- Joel

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.

--Mark

"RokuJoel" wrote:
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.

By "[only] one stream at a time", do you mean that's a hardware limitation (i.e. bottleneck is in the abstraction layer beneath, at the API/library provided by chipset manufacturer or below) of all Rokus in existence, incl. Roku3?

Your idea on manu-matically rotating JPGs for the rest though? Pure genius as far as "making lemonade from lemons" goes.
I know i am rather uh, careful with use of compliments but this one is worth some applause!
Since it will scale up/down gracefully with player performance, i.e. slower players will still be able to refresh non-focused camera views occasionally where fast ones with some luck may appear as video. Taking JPGs is probably "sub-optimal" for camera's hardware compared to mpeg stream but what can you do.

"RokuMarkn" wrote:
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.

As innocent reader of the documentation i can say that, yes - doco on roVideoPlayer should mention that only 1 instance can play at a time. That there is only one decoder in Roku players is not a common knowledge, i haven't seen it elsewhere.

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?

"EnTerr" wrote:
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?

MJPEG is "motion-JPEG" which is a popular digital camera format from olden days. It's basically just a series of JPEGs, so yes, every frame is a keyframe, but I don't think it borrows anything from standard MPEG encoding.

"EnTerr" wrote:
By "[only] one stream at a time", do you mean that's a hardware limitation

Yes, this is a hardware limitation.

Roku support MJPEG in any shape or form?

There's at least one developer who posted on the forums who has got mjpeg "streaming" working via a rather hackish method.
viewtopic.php?f=34&t=75814&p=463162&hilit=mjpeg#p463162

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.

- Joel

"RokuJoel" wrote:
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.

I understand where you are coming from on that 🙂
but it's probably better to implement it as video-player because MJPEGs often contain audio too - both when recorded from digital cameras and when streaming from ip cam. So it's more of a video format - albeit cranky - than animated GIF.

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.

Yeah, that's unfortunate - and too bad they did not use MPEG as container, with I-frames only - but instead used different binary. On the (+) side, i read Webkit (Safari, Chrome) and Mozilla-based (Firefox) browsers have native support for MJPEG, which shows it is a) significant enough and b) not that hard (there must be one or two prevailing varieties)

In general, MJPEG does not support audio.
Further, there really is not a set standard for mjpeg. If you are hearing audio with your MJPEG, then it is probably inside an AVI or Quicktime wrapper. The only common use for MJPEG in this day and age is security cameras, and those usually do not provide audio, and usually are not wrapped in an AVI or Quicktime container.

I really like the idea of the "dynamic bitmap". Otherwise, I would say provide a way to process http response chunk by chunk, and let people write their own MJPEG handlers. The latter option certainly would push more of the work on to channel developers, but is probably the best option for supporting the widest range of mjpeg streams. The pseudoCode would look something like:

contents = createChunkByteArray()

for each chunk from continuosChunkStream
  if isMJPEGBoundry(chunk) Then
    bitmap = decodeJpegByteArray(contents)
    displayBitmap(bitmap)
    contents.empty()
  else
    contents.push(chunk)
  end if
end for

Note that the above sample code assumes the decodeJpegByteArray() function. It would be possible to implement writing it out to a temp file and then reading it back in, but that is unlikely to be efficient. So there would need to be further additions to the API to fully support MJPEG.

Every camera I have tested streams mjpeg via http with mime type multipart/x-mixed-replace

Here is a Wireshark capture from an Axis Camera

HTTP/1.0 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Connection: close
Content-Type: multipart/x-mixed-replace; boundary=myboundary

--myboundary
Content-Type: image/jpeg
Content-Length: 125583

... lots of jpeg content ...

--myboundary
Content-Type: image/jpeg
Content-Length: 125499

... lots of jpeg content ...

and on and on and on and on

I have hacked together initial MJPEG support using "roStreamingSocket". It still needs work, but I plan to open source at some point