deckerst
Unable to edit metadata on some video files
Describe the bug I am unable to edit date/time and other metadata on some video files. This issue only applies to a few files. I was able to successfully edit the date and time on hundreds of other videos.
To Reproduce Steps to reproduce the behavior:
- Open the attached video file in Aves
- Select "Edit date & time" in menu
- Attempt to set any date
- A toast message "Failed" pops up. The date is not changed.
Expected behavior The date/time should be changed.
System information and logs: I'm running GrapheneOS on a Pixel 9.
Package: deckers.thibault.aves.libre Installer: org.fdroid.fdroid Aves version: 1.13.9-libre, build 16002 Flutter: stable 3.27.4 Android version: 16, API 36 Android build: 2025110801 Device: Google Pixel 9 Display: pixel ratio=2.625, logical=411.42857142857144x923.4285714285714, physical=1080.0x2424.0 Support: dynamic colors=true, geocoder=false, HDR=true, wide gamut=true Mobile services: not available Connectivity: none System locales: en_DE, de_DE Storage volumes: /storage/emulated/0/ Storage grants: /storage/emulated/0/Movies/, /storage/emulated/0/Pictures/, /storage/emulated/0/DCIM/, /storage/emulated/0/Android/media/ Error reporting: false
https://github.com/user-attachments/assets/3628be5b-0388-47de-a760-6f89889113ff
Thanks for the report and sample.
At first I thought it was a fragmented MP4, as these are not supported for edition in Aves and it's not obvious whether an MP4 is fragmented or not. But taking a closer look at your sample, I see that parsing fails because of some trailing bytes that do not follow the MP4 box architecture. I don't know yet what this trailer is.
Do you know what app/device made this particular sample? Does the same app/device also produce videos that you can edit with Aves?
Unrelated: I see from your GitHub profile that you've been using it since 2013, but this is your very first issue. I'm honoured! ^^
Exiftool output contains (among other things):
Warning : Unknown trailer with invalid atom size
So it's not a basic parsing issue from Aves, and the sample video is actually unusual.
In that case, it's risky to ignore this invalid atom size and just go ahead with editing, as we don't know what we're doing. To go ahead I'd like to identify this mysterious trailer:
I also have this problem that video metadata cannot be modified, usually for videos that I received via the signal app. Here is the relevant part of the log:
11-25 00:34:47.624 12345 12376 W b.e : failed to get XMP by MP4 parser for mimeType=video/mp4 uri=content://media/external/video/media/1000035231
11-25 00:34:47.624 12345 12376 W b.e : java.lang.RuntimeException: box size of zero means 'till end of file. That is not yet supported
11-25 00:34:47.624 12345 12376 W b.e : at org.mp4parser.AbstractBoxParser.parseBox(SourceFile:440)
11-25 00:34:47.624 12345 12376 W b.e : at org.mp4parser.BasicContainer.initContainer(SourceFile:27)
11-25 00:34:47.624 12345 12376 W b.e : at org.mp4parser.IsoFile.<init>(SourceFile:9)
11-25 00:34:47.624 12345 12376 W b.e : at b4.e.b(SourceFile:57)
11-25 00:34:47.624 12345 12376 W b.e : at R3.n1.a(SourceFile:224)
11-25 00:34:47.624 12345 12376 W b.e : at R3.u1.o(SourceFile:18)
11-25 00:34:47.624 12345 12376 W b.e : at Q4.a.g(SourceFile:9)
11-25 00:34:47.624 12345 12376 W b.e : at i5.K.run(SourceFile:115)
11-25 00:34:47.624 12345 12376 W b.e : at n5.i$a.run(SourceFile:4)
11-25 00:34:47.624 12345 12376 W b.e : at p5.h.run(SourceFile:3)
11-25 00:34:47.624 12345 12376 W b.e : at p5.a$a.run(SourceFile:94)
11-25 00:34:47.628 12345 12376 W Y.k : failed to get User Data box by MP4 parser for mimeType=video/mp4 uri=content://media/external/video/media/1000035231
11-25 00:34:47.628 12345 12376 W Y.k : java.lang.RuntimeException: box size of zero means 'till end of file. That is not yet supported
11-25 00:34:47.628 12345 12376 W Y.k : at org.mp4parser.AbstractBoxParser.parseBox(SourceFile:440)
11-25 00:34:47.628 12345 12376 W Y.k : at org.mp4parser.BasicContainer.initContainer(SourceFile:27)
11-25 00:34:47.628 12345 12376 W Y.k : at org.mp4parser.IsoFile.<init>(SourceFile:9)
11-25 00:34:47.628 12345 12376 W Y.k : at Y3.k.f(SourceFile:58)
11-25 00:34:47.628 12345 12376 W Y.k : at R3.n1.a(SourceFile:226)
11-25 00:34:47.628 12345 12376 W Y.k : at R3.u1.o(SourceFile:18)
11-25 00:34:47.628 12345 12376 W Y.k : at Q4.a.g(SourceFile:9)
11-25 00:34:47.628 12345 12376 W Y.k : at i5.K.run(SourceFile:115)
11-25 00:34:47.628 12345 12376 W Y.k : at n5.i$a.run(SourceFile:4)
11-25 00:34:47.628 12345 12376 W Y.k : at p5.h.run(SourceFile:3)
11-25 00:34:47.628 12345 12376 W Y.k : at p5.a$a.run(SourceFile:94)
11-25 00:34:47.629 12345 12367 I flutter : Report error with exception=PlatformException(editMetadata-failure, failed for entry={origin=0, dateModifiedMillis=1763914709704, mimeType=video/mp4, pageId=null, isFlipped=false, uri=content://media/external/video/media/1000035231, sizeBytes=4000359, path=/storage/emulated/0/Pictures/Shared/signal-2025-11-23-14-45-21-836.mp4, rotationDegrees=0, width=720, trashPath=null, height=1280, trashed=false}, java.lang.RuntimeException: box size of zero means 'till end of file. That is not yet supported
From a quick search, this issue might be relevant?
The video was taken on a Samsung Galaxy S21FE with the stock camera app. There are many other videos taken on the S21FE that I am able to edit. It's possible that this video was trimmed with the WhatsApp video editor, though I'm not sure. I'm going to look into this a bit more and possibly provide more sample files later.
Hey, so in total I have 4 files that are broken in this way. These files were all sent through WhatsApp between November 2023 and February 2024. The original videos on my phone are fine. Only the files inside the WhatsApp Video directory (where sent/received videos are stored by WhatsApp) are affected. Perhaps there was a bug in an older version of WhatsApp? There are however several other WhatsApp Videos sent during this timeframe that are okay.
Here is another sample file affected by this issue:
https://github.com/user-attachments/assets/717dc0fb-9e19-4fee-a2e5-0aae20f43173
The remaining two files contain private information that I am not willing to share here, but screenshots of the unknown trailing data are shown below: