TRichView.com

I have an h264 video stream that I want to display using RVCamera.

FFplay shows it:
But if I try to open the stream via MediaTest demo application it says at first "preparing to revieve" and then "video stream error"
Could you guess what is the reason and what is the error?

Hmm... Maybe the problem in udp:// prefix.
Did you try http ?

Will http:// prefix work for udp stream?

You mean http://127.0.0.1:54000?

No, http://127.0.0.1:54000 doesn't work as well.

I get the same error if I try to stream the file (https://yadi.sk/i/6Gr0hRuHFAlhJw) via vlc
:sout=#udp{dst=127.0.0.1:1234} :no-sout-all :sout-keep

ffplay.exe -i udp://127.0.0.1:1234 shows video
mediatest gets video stream error

Could you please check it and find a solution?

It looks like the problem is in RVCamera.FFMpegProperty.TimeOut.
It is used as 'timeout' parameter for FFmpeg.
It is equal to -1, and FFmpeg documentation says that this is a default value, but it looks like this codec does not like this value of parameter (or this parameter).
A temporal solution is assigning RVCamera.FFMpegProperty.UseFFmpegProperty = False. This means that no parameters will be set for FFmpeg, defaults will be used.
In the next update, value of TimeOut will be set to FFmpeg only if it is not equal to -1.

PS: it looks like only one FFmpeg viewer can be run for local UDP streaming. If you run this stream in ffplay, you will not be able to run it in your application at the same time.

Tried to set RVCamera.FFMpegProperty.UseFFmpegProperty = False to all cameras in MediaTest application, but the result is the same (video stream error).
Did you use this demo project for test or some other?

I used another demo, but MediaTest is ok.

Two things:
1) FFmpeg DLLs must be available for MediaTest (you can copy them to the MediaTest folder)
2) It must not be FFmpeg 4.3.1 (or some versions close to it). It crashes. The newest daily build of FFmpeg is OK, and v4.2.1 and older is ok.

Thanks!
Finally I've got video.

Can I set timeout to 0 instead of assigning RVCamera.FFMpegProperty.UseFFmpegProperty = False?

I am not sure if TimeOut = 0 is a valid property.
You can upgrade to RVMedia 7.5 (just uploaded), it ignores TimeOut = -1.

Good news!
Going to upgrade and test!

So, since version 7.5 I get video, but in a minute it's getting corrupted.

First 30 seconds image: And then this: And this: And this:
What is the reason of this corruption?

FFMpegProperties are set by default except for Audio=false.

And the second problem is the latancy of 2-2.5 seconds.

I get the same or even bigger latency if I use ffplay cmd: ffplay.exe -i udp://127.0.0.1:54000

It can be reduced to 0.1 sec by the following cmd: ffplay.exe -i udp://127.0.0.1:54000 -framedrop -sync video -fflags nobuffer -probesize 64

How can I do the same with RVCamera?

1)
Can video frame corruption be reproduced reliably?
Do you have the same results with ffplay?
Probably, the reason is in UDP protocol. It does not guarantee that data are delivered correctly.

2) All available FFmpeg parameters are in RVCamera.FFMpegProperty.
As you can see, there is no FFlags, FrameDrop and ProbeSize properties. I can add them in future release, if you want. But it will not be released soon, unless a critical bug in v7.5.1 will be found.
You can try to modify source code yourself. Open MRVFFMPEGObject.pas, find procedure TRVMFFMPEG.OpenFile. You will see calls of SetDict* functions. These functions are implemented in MRVFFmpegFuncs.pas and pass parameters to FFmpeg, similarly to ffmpeg.exe parameters.

3) You can also remove TRVCamera buffering by assigning RVCamera.Latency = 0.

Sergey Tkachenko wrote: ↑Fri Aug 14, 2020 2:22 pm Can video frame corruption be reproduced reliably?

Yes.

Sergey Tkachenko wrote: ↑Fri Aug 14, 2020 2:22 pm Do you have the same results with ffplay?

No. FFPlay shows without corruption.

Sergey Tkachenko wrote: ↑Fri Aug 14, 2020 2:22 pm Probably, the reason is in UDP protocol. It does not guarantee that data are delivered correctly.

If the sender was on a remote PC - yes. But it is on the same PC (localhost IP address is used) and there should be no problems with UDP.