RVMedia 2.0
RVMedia 2.0 has been released.
This is a free update for customers who ordered RVMedia 1.x
The new features are listed in this topic. Additionally, we added numerous tweaks and fixed many bugs (including several critical bugs).
So, if you tested RVMedia 1.x and was not satisfied with its speed and stability, please give it a second chance.
RAD Studio XE7
This update supports Delphi and C++Builder XE7.
There are two alternative packages:
- RVMediaDXE7.dproj - for Delphi and C++Builder XE7, requires Delphi personality
- RVMediaCBXE7.cbproj - for C++Builder XE7.
Like for previous versions of RAD Studio, the trial contains only RVMediaDXE7.dproj.
A C++Builder-only trial is available on request.
64-bit compilers
Starting from this update, RVMedia supports 64-bit projects in RAD Studio XE2 and newer.
We decided not to include 64-bit units in the trial.
GStreamer support
RVMedia supports GStreamer, both 32-bit and 64-bit versions.
In the previous version, it was possible to play H.264 videos via RTSP and Mpeg-4 movies via HTTP.
In this version, you can use GStreamer to play MJpeg, Mpeg-4, H.264 videos via HTTP or RTSP, any combinations are possible (providing that necessary GStreamer codecs are installed).
TRVCamera introduces a new property allowing to configure GStreamer.
There is a new demo: Demos\Cameras\GStreamer.
The demo Demos\Cameras\8Cams\ (former 4Cams) uses GStreamer too.
GStreamer is optional in RVMedia. Without GStreamer, RVMedia can display MJpeg streams and video in updated Jpeg files.
Receiving video
In RVMedia 1.x, while TRVCamera and TRVCamReceiver used threads, in general it was a cycle: receive - decode - show.
In RVMedia 2.0, these operations are performed in threads: one thread for receiving, one thread for decoding, one thread initiating video displaying.
It allows using multiple processors more efficiently.
In addition, it solves a lag problem, when a source sends video stream faster than a destination can receive them, and the delay accumulates. It can be because of a low bandwidth or because of a slow processing. RVMedia 2.0 can receive data as fast as possible, so, if the network speed is acceptable, there will be no delay accumulation (on buffer overflow, old frames could be dropped without displaying to support correct timing).
When we implemented this feature, we found that there are a lot of buggy MJpeg translations over the Internet - when data are requested too often, they return invalid frames. So we implemented an automatic frame-rate detection for video streams.
Sending video
RVMedia uses its own protocol to send multimedia data via the network.
When sending video, it can send only changed areas; this mode greatly reduces traffic.
However, in RVMedia 1.x the process of finding changed areas was slow for high resolution videos.
RVMedia 2.0 uses a smaller copies of frames for finding changed areas, so this process is now fast even for hires videos.
Sound
We did many tweaks to improve quality of sound read from a microphone.
For example, a filter that cuts of too quiet sound is not applied for a couple of seconds after a loud sound, to prevent cutting word ends.
Previously, sound from microphone was read using a minimal quality (8000 Hz - 8 bits). In RVMedia 2.0 we added properties allowing to increase sound quality (sample rate, bit depth), but now, for a simple voice transferring, minimal settings work ok.
TRVMicrophone now can read sound not only from a microphone, but also from a Wav file.
TRVMicrophoneView can display activity not only for TRVMicrophone, but for TRVCamReceiver (which receives sound from the network and plays it).
TRVCamMultiView optionally displays sound indicators next to videos, so, when implementing a conference, you can see sources of sounds.
TRVCamReceiver now can mix sound from multiple sources properly, it is absolutely necessary for video chats for multiple users.
Localization
Video viewers and traffic meter components are localized. They can display messages in English, Spanish, Russian, Portuguese (Brazilian)
There are not too many messages to translate, but nevertheless.
New translations are available on request.
Previous version
http://www.trichview.com/forums/viewtopic.php?t=6451
RVMedia 2.0
-
- Site Admin
- Posts: 17522
- Joined: Sat Aug 27, 2005 10:28 am
- Contact:
RVMedia 2.0
Last edited by Sergey Tkachenko on Sun Oct 25, 2015 5:24 pm, edited 2 times in total.
-
- Site Admin
- Posts: 17522
- Joined: Sat Aug 27, 2005 10:28 am
- Contact:
Changes in existing demo projects
The demo Cameras\4Cams is renamed to Cameras\8Cams
It displays video from 8 different sources.
Old sources:
- video camera accessed using CameraHost, CameraPort, UserName, UserPassword properties
- video stream from the specified URL
- local web camera
- video from cycled Jpeg files
New sources:
- H.264 movie via RTSP (works only if GStreamer is available)
- Mpeg movie via HTTP (works only if GStreamer is available)
- Desktop
- local video file (it can be played with sound)
---
In the demo SendAndReceive\TwoApps\Receiver, TfrmMain.RVCamReceiver1DataRead does not update UI any more, it uses PostMessage. It's because OnDataRead is now called in a thread context.
---
The demos that were located in ClientServer were moved to ClientServer\VideoChats
Changes in ClientServer\VideoChats\Server:
- tweaks in UI for the case when only one of servers (HTTP or UDP) fails to start (for example, because its port is busy)
- OnUserConnect, OnUserDisconnect, OnDataRead, OnServerCmd are now called in a thread context, so instead of updating UI directly in these event, the demo uses PostMessage
- OnServerCmd event has new parameters. The server logs not only client-to-server command, but also clients-to-clients commands (FilterUserCmd=False)
In all clients demos in ClientServer\VideoChats, the dialogs for video sending options and for microphone options are added, as well as ability to mute a microphone
Microphone options dialog
Video sending options dialog
Also, the file-receiving code is modified in these demos:
- the demos save received files in subdirectory named by the client identifier (to allow testing several clients on the same computer - preventing multiple demos attempting to save into the same file)
- since OnReceiveFileData is now called in a thread context, a message about file receiving is displayed in OnReceivedFile.
The demo Cameras\4Cams is renamed to Cameras\8Cams
It displays video from 8 different sources.
Old sources:
- video camera accessed using CameraHost, CameraPort, UserName, UserPassword properties
- video stream from the specified URL
- local web camera
- video from cycled Jpeg files
New sources:
- H.264 movie via RTSP (works only if GStreamer is available)
- Mpeg movie via HTTP (works only if GStreamer is available)
- Desktop
- local video file (it can be played with sound)
---
In the demo SendAndReceive\TwoApps\Receiver, TfrmMain.RVCamReceiver1DataRead does not update UI any more, it uses PostMessage. It's because OnDataRead is now called in a thread context.
---
The demos that were located in ClientServer were moved to ClientServer\VideoChats
Changes in ClientServer\VideoChats\Server:
- tweaks in UI for the case when only one of servers (HTTP or UDP) fails to start (for example, because its port is busy)
- OnUserConnect, OnUserDisconnect, OnDataRead, OnServerCmd are now called in a thread context, so instead of updating UI directly in these event, the demo uses PostMessage
- OnServerCmd event has new parameters. The server logs not only client-to-server command, but also clients-to-clients commands (FilterUserCmd=False)
In all clients demos in ClientServer\VideoChats, the dialogs for video sending options and for microphone options are added, as well as ability to mute a microphone
Microphone options dialog
Video sending options dialog
Also, the file-receiving code is modified in these demos:
- the demos save received files in subdirectory named by the client identifier (to allow testing several clients on the same computer - preventing multiple demos attempting to save into the same file)
- since OnReceiveFileData is now called in a thread context, a message about file receiving is displayed in OnReceivedFile.
-
- Site Admin
- Posts: 17522
- Joined: Sat Aug 27, 2005 10:28 am
- Contact:
-
- Site Admin
- Posts: 17522
- Joined: Sat Aug 27, 2005 10:28 am
- Contact:
New demo projects
SendAndReceive\RemoteDesktop
This demo consists of two projects:
- RemoteDesktop: sends desktop as a video stream and accepts commands from the second application
- DesktopControl: receives desktop video stream, sends mouse commands to the first application
DesktopControl application
Sending desktop images as a video stream does not require any programming, it is one of TRVCamera modes.
Some code is needed
- in RemoteDesktop to receive and perform mouse commands from DesktopControl
- in RemoteDesktop to send mouse cursor position to DesktopControl
- in DesktopControl to receive mouse cursor position and draw a mouse cursor
- in DesktopControl to send mouse commands.
As you can see, these task can be easily solved by sending user-defined commands between TRVCamSender and TRVCamReceiver.
These demo use UDP (not TCP) connection, so there are no events for establishing or closing connection. The demos use a "Ping-Pong" technique to determine when the connection is closed: one demo periodically sends PING command, another demo replies with PONG command. If there are no commands received for some time, the demos assume that a connection is broken.
SendAndReceive\RemoteDesktop
This demo consists of two projects:
- RemoteDesktop: sends desktop as a video stream and accepts commands from the second application
- DesktopControl: receives desktop video stream, sends mouse commands to the first application
DesktopControl application
Sending desktop images as a video stream does not require any programming, it is one of TRVCamera modes.
Some code is needed
- in RemoteDesktop to receive and perform mouse commands from DesktopControl
- in RemoteDesktop to send mouse cursor position to DesktopControl
- in DesktopControl to receive mouse cursor position and draw a mouse cursor
- in DesktopControl to send mouse commands.
As you can see, these task can be easily solved by sending user-defined commands between TRVCamSender and TRVCamReceiver.
These demo use UDP (not TCP) connection, so there are no events for establishing or closing connection. The demos use a "Ping-Pong" technique to determine when the connection is closed: one demo periodically sends PING command, another demo replies with PONG command. If there are no commands received for some time, the demos assume that a connection is broken.
Last edited by Sergey Tkachenko on Sun Oct 19, 2014 12:18 pm, edited 1 time in total.
-
- Site Admin
- Posts: 17522
- Joined: Sat Aug 27, 2005 10:28 am
- Contact:
New demo projects
ClientServer\Login
This demo consists of LoginClient and two alternative versions of LoginServer:
- the first version uses BDE
- the second version uses FireDAC
(a database is needed to store records about user accounts)
TRVMediaServer does not support authorization by itself, it accepts any connection. This demo shows how to implement authorization using commands.
An account in this demo consists of three values: GUID, username, password. Username is not necessary unique.
In a real word example, a client can enter GUID and password (as it is implemented, for example, in ICQ)
ClientServer\Login
This demo consists of LoginClient and two alternative versions of LoginServer:
- the first version uses BDE
- the second version uses FireDAC
(a database is needed to store records about user accounts)
TRVMediaServer does not support authorization by itself, it accepts any connection. This demo shows how to implement authorization using commands.
An account in this demo consists of three values: GUID, username, password. Username is not necessary unique.
In a real word example, a client can enter GUID and password (as it is implemented, for example, in ICQ)