RVMedia 2.0

Post by **Sergey Tkachenko** » Sat Oct 18, 2014 6:39 am

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

Post by **Sergey Tkachenko** » Sat Oct 18, 2014 2:11 pm

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.

Post by **Sergey Tkachenko** » Sat Oct 18, 2014 5:12 pm

New demo projects

Cameras\GStreamer

This demo plays multiple videos using GStreamer.
You need to add URLs (http:// or rtsp://) and specify video formats (Mjpeg, Mpeg, H.264)

This demo uses OpenGL for drawing videos (RenderMode property)

Post by **Sergey Tkachenko** » Sat Oct 18, 2014 5:22 pm

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.

Post by **Sergey Tkachenko** » Sat Oct 18, 2014 5:29 pm

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)