Hardware encoding and Latency minimization via FFMPEG

[ShootingKing-AM]

Hardware Encoding Support and Network hand-wave latency reduction

Old/deprecated
- [x] Research low-latency Protocols: Done: RTP best for this application.
- [x] Research Available libraries
    - [x] PJ-SIP, FFMPEG
    - [x] PJ-SIP - Tests: Status: [Failed no pj-media Support](https://github.com/pjsip/pjproject/issues/2601).
    - [ ] Implement FFMPEG
        - [ ] Implement FFMPEG on Desktop
            - [x] Protocols Selection: RTP (ultra-low latency) + NVENC/NVDEC Encoder (h.264 Container format)
            - [ ] Code Implementation:
                - [x] Implement ffmpeg as ffmpeg-cli commandLineInterface integration
                    - [x] Stage0 - Research D3DSharedResourceHandle Streaming
                        - [x] Test1: using Inprocess pipes to get pipe render to ffmpeg for encoding. Status: Failed - WritePipe() Speed too low (~15 fps)
                        - [x] Test2: Piping D3DSharedResourceHandle to ffmpeg.exe process in background. Status Failed - Hard to maintain with FFMPEG-master updates, better to implement libav*
                            - [x] ~Bypass Mobile negotiation, for Development~
                            - [x] ~Modify FFMPEG fopen_inputs() to get D3DSharedResourceHandle~
                - [ ] Implement ffmpeg as libav* libraries, if Test1 & 2 Both fail.
                    - [ ] Stage1 - Static Content Streaming
                        - [ ] Stream Static testfile.mp4, with RTP to localhost, for Dev
                            - [x] Bypass Mobile negotiation, for Development
                            - [x] Code FFMPEG Init()
                            - [x] Code FFMPEG fopen_inputs()
                            - [x] Code FFMPEG fopen_outputs()
                            - [x] Code FFMPEG transcode()
                                - [x] Code FFMPEG transcode_init()
                                - [x] Code FFMPEG transcode_step() <--- Main Loop
                            - [ ] Code FFMPEG stop_stream(), Outputs and Inputs
                            - [x] Code FFMPEG deInit() <--- safe exit + Memory Release
                    - [ ] Stage2 - Dynamic Content Streaming
                        - [ ] Modify FFMPEG fopen_inputs() to get D3DSharedResourceHandle
                            - [x] Research methodology
                            - [x] Modify FFMPEG fopen_inputs() to take D3DSharedResourceHandle as Input instead of Static file
        - [ ] Implement FFMPEG on Mobile End
            - [ ] Add shared libraries (.so) to Android project.
            - [ ] Research into available FFMPEGAndroid ports/wrappers
                - [ ] Test3: Port Wrapper Implementation test on Android
            - [ ] If Test3 not successful, implement FFMPEG libav* code.
            

Fixes #44 and #52

[ShootingKing-AM]

• sister project, ALVR now provides alvr_client_core for server backend which has FFMPEG based hardware encoding (plus other awesome technologies included, which are planned in PhoneVR) which can be used to remove duplication of efforts for server/driver development of the both projects. It does so from v19 (https://github.com/alvr-org/ALVR/releases/tag/v19.0.0)
• better to use its server/client_core
• have to test its usual performance before integration
  • Presently not building Fails to build alvr-cardboard#2
    • Fails to run library "libc++_shared.so" not found alvr-cardboard#3
    • Add missing permissions leading to crash on startup alvr-cardboard#4
    • Run time alvr_client_core issues fixed by Stability Issues PhoneVR-Developers/alvr-cardboard#5

[ShootingKing-AM]

• Tested, ALVR client_core
  • Pros
    • Easy to install
    • Good friendly reliable discovery
    • GUI
    • Some parts of performance like HW Encoding(speed and quality) are better, latency minimization as expected from FFMPEG + ALVR networking is better
  • Cons
    • Todo but yes [Issue] very sensitive to gyro, jitter (fixable) - post beta 0.3 release
    • Also alvr-org has bad policies not modelled for sustainability, but for quick fixes
    • The client-server model is also not robust, only for quest (not even in different repos)
    • ALVR doesn't intend to go beyond quest hardware, frequent breaking changes, no stable client_core lib doc, no testing pipeline (e2e, even no compile time checks)
  • Wayforward
    • Redistribute ALVR server
      • Build manual release
      • Link with phonevr versioning (Readme link to ALVR-phonevr repo [Issue] Streamline Versioning into Windows Driver and Android App, including buildno #74
      • auto PR fork sync with ALVRServer Master
        • Write E2E tests for PhoneVR -> Checks -> Merge ALVR master changes -> release version Add tests for driver and app #107
        • Till e2e Freeze alvrVersion
  • Better to Integrate with PhoneVR along with its own driver and dayDream SDK
    • Integrate Cardboard with Mobile - Integrate ALVR Server with PhoneVR #113
      • Separate vrActivity_Cardboard
      • Should be able to switch back and forth in APP, DayDream-PVR Driver or Cardboard-ALVR (default)
      • Disable settings when Cardboard-ALVR is selected
    • No need to Integrate Server - Communication, Streaming ports are already different
      • Readme - ALVR Server recommended for now #read
      • Update Readme Banner