I use videostreamin TOP to get video stream from my IP camera.
In version 2020.26630 everything is ok
In 2021.10330 has a large latency. About 5-6 seconds.
Windows 10
What is the delay like in 2020.20000 series? What protocol is being used to do the streaming? Can you tell me what model camera it is as well?
RTSP protocol from generic security IP camera (h264 codec). In 2020 it was about 7-12 frames delay, which is normal.
Do you have the exact model? Different ones are going to set different types of streams, so to reproduce I’ll need to get the same model
https://www.aliexpress.com/item/4000766822136.html?spm=a2g0s.9042311.0.0.27424c4dAMAV9x
Testing this issue also on different “noname” cameras. Same effect.
Sorry for the lag in looking at this. What kind of delay do you see in VLC player? I’m seeing 3-4 seconds there also.
In 2020.20000 series I’m seeing a lot of decoding artifacts, which is telling me the decoder there is decoding things too soon, not waiting for B-frames that are needed to properly decode the stream. In 2021.10000 there doesn’t seem to be the artifacts anymore, which I think is correct based on the encoding format of the stream. Low latency streaming generally requires a H264 encoding that doesn’t include b-frames, which the reolink (that I’m testing with) is likely using.
Yes, but sometimes real time is much more important than the occurrence of artifacts. I am developing a project where I use an IP camera. In 2020.26630, I achieved a minimum delay of 150 ms (just switch off realtime option in TD). In 2021, this delay is much longer (about 1-2 seconds). Is it possible to add the option “let there be artifacts, the main thing is real time” to videostreamin TOP? )))
Unfortunately not. The more ‘correct’ behavior comes from our upgrading of the decoding toolkit we use. It isn’t a change I made or controlled. If you are looking for lower latency you may want to consider a camera that doesn’t encode H264 but instead sends uncompressed data over IP such as PointGrey or Ximea cameras.
Very sorry. No, of course I’m always happy about upgrades. But this means that I’m stuck in 2020 builds for a long time. Unless of course I can figure out how else to deliver the signal from the IP camera to TD. By the way, OpenCV does this very slowly…
Just wanted to report that I’m experiencing the same issue in build 2021.14550. I don’t think I had the same issue in the 2020 builds.
Typically when I start a stream it will have a delay of around 3-4 seconds and that time will slowly grow. Right now I’m lookin at a stream I started 1 day ago that now has about 2min of delay.
Running the same stream on the same computer in VLC has about 1 second of delay and that doesn’t seem to grow over time.
This is the camera I’m using: https://amcrest.com/amcrest-smarthome-ash42-b-black.html
One more thing I’d like to mention. This camera has a couple different stream encoding modes: H.265 and H.264H. I was running in H.264H mode and decided to switch to H.265. This caused TouchDesigner to crash.
Thanks for the feedback, I’ve ordered one of those cameras and will try to reproduce.
I am having the same issue with a H.264 stream from a Lumens DC-W80 document camera
Well over a seconds of delay.
VLC plays it without this delay, as does the software included with the camera and it’s browser UI.
Stream information as reported by VLC:
Codec: H264 - MPEG-4 AVC (part 10) (h264)
Video resolution: 1920x1080
Buffer dimensions: 1920x1088
Orientation: Top left
Color primaries: ITU-R BT.709
Color transfer function: ITU-R BT.709
Color space: ITU-R BT.709 Range
Chroma location: Left
bitrate: 5000kb/s
On a laptop with:
Windows 10 home 20H2
Core i7-9750H @ 2.6Ghz
16GB ram
GeForce GTX 1650
which version of TD are you on?
at the time of reporting, it was probably still 2021.15020
Finally got around to setting up this test case, but I ran it overnight with the Amcrest camera and still no luck getting an increasing latency. It seems to be 1-2 seconds, which follows what I’m seeing from VLC.
We are having the same issue on 2021.15800 running OSX Monterey with an 265+ stream…
Same issue persists in 2021.16410
My solution was to have two versions running in separate instances. //hack hack hack
2020.26630 with 2 nodes: Video Stream In → TouchOut (that’s it)
2021.16410 running my real network
Camera was delayed by 1-2 or more seconds and had terrible artifacts, bad decode, etc - this solved it 100% without changing any settings on the video stream or the Stream In TOP.
Camera is a UNV IPC2328SB-DZK-I0 (Uniview) streaming H.264 1920x1080 @ 10fps
No NVIDIA GPU so it is CPU decode.
Thanks for the tip @dim_111, 2020.26630 works great.
@cgbrl you’re saying the stream captured in 2020 both is low latency and doesn’t have decode artifacts, but 2021 has both 1-2 seconds of latency and artifacts?