Page 1 of 2
Video stream error on trying to open udp://127.0.0.1:54000
Posted: Wed Aug 05, 2020 5:52 pm
by 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 45705 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 45705 times
it says at first "preparing to revieve"
- preparing to revieve
- photo_2020-08-05_20-14-26.jpg (53.69 KiB) Viewed 45705 times
and then "video stream error"
- video stream error
- photo_2020-08-05_20-14-18.jpg (57.02 KiB) Viewed 45705 times
Could you guess what is the reason and what is the error?
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Thu Aug 06, 2020 10:44 am
by Sergey Tkachenko
Hmm... Maybe the problem in udp:// prefix.
Did you try http ?
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Thu Aug 06, 2020 11:06 am
by ya_vanka
Will http:// prefix work for udp stream?
You mean
http://127.0.0.1:54000?
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Thu Aug 06, 2020 3:42 pm
by ya_vanka
No,
http://127.0.0.1:54000 doesn't work as well.
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Thu Aug 06, 2020 3:55 pm
by 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?
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Sun Aug 09, 2020 5:06 pm
by 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.
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Sun Aug 09, 2020 7:42 pm
by 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?
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Mon Aug 10, 2020 10:15 am
by 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 45545 times
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Wed Aug 12, 2020 8:27 am
by ya_vanka
Thanks!
Finally I've got video.
Can I set timeout to 0 instead of assigning RVCamera.FFMpegProperty.UseFFmpegProperty = False?
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Wed Aug 12, 2020 12:13 pm
by 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.
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Thu Aug 13, 2020 10:52 am
by ya_vanka
Good news!
Going to upgrade and test!
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Fri Aug 14, 2020 2:00 pm
by 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 45392 times
And then this:
- mediatest_2.jpg (50.25 KiB) Viewed 45390 times
And this:
- mediatest_3.jpg (45.79 KiB) Viewed 45390 times
And this:
- mediatest_4.jpg (41.46 KiB) Viewed 45390 times
What is the reason of this corruption?
FFMpegProperties are set by default except for Audio=false.
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Fri Aug 14, 2020 2:13 pm
by 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?
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Fri Aug 14, 2020 2:22 pm
by 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.
Re: Video stream error on trying to open udp://127.0.0.1:54000
Posted: Fri Aug 14, 2020 2:31 pm
by ya_vanka
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.