Skip to content

Conversation

@marcoambrosini
Copy link
Member

@marcoambrosini marcoambrosini commented Jun 29, 2021

  • for some reason the mimetype of the message is application/octet-stream instead of audio/mpeg thus it doesn't display properly in the messageslist
  • Test on iOS devices

Signed-off-by: Marco Ambrosini [email protected]

this.audioStream.getTracks().forEach(track => track.stop())
if (!this.aborted) {
this.blob = new Blob(this.chunks, { type: 'audio/mpeg-3' })
this.blob = new Blob(this.chunks, { type: 'audio/mpeg; codecs=mp4a.40.2' })
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as far I understand, if the type is audio/mpeg then the extension must be .m4a because then it's a mp4 container with only aac audio in it

if we want to use the ".aac" extension instead, the mimetype would be "audio/aac"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This trick is used by both the ios and the android app. But might be it doesn't work with browsers creating such files.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The AudioPreview is shown only when the mimetype of the file starts with audio, so either the extension needs to be .m4a or .aac needs to be added to the server mimetype mappings.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops... I did not refresh before writing; it is the same written below 🤷

@PVince81
Copy link
Member

from what I see we don't have the ".aac" extension mapped in the global mime type file.
however, we do have ".m4a" there, so maybe switching to that one will work: https://github.com/nextcloud/server/blob/stable22/resources/config/mimetypemapping.dist.json#L97

but in the mapping file it maps to "audio/mp4" which is yet another string

@nickvergessen
Copy link
Member

We don't need to change anything in there server. Android and iOS mobile apps send this files already and they work pretty fine on all devices

Signed-off-by: Marco Ambrosini <[email protected]>
@marcoambrosini marcoambrosini force-pushed the bugfix/noid/use-aac-for-voiuce-messages branch from 4421ec6 to a6c8c1c Compare June 30, 2021 07:35
@marcoambrosini
Copy link
Member Author

Thanks for the help, works now :)

let time = today.getFullYear() + '-' + ('0' + today.getMonth()).slice(-2) + '-' + ('0' + today.getDay()).slice(-2)
time += ' ' + ('0' + today.getHours()).slice(-2) + '-' + ('0' + today.getMinutes()).slice(-2) + '-' + ('0' + today.getSeconds()).slice(-2)
return t('spreed', 'Talk recording from {time} ({conversation})', { time, conversation }) + '.mp3'
return t('spreed', 'Talk recording from {time} ({conversation})', { time, conversation }) + '.m4a'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now it's not marked as a voice message anymore roll eyes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also since m4a is not an audio file format, safari doesn't allow playing it in the audio tag.

@nickvergessen
Copy link
Member

So, we need to specify the mimeType on the MediaRecorder.

The following works in Safari on iPad, but this works no where else nor does anything else work on Safari:

this.mediaRecorder = new MediaRecorder(this.audioStream, {
					audioBitsPerSecond: 128000,
					videoBitsPerSecond: 0,
					mimeType: 'video/mp4; codecs="mp4a.40.2"',
				})

@nickvergessen
Copy link
Member

Safari recoring issue is fixed in #5902

But the files recorded with this PR here still don't play

@nickvergessen
Copy link
Member

nickvergessen commented Jun 30, 2021

Hardcore alternate solution

With !MediaRecorder.isTypeSupported('video/mp4; codecs="mp4a.40.2"') we can know if we can produce valid mp3s or not.
When we can (safari) we do as now.

If we can not:

  1. We upload to a new other endpoint
  2. The endpoint uses local ffmpeg (admin given on the server) and transforms it to mp3, if ffmpeg is not there we show a warning in the admin settings and there is nothing we can do.
  3. Puts the mp3 into the Talk/ folder and returns with the path
  4. UI continues with the confirmation dialog (on cancel we send a delete somewhere)

@marcoambrosini marcoambrosini deleted the bugfix/noid/use-aac-for-voiuce-messages branch July 1, 2021 12:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants