[MMM-RTSPStream] - Video Streaming from Live Feeds & Security Cameras

shbatm

@cr4z33 said in [MMM-RTSPStream] - Video Streaming from Live Feeds & Security Cameras:

It is now offset compared to its module position.

Play with the moduleOffset and absPosition config options. Search this forum for those and check out the README on GitHub for details of what each one does.

cowboysdude

@barnosch Are you getting any console.log errors or PM2 errors?

evroom

I tried playing with absPosition, but it does not do what is expected.

First of all:

absPosition: This overrides the automatic window and moduleOffset settings.

Second of all:

Format: { top: XX, right: XX, bottom: XX, left: XX } where XX is the pixel position on the screen.

This is not quite true.
The omxplayer options say: --win ‘x1 y1 x2 y2’
This would translate to: { top: XX, left: XX, right: XX, bottom: XX }
In principle it is a rectangular with coordinates (x1,y1) - (x2,y2).

But most important:

Whatever I do, including the module position, the video window is ALWAYS in the center of the screen, for the FULL width of the screen.

I will try playing with the other parameters a bit.

evroom

You can move the streaming window using

moduleOffset: { left: XX, top: YY },

left: plus value shifts right, minus value shifts left
top: plus value shifts down, minus value shifts up

The width and height value in the stream config determines the streaming window size.

The name moduleOffset is IMHO a bit misleading, as it does not move the module window.

I still fail to see the connection between the module position (e.g. “top_left”, “top_right”, “bottom_left”, etc) and the position of the streaming window.
The streaming window always appears in the middle.
Except when I use “top_bar” or “bottom_bar”.

evroom

My MMM-RTSPStream module comes last.
So the first modules may shift this module down and therefore my streaming window appears to be always located in the middle.
In principle I want to have it in the middle, so I leave it there.
I made sure that MMM-RTSPStream is the only one using “middle_center”.

The module position will determine where the module window is being placed.
Exactly where is determined by the main.css and perhaps changes in the custom.css.

This is what the main.css does to “middle_center”, as example:

.region.middle.center {
  width: 100%;
  text-align: center;
  -moz-transform: translateY(-50%);
  -o-transform: translateY(-50%);
  -webkit-transform: translateY(-50%);
  -ms-transform: translateY(-50%);
  transform: translateY(-50%);
}

For “middle_center” I changed my custom.css like this, for example:

.region.middle.center {
  width: 60%;
}

This overrules the width in the main.css.
[I have my monitor in portrait mode (900x1600) and have 2 columns of 60% + 40%]

The moduleWidth and moduleHeight determine the size of your module and how other module will wrap around it.
The moduleOffset will move the streaming window relative to the module window.

The stream1 width and hight determine the streaming window size.
When sized bigger than the module window, it will simply use this bigger size.
It will even will cover other modules when too big, those modules will not wrap around it.

This config works for me:

{
  module: "MMM-RTSPStream",
  disabled: false,
  position: "middle_center",
  header: "Axis Security Monitor",
  config: {
    autoStart: true,
    rotateStreams: false,
    moduleWidth: 590,
    moduleHeight: 332,.
//      moduleOffset: { left: 0, top: 0},
    localPlayer: 'omxplayer',
    remotePlayer: 'none',
    showSnapWhenPaused: false,
    remoteSnaps: false,
    stream1: {
      name: 'Axis_M2026_LE_MkII',
      url: 'rtsp://user:password@192.168.178.56/axis-media/media.amp?resolution=640x360',
      width: 590,
      height: 332
    },

With

$ pm2 logs mm

you can check the streaming window parameters:

0|mm  | Starting stream stream1 with args: [
0|mm  |     "--avdict",
0|mm  |     "rtsp_transport:tcp",
0|mm  |     "--win",
0|mm  |     "-2, 656, 588, 988",
0|mm  |     "--no-osd",
0|mm  |     "--live",
0|mm  |     "--video_queue",
0|mm  |     "4",
0|mm  |     "--fps",
0|mm  |     "30",
0|mm  |     "rtsp://user:password@192.168.178.56/axis-media/media.amp?resolution=640x360"
0|mm  | ]

I have changed my custom config like this:

.MMM-RTSPStream header {
    text-align: left;
}
.MMM-RTSPStream .innerWrapper {
  border-style: none;
  //border: 1px solid red;
}

I used solid red in order to see the position of the module window more clear.

Be sure to use

cd ~/MagicMirror; npm run config:check

to check the config for errors before restarting mm, it will save you from obvious mistakes.

Those are my findings, for me the settings work, perhaps it will help other users.

Cr4z33

@shbatm OK thanks.

citizendevpi

Have you got the wayze cam to feed to your mirror?

Cr4z33

@shbatm what if I want to use VLC instead of omxplayer?

I am going to move to a different SBC called Rock Pi 4B and we know that omxplayer is for the Raspberry Pi family only.

Would it be quite simple to edit the scripts or does it need a good programming knowledge? :smiling_face_with_smiling_eyes:

Right now I am using a VLC window in my VMware Debian 8.x based MagicMirror testing session, but it’s not really what I want… :confused_face:

shbatm

@citizendevpi I started looking at VLC as an alternative to OMXPlayer but didn’t make it very far (honestly, just not enough time).

The most promising looked to be webchimera.js with VLC built for hardware acceleration, but the original repo for webchimera.js is marked abandoned. It looks like at least 1 fork is still active, but I didn’t get as far as testing anything.

If you have the capability to pursue it, I’d love some help. From what I have looked at, it should be a close-to-drop-in replacement for the FFMPEG version of this Module, and if that works, I could eliminate all of the OMXPlayer references (read: headaches).

References I’ve found:
https://thepi.io/how-to-compile-vlc-media-player-with-hardware-acceleration-for-the-raspberry-pi/
https://github.com/limoragni/WebChimera.js

Cr4z33

@shbatm unfortunately I am not skilled enough for that sorry. :slightly_frowning_face:

Anyway it came out that VLC was not a good idea when using a Rockchip based SBC.
Its VPU can be used only if using gst-launch-1.0 like ie.:

gst-launch-1.0 uridecodebin uri=file:///usr/local/test.mp4  ! rkximagesink

That way 4K streaming/playing looks good too.