[Bug] Videos with the HEVC encoding are not able to send over iMessage (also possible BT.601 error on Catalina)

[sabogalc]

EDIT - After some testing, Tagavari was able to send a BT.601 video over AirMessage on both 10.13 High Sierra and 11.0 Big Sur. I was able to send the same video over AirMessage on 10.14 Mojave. u/aayyyyyyyyyyyy is not able to send the video through their AirMessage server, which is running on Catalina in a KVM. I am not saying that there is no issue with the BT.601 color profile, but it definitely needs more investigation. In the meantime, I did face quite a few problems with HEVC when performing these tests. Below is my original comment on this issue.

The BT.709 color profile is supported by iMessage, however. Below is some ffmpeg code that transcodes the unsupported videos to the supported profile.

-c:v libx264 -q:v 5 -c:a copy -ab 192k -ar 44100 -crf 15 -color_primaries bt709 -color_trc bt709 -colorspace bt709

Credit where credit is due, taken from u/aayyyyyyyyyyyy at > https://www.reddit.com/r/AirMessage/comments/n3y1ia/cause_for_why_some_videos_fail_to_send/

[sabogalc]

EDIT - The bug in this comment is due to u/aayyyyyyyyyyyy turning on HEVC for their videos. It has nothing to do with the color profile.

This is a very interesting bug. u/aayyyyyyyyyyyy gave a sample video that I will attach below. It's even buggy in the GitHub video player depending on your OS — for me it works on iOS, but it doesn't work on Windows, macOS, or Android. I will describe all of the problems that I observed with this video.

https://user-images.githubusercontent.com/53708281/116945570-05354f00-ac46-11eb-9c51-b586caba74ca.mp4

Firstly, there was no thumbnail/preview image in my Windows file explorer for this video and when I attempted to play it, I was prompted to purchase a new codec for HEVC (despite the fact that the video has a .mp4 extension)

To summarize my test, I sent the same video file through various iMessage forwarding apps, and in all cases, the video was delivered to the person I was sending it to. However, when sent through AirMessage Android and BlueBubbles Android, the video was not playable on iOS or macOS. I am unable to test AirMessage Web because I am not signed up for AirMessage Cloud.

To give a more detailed description of my test, I sent the video through the following apps (in this order)

1. WebMessage (Windows)
2. SMServer (PWA)
3. MyMessage (PWA)
4. BlueBubbles (Windows)
5. BlueBubbles (Android)
6. AirMessage (Android)

These are the results of the test. In WebMessage, the video sent fine and was perfectly playable on the receiver's end, but it showed up as an audio file from the WebMessage app, which @EricRabil described here.

SMServer had the same results as WebMessage, and it also played the video from WebMessage as an audio file.

https://user-images.githubusercontent.com/53708281/116946107-4bd77900-ac47-11eb-976d-06129ba08d61.mp4

MyMessage was similar to WebMessage and SMServer, with the only difference being that attaching the video also seemed a bit buggy. The video was able to be attached/queued with no problems in any of the other apps. LIke SMServer, MyMessage also showed the previous two copies of the video as audio files. The MyMessage video also shows their current issue 35, but that is not related to this test.

BlueBubbles Desktop was very similar to WebMessage and SMServer, with the exception that it was able to play the earlier videos as regular videos, likely due to BlueBubbles's use of ffmpeg. It was only its own video that had the audio file bug.

BlueBubbles Android appeared to work with no problems when looking at the video from the Android app, but when checking it in WebMessage or BlueBubbles Desktop or iOS or macOS it becomes clear that there are in fact some problems with this video.

https://user-images.githubusercontent.com/53708281/116946617-9d343800-ac48-11eb-9edf-9e2fb3473581.mp4

AirMessage behaved the exact same as BlueBubbles Android (I could attach images from other apps if needed, but I feel like it would be redundant).

Overall, this is a very interesting bug, and not one that I'm sure can be solved. It might even be worth reporting this bug to Apple themselves at either this link or this link. Or, perhaps Google/GCam are to blame, and the bug should be reported to them, I'm not sure. Since this bug affects all the apps, I will tag the other developers to hopefully hear their thoughts on it, or at least let them know that it is happening. @sgtaziz, @iandwelker, @zlshames.

[tagavari]

Hmm, this is strange. I can send that video file from AirMessage on my Android phone, and have it play properly across macOS and iOS.

However, I notice the file on receiving devices is not the same as the one I send. I copied the file from a Mac that didn't send the file, and saw that it was converted automatically to airmessage.mov with a color profile of the more common BT.709.

Does the same thing happen for you, or are your devices receiving the original BT.601 video file?

[sabogalc]

This is how the video sent from AirMessage shows up on my Mac. Is there another thing I need to inspect to get more details on it? I right clicked the video file and selected "Get Info". None of the closed menus gave any valuable information. Also, u/aayyyyyyyyyyyy left this comment yesterday

I totally forgot that I just recently turned on hevc for videos after I figured all of this out and it didn't matter. Here's a regular non hevc h264 video https://drive.google.com/file/d/1Bcp5SBRBo2CJE0fxa4xYny-zRF2EUxXW/view?usp=drivesdk That should explain the compatibility issue you're having

So I will reconduct my test with the new video that they provided.

[tagavari]

I opened up the file in QuickTime Player and then hit ⌘ I to open up the inspector. Under Video Details you can see the color information.

The new video file that u/aayyyyyyyyyyyy uploaded worked exactly the same as the first one for me. No issues sending, but it gets converted to .mov on receiving devices. I also find it strange that your file got .mpeg appended to the end of it.

[sabogalc]

Opening the file gave me this Converting... progress bar, but it never advanced from its starting point. The inspector did not give me much information either, unfortunately.

[sabogalc]

I reconducted this test with the updated video supplied by u/aayyyyyyyyyyyy in their comment

I totally forgot that I just recently turned on hevc for videos after I figured all of this out and it didn't matter. Here's a regular non hevc h264 video https://drive.google.com/file/d/1Bcp5SBRBo2CJE0fxa4xYny-zRF2EUxXW/view?usp=drivesdk That should explain the compatibility issue you're having

I found no errors when sending this video (maybe Google Drive automatically corrects the color profile before I can download the video? Is there any way to verify the color profile of my copy of the video?).

The reason I said "problems" instead of "errors" when sending it from AirMessage was because I had an error (-1) when downloading my message history from AirMessage, so I wasn't able to check my previous messages and verify that I was using the same phrasing. I receive that error when I send or receive a new message while my messages are syncing. The reason I sent twice on AirMessage was because after my (-1) error, I was briefly disconnected from my server, and the video did not go through (however, this has nothing to do with the color profile bug).

https://user-images.githubusercontent.com/53708281/117217616-a865a000-adcf-11eb-9871-9cf9d934ecb5.mp4

This is what I was able to get from my Mac.