Remove direct STIRA.WPF dependency keeping the possibility to use it

[CosbyBs86]

Having the library agnostic, it is better to don't have any direct reference to Stira.WPF even because this dependency is only for the implementation of PropertyChanged interface. The interface has been included directly in GigeVision.Core project.

[CosbyBs86]

@Touseefelahi this is the latest one, so far ;) Many many thanks for your time in evaluating my PR.

[Touseefelahi]

@CosbyBs86 Actually thanks to you for making the PRs.

[CosbyBs86]

let me know if I can support you further. This library is very valuable. @Touseefelahi any idea when you can release a new nuget package with those changes inside?

[Touseefelahi]

There is one more important thing to implement. @CosbyBs86 do you have the GigEVision Standard? 2.0.03

[Touseefelahi]

Firewall issue needs to be fixed, look into this if you have time @CosbyBs86.

From GigEVision Standard 2.0.03: 11.9 Traversing Firewalls or Network Address Translation Devices Due to the unidirectional nature of GVSP traffic, it is common for the streaming channel data to be blocked by firewalls or other types of network since the incoming traffic cannot be matched against an outgoing packet. To address this, the SCSPx registers are designed to allow the application associated to a GVSP receiver to create a simulated bidirectional traffic conversation between the GVSP receiver and the GVSP transmitter streaming channel by informing the application of the remote UDP port. This information would otherwise be unknown until the first streaming packet arrives, which may never happen if it was blocked. Additionally, this information may be used in other ways to help configure software and/or networking equipment. The GVSP Capability register (at address 0x092C) can be used to query if SCSPx registers are supported by this device. [CR-094st] If a product supports SCSPx for one GVSP transmitter, then it MUST support it for all its GVCP transmitter stream channels. [CR10-8st] The suggested usage of SCSPx is to query it after opening the image stream via SCDAx and SCPx but before starting the camera’s flow of image data. If desired, the application can query it earlier and cache it off (only if it is non-zero) so that it does not need to query it each time the streaming channel is opened. Refer to [CR-089cd] for proper behavior of SCSPx. Next, the application can send a UDP packet from the same source port it programmed into SCPx to the port specified by SCSPx. The content of this packet is ignored, but the suggested payload should be smaller than the maximum size of a GVCP command packet. This operation should be realized on all the open stream channels. GigE Vision® Specification version 2.0 V2.0.03 April 16, 2013 Page 92 of 427 At this point the application can continue starting the acquisition on the camera. Depending on the configuration of the firewall or other impediment, the application may choose to continue periodically sending packets similar to the first one for the duration of the streaming session. The suggested interval is 30 seconds and could be configurable. Different firewalls might require adjustment to this interval. [CR-095ca] When SCSPx is supported by the application, the application MUST not send packets to the port specified by SCSPx unless it has the stream channel opened and successfully reads a non-zero value back from SCSPx. [CR10-9ca] The application should not expect the device to answer the packet it sends to the GVSP transmitter stream channel. But this mechanism provides a way to open-up the UDP port in the firewall. The implementation is left as a quality of implementation and is likely to vary with different firewall types and operating systems. Note that the same mechanism is also available for the message channel.

[Touseefelahi]

I apologies it is not formatted properly, I lazily copied it from the pdf

[CosbyBs86]

@Touseefelahi i probably run into the same issue with my company laptop. I'll have a look on this and let you know.