MPEG4Writer: do not support out of order frames

[TroyTheGod]

Hi,

I've noticed that some videos recorded with this library are missing their audio tracks. After checking the logs for all the affected recordings, I found the same error message in each one:

`MPEG4Writer: do not support out of order frames (timestamp: 876377301 < last: 876405908 for Audio track
MPEG4Writer: 0 frames to dump timeStamps in Audio track
MediaWriter: Track event err/info msg:100, trackId:0, type:1,val:-1007
MPEG4Writer: Received total/0-length (37399/0) buffers and encoded 37398 frames. - Audio
MPEG4Writer: Audio track drift time: 0 us
MediaAdapter: pushBuffer called before start
PipelineWatcher: onInputBufferReleased: frameIndex not found (32461); ignored
RecordController: Write error
RecordController: java.lang.IllegalStateException: writeSampleData returned an error
RecordController: at android.media.MediaMuxer.nativeWriteSampleData(Native Method)
RecordController: at android.media.MediaMuxer.writeSampleData(MediaMuxer.java:723)
RecordController: at ze.m(Unknown Source:6)
RecordController: at ze.b(Unknown Source:15)
RecordController: at mz7$b.b(Unknown Source:21)
RecordController: at ks.w(Unknown Source:2)
RecordController: at o00.s(Unknown Source:3)
RecordController: at o00.p(Unknown Source:4)
RecordController: at o00$a.onOutputBufferAvailable(Unknown Source:2)
RecordController: at android.media.MediaCodec$EventHandler.handleCallback(MediaCodec.java:1953)
RecordController: at android.media.MediaCodec$EventHandler.handleMessage(MediaCodec.java:1851)
RecordController: at android.os.Handler.dispatchMessage(Handler.java:107)
RecordController: at android.os.Looper.loopOnce(Looper.java:257)
RecordController: at android.os.Looper.loop(Looper.java:342)
RecordController: at android.os.HandlerThread.run(HandlerThread.java:85)
PipelineWatcher: onInputBufferReleased: frameIndex not found (32462); ignored
MediaAdapter: pushBuffer called before start
RecordController: Write error
RecordController: java.lang.IllegalStateException: writeSampleData returned an error
RecordController: at android.media.MediaMuxer.nativeWriteSampleData(Native Method)
RecordController: at android.media.MediaMuxer.writeSampleData(MediaMuxer.java:723)
RecordController: at ze.m(Unknown Source:6)
RecordController: at ze.b(Unknown Source:15)
RecordController: at mz7$b.b(Unknown Source:21)
RecordController: at ks.w(Unknown Source:2)
RecordController: at o00.s(Unknown Source:3)
RecordController: at o00.p(Unknown Source:4)
RecordController: at o00$a.onOutputBufferAvailable(Unknown Source:2)
RecordController: at android.media.MediaCodec$EventHandler.handleCallback(MediaCodec.java:1953)
RecordController: at android.media.MediaCodec$EventHandler.handleMessage(MediaCodec.java:1851)
RecordController: at android.os.Handler.dispatchMessage(Handler.java:107)
RecordController: at android.os.Looper.loopOnce(Looper.java:257)
RecordController: at android.os.Looper.loop(Looper.java:342)
RecordController: at android.os.HandlerThread.run(HandlerThread.java:85)

and the RecordController log just keeps printing over and over until the recording stop.
`

It seems this might be an issue originating from an underlying Android library.
I've looked through the existing issues and saw that #702 reported the same error. It appears that this problem still occurs from time to time.
Unfortunately, I haven't found a consistent way to reproduce it, as it seems to happen randomly.
I'm wondering if there are any known workarounds or potential solutions for this issue. Any help or suggestions would be greatly appreciated.
Thanks!

[pedroSG94]

Hello,

This should be a problem related with this:
https://github.com/pedroSG94/RootEncoder/blob/master/library/src/main/java/com/pedro/library/base/recording/BaseRecordController.java#L108
The error should be that the presentationTimeUs is lower than the previous value. Maybe doing a check to avoid it the error should be solved.

[pedroSG94]

Maybe, this could help:
#1882

[TroyTheGod]

Thank you for the suggestion and for pointing me to the potential fix. I will definitely apply it and monitor the results.

However, since this issue occurs quite rarely and randomly, it might take some time to confirm if the fix is effective.

In the meantime, I have a couple of questions regarding the proposed solution in #1882:

The fix uses Math.max(lastPresentationTimeUs, newPresentationTimeUs) to ensure the timestamp is always increasing. If the newPresentationTimeUs is indeed smaller than the lastPresentationTimeUs when the issue occurs, could this correction lead to a subtle audio-video desynchronization?

I'm also curious about the potential root cause of this problem. As I understand it, the presentationTimeUs is obtained from the MediaCodec buffer info. Does this error imply that MediaCodec itself might occasionally provide a timestamp that is earlier than a previous one?

Any insights on these points would be greatly appreciated. Thanks again for your help!

[pedroSG94]

Hello,

Yes, you are right. You could have sync problems if the problem is produced in all frames or even still break the audio track if you never receive increment values, you will have all time the last higher value in all frames.

I don't know the exact reason about the possible problem with timestamp in AudioEncoder because the timestamp is already checked to be sure that increase here:
https://github.com/pedroSG94/RootEncoder/blob/master/encoder/src/main/java/com/pedro/encoder/BaseEncoder.java#L133
This was done because in some devices, sometimes, the first timestamp was negative breaking all.
It is the last timestamp modification before send to stream or record. The last commit should fix it but maybe is not the best way to do it.

I only can figure that the reason could be in this points:

1 - AudioSource timestamp. An error here is really difficult because only use the system clock timestamp without modifications. (The only possibility is the clock returning a decrement value)

2 - AudioEncoder timestamp. AudioEncoder manipulate timestamp in 3 ways:

• AudioEncoder create a starting timestamp (presentTimeUs) with value when the encoder start. It is to use timestamps starting in 0.
• The timestamp could be fixed after encode the frame to avoid decrement values (line shared above).
• If you are using TimeStampMode.BUFFER, the timestamp is calculated based on the buffer size received by the AudioSource and all timestamps based on clock received from AudioSource are ignored.

3 - BaseRecordController timestamp. This class basically copy the timestamp provided by AudioEncoder. It is exactly the same but I modify the values if you pause/resume the record. This class discount the time on pause to get a video/audio without pauses.
This class also modify the timestamp to start from 0 exactly like AudioEncoder, but in this case use the first frame received as presentTimeUs value.

My main suspicious is the last class, because the line shared should fix all problems in AudioSource and AudioEncoder. At least, I think so.

[TroyTheGod]

Thank you for the very detailed breakdown. It provides a much clearer picture of the entire timestamp lifecycle.

Based on your analysis, it seems the logic within BaseRecordController, especially concerning the pause/resume functionality, is indeed the most probable area to investigate.

Here is my plan: I will deploy the application with additional logging focused on that section and will also apply the timestamp check we discussed earlier. I'll keep a close watch on whether the issue reoccurs and if any audio desynchronization is introduced.

For now, I will close this issue to keep the tracker clean. If the problem persists or new issues arise from the fix, I will reopen it with the additional logs and findings.

Thanks again for your thorough support!

[TroyTheGod]

Hi,

Following up on this issue. Recently, I was able to consistently reproduce a similar problem on the same device.

The scenario is as follows: I start both recording to a local file and streaming via RTMP simultaneously. The process runs normally for about 5-7 minutes, after which the local recording fails with a repeating writeSampleData error:

RecordController: Write error

java.lang.IllegalStateException: writeSampleData returned an error

	at android.media.MediaMuxer.nativeWriteSampleData(Native Method)

	at android.media.MediaMuxer.writeSampleData(MediaMuxer.java:723)

	at ak.m(Unknown Source:6)

	at ak.d(Unknown Source:21)

	at jnc$a.b(Unknown Source:21)

	at l10.w(Unknown Source:2)

	at oc0.s(Unknown Source:3)

	at oc0.p(Unknown Source:4)

	at oc0$a.onOutputBufferAvailable(Unknown Source:2)

	at android.media.MediaCodec$EventHandler.handleCallback(MediaCodec.java:1956)

	at android.media.MediaCodec$EventHandler.handleMessage(MediaCodec.java:1854)

	at android.os.Handler.dispatchMessage(Handler.java:107)

	at android.os.Looper.loopOnce(Looper.java:249)

	at android.os.Looper.loop(Lo.java:337)

	at android.os.HandlerThread.run(HandlerThread.java:85)

Interestingly, while the local recording is failing, the RTMP stream seems unaffected. The logs show that audio packets are still being sent successfully to the server:
I RtmpSender: wrote Audio packet, size 385

The resulting local MP4 file is corrupted. Although it contains an audio track, the codec is marked as unknown. Running ffprobe on the file confirms this:

`$ ffprobe -v error -show_entries stream=index,codec_type,codec_name -of default=noprint_wrappers=1 xxxx.mp4

index=0

codec_name=h24

codec_type=video

index=1

codec_name=unknown

codec_type=audio`

(A valid file would typically show aac as the audio codec name.)

I have an auto-save function that stop and restart the record every hour. It capture five broken video files in a row, and each one failed consistently after 5-7 minutes with the same error.

While the symptom is a broken recording, the error message (writeSampleData returned an error) is different from the original timestamp issue we discussed. I'm not sure if these two problems are related, but it seems to point towards an issue with the MediaMuxer.

Any insights on this would be greatly appreciated.

[pedroSG94]

Hello,

I updated the PR used before for this case and added logs to allow follow the case easier. Try using this and share logs if the error persists:
#1882

[TroyTheGod]

Hi,

I have managed to reproduce this issue again on the same device (Xiaomi 15).

I've attached a clipped portion of the log file

that contains the relevant sections leading up to the error. The full log is quite large, but I can provide it if you need more context.

Hopefully, this additional information is helpful for the investigation.

LogCat2025-09-25.txt

[pedroSG94]

Hello,

I think this is the relevant log:

09-25 17:51:52.213 23960  6923 I RecordController: Audio, ts: 113433795, flag: 0
09-25 17:51:52.213 23960  6923 I RecordController: Audio, ts: 113433795, flag: 0
09-25 17:51:52.214 23960  6995 E MPEG4Writer: do not support out of order frames (timestamp: 113433814 < last: 113433863 for Audio track
09-25 17:51:52.214 23960  6923 I RecordController: Audio, ts: 113433814, flag: 0

After that the write fail always. I think that the problem is the second line.

That buffer was forced to change the ts with my last change but the fix seems that is not enough.
I think that discard out of order frames is a possible solution. I did a new commit in the PR for it:
ae68742

[TroyTheGod]

Hi,

I've tested the fix from commit ae68742, but unfortunately, the issue still occurs on the same device.

While analyzing the new logs, I noticed some interesting behavior. It appears that the same audio timestamp is being processed twice consecutively. For example:

09-26 09:55:13.203 19164 23251 I RecordController: Audio, ts: 71161679, flag: 0
09-26 09:55:13.203 19164 23251 I RecordController: Audio, ts: 71161679, flag: 0

and

09-26 09:55:13.206 19164 23251 I RecordController: Audio, ts: 71161862, flag: 0
09-26 09:55:13.206 19164 23251 I RecordController: Audio, ts: 71161862, flag: 0

I assume the fix in the last commit was intended to handle such duplicate timestamps. However, the recording process still fails shortly after with an MPEG4Writer error indicating an out-of-order frame:

09-26 09:55:13.207 19164 23251 I RecordController: Audio, ts: 71161879, flag: 0
09-26 09:55:13.208 19164 21219 D PipelineWatcher: onInputBufferReleased: frameIndex not found (2184); ignored
09-26 09:55:13.211 19164 23305 E MPEG4Writer: do not support out of order frames (timestamp: 71161879 < last: 71161902 for Audio track

My main question is regarding the error message timestamp: 71161879 < last: 71161902. The last audio timestamp logged by RecordController before the error was 71161879. I'm confused as to where the last timestamp value of 71161902 is coming from.

Any insights on this would be greatly appreciated. I have the full logs available if needed.

LogCat2025-09-26.txt

[pedroSG94]

Hello,

The duplicate timestamp could be because I have a method to avoid decrement ts in the AudioEncoder that use the last timestamp if a decrement timestamp happens.
I did a commit in the PR to avoid it and tried to fix it but I'm not sure if this will work. Test it and let me know the result.

Can you tell me if you are using TimestampMode.BUFFER? (byte default is TimestampMode.CLOCK)
Are you recording without pause/resume and stop/start multiple times?

[TroyTheGod]

Hi,

Thanks for the quick update.

I've tested the latest commit, but it seems to have introduced a regression that prevents the recording from starting. When I call startRecord, the status correctly changes to RecordController.Status.STARTED, but it never transitions to RecordController.Status.RECORDING.

To answer your questions from the previous comment:

TimestampMode: I haven't change this setting, by default, it should be TimestampMode.CLOCK.

Pause/Resume: I am not using the pause/resume functionality in my tests.

Stop/Start Cycles: The issue appears to be random. It can occur on the very first recording attempt, but it can also happen after a few successful start/stop cycles.

Please let me know if there's anything else I can test.

[pedroSG94]

Hello,

I did another commit to the PR to try solve this. Let me know if the issue is solved and share me the error again if not.