Android phones not opening mp4 send in app via iOS

[Buzzword Consulting]

We are developing a music app and the ios version can open videos sent from android but not all androids can open iOS.

All have 9.0 android

Specifically, the google pixel 3 can open them but the Samsung GALAXY S9 and S10 cannot.

Those same phones can also only upload smaller photos to our video feature and rejects larger photos but can accept larger photos for profile image.

Is anyone aware of an issue for Samsung galaxy android devices why they wouldnt be able to open a video rendered into mp4 format on an iOS phone?

From what I understand, the OS matters for the coding but the hardware can effect as well.

S9 is verizon, s10 and pixel 3 are tmobile phones and both ios phones (xs max and 6 plus) are on verizon.

Thanks in advance to anyone who might have some idea.
Katya

 

[svim]

Could you upload one or more of those videos you cannot open using Android so we can try to make any kind of relevant suggestions?
(sharable link to an online storage service like Google Drive, MS OneDrive, Dropbox, etc. or Firefox Send)

 

[Buzzword Consulting]

Yes, thank you. Here is a link. https://drive.google.com/drive/folders/1OcpnApaqGPXibT36-5ZGsJeSEe3c1GvG?usp=sharing

BUT it does open if I send the videos via WhatsApp - although I think they compress - but when we render test videos (combining a trimmed mp3 section and combining with jpg or png into mp4 and send IN APP messaging, androids cannot open ios renders but ios can open android fine.

These are random test renders at various lengths in the folder. Also are 3 pictures - showing it receives a video, tries to retrieve and then says it cannot.

The app is a music compression app. Import a song large, compress file size down with high quality sound intact and users can then also use those songs to combine with a photo and render the mp4 and share with premium users in app messaging. All songs can send but the androids wont open videos rendered by ios and they open mp3's compressed but not audio voice recordings taken in app.

The basic version phase one of this app is on the app store "4fame smash" but the phase 2 with premium features is not yet up, which we are testing.

If you might want to try downloading the test app and signing in, I can try sending you the video in app to experience it.

We dont understand why the limitations of size are impacted in androids own render when its not coded to do so and only samsungs so far - and why the android can open via another method but not inside the app.

 

[svim]

So I did encounter some issues viewing those video samples you posted. Using the MX Player Pro app the video and audio were not a problem but using the VLC and the stock Android media player both apps had would play the audio but with a blank screen. Disabling hardware acceleration in VLC's Settings menu fixed the problem so both the video and audio playback was OK. But this is a very conditional test result, the problem being for most Android users they often rely on the default apps (...with the added issue being MX Player has more than typical hardware and software codec/decoder options that can be set to match the particular hardware configuration of the device, and most people don't alter their app Settings menu very often if at all, so that just skews my results even more.)
Also the problem isn't so much with the file type (mp4) that needs to be addressed, it's how the video and the audio are being encoded. Every video file has a video stream (xvid, h.264, h.265, etc.) and an audio stream (mp3, AAC, flac, etc.) inside it, hopefully synced properly to be in unison during playback. The file type is just the container. So an mp4 movie can consist of a h.265 video stream and an AAC audio stream, or a different mp4 movie might consist of a xvid video stream and a mp3 audio stream. The container is mp4 for both but internally they're quite different. It's those internal codecs that are the issue here.
Looking at the properties of those videos the video specs are:
Resolution: 1350 x 1800
Bitrate: 15 kbps
Frames per second: 0.008
Codec: h264

and the audio:
Bitrate: 250 kbps
Rate: 44100 Hz
Channels: 2
Codec: aac

Oh and it's not so much an issue with WhatsApp but more a matter with text messaging itself. A WhatsApp user exchanging large attachments with another WhatsApp user does not need to worry about the scaling down of high res, large videos or photos (those transfers take place via WhatsApp servers), the big problem is when it involves exchanges between users who are using other different text messaging services, the most common scenario. When MMS is involved, it's a very low bandwidth communication service and since most carriers prefer to retain their uncooperative pissing matches with each other, one the resulting problems all of us as consumers have to cope with are things like small file transfers as text messaging attachments. There are workarounds like relying on online storage sharable links and file transfer services like Firefox Send but they still require extra efforts on our end.

But getting back to your issues with Android and the file viewing problem, does that compression app you're trying out have any options as far as selecting different compression codecs? That 'could' be part of the problem but looking at its description summary it appears to be just for audio files. I have more suspicions the issue is tied more towards how you're combining the video and the audio streams when creating those mp4 files.

 

[Buzzword Consulting]

Thank you.. so while i'm following most of the logic you are stating... I don't have the ability to answer as I am working with my developers for this app development. I can send them this reply and we are wondering two things - would you be willing to advise / test and work with our developer to uncover the issues and how we can best resolve and if so - how much do you charge?

If if you are willing, we could also send you the latest android build for you to try the video inside the app if I send you the files and user account to sign in and see if that shows anything more to you?

There is an additional issue android is having when rendering its own videos inside the app. it is using a compressed audio file and combining with video, but its lowering the sound quality in the combination process which we dont know why and it also is only uploading some images and not others to use, which we thing is size, since we tested a large and small version of a photo that wouldnt upload and it worked with the small file (under 1000 px) but then that theory was debunked because right after that the same android uploaded a photo of 1600 x 800 fine.

We are using existing libraries (open source?) but are willing to pay our team for custom coding whats required to fix the limitations within those libraries but I feel like we need a step up on our technical understanding to better guide our team and you seem to have those skills to work with them as an advisor on what we can customize, implement and test? Are you willing?

I can send you the app apk if interested and please let me know what you charge.

 

[Buzzword Consulting]

Iphone video render sound quality and audio is great and no issues with image uploads and can send back and forth to other iphones.

Android sound is lowered upon mp4 render and can send to ios but not receive from ios and the lowered sound quality makes this feature unable to launch as this is a music app and the sound quality has to stay good.

When we send mp3 song files compressed in the app to each other, they go through but the system is also automatically renaming them to a random set of numbers instead of retailing the song title from the import and compression, so we are having the team research now as well how to custom fix that so it keeps the song title inside the in-app messaging as that is also critical.

The app is called 4fame Smash and is in the store as phase 1 for compression. But it does not yet have the messaging and video functions we are testing now for the next phase.

 

[Dannydet]

Can a mod remove the email address from the above post?

 

[svim]

Something to keep in mind when exchanging video and audio files from iPhone to iPhone is all those transfers take place within Apple's venue. The uploading and downloading go through Apple's server farm, not unlike WhatsApp to WhatsApp exchanges that occur through online WhatsApp servers. But most of us cannot rely on everyone we are in contact with to be using the same services. Unlike say email, where there are seamless exchanges no matter what email service is involved, text messaging is crippled by proprietary standards backed by different, opposing companies. Currently SMS and MMS are the only common thread that all the text messaging services will support, some by default and some with just limited, incidental support. But both protocols are decades old and have problems with today's technology so things like texting compression will continue to be a problem we have to cope with. So sending a video to another iOS user whether the same carrier is involved or not isn't an issue, but sending it elsewhere often will be. When I'm sending an attachment by text I rarely know which carrier or what text messaging app the recipient is using so it's always a matter of just assuming to use something like a sharable link when it involves a file larger than 1MB or so.

As for your offer to do private work, I'll have to pass. Why not post your current work here? Part of of the appeal here at a help forum like AF is being able to learn more from other postings.

 

[Buzzword Consulting]

Something to keep in mind when exchanging video and audio files from iPhone to iPhone is all those transfers take place within Apple's venue. The uploading and downloading go through Apple's server farm, not unlike WhatsApp to WhatsApp exchanges that occur through online WhatsApp servers. But most of us cannot rely on everyone we are in contact with to be using the same services. Unlike say email, where there are seamless exchanges no matter what email service is involved, text messaging is crippled by proprietary standards backed by different, opposing companies. Currently SMS and MMS are the only common thread that all the text messaging services will support, some by default and some with just limited, incidental support. But both protocols are decades old and have problems with today's technology so things like texting compression will continue to be a problem we have to cope with. So sending a video to another iOS user whether the same carrier is involved or not isn't an issue, but sending it elsewhere often will be. When I'm sending an attachment by text I rarely know which carrier or what text messaging app the recipient is using so it's always a matter of just assuming to use something like a sharable link when it involves a file larger than 1MB or so.

As for your offer to do private work, I'll have to pass. Why not post your current work here? Part of of the appeal here at a help forum like AF is being able to learn more from other postings.

Thank you - I really appreciate this help. And sorry, I didnt mean to step out of the box by asking for the private work - It's that we are so confused by the issues and I didnt want to take advantage of your time. But thank you and for this community. I am going to try and get the info about the codecs and if it can be modified. If I can get more specific code or details Ill post it here.

IS this the same for photos too? Can a jpg or png file have different specs inside too? All I know of would be the size of the file - but inside our app currently android can upload some photos but not others and size is not the factor evidently and some jpgs open and some dont and some pngs open and some dont and we have ZERO idea why some are different.

If I attach two pictures, one that will open and one that wont, is there anything anyone can see more than simply size and format?

 

[Buzzword Consulting]

Can a mod remove the email address from the above post?

I removed it. My apologies.

 

[Buzzword Consulting]

So I did encounter some issues viewing those video samples you posted. Using the MX Player Pro app the video and audio were not a problem but using the VLC and the stock Android media player both apps had would play the audio but with a blank screen. Disabling hardware acceleration in VLC's Settings menu fixed the problem so both the video and audio playback was OK. But this is a very conditional test result, the problem being for most Android users they often rely on the default apps (...with the added issue being MX Player has more than typical hardware and software codec/decoder options that can be set to match the particular hardware configuration of the device, and most people don't alter their app Settings menu very often if at all, so that just skews my results even more.)
Also the problem isn't so much with the file type (mp4) that needs to be addressed, it's how the video and the audio are being encoded. Every video file has a video stream (xvid, h.264, h.265, etc.) and an audio stream (mp3, AAC, flac, etc.) inside it, hopefully synced properly to be in unison during playback. The file type is just the container. So an mp4 movie can consist of a h.265 video stream and an AAC audio stream, or a different mp4 movie might consist of a xvid video stream and a mp3 audio stream. The container is mp4 for both but internally they're quite different. It's those internal codecs that are the issue here.
Looking at the properties of those videos the video specs are:
Resolution: 1350 x 1800
Bitrate: 15 kbps
Frames per second: 0.008
Codec: h264

and the audio:
Bitrate: 250 kbps
Rate: 44100 Hz
Channels: 2
Codec: aac

Oh and it's not so much an issue with WhatsApp but more a matter with text messaging itself. A WhatsApp user exchanging large attachments with another WhatsApp user does not need to worry about the scaling down of high res, large videos or photos (those transfers take place via WhatsApp servers), the big problem is when it involves exchanges between users who are using other different text messaging services, the most common scenario. When MMS is involved, it's a very low bandwidth communication service and since most carriers prefer to retain their uncooperative pissing matches with each other, one the resulting problems all of us as consumers have to cope with are things like small file transfers as text messaging attachments. There are workarounds like relying on online storage sharable links and file transfer services like Firefox Send but they still require extra efforts on our end.

But getting back to your issues with Android and the file viewing problem, does that compression app you're trying out have any options as far as selecting different compression codecs? That 'could' be part of the problem but looking at its description summary it appears to be just for audio files. I have more suspicions the issue is tied more towards how you're combining the video and the audio streams when creating those mp4 files.

Can you view the attachment and let me know if that makes sense at all? Me texting per your reply and thinking since the audio compression app was created to import mp3 and wav files from external source like drive, dropbox, icloud - and then we are now adding this video render tool inside to combine those compressed files with a photo into an mp4, but if you're saying that the iphone videos I send are aac - then is that why android is not reading them? And if we can override or code that to instead render with mp3 inside it would be opened by android user?

 

[Buzzword Consulting]

Can you view the attachment and let me know if that makes sense at all? Me texting per your reply and thinking since the audio compression app was created to import mp3 and wav files from external source like drive, dropbox, icloud - and then we are now adding this video render tool inside to combine those compressed files with a photo into an mp4, but if you're saying that the iphone videos I send are aac - then is that why android is not reading them? And if we can override or code that to instead render with mp3 inside it would be opened by android user?

And this is the error we got just now rendering a video on the android when trying to playback. See attached image.

I also saw for android these specs (attached) so, since its 1350x1800 and thats bigger than the listed amount and it says aac-lc which is not aac - is that it? or is aac-lc and aac the same...

 

[svim]

Can you view the attachment and let me know if that makes sense at all? Me texting per your reply and thinking since the audio compression app was created to import mp3 and wav files from external source like drive, dropbox, icloud - and then we are now adding this video render tool inside to combine those compressed files with a photo into an mp4, but if you're saying that the iphone videos I send are aac - then is that why android is not reading them? And if we can override or code that to instead render with mp3 inside it would be opened by android user?

AAC and mp3 are very common codecs so it seems very unlikely for a media player in any platform not being able to handle content with either. When it involves h.264 and mp3 because they're so common it often involves hardware decoding (the issue being hardware decoding is less taxing on system resources than software decoding, as a general but not absolute rule).
Since the writer of that message doesn't believe me, they should just check those video files out themselves. The stats I posted previously were just the result of a copy and paste while I was just looking at their internal specs. Both the MX Player Pro app on my phone, and the SMPlayer application on my desktop PC (SMPlayer being a GUI front end to mplayer) showed similar results
Just checked using ffmpeg to confirm:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'renderExportVideoNew 5.MP4':
Metadata:
major_brand : mp42
minor_version : 1
compatible_brands: isommp41mp42
creation_time : 2019-11-18T03:38:55.000000Z
Duration: 00:00:30.00, start: 0.000000, bitrate: 288 kb/s
Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 250 kb/s (default)
Metadata:
creation_time : 2019-11-18T03:38:55.000000Z
handler_name : Core Media Audio
Stream #0:1(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1800x1800, 35 kb/s, 0.07 fps, 0.07 tbr, 600 tbn, 1200 tbc (default)
Metadata:
creation_time : 2019-11-18T03:38:55.000000Z
handler_name : Core Media Video

 

[Buzzword Consulting]

AAC and mp3 are very common codecs so it seems very unlikely for a media player in any platform not being able to handle content with either. When it involves h.264 and mp3 because they're so common it often involves hardware decoding (the issue being hardware decoding is less taxing on system resources than software decoding, as a general but not absolute rule).
Since the writer of that message doesn't believe me, they should just check those video files out themselves. The stats I posted previously were just the result of a copy and paste while I was just looking at their internal specs. Both the MX Player Pro app on my phone, and the SMPlayer application on my desktop PC (SMPlayer being a GUI front end to mplayer) showed similar results
Just checked using ffmpeg to confirm:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'renderExportVideoNew 5.MP4':
Metadata:
major_brand : mp42
minor_version : 1
compatible_brands: isommp41mp42
creation_time : 2019-11-18T03:38:55.000000Z
Duration: 00:00:30.00, start: 0.000000, bitrate: 288 kb/s
Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 250 kb/s (default)
Metadata:
creation_time : 2019-11-18T03:38:55.000000Z
handler_name : Core Media Audio
Stream #0:1(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1800x1800, 35 kb/s, 0.07 fps, 0.07 tbr, 600 tbn, 1200 tbc (default)
Metadata:
creation_time : 2019-11-18T03:38:55.000000Z
handler_name : Core Media Video

Oh sorry! The message was interpreted wrong - the text saying "weird he says that" was meaning - "Interesting! maybe this is why its not working" not at all not believing you. We meant that since our app is coded to compress mp3 and wav files only, and cant import aac, if the fact that its rendering mp4s with aac perhaps causing the issue that android has based on the app code - we totally see and agree that the videos have the aac. We just didnt know if maybe thats whats making it not open since our app was importing only mp3 and wav.

But it sounds like youre saying androids can read aac too. So - there is definitely something wrong with the codecs but... I guess we dont know what?

Super sorry if my technical message is lacking - You have given us such great insight! We feel like your answers and info have led us closer to figuring out the issue but we cant figure out what - I thought maybe ios to ios could get videos and open in app bc its the same network and using aac as default. And that maybe if we forced it to be h264 and mp3 instead that android would open the mp4 but per your reply and that specs image, I guess androids can open aac too.

I dont understand why the google pixel 3 will open the videos fine but the samsungs wont. and they are all 9.0 android and can read those file types. :/

 

[svim]

And this is the error we got just now rendering a video on the android when trying to playback. See attached image.

I also saw for android these specs (attached) so, since its 1350x1800 and thats bigger than the listed amount and it says aac-lc which is not aac - is that it? or is aac-lc and aac the same...

I'm a bit baffled by all this too. But uploading video to online storage sites shouldn't involve any compression schemes either in the uploading or downloading process. With something like Google Photos than yes, but that's a similar but different scenario. If the online storage services like Dropbox were altering content, that would be a notable event. Carriers can get away with it but again, that's also a similar but different scenario. (Plus carriers can get away with a lot of stuff because of the bags of money and hookers their lobbyists give to our Congress critters.) Archiving and backing up files are a separate issue than just transferring them even if the distinction between the two is blurred.
Anyway, I'm still thinking it's not a matter of the codecs involved (again, none of them appear to be non-standard or unique), but since there's apparently something going on with compressing the video and the audio streams involving separate apps, something is going on involving how the two are merged together (or combined back together again if that's the case).
Also, is there also testing going on involving transferring files via text messaging??? If yes it might be better to get the file type/codec/file creation matter straightened out first.

 

[svim]

.....

I dont understand why the google pixel 3 will open the videos fine but the samsungs wont. and they are all 9.0 android and can read those file types. :/

Not that it pertains to this perplexing issue but more as just an observation-- those choices for Android smartphones (Pixel 3, Galaxy S9 and S10) are or were flagship models, the issue being the majority of phones out there are not. Just to toss in some added confusion sometimes in the development stage targeting the 'lowest common denominator' works out better. Having video files that have their video and audio streams compressed to a maximum while retaining quality is an optimal state and results in a smaller file size but they also involve more system resources during playback, the issue being flagship models tend to have more RAM, more capable CPU and GPU resources, etc. than lessor models. Don't mean to be snarky, again, just an observation.

The attached file below is a reprocessed mp4 of your posted 'renderExportVideoNew 5' video. The video stream is h.265 and the audio is mp3. Is it playable in your Android test phones?

 

[Buzzword Consulting]

I am going to ask my developer to check this thread and see if perhaps he can share something more and if its something you might have insight in - that would amazing. Its really the samsung phones default players that seem to b e the issue.

 

[Buzzword Consulting]

When i tried to play the above video "test.mp4" it's having the same codec not support. Another thing is while i sent videos from my iphone (recorded) then also it's show the same codec issue

While with this checked with different codec formats like h.264, h.265, mpeg4 etc. but when i change resolution of image with preset 1280 X 720 and 30p then it works fine (Audio codec is aac)

So is there any specification or combination of resolution and codec for samsung devices

Not working case in general
Case 1 : Send video form my iPhone to Samsung device via firebase
Case 2 : Send Generated Video from my iPhone to Samsung device via firebase

So dose firebase change any format of video or codec or supported type to videos ? because in general i see that audio(s) are playing well

 

[techprevue]

it can be an encoding or codec issue.

 

[svim]

When i tried to play the above video "test.mp4" it's having the same codec not support. Another thing is while i sent videos from my iphone (recorded) then also it's show the same codec issue.....

I'm not surprised that test.mp4 file is a problem, while h.264 has a really wide range of support, h.265 not as much. Playback involving h.265 is often software based so it'll be app-specific (the issue being default media players tend to focus more on basic support for most commonly used situations).

.....
So is there any specification or combination of resolution and codec for samsung devices.....
/QUOTE]
I don't think the codecs being used are this particular issue. AAC and h.264 are almost generic at this point, and have been for several years. As for resolution, I tend to doubt that's an issue either since screen resolution and aspect ratios are such big variables. Most of the time whatever we're watching is being scaled up or down in accordance to the display at the time.
... and anecdotally, out of curiosity I just fired up a very dated but still kicking Galaxy S3 (KitKat) and that 'renderExportVideoNew 5' file was viewable using the MX Player Pro and the VLC apps, but the default video app just showed a blank screen with a very brief (two second) audio bleep. No clue as to whether this does or doesn't add any useful input but given how common those codecs are it just doesn't seem like either is directly related.

.....
Not working case in general
Case 1 : Send video form my iPhone to Samsung device via firebase
Case 2 : Send Generated Video from my iPhone to Samsung device via firebase

So dose firebase change any format of video or codec or supported type to videos ? because in general i see that audio(s) are playing well

Looking up info online for Firebase, file transfers go through their online servers so it would highly unlikely there are scaling/file alterations involved when you're uploading or downloading on-the-fly. Again, it's the carriers taking it upon themselves to scaled down higher res photos and videos when they have to interact with other, when you're interacting with Firebase that's a different matter. Online file storage services like Firebase should not be altering any archiving/backing up as you use them. You can confirm this by simply checking the original file size of a file, to the file size of that same file uploaded to Firebase, and then to the file size of a downloaded copy of that same file -- the original file size should be bit-by-bit the same as the copy. (Use bit size as opposed to something like megabyte size, a really subtle change might not be noticeable using MBs but even a few changes in text will be more evidence using bits)