TRichView.com

OK - It does work with uncompressed WAVs. Maybe you could add that to the documentation.

Thanks

As you can see from the comment in that code fragment, it is assigned.

I cannot get playing from Wav files to work. According to the documentation, this should be OK:

procedure TfrmMain.btn_audiofileClick(Sender: TObject);
begin
// Microphone has SourceType rvsstWav
if opendialog1.Execute then
begin
rvmicrophone1.WavFileName:= opendialog1.FileName;
rvmicrophone1 ...

Nearly there!

But - I don't want to extract the track to a wav unless I have to. That would cause a lot of sync problems. I really need to be able to write data in real-time.

Thanks, Sergey

All I need is to expose a method to send audio and video to a Tcamsender. My FFMPEG system can deliver video frame and audio frame events very reliably, if necessary with transcoding. The audio frames are all PCM with the samples/sec, channels and bits/sample in the event call. The ...

Congratulations Sergey. An excellent update.

A few points:

• Disconnects : In client-server mode the client drops out randomly – usually after a period of no interaction. I can’t see any automatic re-connect mechanism, but maybe I’ve missed it.

• FFMPEG : There seems to be a complete FFMPEG ...

It is working.

It's important to use this kind of sequence when using video:

procedure TfrmMain.Button_choosevideoClick(Sender: TObject);
begin
//
if opendialog2.execute then
begin
rvcamera1.abort;
rvcamera1.SourceFileName := opendialog2.FileName;
rvcamera1.PlayVideoStream;
end;
end;

But ...

It's much improved. Client/Server is about 1.5 seconds latency, which is acceptable for chat.

Well done, Sergey!

Thank you - Got installers and will test!

Jim

I would love to test it, but I can't locate it anywhere!

Thanks, Sergey. Really video should drop frames if overloaded. Audio should be a higher priority, surely?

After many tests I have reluctantly come to the conclusion that RVMedia is not adequate for a professional environment. We have found it impossible to get latency below about 4 seconds in LAN or WAN tests. IN my area - interpreting - latency must be as low as possible. Below one second would be ...

The sound quality is much more variable than the video. Specifically, it's hard to eliminate pops and crackles and keep the latency down to something acceptable.

One possible reason for excessive latency is that TRVMicrophone uses TMemory streams for buffering. I've got about 30+ years of ...

These tests are the demos.

I've seen disconnects. In one session one client (identical to the others but with a unique identity) refused to connect.

Changing the audio or video settings on the sender can cause a disconnect if another client is listening.

Inactivity will cause a disconnect - but I need to explore this ...