Conversations
Conversations copied to clipboard
iNPUTmice
video compression fails
when sending a video, the compression process is running and the progress is indicated in the notifications but at the end, the video will be sent without compression. The file sent has the same size like the origin. This behavior is reproducible since some time on Samsung Galaxy A8 smartphones on Android 9.
Ref: https://github.com/iNPUTmice/Conversations/issues/4167 and the linked issues in the lib
/LE: can you record and upload somewhere a sample?
The record part (use camera, video, film something non private) or the upload (have it under 9Mb, zip archive it, attach it here)?
Do test that its size is not shrunken when sent via Conversations first.
So on your device, with video compression set at 720p in Conversations Settings, when you send this file, it's sent as it is at 8Mb?
Here on my AOSP11, it gets compressed to 1057Kb.
That's correct @licaon-kter Additional there's no difference in setting 720p or 360p here. The result are always 8MB file size sent via Conversations.
Can you capture a bit of logcat via adb as the Readme says? The moment when you compress should be the interesting one.
Here's another fail mode, it ~~compresses~~corrupts it to 19Kb or 25K, basically just does a couple of frames only
I have the same issue on my device - Xiaomi Redmi Note 9 Pro (Android 10).
Videos are not compressed.
Logcat:
09-10 20:56:23.030 E/TranscodeEngine(10146): Unexpected error while transcoding.
09-10 20:56:23.030 E/TranscodeEngine(10146): java.lang.IllegalStateException: Failed to stop the muxer
09-10 20:56:23.030 E/TranscodeEngine(10146): at android.media.MediaMuxer.nativeStop(Native Method)
09-10 20:56:23.030 E/TranscodeEngine(10146): at android.media.MediaMuxer.stop(MediaMuxer.java:466)
09-10 20:56:23.030 E/TranscodeEngine(10146): at com.otaliastudios.transcoder.sink.DefaultDataSink.stop(DefaultDataSink.java:218)
09-10 20:56:23.030 E/TranscodeEngine(10146): at com.otaliastudios.transcoder.internal.transcode.DefaultTranscodeEngine.transcode(DefaultTranscodeEngine.kt:132)
09-10 20:56:23.030 E/TranscodeEngine(10146): at com.otaliastudios.transcoder.internal.transcode.TranscodeEngine$Companion.transcode(TranscodeEngine.kt:48)
09-10 20:56:23.030 E/TranscodeEngine(10146): at com.otaliastudios.transcoder.internal.transcode.TranscodeEngine.transcode(Unknown Source:2)
09-10 20:56:23.030 E/TranscodeEngine(10146): at com.otaliastudios.transcoder.Transcoder$1.call(Transcoder.java:102)
09-10 20:56:23.030 E/TranscodeEngine(10146): at com.otaliastudios.transcoder.Transcoder$1.call(Transcoder.java:99)
09-10 20:56:23.030 E/TranscodeEngine(10146): at java.util.concurrent.FutureTask.run(FutureTask.java:266)
09-10 20:56:23.030 E/TranscodeEngine(10146): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
09-10 20:56:23.030 E/TranscodeEngine(10146): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
09-10 20:56:23.030 E/TranscodeEngine(10146): at java.lang.Thread.run(Thread.java:919)
09-10 20:56:23.031 I/Decoder(VIDEO,4)(10146): release(): releasing codec. dequeuedInputs=0 dequeuedOutputs=0
09-10 20:56:23.031 E/MediaMuxer(10146): stop() is called in invalid state 3
09-10 20:56:23.032 W/DefaultDataSink(10146): Failed to release the muxer.
09-10 20:56:23.032 W/DefaultDataSink(10146): java.lang.IllegalStateException: Failed to stop the muxer
09-10 20:56:23.032 W/DefaultDataSink(10146): at android.media.MediaMuxer.nativeStop(Native Method)
09-10 20:56:23.032 W/DefaultDataSink(10146): at android.media.MediaMuxer.stop(MediaMuxer.java:466)
09-10 20:56:23.032 W/DefaultDataSink(10146): at android.media.MediaMuxer.release(MediaMuxer.java:706)
09-10 20:56:23.032 W/DefaultDataSink(10146): at com.otaliastudios.transcoder.sink.DefaultDataSink.release(DefaultDataSink.java:224)
09-10 20:56:23.032 W/DefaultDataSink(10146): at com.otaliastudios.transcoder.internal.transcode.DefaultTranscodeEngine.cleanup(DefaultTranscodeEngine.kt:137)
09-10 20:56:23.032 W/DefaultDataSink(10146): at com.otaliastudios.transcoder.internal.transcode.TranscodeEngine$Companion.transcode(TranscodeEngine.kt:63)
09-10 20:56:23.032 W/DefaultDataSink(10146): at com.otaliastudios.transcoder.internal.transcode.TranscodeEngine.transcode(Unknown Source:2)
09-10 20:56:23.032 W/DefaultDataSink(10146): at com.otaliastudios.transcoder.Transcoder$1.call(Transcoder.java:102)
09-10 20:56:23.032 W/DefaultDataSink(10146): at com.otaliastudios.transcoder.Transcoder$1.call(Transcoder.java:99)
09-10 20:56:23.032 W/DefaultDataSink(10146): at java.util.concurrent.FutureTask.run(FutureTask.java:266)
09-10 20:56:23.032 W/DefaultDataSink(10146): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
09-10 20:56:23.032 W/DefaultDataSink(10146): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
09-10 20:56:23.032 W/DefaultDataSink(10146): at java.lang.Thread.run(Thread.java:919)
It seems that this is a known issue with the transcoding library and it is still not fixed:
https://github.com/natario1/Transcoder/issues/139
@iNPUTmice could you downgrade the transcoding library to version 0.9.1 as suggested here https://github.com/natario1/Transcoder/issues/139 in the issue?
I've also found that unsuccessful transcoding attempt leaves a corrupted unplayable video file in Conversations video directory. Shouldn't a target file be deleted if the transcoding has failed?
We've bumped the version to fix some issues this caused other regressions. But lowering it will only re-introduce the original issues.
@iNPUTmice reading https://github.com/iNPUTmice/Conversations/issues/4167#issuecomment-920216596 it's not clear that 0.10.4 was chosen to fix 0.10.3 or just because 0.10.4 was the latest but 0.9.1 fixed it as well.
Eg. See commit in https://github.com/iNPUTmice/Conversations/issues/4167#issuecomment-920067841 it's 0.10.3
/LE: 0.9.1 does not fix the corruption of the sample in https://github.com/iNPUTmice/Conversations/issues/4306#issuecomment-1098030881 though
In the support channel we've got 2 users testing with 0.9.1 and it compresses fine while current 0.10.4 does not compress at all and sends the uncompressed file.
Besides does 2 users above I've asked 2 more users (but these are my contacts) to test a 0.9.1 APK, reading https://github.com/iNPUTmice/Conversations/issues/4167 I guess the very same contacts.
The one with a Huawei P9 Lite (2017 I think) Android 10 Quicksy Play version, videos are never compressing, but they compress fine with my 0.9.1 APK testing on their device. I only tested samples back in 2021 on my device and since those compressed with 0.9.1 and 0.10.4 fine I've called it solved. :(
Another one OnePlus 6/6T Android 11 or 12, this device got fixed with 0.10.4, compresses fine today, but I asked them to test now with my 0.9.1 APK to confirm that downgrading the version does not break it for them again, and it doesn't.
@iNPUTmice
We've bumped the version to fix some issues this caused other regressions. But lowering it will only re-introduce the original issues.
Looking at the initial compressing lib swap https://github.com/iNPUTmice/Conversations/commit/3075833ab3812f7dbce8886fd750950fb376dd48#diff-49a96e7eea8a94af862798a45174e6ac43eb4f8b4bd40759b5da63ba31ec3ef7R67 you've used 0.10.3 directly (current version at that time?) and THEN bumped to the higher version 0.10.4 to fix its breakage, although I confirmed that 0.9.1 was working correctly.
What do I need to test or show to be able to convince you to downgrade to 0.9.1 (as swapping the lib to https://github.com/linkedin/LiTr might be more work lol) ? At least a beta test or something.
I can confirm that licaon-kter's test build with compression library downgraded to 0.9.1 works fine on Xiaomi Redmi Note 9 Pro (Android 10) and Xiaomi Redmi 9T (Android 10). The official build with 0.10.4 doesn't work on these devices (videos are not compressed).