Refresher Requested on MPEG4 Container and AtomicParsley

Tue Jul 28 15:48:40 PDT 2015

DISCLAIMER: I hope our member Mr Steven Carr does not
object to the content of this post - feel free to disregard
otherwise...

On Tue Jul 28 19:27:11 BST 2015, Budgie wrote:

> Assuming the source material from BBC was OK
> what is the process when using GiP
> which builds the stco box (atom?) at my end.
> Is this done by rtmpdump or GiP and where does AtomicParsley fit in?
> I need a primer on the process.
> Any suggested further reading please?

Hi - as a start I'll try to describe briefly to you how GiP
creates the M4A audio files - since your problem audio
files date back to 2013, I'll assume they were the products
of flashaac radiomodes; back then the hlsaac modes
were non-existent...

1. rtmpdump is used to download the audio stream
from a Flash Media Server (FMS) - the stream itself
is in the form of an AAC raw audio stream, but by
default rtmpdump puts everything inside Adobe's
FLV container.
If the download was done without interruptions
all in one go, then usually the resultant .flv audio
file is fine, with correct metadata and timestamps.
However, rtmpdump is known to produce mal-formed
.flv files when the connection to the FMS is fickle
and the download timed-out & resumed multiple
times until completion.

2. Unless the --raw switch was used, GiP then
proceeds to REMUX LOSSLESSLY the rtmpdump
produced flv file to the MP4 container - this is done
by FFMPEG;  so ffmpeg is the utility responsible for
creating the MP4 file structure (hence the stco box).

The recent versions of GiP perform the remux in one
step, in essence using something resembling:

ffmpeg -i "audio.flv" -vn -c:a copy "audio-untagged.m4a"

However, I do recall that older versions of GiP with
older versions of ffmpeg used to do what was described
as "double-remux":
First the raw audio stream was extracted from the flv file:

ffmpeg -i "audio.flv" -vn -c:a copy "audio.aac"

and then that was remuxed to the MP4 container:

ffmpeg -i "audio.aac" -c:a copy -bsf:a aac_adtstoasc "audio-untagged.m4a"

This "double-remux" was obligatory at the time since
the older version of ffmpeg failed to produce iTunes
compatible .m4a files with a direct (single) remux -
this was rectified in updated versions of ffmpeg...
Can't remember whether GiP in 2013 "double-remuxed"...

3. Finally, unless the --no-tag switch is used, the ffmpeg
created .m4a file is passed on to AtomicParsley (AP),
which, as you know, is an MP4 tagger; AP writes the MP4
metadata inside the moov box (atom); the moov atom
created by ffmpeg is placed at the end of the file; unsure
whether AP moves this to another position within the container
(as is the case with MP4Box, which relocates the moov box
to the beginning of the file). Since AP interferes directly
with the MP4 file structure, a "faulty" AP can also be
the culprit for your M4A file seeking issues...

To recap:

The MP4 container is initially created by FFmpeg -
AP modifies the atoms' structure by writing MP4
metadata (tag) - though unlikely in your case, rtmpdump
could've also created an FLV with wrong metadata
that FFmpeg wasn't able to correct fully by simply
remuxing to MP4.