-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MOV containing PCM - playback speed too high [reopened] [question] #4228
Comments
It still looks like the media is broken. The raw audio actually has a sample rate of 16 kHz while the headers claim its 32 kHz (see the ffmpeg output in #1592). When I override the sample rate to be 16 kHz, everything works as expected. Note: I derived the actual sample rate from the Mp4 sample table. The chunks have 1024 bytes, meaning 512 samples with 16 bit. The timestamp difference between the chunks is 32000 us which leads to 32000/512 = 62.5 us per sample, which is 16kHz. |
@tonihei OK, so it's bad media. A few things then:
|
|
When the audio track is rechunked in |
Let me know if you need any more sample files. I should be able to get 1440p, 1080p, 720p files in 30 and 60FPS. |
The sample size from the stsd box takes precedence over the sample size in the stsz box. Also remove assumption that C.INDEX_UNSET is -1 in ChunkIterator (which is a no-op change). Issue: #4228 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=196661751
@andrewlewis @tonihei , Exo Player Team: Thank you so much. I successfully tested the latest revision from git. Very happy. 🎉 |
I would like to re-open the issue here, rgd. incorrect MOV file playback when the audio stream contains PCM 16 LE raw audio.
#1592
The issue appears when a Android phone connects Dash Cams or IP Cameras, downloads the recordings and tries to play them. The issue is present throughout multiple chipsets and manufacturers.
To followup with the original issue, I submitted additional sample files by email.
As a follow-up question to this: Is this something the FFmpeg extension could takeover? In that case, I will close this issue immediately.
The text was updated successfully, but these errors were encountered: