Mobile App with real-time MIC-responsive Variable Speed Video Playback

A very simple (but later extendable) feature Application for Android & iOS is needed. Freelancer needs to develop front end Very briefly - a Server-side API (Provided by me) sends a Video file (Mp4) to the APP by some meta-info (Ie. target FPS). The App should be listening to the approximate rhytm of the Microphone Input, and speed up / slow down (or even stop) the Video according to the detected change in the musical rhythm of the Mic input, all this in real-time, with very-very little latency. More detailed description - For accomplishing this feature, the App needs to detect the so called "BPM" (Beat per Minute) - at least approximately - of whatever sound id being recorded live by the Microphone. It can be singing, drum, piano, birds, sound of waves, or even industrial noise. Does not metter. BPM is mathematically defined as the frequency of Peak Volumes in a given time window. Accuracy of BPM detection is NOT very important, only the very fast, real-time response for the changing rhythm. For example, 120 BPM (which is a very frequent rhythm in pop music), can be detected with an error margin of, let's say, +- 15, max +-20 BPM. On startup, we presume that there's silence, and our starting Video Playback speed is Zero (video displays the 1st frame, waiting for some sound from the Mic, exceeding a relative Noise threshold - ie. 20 % of Max Volume, defined by also the API). Whenever there's sound from the MIC (exceeding the Noise Threshold), the Video must speed up _Immediately_, as soon as possible (ie. maximum delay is 100-200 miliSec), to the Target FPS of 1.0x video Playback ("Real") speed, also defined by the API. BPM can only be measured in a sliding time window - that we do NOT have at startup, that's why we have to assume _something_ when we detect MIC input, so we shall assume 1.0x video speed, play the video immediately, and as the Sliding Time Window becomes longer, we can start aligning to the true rhythm. The Sliding Time Window Maximum length will also be defined by the API (in seconds). It'S expected value will be most likely between 2 and 6 seconds. There must be some 'Sanity' checks on the detected BPMs, ie. it is not possible for any reasonable music to exceed ie. 300 BPM, which means that no "presumably" detected Peaks can follow each other within 200 miliSecs (200 mSec = 5 Beat/sec = 300 BPM). Also, consider anything below 30 BPM so slow, that the Video should slow down & stop completely (30 BPM = 1 Peak within 2 seconds, separated by 2000 miliSecs). Also, rhytm can not "Jump" irrationally. If there's silence again at any point (no Peaks above the Noise Threshold in the give Time Window), the Video should gradually slow down & freeze, within about 3-5 seconds (Value provided by API). Cycle Restart. Note 1. - for good-looking slow-motion, the Mp4 Videos will have relatively high Frame Rate (typically 120-240 FPS). Note 2. This basic functionality will _LATER_ needs to be extended by actually uploading the Recording to the Server, also allowing Playback, simultaneously with the Recording (requiring the User to use Headphones to spearate his / her recording from the Playback). But this is NOT part of the Project right now, it is only to be noted that it should be realized in a way that is later extendable. All variables (Target FPS, the Video, BPM Detection Window Max Length, "Silence" criteria in Seconds, Background Noise Threshold will be provided by my Server's API. It is NOT important at this stage if the App uses lots of Memory, Battery, neither it is a problem if it creates huge data traffic by downloading high-FPS Vids, etc. Please only bid if You fully understand the requirements. Questions are welcome if You are not certain if You fully understood the basic functionality. If the basic functionality if workingf seamlessly (Ie. the Video must NOT be jumping, freezing, glitching, etc. on speeding up / slowing down ), I am willing to hire the given Freelancer for a much larger project, extending this all. Thank You.