[Feature Request] Option to change container only without reencoding

[flanter21]

Firstly, thank you for such a useful, well maintained program.

My problem is that I have a conversation that was 5.3GB big according to the program. First I used -f html -c clone to create the export, but then I found out audio files wouldn't play (because they're in an x-caf container). So I tried -c full, however, it was taking really long, when my original try took seconds.

Looking at the code for using ffmpeg to convert audio and video,

• imessage-exporter/src/app/compatibility/converters/audio.rs

AudioConverter::Ffmpeg => vec!["-i", from_path, to_path],

• imessage-exporter/src/app/compatibility/converters/audio.rs

VideoConverter::Ffmpeg => vec!["-i", from_path, to_path],

I realised both audio and video are re-encoding (as no codec has been specified in either case), so it was going to take a long time to reencode all that.

This is the default behaviour of ffmpeg per the DESCRIPTION section of the manpage

       Some simple examples follow.

       •   Convert an input media file to a different format, by re-encoding media streams:

                   ffmpeg -i input.avi output.mp4

Afaik, afconvert/audiotoolbox can only create caf or m4a, so ffmpeg would be required for this option, but the command should rather be

• ffmpeg -i from_path -c copy to_path or
• ffmpeg -i from_path -c:a copy -c:v copy -c:s copy copy to_path

This would avoid re-encoding, so the speed would be very similar to the -c clone option, while improving compatibility and it would avoid quality loss.

The last part of the equation would be the container to use. ffmpeg -muxers would show the potential container formats, which can either be given as to_path.ext or specified with the -f parameter in ffmpeg.

Looking at https://en.wikipedia.org/wiki/HTML_audio#Supported_audio_coding_formats, I suggest using webm for opus audio messages and mp4 for everything else.

Sorry for the long issue, hopefully this makes sense. I would also like if this option could override the use of afconvert on macos. Feel free to ask me if you didn't understand anything or would like some more detail.

[ReagentX]

The problem here is that imessage-exporter can't guarantee that the original codecs are compatible with the target format/platform.

[flanter21]

Can it not then use ffprobe to find the original codecs and if it's not in a list of accepted codecs (eg. aac, mp3, opus, hevc, h264), only then re encode, instead of re-encoding everything irrespective of whether they're already using well-supported codecs. Maybe there could be several options, like -c remux to only change the container or -c compatible to re encode everything to h264 and aac?

I also realised that I got subtitles wrong, it should be -c:s mov_text for mp4 since that is afaik the only way to get subtitles in a mp4 container, but that has issues since it will only be seen by safari, otherwise subtitles would need to be a in a different file, usually a vtt. I believe you can also add vtt codec subtitles to webm, but webm can't have hevc or h264 and I believe most browsers don't support mkv.

But to avoid remuxing at all, maybe a demuxer library like this could be used. It could be optional the same way the custom css is, though that would add another part that could fail and I think it would be better to avoid javascript or wasm.

Also on that note, could you add a fallback download link in the <video> and <audio> tags. eg.

diff a/chat.html b/chat.html
 <video controls>
     <source src="attachments/90/528" type="quicktime">
     <source src="attachments/90/528">
+    Attachment could not be displayed in your browser. Please <a href="attachments/90/528">download it instead</a>
 </video>

It would avoid having to manually go to the location of the file. Maybe it could also say the container and codec used in the type attribute of <source>.

[ReagentX]

I created a branch/PR that incorporates some of the prospective changes, if you have time, test it out and let me know if it addresses your suggestions.

[flanter21]

I created a branch/PR that incorporates some of the prospective changes, if you have time, test it out and let me know if it addresses your suggestions.

Hey I've tested it. It works almost exactly as I hoped. Thank you so much this is amazing. The only issue I had was that some videos were in hevc, which didn't play in firefox on Mac for me (which is weird since I heard hevc works on firefox on linux now). An option to convert hevc to h264 to improve compatibility might be nice, though is pretty moot when I can do that manually.

[ReagentX]

What is the file name extension of the affected video files?

[flanter21]

What is the file name extension of the affected video files?

mp4

[ReagentX]

According to the Firefox docs, Firefox enables HEVC on:

• Windows from Firefox 134 using either hardware (on devices that support it, where the range is the same as Edge) or software (on Windows the user must pay for and install an extension)
• macOS from Firefox 136 using either hardware or software.
• Linux from Firefox 137 using either hardware or software (via the system ffmpeg).
• Android from Firefox 137 using hardware only.

I am able to play HEVC content in Firefox on macOS, per the test here:

[flanter21]

According to the Firefox docs, Firefox enables HEVC on:

• Windows from Firefox 134 using either hardware (on devices that support it, where the range is the same as Edge) or software (on Windows the user must pay for and install an extension)
• macOS from Firefox 136 using either hardware or software.
• Linux from Firefox 137 using either hardware or software (via the system ffmpeg).
• Android from Firefox 137 using hardware only.

I am able to play HEVC content in Firefox on macOS, per the test here:

I'm pretty sure I was up to date at the time of the comment, but yeah hevc works for me too now. Thanks!