element-hq
Since 25.05.4 my homeserver users can't send (larger) videos in EXA any more
Steps to reproduce
- Where are you starting? What can you see? I take a video from inner EXA "add Video" and record e.g. 2 min 1080p videofile
- What do you click? I click send button and see the media uploads starts, then it switches to the chat and the send confirmed tag is still not seen .... seems to be sending in the background
- More steps… after many minutes (> 12 min i still see the empty circle missing the send confirm tag in it (seems further sending the video) but for a 2 min video that was never the case before (with older versions)
Outcome
What did you expect?
I expect a short time of sending period for the just 2 min video file (depending on the internet connection speed of the location from where you send the video) and then a confirm tag in the chat appears for a successful sending.
What happened instead?
I did expect an error message or anything else (timeout etc.) but nothing happens. I tried with a very small video (just 15 sec taken video) that endures a few minutes but after let's say 1or2 min the send confirm tag appears and a message income was signalised by the receipient client. I also tried a video compressor (panda) and with that i compressed a very small file (8 MB for a 1min 20 sec video) then i shared this compressed video with EXA -> just the file appears not the embeded video. The sender can download the file but the receipient can't. There is no download file option.
In earlier versions of EXA it was possible to compress a video and the share it from "panda" to EXA and an emebded video preview appears in the chat.
So i tried to disable the experimental "Media upload through send queue" but here the same An upload is signaled and when the "upload indicationg circle is full" nothing happen -> endless loop
Also here a smaller file comes through but that is not practicable for every day use.
I have no logs from Android so i also don't know how to find those ??
I have send a video nearly 40 MB large from Element Web 1.11.101 with no problems on the same homeserver!
In the old Element i had the choice between sending video with transcoding or just the raw file. With the by a separate video-compressor app like "panda" compressed videos it was very good to take the "send raw video" option. But this option is (still not present in EXA) so i just have the share option but no influence what EXA is doing then.
So because the compressed file maybe can't be transcoded by EXA it is send as file (transcoding fails maybe, can't verify this) but on the other hand the receipient of the file does not see a preview of the video in the chat nor can he or she download the mp4 video file. That's a dilemma
Your phone model
Google Pixel 9a
Operating system version
15
Application version and app store
25.05.4
Homeserver
1.130.0
Will you send logs?
No
Are you willing to provide a PR?
Yes
I believe you're seeing 2 different issues:
- Without logs it's difficult to tell, but your file is probably larger than either what your homeserver allows to upload or maybe some proxy in front of it (the reverse proxy/cloudflare?). When I tested this with a 2 min video I could see it was 194MB after compression and was failing to upload with a
520HTTP status code coming back from cloudflare, and retrying indefinitely, without giving any actual feedback on what's going on. On the app version you mentioned we allowed video files to be less compressed when being uploaded, so that's probably why you're seeing the issue now. - When you use your app to transcode the video yourself, it probably uses some video encoder which is not fully supported by the Android OS in your version so when we try to transcode it to match the commonly supported codecs and dimensions and get a preview image it fails, so we default to sending it as a file as is.
For the 1st issue, if you have control over your homeserver, you can try increasing the media upload limit. On our side, I think we should do several improvements:
- Figure out if we can increase compression while keeping the current default dimensions and a similar image quality.
- When the upload endpoint fails with a status code meaning the server won't accept the media, don't retry and give the user feedback instead.
- Worst case scenario, transcode to the higher quality version, check if it uploads, and if we have some of these errors, transcode to the lower quality and size version and upload that one instead.
So i checked my synapse main yaml file containing the upload size and set the following
# The largest allowed upload size in bytes
#
# If you are using a reverse proxy you may also need to set this value in
# your reverse proxy's config. Notably Nginx has a small max body size by default.
# See https://matrix-org.github.io/synapse/latest/reverse_proxy.html.
#
max_upload_size: 250M
before it was set to 70M (definitely to small for videos that are taken within EXA.
On my NGinx Reverse proxy i set
# Nginx by default only allows file uploads up to 1M in size
# Increase client_max_body_size to match max_upload_size defined in homeserver.yaml
client_max_body_size 0;
the value before was 100M and for test purposes i set it to "zero" now, because anyway the synapse yaml value fences the max.
With that (after restart of both servers (synapse and reverse proxy are on different Vmachines) i was able to upload a video of 1min 25sec with my Android client - but indeed the file was very large as well. I also tested a CamPro X video, in this android app i am able to set the video resolution to 720p so the video is kept smaller before EXA it get to transcode but also this file was not as small as the files i can produce by using a compressor app like panda. Panda use MP4 files H.264 AVC, possible were also H.265 (HEVC) or VP9 In earlier EXA versions 24.x.x it was no problem to share sheet videos from camera app -> to panda -> compress the videos -> share sheet the output -> to EXA and have a very, very small MP4 videofile also with a thumbnail in chat and playable on other clients (EXA old element, element iOS etc. etc.)
Can you give me a hint, how to get any logs from android device that could help you ?
Can you give me a hint, how to get any logs from android device that could help you ?
After reproducing the issue, go to Settings -> report a bug, in the message mention this issue's URL and that should be enough, I think.
I made a further test with a ~2min video file (182MB in size) and shared it with panda . In panda i switched the compressor from native file to messenger optimized and switched in step 2 from H.264 to H.265 (HEVC) as MP4.
After successful compression panda made a 35-36 MB file of the >180MB video. Now i shared the product with EXA and, yes, EXA put it as thumbnail into the message queue and seems to work in background (no send approve) after while (less than a minute!!) EXA set the send approved tag and i could open the file to watch and to check the details. EXA says MP4 file with 44MB video size !!!!
Seems as if the transcoding process in EXA "re-enlarged" the perfect compressed MP4 (H.265) from 36MB to 44MB ???
OK so i have a way to use panda with EXA 25.05.4 ; not understanding why EXA does not offer a "send original file without re-transcoding" when the original file is "better compressed / transcoded" as EXA is able to produce.
That was possible in element before - this option also would be great to have again.
I will send logs by using the native way (not using panda just EXA to upload / transcode)
Confirming this issue.
I have a video which is 6.46MB when uploaded increased to 17MB.
Also it is not possible to send as attachment as it's again change it to video file with larger size.
https://github.com/user-attachments/assets/b43af441-7394-47f1-9f7e-d847d162fa73
https://github.com/user-attachments/assets/942d7479-5088-4996-95ea-e4346dda163d
I've sent a rageshake about this, mentioning this issue. In Element X, the UI shows "sending" where it just spins, then it exits to the timeline showing nothing. No failure, no pending message. In Schildichat next, it at least gets put on the timeline with a little red ! (though with no way to determine the error message). It's unclear to me if there is any processing being done or not, as the original video (in my test) was 70MB, with my limit being set to 50M server-side. (on the schildichat side, if I click on the failed media in the timeline and then info, it shows the original 70MB size. I don't know if that information can be extrapolated to vanilla Element X though).
Since a successful video starts with the "spinning" sending, then changes to a circle that slowly fills up as it uploads/sends. It seems it completely dies during the processing of the video. If the video is too big, it should state that. Some users have reported that it shows with a little ! next to the video, but it also does not mention the error.
This bug and resulting poor UX has users not being able to send any videos at all from mobile. Unless it's coincidentally short/small enough to fit in the upload size.
Note: This appears to be purely client-side for me. There are no logs server-side indicating that it ever attempted to upload the video (the only request I see it hitting is the /_matrix/client/v1/media/config endpoint). I am also not doing any other pre-processing. Purely + -> Photo & Video Library -> pick video -> send.
Trying older versions:
25.05.4- Appears to finish processing, tries to upload to the server. However the sending circle(?) stops, as it appears the file is too large. There is no feedback in the UI, however the media worker server-side reportsAborting connection from IPv6Address(<blah>) because the request exceeds maximum size: (no method yet) (no uri yet)25.06.0- Same problem25.05.3- Works as expected, zero issues
On the latest version, 25.06.3, if I try to send the video as an attachment (the "fallback" mentioned in this PR https://github.com/element-hq/element-x-android/pull/4257) there is no file in the timeline, no error, nothing. The same symptoms as what occurs post-processing mentioned previously. Similar, the only server-side request I see is for /_matrix/client/v1/media/config.
I also tried with a non-video, non-image, file to see what occurs when you try to upload an attachment that is too large (and to avoid any potential processing/transcoding). The same thing occurs. It exists, with no error, message in timeline, etc.
With https://github.com/matrix-org/matrix-rust-sdk/pull/5119, it should be fixed. cc @jmartinesp
With matrix-org/matrix-rust-sdk#5119, it should be fixed. cc @jmartinesp
I think the part about the app not providing feedback to the user will be fixed, but I interpret that as only half of the problem here.
I read this issue as the app trying to compress/transcode videos and it being larger than the allowed media limit of the server (or, sometimes, larger than the video was originally). Not being able to send a video because it is "too large" isn't really a great experience as there's nothing the user can really do about it. Additionally, it seems this problem will be felt more as matrix.org introduces media limits for unpaid users. It will mostly eliminate sending videos entirely. Even at the default synapse upload limit - which is somewhat generous (if we're comparing with Discord's 10M limit) - I am unable to send a 30 second video recorded from my phone. Discord, however, will handle this just fine. It compresses/transcodes my 97.5MB file to 8.1MB, while Element X can't even get it under 50M. The quality on discord is quite poor, however I'm able to send it, which is more important.
Edit: I also did a comparison with Signal, out of curiosity, and the same 30 second video (97.5MB) gets compressed to 9.4MB with High quality setting, and 4.9MB on Standard. The quality (resolution) is noticeably higher than Discord's as well.
I also tried a smaller (26.4MB) 10 second video to see how well Element does. It transcodes it to 25.3MB with very bad noise/graininess. Signal transcodes it to 3.2MB and is visibly a much higher quality, despite the resolution difference (1080x1920 on Element vs 720x1280 on Signal). There's about the same level of detail in each, however the "quality" is much improved on the signal video due to the lack of extreme noise.
I tried the same 30 second video 97.5MB on Element Android (legacy) and it appears to perform identically to Signal. Same file size of (9.4MB) and the same resolution (720x1280).
@MisguidedEmails we're going to iterate on this soon so we'll work on improving the UX.
Comparing the video compression to Discord or Signal is useful, but only if they also use H264 as its codec. I've seen it's possible that they use AV1, which is a lot better for compression, but has limited support - i.e. we'd have to bump the min SDK of the Android app to Android 10 to be able to play videos in this format, or Android 14 to encode them with this codec. Could you check which codec is used in the transcoded videos?
Your comment about EXA vs legacy EA is interesting, because we're using the same library for transcoding in both apps, just with slightly different parameters, which I wouldn't expect to cause so much difference in size. Can I ask you to share the 30s video you used for testing so we can test it too?
@jmartinesp
Comparing the video compression to Discord or Signal is useful, but only if they also use H264 as its codec. ... Could you check which codec is used in the transcoded videos?
Ah, yes. Checking the codec never came to mind. Looks like all the videos I was comparing were h.264.
Your comment about EXA vs legacy EA is interesting, because we're using the same library for transcoding in both apps, just with slightly different parameters, which I wouldn't expect to cause so much difference in size. Can I ask you to share the 30s video you used for testing so we can test it too?
If you would still like it, I'm happy to send it out-of-band (i.e. email). There's nothing odd about the video (it's a video of birds), but I'd prefer to not post it publicly.
I see there's been a few tweaks to the transcoding. I've tested (on 25.07.1) the same 30 sec (97.5MB) video and it sent fine (where previously it would fail).
However I'm seeing it output different codecs on different devices. On Android 16, it's outputting as HEVC (if the input was HEVC), otherwise it seems to retain the codec (h.264 -> h.264). Android 14 outputs h.264 even if the input was HEVC. In either case, the file size seems acceptable (97.5MB -> ~11MB) similar to Signal/Element Legacy. Note: On Android 16, Element Legacy is also now outputting HEVC files as well, Signal remains at h.264.
Comparing h.264 to h.264 the quality seems to be slightly better, if not the same as Signal. Though h.264 is noticeably darker than the HEVC one, perhaps a HDR tonemapping issue.
@MisguidedEmails we recently replaced the transcoding library for 2 reasons:
- The most recent versions of the lib had issues when transcoding certain videos, which forced us to send them as files. This should happen way less often now.
- The new one (official by google) seems more flexible and apparently produces slightly better results with the same tweaked parameters, which is probably what you're seeing.
It's odd though that on Android 16 it's outputting HEVC files, we explicitly ask for H264 ones. I'll need to double check this.
I thought this was solved, but I'm still seeing this problem. The behaviour is also similar:
- No error message
- Message doesn't show in timeline for a few seconds (this is an improvement)
- When it does it has a red
! - Clicking on it only shows/plays the video
- Press and hold shows no additional information (though it says I can add a caption? lol)
- Viewing the source and looking at the model shows
MediaTooLargeToUploadin there somewhere
The video is ~118.7MB and gets compressed to ~66MB
I'd attach the video, but it's too big for GitHub. I can email it, or link it somewhere.
Note: FWIW I'm still seeing that videos are outputted as HEVC.
Note: Element Legacy handles this fine (it compresses it down to ~11MB), quality is also OK, albeit with some washed out colours (probably HDR stuff).
Edit:
- Tested on Pixel 7 Pro (Android 16, Element 25.10.0)
- However, when testing on a Samsung Galaxy A52s 5G (Android 14, Element 25.10.1) the video is compressed vastly, down to
~14MBand then sends successfully. Perhaps this is because it's converting fromHEVC->h.264?- Element Legacy (on Android 16) is also sending as
h.264, which is different to the behaviour I saw previously (whereHEVCinput would lead toHEVCoutput)
- Element Legacy (on Android 16) is also sending as