Search results

Thank you!! This is awesome, been waiting on this for awhile. Now I can try using my RPi 4 again with dual displays. I appreciate your time/effort on this!!

Another update to my original post regarding the secondary monitor. That said, the RPi4 seems faster all around, even with this issue.

*DING* *DING* *DING* We have a winner! @bp2008 That was exactly it, the setting was at the default 64mb. I should have checked that first!!! :o After changing that it worked flawlessly. I'll update the earlier thread for anyone else who might come across this or when they're considering a RPi4...

That's a good point on the GPU setting, I don't recall changing that after the initial install of the OS and might be the issue. I'll try that tomorrow. :)

*7/24/19 update* While the RPi works wonderfully with Omxplayer, I cannot get it to work on the second monitor. I tried every combination of --display n that I could think of without success. Normal desktop graphics work normally on the primary and secondary monitor. I also tried an x,y range...

I'll try modifying the layer numbers, didn't think (or notice) that previously. I'm not all that certain about the command options with Omxplayer and should probably read up on the syntax. 7 on a RPi2? That's not bad, even with the variety of stream sizes. Worse case I can get another monitor...

Well, doing a 4x4 didn't cause the effect, so perhaps anything past 8 streams is just too much for the RPi? I wonder if it's the GPU? Anyone else been successful at running more than 8 streams at once?

It's a RPi v3b Yup! Learned that lesson the hard way in the past, it choked. The substreams are running at "D1" 704*480 on the cameras. --hdmiclocksync made it very angry and immediately triggered the video artifact, then the screen went blank. :wow: --nohdmiclocksync was previously included...

Anyone else experienced video artifacts with Omxplayer under specific configurations? Whenever I configure a full screen of video sources, I get the video artifact shown below. Tried this with rpisurv as well as OmxPlayerAuto with the same result so I think it's specific to the Omxplayer itself...

I've got a large area to cover that would be great for a high resolution camera like these 4k starlights. Assuming, like others said, the price is right for the WAF part lol. ;)

Hi! The RasPipC program isn't complete, however please see this post for details on an alternative. :)

Yes that is the other option I was considering and if the price is close then I'll probably go with those anyway to keep a consistent look with the other turrents already in place.

I live in a rural area and have spider web issues on all my cameras. :( Good point though, I bet they would love to make a web right in front of that lens.

I'm researching my next purchase and wanted to know if anyone has used or tried the IPC-HDW4231M Starlight? Just sent a note to Andy asking his price on it, hoping it's less than the other turrets. Looking for something less expensive to Detect/Observe for my live feed to complement the...

Wish I had the available funds, I'd take that off your hands :)

Too true sir, too true. Corrected and updated in my reply. I'm just still excited that this works so well, haha. :)

Edit/Update: For RasPipC, no, but for an alternative that @bp2008 put together you could do this: Follow these instructions and be sure to use the sub stream for the video feeds, not the main feed. Use the Raspbian PIXEL image, available for download here. :)

Thank you! :)

SUCCESS! :) It was fisheye/360 cam. Removed it and all is well. Also tested with 256 and 384 for the GPU, no difference there. The video is now very close to real time, less than a second. Maybe 250ms ~ 500ms slower than my PC-NVR which is much beefier. I'm very VERY *VERY* excited about this...

RIGHT!!! It's very weird and very strange. Yup using sub-streams, details below. That's what I was thinking too, maybe I should try with fewer streams. I wish there was a way to see the utilization of the GPU to know how well it is/isn't handling the load. I'm going to bump it up to 384 and see...

(Modifying earlier post) Anyone else seeing really odd latency issues with the video? No tearing or pixelation but a very strange latency issue where certain objects in a video stream are out of sync. Example: A person walking by the camera shows up normally, and then a vehicle will drive...

Disregard, I got my threads and instructions mixed up (the Rpisurv versus RasPipC). :(

Great! Thank you! :) Edit: Searching for that command, and I found where it was already provided. Looks like my search fu is weak. ;) Although it doesn't include the python piece which, I suppose, was triggering the re-launch of the feeds.

Unfortunately, no. Tried "q" and "ctrl-c" and "ctrl-x". If I SSH into the RPi and "sudo killall omxplayer.bin" it stops the feeds momentarily but the script then restarts the video feeds (and it's quite impressive!). I'm sure it's somewhere in the readme file or in this thread but I can't find...

Just set this up at home and it's amazing. Thank you for putting this together! :) Is there a way to gracefully exit the display when connected directly via the keyboard?

While we're on the topic of LPR, is the goal to have evidence and/or documentation for the police should something happen? Or is there some other information that could be gathered (legally. as a civilian.) from the LPR data?

This is what I would be curious about...also wonder if a RPi 3 would yield a higher FPS (if it's multi-thread enabled)

nayr, you're making my wallet hurt and my wife is giving me the stink eye...

Great! :) Working on payment method right now, might have to use PayPal as I'm having the same issues as others have experienced. Will message you soon.

Thank you :)