Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
EnTerr
Roku Guru

Multiple roVideoPlayers behavior?

What happens if i place multiple roVideoPlayer on the same screen and try to play them concurrently?
(Assume non-overlapping setDestinationRect, separate ports serviced in the loop etc - whatever it takes)

The scenario is simultaneously showing two (or more) H.264 streams from security cameras - which is not necessarily a crazy idea, considering low bandwidth of say 500kbps 15fps.

What happens when a 2nd player is play()ed? (do both work alongside or does 1st pause, or does Roku crash etc)
This should be covered in doco but i cannot find a mention.
0 Kudos
11 REPLIES 11
RokuJoel
Binge Watcher

Re: 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
0 Kudos
RokuMarkn
Visitor

Re: Multiple roVideoPlayers behavior?

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
0 Kudos
EnTerr
Roku Guru

Re: Multiple roVideoPlayers behavior?

"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.
0 Kudos
EnTerr
Roku Guru

Re: Multiple roVideoPlayers behavior?

"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?
0 Kudos
TheEndless
Channel Surfer

Re: Multiple roVideoPlayers behavior?

"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.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
RokuJoel
Binge Watcher

Re: Multiple roVideoPlayers behavior?

"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
0 Kudos
EnTerr
Roku Guru

Re: Multiple roVideoPlayers behavior?

"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)
0 Kudos
jamest
Visitor

Re: Multiple roVideoPlayers behavior?

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.
0 Kudos
jamest
Visitor

Re: Multiple roVideoPlayers behavior?

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
0 Kudos