TRichView.com

I need to send video stream that I recieve with RVCamera (either USB Camera or RTSP stream) over the internet to another client/clients and display it in my client application.
I do not use RVCamView because my application is OpenGL based and I get frame via TRVMBitmap.AssignRVMBitmap() inside RVCamera1GetImage(Sender: TObject; img: TRVMBitmap); and must use the same approach in client application (that is the same as server actually).

Tried some demos and got lots of questions:

1. At first glance I can do it with the help of RVCamSender. But as far as I understand it works only together with RVCamReciver (am I right?).
And if so then I don't know how to get each video frame in memory that I get now through RVCamera1GetImage(Sender: TObject; img: TRVMBitmap);

2. Video latency is of great importance for me so I've set RVCamReciver.VideoLatency = 200 and found an issue: on the first connection latency is more than 1000 ms (and I can see video jittering) but after stopping sender and then starting again latency is 200-300 ms and no jitter visible.

3. In case of big resolution 1024х768 or more it looks that tvpTCP prorocol works faster than rvtUDP. Can you explain why?

4. Don't understand how RVCamera.VideoResolution affects RVCamSender. Despite of what I assign to RVCamera.VideoResolution actual video stream resolution depends on the size of applications window (SenderMainFrm). If the window is small, the resolution is low. If it is big, the resolution is high.
I can even see the delay as if RVCamera reconnects to my USBcamera.
What is the right way to set the output resolution for RVCamSender?

5. Is there another way to send video stream recieved by RVCamera over TCP/IP or UDP? So that user could watch it in any player he has?

6. Can RVCamera recieve data being sent by RVCamSender directly (without using RVCamReciver)?

7. Does RVCamera.VideoFormat affects RVCamSender output?

8. What codec uses RVCamSender?


Thanks in advance and waiting for answers.

Tests were made in version 7.

I am sorry for the delay, it is caused by uploading a new version, compatible with Delphi 10.4.
I'll answer tomorrow.

1. Yes, TRVCamSender and TRVCamReceiver work together. One receiver can receive data from one or more senders.
Currently, TRVCamSenders sends all frames received from the camera. When a camera receives a new frame, it calls OnGetImage, and also give this frame to all linked viewers and senders.

2. Yes, the actual latency may depend on the speed of receiving of the first frame, because the receiver measures time from receiving the first frame. However, only latency depends on it, because all frames must be delayed identically.
Nonzero VideoLatency is useful only to synchronize sound and video. If you send only video, you can assign VideoLatency = 0.

3. Probably, the larger frame size, the larger chance that it will be corrupted when sent using UDP, so it will be dropped.

4. Maybe you set TRVCamView.UseOptimalVideoResolution = True? In this case, TRVCamera's VideoResolution is assigned automatically to provide the best fit.
Assigning a value to TRVCamera.VideoResolution works differently depending on the DeviceType, see the help file. Generally, it instructs the video source to provide video having resolution as close to the specified value as possible (it this video source supports it). TRVCamSender has its own VideoResolution property, so it can scale frames received from the camera before sending.

5. Currently, RVMedia does not support streaming in standard formats.

6. No, it cannot

7. No, it does not. This property helps TRVCamera to decode video source correctly.

8. It sends data in proprietary format. This is a very simple format. Basically, some header + an image (normally as jpeg, but can be other format, depending on TRVCamSender.Encoding). The format is slightly more complicated if Encoding = *Change, such as rvetJPEGChange. In this case, only changed frame areas are sent, as several smaller images.
Streaming in standard formats is not supported yet. Although, it is planned for future (using FFmpeg and GStreamer, probably using a new component). But I cannot tell when it will be implemented.

2. Still don't understant why videolatency is few times bigger on first connect and gets few times smaller after restarting server (without stopping reciever)?
If I Stop reciever after stopping sender or if I restart reciever without stopping sender videolatency remains big.

Could you please fix the issue?

Tried to set VideoLatency = 0. If so Reciever doesn't show video on start, only after restarting server (without stopping reciever).

4. You are right in part that TRVCamView.UseOptimalVideoResolution = True. But it was set in demo project.

8.

it is planned for future (using FFmpeg and GStreamer, probably using a new component)

Waiting for this feature!
Don't think it's hard to implement. It can be done even without new component (on the base of TRVCamSender). And sure it will be widely used.

9. Am I right that if Encoding = *Change it should send less data and work faster? Or it depends?

2. Do you use the newest version of RVMedia? In older versions, there was a bug with VideoLatency = 0, it is fixed in the new version.

9. Encoding = *Change uses less traffic. But it requires more CPU usage (mostly on the sender side), because it requires detection of changed areas.
And this mode makes sense only of changed area do not occupy the full frame. For example, there maybe noise, especially at night, and RVMedia may think that it is a movement. So, if there is a noise, you should decrease sensitivity.
Properties affecting sensitivity are described here: https://www.trichview.com/help-media/tr ... easize.htm
But if you decrease it too much, small movements will not be detected.
There is a special mode where you can see how motion detection works, it is TestMode: https://www.trichview.com/help-media/tr ... stmode.htm
You can see how it works in the demo SendAndReceive\SingleApp\
This screenshot is shown what is sent in a test mode: https://www.trichview.com/shots/rvmedia ... eceive.png
You can see changed pixels and areas that would be sent.

2. I've downloaded the latest version and recorded a test with the last compiled demo version (30.05.2020): https://yadi.sk/i/wBUPrTPjrD9QsQ

You can see video jittering (on 7-8 second) and big video latency on first connect and small after reconnect.

Please, fix this issue.

Sergey, have you watched the recorded test?
How can I overcome the problem?

I can reproduce the latency on the first connect.
I requires some time to fix, since there is other urgent work now. I'll try to fix it later in this week.

Thanks for your reply, waiting for the fix!

The correct delay is on the first connect. Video is delayed according to the TRVCamReceiver.VideoLatency property. In this demo, it is 1 second.
I am working on a fix. After this fix, a delay after restarting the sender will be the same as at the first connect.
To remove the delay, assign RVCamReceiver.VideoLatency = 0. This value works in RVMedia 7.4

Fixed in v7.4.1 (just uploaded)