The root cause:
- some MP4 files come with H.264/H.265 streams which explicitly
state their timescale. In such cases, it is wise that MP4 muxer
adopts these values
- unfortunately, the recent trend has been that such values coming
from video stream SPS (vui_parameters/timing info) are exorbitantly
high - instead of being FPS *1000, they tend to be FPS * 100,000,000
- when trying to express the duration of the movie, the MP4 muxer
normally tries to find the adequate timescale value which will
fit both audio and video timescaling domains. The most suitable
approach is that the LCM (least common multiplier) value is taken
which mathematically will be the least disruptive.
HOWEVER:
- in cases when video and timescale numeric values are mutually 'odd',
say 30*100,000,000 and 44100, the LCM ends up being a huge number,
which outgrows the 32-bit storage capacity granted by the ISO MP4
spec (MVHD box).
Problem solution:
1) identifying when the LCM timescale exceeds 32-bit storage space
2) scaling down its value by nearest larger 10X factor, which will
guarantee its value fitting the 32-bit space. Given the afore
mentioned video timescale factors, dividing by 10X is harmless
3) rescaling the duration 64-bit value based on the new timescale
Eliminating unnecessary and potentially counter-productive zero-sized
samples from the audio trak. The Android MP4 multiplexer tends to add
them at the very end of the audio stream. Their presence may negatively
affect the declared audio stream duration, and pose further complications
down the road.
The changes are verified on Samsung A54 (Android 14) device.
