T4 and rtsp source

dogfox · Post by **dogfox** » Tue Aug 15, 2017 18:39

Hi guys,

Ive got a T4 and also a 4 camera pvr network on the same network that i am able to view on my laptop using vlc.

The first camera's url is rtsp://192.168.1.200:554/user=usr&password=pwd&channel=1&stream=0.sdp
The second camera's url is rtsp://192.168.1.200:554/user=usr&password=pwd&channel=2&stream=0.sdp

What is the best way to display this on the T4? is there a plugin that is required?

Thanks in advance

Grumpy_Geoff · Post by **Grumpy_Geoff** » Tue Aug 15, 2017 19:27

See thread "Stream a Web Cam to PIP?"

MrQuade · Post by **MrQuade** » Tue Aug 15, 2017 19:47

There was also some brief discussion on Whirlpool:
http://whrl.pl/ReXkfh

Grumpy_Geoff · Post by **Grumpy_Geoff** » Tue Aug 15, 2017 20:55

MrQuade wrote: ↑
Tue Aug 15, 2017 19:47
There was also some brief discussion on Whirlpool:

Yeah, prl's last post in the linked Wiz thread contains that link to Whingepool

MrQuade · Post by **MrQuade** » Tue Aug 15, 2017 21:05

Ahh so he did!

. I was so focused in trying to remember where one of my posts on the topic was hiding and I missed that

prl · Post by **prl** » Tue Aug 15, 2017 22:09

And when I made that post, I'd hunted and hunted for the content on the Beyonwiz forum before I realised it was on Whirlpool.

dogfox · Post by **dogfox** » Wed Aug 16, 2017 08:05

Thanks for the info guys. I have looked into camoFS and got it to work for one IPcam but not for the 4 camera pvr network.

I had the opposite problem with the last firmware (from Nov 5 2015) where I had perfect picture from the 4 camera pvr network (just by adding service lines to the bouquet) but I could never get anything from the single IPcam.

I have tried adding these lines to the bouquet.

#SERVICE 4097:0:0:0:0:0:0:0:0:0:rtsp%3A//192.168.1.200%3A554/user%3Dusr%26password%3Dpwd%26channel%3D1%26stream%3D0.sdp:___cam1
#SERVICE 4097:0:0:0:0:0:0:0:0:0:rtsp%3A//192.168.1.200%3A554/user%3Dusr%26password%3Dpwd%26channel%3D2%26stream%3D0.sdp:___cam2
#SERVICE 4097:0:0:0:0:0:0:0:0:0:rtsp%3A//192.168.1.200%3A554/user%3Dusr%26password%3Dpwd%26channel%3D3%26stream%3D0.sdp:___cam3
#SERVICE 4097:0:0:0:0:0:0:0:0:0:rtsp%3A//192.168.1.200%3A554/user%3Dusr%26password%3Dpwd%26channel%3D4%26stream%3D0.sdp:___cam4
#SERVICE 4097:0:0:0:0:0:0:0:0:0:rtsp%3A//192.168.1.200%3A554/user%3Dusr%26password%3Dpwd%26channel%3D5%26stream%3D0.sdp:___cam5

I do get a picture but it is super pixellated/blotchy and includes bits of the previously viewed channel, almost like the image buffer hasnt been cleared . Dont know about audio as none of my cams have mics attached. Could something have changed in the newest firmware that would cause this or is there some parameters I can modify get a cleaner pic?

In the attachement, you will see numbers in white.. they are from abc2's advirt that was on screen just before I switched to the rtsp stream. They should be the number 2, 7:30 and 8pm. The mesh that is barely seen going from bottom left to upper right is fencing viewed from the cam

Thanks

MrQuade · Post by **MrQuade** » Wed Aug 16, 2017 08:31

Can you explain what you mean about being able to view a single camera vs the 4 camera network?

dogfox · Post by **dogfox** » Wed Aug 16, 2017 08:48

Apologies for not being clear..

I have a pvr with 4 cameras attached where I can stream each individual cam independently with VLC using a rtsp protocol as above. Lets call this KennelCam

I have an IPcamera (foscam branded) that I can view on a browser using http protocol as stills. Lets call this ShedCam. i can get streaming video in a browser from this if I navigate to the IPcam's web server

With the old T4 firmware, I could not get shedcam to come up (as stills or continuous video) no matter what plugin i tried. I did get KennelCam to come up as channels on my bouquet using the plugin "add stream url", however. Crisp, clear video

With this new firmware, and, I guess, the updated camoFS, I managed to get a crisp image that updates every 2 secs from the Shedcam (I stll cannot get streaming video from Shedcam. )
However, the new frmware gives me barely usable video from the KennelCam streams as channels on my bouquet.

MrQuade · Post by **MrQuade** » Wed Aug 16, 2017 09:03

dogfox wrote: ↑
Wed Aug 16, 2017 08:48
I have an IPcamera (foscam branded) that I can view on a browser using http protocol as stills. Lets call this ShedCam. i can get streaming video in a browser from this if I navigate to the IPcam's web server

What's the difference in the two cases? Isn't the webserver hosted on the camera itself? In both instances you mention seeing footage from the camera using a browser and http, yet one way produces stills and the other produces continuous video.

dogfox wrote: ↑
Wed Aug 16, 2017 08:48
With this new firmware, and, I guess, the updated camoFS, I managed to get a crisp image that updates every 2 secs from the Shedcam (I stll cannot get streaming video from Shedcam. )
However, the new frmware gives me barely usable video from the KennelCam streams as channels on my bouquet.

The example service references you provided in a previous post all have the same IP address. Shouldn't one of them be different seeing as four cameras are going to your NVR and the other camera is standalone?

dogfox · Post by **dogfox** » Wed Aug 16, 2017 09:32

Thanks for taking your time with this

The shedcam is on 192.168.1.210 and the kennelcam is on 192.168.1.200. They are two disparate units.
Shedcam is one camera with its own http server.
Kennelcam is a nvr with 4 analog cameras hanging off of it.

Im not sure if I answering your question, sorry

MrQuade · Post by **MrQuade** » Wed Aug 16, 2017 09:46

dogfox wrote: ↑
Wed Aug 16, 2017 09:32
The shedcam is on 192.168.1.210 and the kennelcam is on 192.168.1.200. They are two disparate units.
Shedcam is one camera with its own http server.
Kennelcam is a nvr with 4 analog cameras hanging off of it.

I was just observing that you had defined 5 cameras in your bouquet and they all had an address of 192.168.1.200. I would have expected that 4 of them would have an address of 192.168.1.210 and the 5th would not be using the same URL format as the other 4.

dogfox · Post by **dogfox** » Wed Aug 16, 2017 10:00

Uggg
Sorry for the confusion.. I didnt realize that I specified 5 cams in the bouquet. My mistake, cam5 should not be there.. It was a placeholder for when I finally got shedcam working (which I never did)..

The bouquet should be
#SERVICE 4097:0:0:0:0:0:0:0:0:0:rtsp%3A//192.168.1.200%3A554/user%3Dusr%26password%3Dpwd%26channel%3D1%26stream%3D0.sdp:___cam1
#SERVICE 4097:0:0:0:0:0:0:0:0:0:rtsp%3A//192.168.1.200%3A554/user%3Dusr%26password%3Dpwd%26channel%3D2%26stream%3D0.sdp:___cam2
#SERVICE 4097:0:0:0:0:0:0:0:0:0:rtsp%3A//192.168.1.200%3A554/user%3Dusr%26password%3Dpwd%26channel%3D3%26stream%3D0.sdp:___cam3
#SERVICE 4097:0:0:0:0:0:0:0:0:0:rtsp%3A//192.168.1.200%3A554/user%3Dusr%26password%3Dpwd%26channel%3D4%26stream%3D0.sdp:___cam4

Apologies

MrQuade · Post by **MrQuade** » Wed Aug 16, 2017 10:31

Ahh thanks, that make sense now.

Have you tried enabling buffering for those streams using the following format?
4097:0:1:0:0:0:0:0:0:1:
(Info courtesy of prl's post on Whirlpool)

Code: Select all

#SERVICE 4097:0:0:0:0:0:0:0:0:1:rtsp%3A//192.168.1.200%3A554/user%3Dusr%26password%3Dpwd%26channel%3D1%26stream%3D0.sdp:___cam1
#SERVICE 4097:0:0:0:0:0:0:0:0:1:rtsp%3A//192.168.1.200%3A554/user%3Dusr%26password%3Dpwd%26channel%3D2%26stream%3D0.sdp:___cam2
#SERVICE 4097:0:0:0:0:0:0:0:0:1:rtsp%3A//192.168.1.200%3A554/user%3Dusr%26password%3Dpwd%26channel%3D3%26stream%3D0.sdp:___cam3
#SERVICE 4097:0:0:0:0:0:0:0:0:1:rtsp%3A//192.168.1.200%3A554/user%3Dusr%26password%3Dpwd%26channel%3D4%26stream%3D0.sdp:___cam4

I am not sure exactly what progressive download means in this context, but you could also try a 3 in the buffering field as well.

prl · Post by **prl** » Wed Aug 16, 2017 12:21

MrQuade wrote: ↑
Wed Aug 16, 2017 10:31
...
I am not sure exactly what progressive download means in this context, but you could also try a 3 in the buffering field as well.

Without going too far into the code, it looks like "buffering into a file". It looks like this implies an 8MB file buffer either as well as, or perhaps instead of, a 5MB memory buffer. I don't know GStreamer well enough to say, but I suspect it's "as well as".

Enabling progressive download (2) by itself does nothing: it's only used if buffering is also used, so:

0: unbuffered
1: memory buffer (5MB)
2: unbuffered
3: memory buffer (5MB) + file buffer (8MB)

I'd have though that for stuff on a home network, the 5MB memory buffer should easily be enough.

dogfox · Post by **dogfox** » Wed Aug 16, 2017 13:52

Well, I really thought that was gonna work ( buffering )

unfortunately, no change

MrQuade · Post by **MrQuade** » Wed Aug 16, 2017 14:33

dogfox wrote: ↑
Wed Aug 16, 2017 13:52
Well, I really thought that was gonna work ( buffering )

unfortunately, no change

Dang!

I was just having another look at the screenshot that you posted. As you rightly point out, the camera image is indeed there, but just overlayed/interlaced with old garbage from ABC. Is the image that you get back from the Kennelcam smoothly animated, or is the framerate jerky?

Just thinking about it a bit, if the image is nice and smooth, then it probably means the streaming part of the chain is ok, and it is just the decoding of the video that is shot to pieces. Sort of like when you play back a video and miss a keyframe, the video plays at the correct speed, you just get nasty blocking and smeared images.

The video playback engine, GStreamer, was updated in the 4.4->16.1 series update which may account for the fact that this used to work and no longer does. GStreamer has again been updated with the latest 17.5 series (which is almost out for general release).

Perhaps you could try the 17.5 series firmware and see if that offers any improvement. The current release candidate is pretty much due for release any day now, so the update is on the cards anyway.

dogfox · Post by **dogfox** » Wed Aug 16, 2017 14:51

Just thinking about it a bit, if the image is nice and smooth, then it probably means the streaming part of the chain is ok, and it is just the decoding of the video that is shot to pieces. Sort of like when you play back a video and miss a keyframe, the video plays at the correct speed, you just get nasty blocking and smeared images.

That sounds like what is occuring. video feed (when I can see movement) is indeed smooth but I am getting blocking and smears.

Are there any files or settings I can modify to correct this without having to update (which might cause other issues)

MrQuade · Post by **MrQuade** » Wed Aug 16, 2017 15:07

dogfox wrote: ↑
Wed Aug 16, 2017 14:51
That sounds like what is occuring. video is indeed smooth but I am getting blocking and smears.

Are there any files or settings I can modify to correct this without having to update (which might cause other issues)

Nothing that I know of.

Have you tried, or are you able to connect directly to the cameras without going through the NVR? Or are they not IP cameras (the cameras/encoders that I have encountered ay work usually allow multiple independent streams)?
Also, is the video feed being re-encoded on the NVR? Are there any encoding settings that you can modify on the cameras and/or NVR?

If this was actually a keyframe problem, I would have expected the image to maybe be corrupt initially for 5-10 seconds, and then clear up when the next keyframe arrived. It could be something way more obscure and outside the realm of my limited expertise

The 17.5 series firmware shouldn't introduce any real surprises for you, as it has been pretty thoroughly tested now. You can read about the changes in the beta thread if you like, but the only real gochas now are that you need to re-configure the T4 from scratch, and there are now some additional security changes that require you to set a password to remotely access the T4.

dogfox · Post by **dogfox** » Wed Aug 16, 2017 18:07

Unfortunate that I cannot tweak something somewhere to make it work

The cameras hanging off the NVR are all analog (non-ip) cameras. So I cannot connect to them like I can to ShedCam.

re "keyframe problem"... now I know why in vlc, sometimes the video comes thru funny then comes good after about 4-6 secs

I have just upgraded to 08082017 firmware on the T4 . Is this the 17.5 that you are referring to?

MrQuade · Post by **MrQuade** » Wed Aug 16, 2017 18:10

dogfox wrote: ↑
Wed Aug 16, 2017 18:07
Unfortunate that I cannot tweak something somewhere to make it work

There may be something on the T4, but it's out of my league

dogfox wrote: ↑
Wed Aug 16, 2017 18:07
The cameras hanging off the NVR are all analog (non-ip) cameras. So I cannot connect to them like I can to ShedCam.

No worries. Are there any video encoder tweaks/settings in the NVR that may be relevant then?

dogfox wrote: ↑
Wed Aug 16, 2017 18:07
I have just upgraded to 08082017 firmware on the T4 . Is this the 17.5 that you are referring to?

Yep, that's the one. It will become the official release very shortly and all future development will be based from this 17.5 series from here on in.

prl · Post by **prl** » Thu Aug 17, 2017 09:27

dogfox wrote: ↑
Wed Aug 16, 2017 18:07
...
I have just upgraded to 08082017 firmware on the T4 . Is this the 17.5 that you are referring to?

Yes and no. 20170808 (firmware version numbers are given in ISO date order) is built using the 17.5 core, but so are a number of other recent beta releases. The GStreamer version is actually given separately in MENU>Information>About.

dogfox · Post by **dogfox** » Thu Aug 17, 2017 09:42

Attached is my info>about

Are you saying that a new GStreamer version is going to be released or am I all updated?

Thanks again everyone

prl · Post by **prl** » Thu Aug 17, 2017 10:01

dogfox wrote: ↑
Thu Aug 17, 2017 09:42
...
Are you saying that a new GStreamer version is going to be released or am I all updated?
...

I'm not sure who "you" is in that sentence, but the version of GStreamer in 20170808 is the most recent GStreamer used in any Beyonwiz (beta or official) firmware release. It will almost certainly be the GStreamer version used in the next official release.

GStreamer is part of the release. You can't (or more correctly it's unwise to) use a different GStreamer version in the firmware than the one supplied. It may well be possible to install a newer GStreamer in the firmware, but I definitely wouldn't recommend it.

MrQuade · Post by **MrQuade** » Thu Aug 17, 2017 10:34

dogfox wrote: ↑
Thu Aug 17, 2017 09:42
Are you saying that a new GStreamer version is going to be released or am I all updated?

Don't worry. You have the latest firmware version and that includes the latest version of GStreamer. The 08082017 USB image that you installed is indeed the most up to date firmware currently available.

prl is just being thorough in explaining the firmware version.
He was just pointing out that 17.5 isn't the actual version number per-se, it just refers to what I was calling the "series" of firmware, or the core on which the firmware is based on.

In recent history, we have had the 4.4 series, the 16.1 series, and now the 17.5 series. The series are different enough from each-other that you cannot use the online update mechanism to upgrade from one to the other, and the difference is so great that the settings backups from earlier series are not compatible with the later series (hence the requirement to set up from scratch).

dogfox · Post by **dogfox** » Fri Aug 25, 2017 16:00

Just FYI,

In an effort to restore domestic bliss, I have had to downgrade to the public firmware from 17 08 2016 since that was the last one before the Gstreamer was updated.

My cam feeds are perfect again

MrQuade · Post by **MrQuade** » Fri Aug 25, 2017 16:39

What about the single IP cam? Is that back to a non-working state?

dogfox · Post by **dogfox** » Fri Aug 25, 2017 17:32

Have not tried as of yet as I have to install camofs which was low priority..

I am wondering if I can make a firmware with the newest fixes and the old gstreamer version... Doable?

MrQuade · Post by **MrQuade** » Fri Aug 25, 2017 17:39

dogfox wrote: ↑
Fri Aug 25, 2017 17:32
I am wondering if I can make a firmware with the newest fixes and the old gstreamer version... Doable?

Not for an end-user no. Too many inter-dependencies.
It's not even clear if it is indeed GStreamer that is at fault here either. Just that it is one major component of video playback that was updated between those two versions.

dogfox · Post by **dogfox** » Sat Nov 24, 2018 07:41

Hi guys,

This issue has cropped up again because Warkus was pretty convincing about updating firmware to the latest (which he did). I have NOT restored any settings from my prevous firmware but went through every setting in the setup to get back to what I had before.

Everything works great EXCEPT for this rtsp ssue. It is exactly the same now as it was way back when I started this thread. Any hints, tips, suggestions would be most welcome.

Thanks in advance!

Current screenshot

T4 and rtsp source

T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp sources

Re: T4 and rtsp sources

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

Re: T4 and rtsp source

About the Forum

About the Forum

Join us