search

phhusson / treble_experimentations

Notes about tinkering with Android Project Treble
3.36k stars 658 forks source link

[Xiaomi Redmi 8A] Video recording is broken (a64_bgS v123) #1054

Open milankragujevic opened 4 years ago

milankragujevic commented 4 years ago

Device: Xiaomi Redmi 8A (olivelite) OS: phh-gsi v123 a64_bgS AOSP

Recording a video produces a corrupted file with incorrect length, which can be manually repaired with FFmpeg on the PC, but cannot be played properly on the device. When repaired, other than the corrupted moov data in the MP4 file and some broken keyframes leading to green smearing, it works. Sound works but sometimes runs backwards due to the broken container file.

Original: https://milankragujevic.com/uploads/VID_20200105_231943.mp4

This example video is approximately 15s long, but shows up as being 6:27:34 long.

Fixed: https://milankragujevic.com/uploads/VID_20200105_231943-fixed.mp4

This is the same video after being processed with ffmpeg:

ffmpeg -i VID_20200105_231943.mp4 -map 0:v -vcodec copy -bsf:v h264_mp4toannexb VID_20200105_231943.h264
ffmpeg -i VID_20200105_231943.mp4 -map 0:a -acodec copy VID_20200105_231943.m4a
ffmpeg -fflags +genpts -r 25 -i VID_20200105_231943.h264 -i VID_20200105_231943.m4a -codec copy -map_metadata -1 -map_chapters -1 -movflags +faststart VID_20200105_231943-fixed.mp4

It shows up as 16s long and plays normally, as does sound.

Using default camera app from AOSP GSI.

phhusson commented 4 years ago

I've once been told that this issue only happen after some uptime. Do you have this issue right after reboot?

Le dim. 5 janv. 2020 à 23:37, Milan Kragujević notifications@github.com a écrit :

Device: Xiaomi Redmi 8A (olivelite) OS: phh-gsi v123 a64_bgS AOSP

Recording a video produces a corrupted file with incorrect length, which can be manually repaired with FFmpeg on the PC, but cannot be played properly on the device. When repaired, other than the corrupted moov data in the MP4 file and some broken keyframes leading to green smearing, it works. Sound works but sometimes runs backwards due to the broken container file.

Original: https://milankragujevic.com/uploads/VID_20200105_231943.mp4

This example video is approximately 15s long, but shows up as being 6:27:34 long.

Fixed: https://milankragujevic.com/uploads/VID_20200105_231943-fixed.mp4

This is the same video after being processed with ffmpeg:

ffmpeg -i VID_20200105_231943.mp4 -map 0:v -vcodec copy -bsf:v h264_mp4toannexb VID_20200105_231943.h264 ffmpeg -i VID_20200105_231943.mp4 -map 0:a -acodec copy VID_20200105_231943.m4a ffmpeg -fflags +genpts -r 25 -i VID_20200105_231943.h264 -i VID_20200105_231943.m4a -codec copy -map_metadata -1 -map_chapters -1 -movflags +faststart VID_20200105_231943-fixed.mp4

It shows up as 16s long and plays normally, as does sound.

Using default camera app from AOSP GSI.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/phhusson/treble_experimentations/issues/1054?email_source=notifications&email_token=AAAA4OWLZ73MYL5WYXPDOK3Q4JOJVA5CNFSM4KC5P6O2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IEDKBUQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAA4OT3WPXPWPL3GFRTRMTQ4JOJVANCNFSM4KC5P6OQ .

Sovhan commented 4 years ago

Hi, it seems that this bug still happens in v222. By my observations it is indeed linked to uptime, but only locked (as behind lockscreen / screen turned off) uptime. any video taken right after reboot has a few seconds of runtime more than filmed ( for example a 5s clip is 9s in length when opened in vlc), you can take as much clips as you want they all have the same offset. then you lock it an you wait a few minutes ( say two for example) and the offset is right there 2 min 9s for a clip of 5 seconds.

Is there any help I can provide with this?

phhusson commented 4 years ago

There is an option in Treble Settings => Misc about Camera timestamps. Try switching it.

Le mar. 1 sept. 2020 à 15:07, Sovhan notifications@github.com a écrit :

Hi, it seems that this bug still happens in v222. By my observations it is indeed linked to uptime, but only locked (as behind lockscreen / screen turned off) uptime. any video taken right after reboot has a few seconds of runtime more than filmed ( for example a 5s clip is 9s in length when opened in vlc), you can take as much clips as you want they all have the same offset. then you lock it an you wait a few minutes ( say two for example) and the offset is right there 2 min 9s for a clip of 5 seconds.

Is there any help I can provide with this?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/phhusson/treble_experimentations/issues/1054#issuecomment-684839063, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAA4OWXSHPUPL2QYW7SNNLSDTW2BANCNFSM4KC5P6OQ .

Sovhan commented 4 years ago

the bug persists with the monotonic clock option, and is partially fixed with the boottime option ( the video works but is 1 second short). Will keep you posted if anything evolves with uptime.

Thanks for the quick reply and insight !