Corrupt duration in file metadata when recording and livestreaming

[NerdySouth]

Describe the bug If we are recording a video, and activate livestreaming then the recording gets corrupted with a bad duration. We have two stream objects running simultaneously, but if there is a better way to stream audio always, record audio + video selectively, and selectively stream video, please let us know.

To Reproduce Steps to reproduce the behavior:

1. instantiate two generic streams, one with no video source and a mic, the other with both video and mic
2. start the audio only stream object with RTMP
3. start the audio + video object to record with startRecording()
4. activate video livestream by calling stopStreaming() on the audio only object, and then startStreaming() on the audio + video object, while it is still recording locally.
5. end the recording and livestream
6. recorded mp4 file has bad duration

Expected behavior Normally, we expect that the mp4 had the correct duration, so the recording and livestreaming can happen simultaneously. This is on a Motorola Razr+ 2023

Screenshots If applicable, add screenshots to help explain your problem.

Smartphone (please complete the following information):

• Library version [e.g. 2.2.7]
• Device: Motorola Razr+ 2023
• OS: Android1 3
• Media server Nginx RTMP
• Class used: GenericStream

Additional context We are building an app which needs to always be streaming audio via RTMP, while being able to selectively record video + audio locally (ex. when the user taps a button). We would also like to be able to selectively stream video along with the audio via RTMP. Currently, we do this by having two GenericStream objects, one with NoVideoSource() and MicrophoneSource() and the other with a Camera2Source and Microphone source. The one with audio only streams to our endpoint, and when the user taps a button the other stream object will start/stop recording locally to the device.

The bug happens when we try to then activate the video on the audio only stream. First we tried to change the video source on-the-fly, but we would never see the video in the player. So we then tried to just stop the audio stream object, release it, then instantiate a new GenericStream with Camera2Source and Mic. This worked, but if the device was recording locally when the video livestream is activated, we would end up with a recorded mp4 file that had a duration of 275 hours long. This was not correct, and there was also no video track in the mp4. If we never activate the video livestream during a recording, this would not happen.

After that, we decided we would just call stopStream() on the audio only object when we start a video livestream, and then just call startStream() on the stream object that is already recording locally. This fixed the issue of having no video track in the recording, but the duration was still the same (around 275 hours for a 20 second recording). This time, the video would freeze on the last frame for the remaining (incorrect) duration.

We did some digging and found this relevant article which may be the problem?