Background: Could having audio as stream 0 and video as stream 1 explain why my MPG will play on OSX QuickTime Player, but not Win10 Movies & TV?
I've got an mpg file with audio as stream 0 and video as stream 1.
It plays fine under OSX QT Player, but not under Win10's default app.
For lack of a better idea, I'm assuming the unusual stream ordering is my problem, and I'm trying to fix it with ffmpeg.
What luck! https://trac.ffmpeg.org/wiki/Map describes exactly my case!
Re-order streams
The order of your -map options determines the order of the streams in the output. In this example the input file has audio as stream #0 and video as stream #1 (which is possible but unusual). Example to re-position video so it is listed first, followed by the audio:
ffmpeg -i input.mp4 -map 0:v -map 0:a -c copy output.mp4
This example stream copies (re-mux) with -c copy to avoid re-encoding.
I use exactly that command, but the flipping doesn't seem to work, like so:
ffprobe -hide_banner myfile.trimmed.mpg
[h264 # 000001b965b569c0] Increasing reorder buffer to 2
Input #0, mpeg, from 'myfile.trimmed.mpg':
Duration: 00:02:41.09, start: 0.500000, bitrate: 6255 kb/s
Stream #0:0[0x80]: Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:1[0x1e2]: Video: h264 (High), yuv420p(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc
ffmpeg -hide_banner -i myfile.trimmed.mpg -map 0:v -map 0:a -c copy myfile.trimmed.flipped.mpg
[h264 # 000001fa0ee94680] Increasing reorder buffer to 2
Input #0, mpeg, from 'myfile.trimmed.mpg':
Duration: 00:02:41.09, start: 0.500000, bitrate: 6255 kb/s
Stream #0:0[0x80]: Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:1[0x1e2]: Video: h264 (High), yuv420p(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc
[mpeg # 000001fa0ee88dc0] VBV buffer size not set, using default size of 230KB
If you want the mpeg file to be compliant to some specification
Like DVD, VCD or others, make sure you set the correct buffer size
[mpeg # 000001fa0ee88dc0] ac3 in MPEG-1 system streams is not widely supported, consider using the vob or the dvd muxer to force a MPEG-2 program stream.
Output #0, mpeg, to 'myfile.trimmed.flipped.mpg':
Metadata:
encoder : Lavf58.45.100
Stream #0:0: Video: h264 (High), yuv420p(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 59.94 fps, 59.94 tbr, 90k tbn, 59.94 tbc
Stream #0:1: Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream mapping:
Stream #0:1 -> #0:0 (copy)
Stream #0:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 9570 fps=0.0 q=-1.0 Lsize= 123008kB time=00:02:40.95 bitrate=6260.6kbits/s speed= 518x
video:114772kB audio:7545kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.565047%
ffprobe -hide_banner myfile.trimmed.flipped.mpg
[h264 # 0000021edcf36ac0] Increasing reorder buffer to 2
Input #0, mpeg, from 'myfile.trimmed.flipped.mpg':
Duration: 00:02:41.09, start: 0.500000, bitrate: 6255 kb/s
Stream #0:0[0x80]: Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:1[0x1e2]: Video: h264 (High), yuv420p(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc
What, what?!
The command output looks like it did exactly what I asked, but the resulting file has the same stream ordering as the original file. What am I missing?
One possible clue: It looks like the audio stream starts before the video stream. The smallest pkt_pts_time I see in the audio stream is 00:00:00.500000, while the smallest I see in the video stream is 0:00:01.912967. Could that matter?
Tricky one this seemed at first. I wondered if this old FFmpeg trac ticket might hold the key:
There is no stream order in mpeg-ps.
what you see from ffmpeg output order is likely just if a audio or video packet comes first
But that's not actually the problem; however it is worth noting that your file has a .mpg extension, when you should be trying to output an MP4 or MKV. ".mpg" is only valid if it contains legacy MPEG-1 and MPEG-2 formats. H.264 or AAC elementary streams are invalid.
If you've not created this file yourself, it's either a mislabelled container (e.g. MKV or MP4), or someone has bizarrely muxed the streams to .mpg. Note how FFmpeg warns you of the incompatible codec during your stream reorder attempt.
MPEG-PS is a packetised format, so there's no elementary streams as such. If it's genuinely an MPEG-PS file, it may be that an audio sample appears first. Either way, you should abandon using .mpg for your formats.
See the end of this answer for how you can use FFprobe to fairly accurately identify the actual container format.
I had another think, and finally a neuron reminded me about how the -map output follows the order of assignment.
An important thing to note is that -map 0:v -map 0:a doesn't quite work how you might expect it with files containing more than one of a stream type, as that syntax matches all applicable streams of that type.
Gyan has clarified that if you have a file with exactly one video and one audio stream, -map 0:v -map 0:a will function equivalently to -map 0:1 -map 0:0.
If you want to use the 0:a syntax, if you have more than one audio for example you must address them individually, otherwise FFmpeg will group them when reordering. -map 0:a will move both audios; -map 0:a:0 will move just the first audio.
The alternative, remembering to always check stream order in every file you manipulate, is to specify absolute stream numbers in the order you wish to have them in the output. So, -map 0:1 -map 0:0 if your video is the second of two streams in the source file.
For files with one video and one audio stream, you can use either method.
Tests
I created an .MP4 file containing one H.264 video as stream 0:0 and one MP3 audio as stream 0:1.
Original file:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'C:\temp\video-audio.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.78.100
Duration: 00:05:00.30, start: 0.000000, bitrate: 422 kb/s
Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 421 kb/s, 23.98 fps, 23.98 tbr, 11988 tbn, 47.95 tbc (default)
Metadata:
handler_name : GPAC ISO Video Handler
vendor_id : [0][0][0][0]
Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 180 kb/s (default)
Metadata:
handler_name : SoundHandler
vendor_id : [0][0][0][0]
Then I fed it back to FFmpeg:
ffmpeg -i C:\temp\video-audio.mp4 -map 0:1 -map 0:0 -c copy C:\temp\swapped.mp4
(equivalent to -map 0:a -map 0:v in this case)
Result: swapped streams; MP3 audio stream is 0:0, H.264 video stream is 0:1
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'C:\temp\swapped.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.78.100
Duration: 00:05:00.30, start: 0.000000, bitrate: 422 kb/s
Stream #0:0(und): Audio: mp3 (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 180 kb/s (default)
Metadata:
handler_name : SoundHandler
vendor_id : [0][0][0][0]
Stream #0:1(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 421 kb/s, 23.98 fps, 23.98 tbr, 11988 tbn, 47.95 tbc (default)
Metadata:
handler_name : GPAC ISO Video Handler
vendor_id : [0][0][0][0]
This appears to accomplish what you want :-)
ffmpeg -i INPUTFILE -map 0:1 -map 0:0 -c copy OUTPUTFILE.mp4 or
ffmpeg -i INPUTFILE -map 0:v -map 0:a -c copy OUTPUTFILE.mp4
Reminder:
For files with one video and one audio stream, you can use either method above.
For files with multiple audios or videos, determine the stream index and specify using the more granular 0:v:0, 0:a:0 syntax.
ffmpeg -i INPUTFILE shows a file's numeric stream IDs, and this may be quicker for the odd file. However, numeric references skips the sanity check of specifying only audio, video, subtitles etc. when reordering.
FFmpeg's Stream Specifiers and Advanced Options documentation is worth bookmarking.
Further reading:
FFmpeg Trac documentation for -map and their main documentation for -map.
This previous Q&A on Video.SE, which in turn references this answer which talks about the -disposition switch. NB that -disposition is used for indicating which streams the player 'should' consider as default (Section 5.4, "Main Options" in the FFmpeg docs), not doing any physical stream reordering.
(big thanks to Gyan for being so observant!)
Using FFprobe to identify container
FFprobe can do a best-effort detection of the real container format, ignoring the extension. Here's an example of my demo "swapped.mp4", renamed to .mpg:
ffprobe -hide_banner -show_error -show_format -i "C:\temp\swapped.mpg"
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'C:\temp\swapped.mpg':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.78.100
Duration: 00:05:00.30, start: 0.000000, bitrate: 422 kb/s
Stream #0:0(und): Audio: mp3 (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 180 kb/s (default)
Metadata:
handler_name : SoundHandler
vendor_id : [0][0][0][0]
Stream #0:1(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 421 kb/s, 23.98 fps, 23.98 tbr, 11988 tbn, 47.95 tbc (default)
Metadata:
handler_name : GPAC ISO Video Handler
vendor_id : [0][0][0][0]
[FORMAT]
filename=C:\temp\swapped.mpg
nb_streams=2
nb_programs=0
format_name=mov,mp4,m4a,3gp,3g2,mj2
format_long_name=QuickTime / MOV
start_time=0.000000
duration=300.301000
size=15847817
bit_rate=422184
probe_score=100
TAG:major_brand=isom
TAG:minor_version=512
TAG:compatible_brands=isomiso2avc1mp41
TAG:encoder=Lavf58.78.100
[/FORMAT]
Note major_brand=isom (ISO Base Media file format), format_name, format_long_name and so on.
A true MPEG-2 video I produced last month (a DVD rip) outputs this:
ffprobe -hide_banner -show_error -show_format -i "C:\temp\opera.mpg"
Input #0, mpeg, from 'C:\temp\opera.mpg':
Duration: 02:15:23.71, start: 66240.530111, bitrate: 4194 kb/s
Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, smpte170m, top first), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
Side data:
cpb: bitrate max/min/avg: 7000000/0/0 buffer size: 1835008 vbv_delay: N/A
Stream #0:1[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
[FORMAT]
filename=C:\temp\opera.mpg
nb_streams=2
nb_programs=0
format_name=mpeg
format_long_name=MPEG-PS (MPEG-2 Program Stream)
start_time=66240.530111
duration=8123.712000
size=4259503237
bit_rate=4194637
probe_score=26
[/FORMAT]
FFprobe correctly reports format_name as mpeg and format_long_name as MPEG-PS.
Everything Chris said was right, and a big help. The original .MPG with H264 video inside came from TivoDecoder; I never thought to question whether that container was valid for that video format, and when QT was willing to play it, I figured the ffprobe warning wasn't a big deal. :)
Remuxing to an MP4 container gave me something Windows will play.
ffmpeg -hide_banner -ss 00:17:24 -i myfile.mpg -t 00:02:40 -c copy myfile.trimmed.mp4
[h264 # 000002d5d73f4040] Increasing reorder buffer to 2
[mpegts # 000002d5d73edbc0] PES packet size mismatch
[mpegts # 000002d5d73edbc0] Packet corrupt (stream = 1, dts = 8467425232).
[mpegts # 000002d5d73edbc0] Could not find codec parameters for stream 2 (Unknown: none ([151][0][0][0] / 0x0097)): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[mpegts # 000002d5d73edbc0] PES packet size mismatch
[mpegts # 000002d5d73edbc0] Packet corrupt (stream = 1, dts = 8467425232).
Input #0, mpegts, from 'myfile.mpg':
Duration: 00:30:00.63, start: 92282.982578, bitrate: 6249 kb/s
Program 1
Stream #0:0[0x1aab]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc
Stream #0:1[0x1abf]: Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:2[0x1ac1]: Unknown: none ([151][0][0][0] / 0x0097)
[mp4 # 000002d5d7e90540] track 1: codec frame size is not set
Output #0, mp4, to 'myfile.trimmed.mp4':
Metadata:
encoder : Lavf58.45.100
Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 59.94 fps, 59.94 tbr, 90k tbn, 90k tbc
Stream #0:1: Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 9570 fps=0.0 q=-1.0 Lsize= 122587kB time=00:02:39.99 bitrate=6276.6kbits/s speed= 462x
video:114772kB audio:7545kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.220873%
ffprobe -hide_banner -show_error -show_format -i myfile.trimmed.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'myfile.trimmed.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.45.100
Duration: 00:02:40.96, start: 0.000000, bitrate: 6239 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 5890 kb/s, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc (default)
Metadata:
handler_name : VideoHandler
Stream #0:1(und): Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz, 5.1(side), fltp, 384 kb/s (default)
Metadata:
handler_name : SoundHandler
Side data:
audio service type: main
[FORMAT]
filename=myfile.trimmed.mp4
nb_streams=2
nb_programs=0
format_name=mov,mp4,m4a,3gp,3g2,mj2
format_long_name=QuickTime / MOV
start_time=0.000000
duration=160.960000
size=125529106
bit_rate=6239021
probe_score=100
TAG:major_brand=isom
TAG:minor_version=512
TAG:compatible_brands=isomiso2avc1mp41
TAG:encoder=Lavf58.45.100
[/FORMAT]
I've got a new problem with the video and audio being massively out of sync, but I'll ask that as a separate question.
It's very tricky but possible to reorder audio streams with ffmpeg tool.
If you know the source streams' numbers, or their ids just map them in order you want:
ffmpeg -i "..." -map 0:a:0,0:1 -map 0:a:1,0:1 ... or use -map i:0xbbbb -map i:0xaaaa ... i.e. the -map commands allows to select new order of your audio streams.
The more tricky is if you want to reorder them based on their language: imagine your source contains English, French and Spanish (and possible other) audio tracks, and you want to order them as French, English, Spanish, and any other languages following. So based on -map command you can do the following: ffmpeg -i "..." -map 0:V,0:0 -map 0:m:language:fre? 0:m:language:eng? 0:m:language:spa? -map 0:a? -map -0:s? .... a little explanation of parameters: first map real video stream (capital V) as target stream 0 (you can change this), then search for stream with metadata's language French and if it exists (the question mark at end) put as first audio stream, repeat the same with other requested languages, but before finish map any other(s) stream in case there is no any of your requested languages or won't loose some source audio stream, and finally (very important in some cases) delete mapping of subtitles because the metadata for subtitles is same as metadata for audio streams, and if there is subtitle stream for French but no audio stream for French the result will be subtitle stream mapped and no audio stream - this depends on your requirements of course.
Do not forget that using -map command prevent automatically mapping all stream(s) to target, that's why '-map 0:v' is placed in command, the same is true for data and and download streams too. The question marks at end of any audio streams selection allows absent of exact audio stream, so the ffmpeg command will not stops with error.
Note: it's possible mapping commands to duplicate your audio stream(s) in output...
I have an issue with ffmpeg. I am not a pro user so I'm on a constant trial & error mode. I would need a little help from this community that helped me countless time before.
I downloaded separate audio and video segments of a video stream. Both audio and video were shown in the Network tab as being .m4s files, but the .m3u8 playlist gave me .ts files for both. So then I downloaded the whole audio batch and concatenated it into a single .ts file. I did the same with video, but using a .mp4 output.
EDIT: When merging the audio .ts files, I encounter this issue:
[mpegts # 0x7f88cb805600] Non-monotonous DTS in output stream 0:0;
previous: 1077120, current: 1073280; changing to 1077121. This may
result in incorrect timestamps in the output file.
UPDATE: Just noticed that when I examine the .ts audio file with MediaInfo, the frame rate is 41.667 fps (1152 SPF).
So now I have two files: a working single .ts with audio and a working single .mp4 with video.
Only when I tried to merge them, however, I noticed that audio and video resulted as out of sync.
This is because audio has a different length from video (don't know why, they were the same amount of segments: 750).
Audio info:
Input #0, mpegts, from 'output.ts':
Duration: 01:14:12.11, start: 1.400000, bitrate: 434 kb/s
Program 1
Metadata:
service_name : Service01
service_provider: FFmpeg
Stream #0:0[0x100]: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 384 kb/s
I can see that for some reason, it starts at 1.4s.
Video info:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'output.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.12.100
Duration: 01:14:57.84, start: 0.000000, bitrate: 2425 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1280x720 [SAR 1:1 DAR 16:9], 2423 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc (default)
Metadata:
handler_name : VideoHandler
Video and audio are synced at the beginning (somehow the 1.4 start makes sense) but audio starts drifting and goes out of sync after a while. How do I solve the issue?
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
ffmpeg: videos before and after conversion aren't the same length
Recently, I've been trying to use FFmpeg for an application which requires a VERY accurate manipulation when it comes to the time parameter (milliseconds resolution). Unfortunately, I was surprised to find out that FFmpeg's manipulation functionalities return some inaccurate results.
Here is the output of 'ffmpeg':
ffmpeg version 0.11.1 Copyright (c) 2000-2012 the FFmpeg developers
built on Jul 25 2012 19:55:05 with gcc 4.2.1 (Apple Inc. build 5664)
configuration: --enable-gpl --enable-shared --enable-pthreads --enable-libx264 --enable-libmp3lame
libavutil 51. 54.100 / 51. 54.100
libavcodec 54. 23.100 / 54. 23.100
libavformat 54. 6.100 / 54. 6.100
libavdevice 54. 0.100 / 54. 0.100
libavfilter 2. 77.100 / 2. 77.100
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 15.100 / 0. 15.100
libpostproc 52. 0.100 / 52. 0.100
Now, let's assume I want to rip the audio track of 'foo.mov'. Here is the relevant output of 'ffmpeg -i foo.mov':
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'foo.mov':
Metadata:
major_brand : qt
minor_version : 0
compatible_brands: qt
creation_time : 2012-07-24 23:16:08
Duration: 00:00:40.38, start: 0.000000, bitrate: 805 kb/s
Stream #0:0(und): Video: h264 (Baseline) (avc1 / 0x31637661), yuv420p, 480x360, 733 kb/s, 24.46 fps, 29.97 tbr, 600 tbn, 1200 tbc
Metadata:
rotate : 90
creation_time : 2012-07-24 23:16:08
handler_name : Core Media Data Handler
Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, mono, s16, 63 kb/s
Metadata:
creation_time : 2012-07-24 23:16:08
handler_name : Core Media Data Handler
As you probably noticed, the video file duration is 00:00:40.38. Using the following command, I ripped it's audio track:
'ffmpeg -i foo.mov foo.wav'
Output:
Output #0, wav, to 'foo.wav':
Metadata:
major_brand : qt
minor_version : 0
compatible_brands: qt
creation_time : 2012-07-24 23:16:08
encoder : Lavf54.6.100
Stream #0:0(und): Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, mono, s16, 705 kb/s
Metadata:
creation_time : 2012-07-24 23:16:08
handler_name : Core Media Data Handler
Stream mapping:
Stream #0:1 -> #0:0 (aac -> pcm_s16le)
Press [q] to stop, [?] for help
size=3482kB time=00:00:40.42 bitrate= 705.6kbits/s
video:0kB audio:3482kB global headers:0kB muxing overhead 0.001290%
As you can see, the output file is longer than the file in the input.
Another example is audio (and video) file trimming:
Let's assume I would like to use ffmpeg for audio file trimming. I used the next command:
'ffmpeg -t 00:00:10.000 -i foo.wav trimmed_foo.wav -ss 00:00:25.000'
Output:
[wav # 0x10180e800] max_analyze_duration 5000000 reached at 5015510
Guessed Channel Layout for Input Stream #0.0 : mono
Input #0, wav, from 'foo.wav':
Duration: 00:00:40.42, bitrate: 705 kb/s
Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, mono, s16, 705 kb/s
Output #0, wav, to 'trimmed_foo.wav':
Metadata:
encoder : Lavf54.6.100
Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, mono, s16, 705 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (pcm_s16le -> pcm_s16le)
Press [q] to stop, [?] for help
size=864kB time=00:00:10.03 bitrate= 705.6kbits/s
video:0kB audio:864kB global headers:0kB muxing overhead 0.005199%
Again, the output file is 30 milliseconds longer than I expected.
I tried, for a long time, to research the issue without any success. When I use audacity for the same functionality, it does it very accurately!
Does anyone have any idea how to solve this problem?
TL; DR: FFmpeg and your iOS device are the wrong tools for your needs.
There are a host of problems to cover, so in no particular order:
Neither FFmpeg or the underlying codecs that you're working with are designed for the sort of time resolution you want. 40ms is 1 frame at 25fps, which just isn't much in the context of most video and audio files. Hyperaccurate timing isn't a design feature of common audio codecs, like your source AAC data, and FFmpeg follows suit.
Don't do any transcoding! If you want to change the data as little as possible... don't change it. You can use ffmpeg -i in.mov -c:a copy out.m4a to extract the audio stream exactly instead of transcoding it to wav format.
Use FFprobe instead of FFmpeg to get file information. FFmpeg just gives some cursory information about input and output files because its default logging is overly verbose. FFprobe is usually bundled with FFmpeg and is specifically designed to extract information in a convenient form. Use ffprobe -show_streams -show_format in.mov to get information.
Increase your -analyzeduration! You might've noticed the note about max_analyze_duration reached in your output. From the docs that's how many microseconds are going to actually be read of the file before FFmpeg estimates the total length. Again, for most purposes knowing the length of the file to microsecond accuracy isn't feasible or desirable and it is expensive. If you want hyperaccuracy, make sure that that parameter is set much higher, probably longer than your actual input.
Be a bit more careful with your option placement. This is fairly minor, but I thought that I should bring it up in case you're unaware. Many of FFmpeg's options behave differently depending on the order they're given with respect to input and output. Notably -ss that you're using. You have it after the input, which is where you want it, but you also have the output-only option -t at the beginning which is... weird. The more natural way to order that command would be:
ffmpeg -i foo.wav -ss 00:00:25.000 -t 00:00:10.000 trimmed_foo.wav
All the timing commands accept input in seconds (including fractional seconds), so you don't have to prepend everything with 00:00:.
Distinguish container length and actual stream length. I don't use Audacity, but I wouldn't be surprised if it showed extreme accuracy because it was lying to you about what it was doing. Actually trimming audio or video data with millisecond accuracy would require not merely choosing which frames from the input are included in the output (which is accurate to 40ms at 25fps!) but changing frame data to insert silence at the end. Far easier would be to just trim based on frame inclusion, then put the hyper-accurate length in the container file metadata. Some playback software might actually cut off based on that number, but again, most AV software just isn't designed for that level of accuracy. I would be curious to see what FFmpeg shows as the length of a file trimmed by Audacity.
That's all that springs to mind now, but I'm happy to give more feedback once you've had a chance to incorporate some of the above. My guess would be that this sort of accuracy is required for research pruposes, in which case, happy researching!