mirror of
https://github.com/signalapp/Signal-Android.git
synced 2025-12-23 12:38:33 +00:00
90a356b29d
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