Hello, I've encountered several issues trying to encode audio PCM into MP4/AAC. I've recompiled the latest nightly to make sure it was not already solved.
Here are the FFmpeg command line I ran to encode a 8192 bytes of raw s16le PCM file (4096 samples) into MP4/AAC: ffmpeg -nostdin -hide_banner -loglevel debug \ -f s16le -channel_layout mono -vn -ac 1 -i test-8192.raw \ -f mp4 -acodec aac -movflags empty_moov -ac 1 -ar 44100 -b:a 128000 \ result.mp4 (same without empty_moov) ffmpeg -nostdin -hide_banner -loglevel debug \ -f s16le -channel_layout mono -vn -ac 1 -i test-8192.raw \ -f mp4 -acodec aac -ac 1 -ar 44100 -b:a 128000 \ result.mp4 1/ Why is there an empty packet added to the MP4? When I run ffmpeg, I get the following logs: video:0kB audio:2kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 50.496140% Input file #0 (test-8192.raw): Input stream #0:0 (audio): 4 packets read (8192 bytes); 4 frames decoded (4096 samples); Total: 4 packets (8192 bytes) demuxed Output file #0 (result.mp4): Output stream #0:0 (audio): 4 frames encoded (4096 samples); 5 packets muxed (1814 bytes); Total: 5 packets (1814 bytes) muxed 4 frames successfully decoded, 0 decoding errors [AVIOContext @ 0x25eb300] Statistics: 0 seeks, 4 writeouts --> There are *5* packets (and 5 frames) instead of the 4 frames from the input file. When decoded, this additional packet is a series of 2048 bytes of pure zeros (1024 samples of 0). However, it does use 536 bytes in the mp4 file. Why such a waste?? Moreover, with empty_moov flag, the mp4 file is seen having a LONGER DURATION by players, and it triggers 23ms of initial silence when playing the file. 2/ PTS/DTS bug with EMPTY_MOOV on this first packet Running ffprobe on the result.mp4, the pts/dts seems wrong when using -movflags empty_moov. # ffprobe -hide_banner -pretty -show_packets result.mp4 WITHOUT empty_moov, the first packet (the empty one with pure zeros) has pts/dts with negative values, so that the next packet with actual sound starts at 0:00 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'result.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf57.72.100 Duration: 00:00:00.12, start: 0.000000, bitrate: 176 kb/s Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 124 kb/s (default) Metadata: handler_name : SoundHandler [PACKET] codec_type=audio stream_index=0 pts=-1024 pts_time=0:00:-0.023220 dts=-1024 dts_time=0:00:-0.023220 duration=1024 duration_time=0:00:00.023220 convergence_duration=N/A convergence_duration_time=N/A size=536 byte pos=44 flags=KD [SIDE_DATA] side_data_type=Skip Samples skip_samples=1024 discard_padding=0 skip_reason=0 discard_reason=0 [/SIDE_DATA] [/PACKET] [PACKET] codec_type=audio stream_index=0 pts=0 pts_time=0:00:00.000000 dts=0 dts_time=0:00:00.000000 duration=1024 duration_time=0:00:00.023220 ... But WITH -movflags empty_moov, the first packet starts at pts/dts 0:00, and therefore mp4 players see a LONGER file, with 23ms of silence at the start: [PACKET] codec_type=audio stream_index=0 pts=0 pts_time=0:00:00.000000 dts=0 dts_time=0:00:00.000000 duration=N/A duration_time=N/A convergence_duration=N/A convergence_duration_time=N/A size=536 byte pos=849 flags=K_ [/PACKET] [PACKET] codec_type=audio stream_index=0 pts=1024 pts_time=0:00:00.023220 dts=1024 dts_time=0:00:00.023220 duration=1024 duration_time=0:00:00.023220 Here is the detail about my FFmpeg version: ffmpeg version N-85272-gc901ae9 Copyright (c) 2000-2017 the FFmpeg developers built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-11) configuration: --prefix=/opt/ffmpeg_build --extra-cflags=-I/opt/ffmpeg_build/include --extra-ldflags='-L/opt/ffmpeg_build/lib -ldl' --bindir=/usr/local/bin --pkg-config-flags=--static --enable-gpl --enable-libfreetype libavutil 55. 59.100 / 55. 59.100 libavcodec 57. 91.100 / 57. 91.100 libavformat 57. 72.100 / 57. 72.100 libavdevice 57. 7.100 / 57. 7.100 libavfilter 6. 84.100 / 6. 84.100 libswscale 4. 7.100 / 4. 7.100 libswresample 2. 8.100 / 2. 8.100 libpostproc 54. 6.100 / 54. 6.100 Any help about why there is an additional first packet filled with zeros, and why the timing turns wrong with empty_moov would be much appreciated!! Thank you! _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".