Video stream error on trying to open udp://127.0.0.1:54000

[ya_vanka]

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

FFplay shows it:

ffplay

photo_2020-08-05_20-13-46.jpg (88.89 KiB) Viewed 42524 times

But if I try to open the stream via MediaTest demo application

photo_2020-08-05_20-14-23.jpg (68.98 KiB) Viewed 42524 times

it says at first "preparing to revieve"

preparing to revieve

photo_2020-08-05_20-14-26.jpg (53.69 KiB) Viewed 42524 times

and then "video stream error"

video stream error

photo_2020-08-05_20-14-18.jpg (57.02 KiB) Viewed 42524 times

Could you guess what is the reason and what is the error?

[Sergey Tkachenko]

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

[ya_vanka]

Will http:// prefix work for udp stream?

You mean http://127.0.0.1:54000?

[ya_vanka]

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

[ya_vanka]

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?

[Sergey Tkachenko]

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.

[ya_vanka]

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?

[Sergey Tkachenko]

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.

vlc-udp-streaming.jpg (143.16 KiB) Viewed 42364 times

[ya_vanka]

Thanks!
Finally I've got video.

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

[Sergey Tkachenko]

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

[ya_vanka]

Good news!
Going to upgrade and test!

[ya_vanka]

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

First 30 seconds image:

mediatest_1.jpg (59.09 KiB) Viewed 42211 times

And then this:

mediatest_2.jpg (50.25 KiB) Viewed 42209 times

And this:

mediatest_3.jpg (45.79 KiB) Viewed 42209 times

And this:

mediatest_4.jpg (41.46 KiB) Viewed 42209 times

What is the reason of this corruption?

FFMpegProperties are set by default except for Audio=false.

[ya_vanka]

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?

[Sergey Tkachenko]

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.

[ya_vanka]

Can video frame corruption be reproduced reliably?

Yes.

Do you have the same results with ffplay?

No. FFPlay shows without corruption.

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.