jacobbo / WebEye

WebEye is a collection of .NET controls.
190 stars 132 forks source link

Crash on 4g RTSP stream #55

Open SandipBR opened 5 years ago

SandipBR commented 5 years ago

Hi I am really grateful for this awesome control. There is an issue I am coming across and want some guideline to fix it. I am using the control for a video monitoring application. I have like 25 rtsp streams. Many times when the streams stop the StreamStopped or StreamFailed events are not fired and the IsPlaying remains true. So it's difficult to bring back the stream.

Another issue is when I use rtsp streams from ip camera over 4g (transport is tcp, can't use udp) when the connection drops the same situation happens as above but as soon as I press the stop button or try to start the playback again the application goes to non responding state and crashes. I tested i with the demo application and does the same too. Please help

SandipBR commented 5 years ago

UPDATE : I could see that it happens for all tcp stream not only 4g. When I used ThreadPool.QueueUserWorkItem(_ => streamPlayerControl1.Stop()); I could stop the stream and the StreamStopped event fired. But I could not execute the StartPlay anymore. The stream never comes back. The demo app remains at a connecting state.

jacobbo commented 5 years ago

Hi Sandip, can you reproduce your issues using ffplay?

SandipBR commented 5 years ago

Hi Yes the same thing happens with ffplay. The stream does not comeback. The only difference is if I press ctrl + c ffplay stops without getting stuck.

On Thu, Aug 8, 2019 at 4:29 PM Alexander Iacobciuc notifications@github.com wrote:

Hi Sandip, can you reproduce your issues using ffplay?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jacobbo/WebEye/issues/55?email_source=notifications&email_token=AK6DEZGQSMKI2EKFYFGWLH3QDRXZLA5CNFSM4IKE3ATKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD34VFKY#issuecomment-519656107, or mute the thread https://github.com/notifications/unsubscribe-auth/AK6DEZCWQKCVABEHEEGCQTLQDRXZLANCNFSM4IKE3ATA .

-- सोाहम्

SandipBR commented 5 years ago

Hi, As I tested more I came to understand the -timeout option does not work for ffplay and -stimeout option has no effect so ffplay stays in a constant reading state although the stream is dropped.

How does the timeout option of StartPlay work ? Does it pass the value to commandline ? is there a way to set the socket timeout to 5 seconds ?

jacobbo commented 5 years ago

No, I have my own implementation of timeout feature: it just exits the thread if not connected after timeout.

Speaking about stream events, I can't really help you without reproducing your issue. Is it the same issue for all your cameras or just a few?

SandipBR commented 5 years ago

I understand.. but some how the timeout logic is not exiting the thread. This issue is there in all the cameras. I tested with test tcp stream and the same issue exists.

rtsp://testuser:testcam2@sam-cam.ddns.net:9912/0 (can use 1 for low bitrate, must use tcp as transport; udp does not work).

This is the test stream you can use to reproduce the issue. The issue appears when the stream is playing and somehow the session gets closed. If you just pull out your internet cable it does not produce the issue. Either you can do it programmatically or send one email in sandip.sam.bh@gmail.com when you want to test. We can come up with some real time communication and I can help from here to produce the issue. Please help me.. Thanks a lot for all these attention and quick response. I will be available whole weekend if you want to test it. Thanks

jacobbo commented 5 years ago

OK, I can connect to it. What's the issue with timeout? If I set timeout to 1 sec, it fails the connection, as expected.

SandipBR commented 5 years ago

Thanks for the rapid response

Actually the issue is in the other direction. Once the connection is established and plays the video try to drop the session and see. The event does not fire up and with stop button the application hangs up

SandipBR commented 5 years ago

Could you reproduce the issue ? Otherwise send me a message when you are in front of the system and running the app. I can pull the camera cable and you can see the issue.

jacobbo commented 5 years ago

Stop is also not working, correct?

SandipBR commented 5 years ago

Yes. As soon as I press the stop button the application hangs up.. becomes non-responding.. When use ThreadPool.QueueUserWorkItem(_ => streamPlayerControl1.Stop()); the application remains responsive but can't Play again or even can't dispose the player without error.

jacobbo commented 5 years ago

That one can be fixed, as for the not coming events issue, it's ffmpeg logic there and if ffmpeg thinks that the stream is OK, then we can't do much here, I'm afraid.

SandipBR commented 5 years ago

But here is the thing.. I record the same stream by ffmpeg too and I use -stimeout option to set the socket timeout for 2 seconds, As soon as the stream drops ffpmeg returns back without doing any harm to other part of the code. Then I repeatedly check if the stream is again available. Everything works fine.

So my request is if you can expose one more parameter in StartPlay function to set the -stimeout of ffmpeg it will resolve the whole issue. Please have a look towards it. Thanks

jacobbo commented 5 years ago

Right, I see. That is possible, not sure when I have time for this though. Let's schedule for this weekend, but I do not promise :)

SandipBR commented 5 years ago

Excellent... I really appreciate and value your attention. I will wait for it. Thanks a lot

SandipBR commented 5 years ago

I hope you get some time to fix the issues during the weekend. I really need it asap. If any thing I can do from my side please let me know. Thanks again

jacobbo commented 5 years ago

Will send you a version to try by the end of the day. Are you using x86 as a target platform?

jacobbo commented 5 years ago

WPF or WinForms?

SandipBR commented 5 years ago

Thanks for the effort.. I use x64 winforms

jacobbo commented 5 years ago

Does the -stimeout option work with ffplay as well? I'm trying it but it has no effect.

SandipBR commented 5 years ago

No it does not work with ffplay.. but works well with ffmpeg.

SandipBR commented 5 years ago

There can be another workaround.. if ffmpeg can give a number, like frame number or something which can be checked from outside thread and if this number stops to change we recognize that the stream has dropped. After the timeout period we can make the stop call, free the resources and return back to the main thread.

jacobbo commented 5 years ago

Try this one: https://drive.google.com/file/d/1iF8S_y8PchdhwVRrBZk6_wJLpUaz_6lx/view?usp=sharing StartPlay method now has an extra parameter: streamTimeout, the one you are looking for. For now it's x86 only, but if it works, I'll publish Any CPU version in a couple of days.

SandipBR commented 5 years ago

Ok.. it's already midnight here.. I will check tomorrow morning and let you know as soon as possible.. Thanks a lot

SandipBR commented 5 years ago

Hi... Sorry I could not check it on Sunday. I tested it today and it exactly working as it should work. The issue resolved. I am really grateful. Thanks a lot. If you can make it for anycpu and also publish in git and nuget all people using tcp will be benefited for it. I thank you again.

jacobbo commented 5 years ago

Thank you for the testing. I'll publish the full version by the end of the week.

SandipBR commented 5 years ago

Great..

SandipBR commented 5 years ago

Could you fix the stop() method ? It's still making the application non-responsive.

jacobbo commented 5 years ago

How to reproduce this issue?

On Wed, 21 Aug 2019 at 17:34, SandipBR notifications@github.com wrote:

Could you fix the stop() method ? It's still making the application non-responsive.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/jacobbo/WebEye/issues/55?email_source=notifications&email_token=AAN57QE4QQ4U2LJG4QE5NWTQFVVCDA5CNFSM4IKE3ATKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD42JSUA#issuecomment-523540816, or mute the thread https://github.com/notifications/unsubscribe-auth/AAN57QDIQVZWPKWTZD4X6RLQFVVCDANCNFSM4IKE3ATA .

SandipBR commented 5 years ago

Sorry for the delay... I am managing the video streams to send to you so you can reproduce the issue. It will take 1-2 days.

SandipBR commented 5 years ago

Hi Actually after more testing and tries I could avoid the error coming because of the stop method. It's working fine now. But the application getting cashed because of another error. I am putting it below. Please have look at it. In internet I found it's an access violation error. Please let me know how to fix it or at least avoid it.

Problem Event Name: APPCRASH App Name: CamViewerNew.exe App Version: 1.0.0.0 Application Timestamp: 5d5efbd1 Fault Module Name: tmp9CD8.tmp Fault Module Version: 0.0.0.0 Fault Module Timestamp: 5d58a0ec Exception Code: c0000005 Exception Offset: 0011244f Operating System Version: 6.1.7601.2.1.0.256.48 Locality ID: 1046 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

SandipBR commented 5 years ago

UPDATE : I put [System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptionsAttribute()] for the method calling StartPlay and put a try catch block but did not catch anything neither it stopped the crash. Please help

jacobbo commented 5 years ago

Is it always reproducible?

SandipBR commented 5 years ago

Yes it is.. can you provide me a private email. i will pass you the 4 test streams so you can produce all the errors and fix it all. Thanks again

jacobbo commented 5 years ago

a.iacobciuc at gmail

SandipBR commented 5 years ago

I sent you the streams by mail