Since 25.05.4 my homeserver users can't send (larger) videos in EXA any more

[chrissi55]

Steps to reproduce

1. 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
2. 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
3. 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

[jmartinesp]

I believe you're seeing 2 different issues:

1. 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 520 HTTP 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.
2. 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:

1. Figure out if we can increase compression while keeping the current default dimensions and a similar image quality.
2. 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.
3. 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.

[chrissi55]

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 ?

[jmartinesp]

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.

[chrissi55]

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)

[escix]

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

[escix]

@jmartinesp This may also be relevant I am not sure.

3890

[MisguidedEmails]

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.

[MisguidedEmails]

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 reports Aborting connection from IPv6Address(<blah>) because the request exceeds maximum size: (no method yet) (no uri yet)
• 25.06.0 - Same problem
• 25.05.3 - Works as expected, zero issues

[MisguidedEmails]

On the latest version, 25.06.3, if I try to send the video as an attachment (the "fallback" mentioned in this PR #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.

[Hywan]

With matrix-org/matrix-rust-sdk#5119, it should be fixed. cc @jmartinesp

[MisguidedEmails]

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).