Audio copy fast path is unreachable for AAC because priming delay makes firstTimestamp negative

[breezefeng]

I have been using Conversion to pass files through without re-encoding when the
source already meets the target. Video copies correctly. Audio never does, and
I think the reason is structural rather than a bug in my usage.

The copy fast path in conversion.js requires !needsTrimming, where
needsTrimming is firstTimestamp < this._startTimestamp. For an ordinary MP4
produced by ffmpeg:

video codec: avc   firstTimestamp: 0
audio codec: aac   firstTimestamp: -0.023219954648526078
mp4 supports aac: true   supportsTimestampedMediaData: true

0.0232 s at 44100 Hz is 1024 samples, exactly one AAC frame. That is encoder
priming delay, and as far as I know every AAC track from every normal encoder
carries it. So needsTrimming is true for essentially all AAC input and the
copy path is never taken.

The visible effect is that a passthrough grows the file. Parsing the output:

avc1   900 samples   3,071,520 bytes   (byte identical to source)
mp4a  1295 samples     717,380 bytes   (source was 360,476)

The audio was re-encoded at roughly 191 kbps from a 96 kbps source, and a
3.3 MB input came back at 3.6 MB. On the low bitrate files a passthrough is
most useful for, that is around 10 percent.

I could not find a way around it from the caller's side. Passing a bitrate to
control the size forces a transcode on its own, since !trackOptions.bitrate is
also one of the copy conditions, so the choice is between an uncontrolled
re-encode and an uncontrolled re-encode. I ended up adding a floor in my own
code: if a passthrough returns more bytes than it received and the source is
already MP4, return the source untouched.

Is treating a negative first timestamp caused by priming delay as trimming
intentional? If the priming offset could be carried into the output as an edit
list instead, the copy path would open up for a large share of real world MP4s.

Repro is any ffmpeg produced -c:a aac file. If a live example helps, the
browser side compressor I hit this in is public,
and the passthrough case is easiest to trigger on an already small clip such as
the one on the compress video to 10 MB
page.

[Vanilagy]

Yes, this is a known gap and I will fix this in the future properly, across all containers and codecs.

[breezefeng]

Confirming the workaround from #482 works, with byte-level numbers in case they help anyone landing here.

trim: { start: await input.getFirstTimestamp() }, same 5 s H.264 + AAC 192k MP4, pure copy (video: {}, audio: {}):

	output size	audio bitrate	AAC elementary stream md5	H.264 md5
source	556,146	129,344	64a65dc2…	d80d358d…
without trim	590,573 (+6.2%)	186,336	93ee9872…	—
with trim	553,396 (−0.5%)	129,344	64a65dc2…	d80d358d…

Both elementary streams come back identical to the source, and the packet counts match (150 video / 217 audio; without the trim the audio gains two packets). Output duration goes 5.000 → 5.023 s, i.e. the 1024-sample priming delay is preserved rather than flattened — without the trim it drifts to 5.085 s.

One note for anyone applying this: Input.getFirstTimestamp() is the minimum across tracks, so passing it as trim.start cannot remove anything — there is nothing before it. I still gate on < 0 so files that never had the problem keep their existing path:

const first = await input.getFirstTimestamp();
const conversion = await Conversion.init({
  input, output, tracks: 'all', video: {}, audio: {},
  ...(first < 0 ? { trim: { start: first } } : {}),
});

Thanks for the pointer — that turns a 6% regression into a real copy today, and it's a good enough answer that the proper cross-container fix doesn't need to be rushed on my account.

[Vanilagy]

Glad it helped.

See #482 (comment)