Opened 10 years ago
Last modified 3 years ago
#11163 new bug
Audio/Video out of sync with some .ogv files
| Reported by: | humdinger | Owned by: | colin |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Kits/Media Kit | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | #6976 | |
| Platform: | All |
Description
This is hrev47733.
Some .ogv files show non-snc audio/video, e.g. in mmu_man's screen-capture [40 MiB] the audio is about 35 secs late when played with MediaPlayer.
Other .ogv do not show this, e.g. Bug Bunny trailers.
Might be the different encodings:
RMLL: 15 fps, 22.050 kHz, 90 kbps
Bunny: 25 fps, 48 kHz, 80 kbps
Change History (3)
comment:2 by , 9 years ago
| Blocking: | 6976 added |
|---|
comment:3 by , 3 years ago
Example video still has the sync issue. Seeking does resync though. hrev55112.
Note:
See TracTickets
for help on using tickets.
This sounds very similar to an issue I tracked down at work a couple of years ago with Theora video sync. The issue arose in videos that contained duplicate frames - something that is probably quite common with screen-capture videos.
Page 17 of the Theora spec at http://www.theora.org/doc/Theora.pdf mentions that Theora can code duplicate frames using empty (0-byte) packets. Not all Theora encoders do this, but some definitely do (slightly hazy memory but ffmpeg2theora, which uses the reference encoder, did produce these 0-byte duplicate packets, whereas a straight ffmpeg conversion to ogg did not).
The ogg container format doesn't specify the individual frame numbers for each packet, the container only specifies the last one in each page. I think that means that ffmpeg doesn't really use the frame number in the container other than for seeking, but just increments it for every packet. I think the cause of the bug was then down to the fact ffmpeg did not handle these "0-byte packets" correctly as being duplicate frames, but thought they were corrupt data.
Again, hazy memory, but it was either just not counting them as frames, so the video was all played too quickly, or it was correctly counting them but thinking they were corrupt and thus jumping past all of the duplicates and displaying the next (non-duplicate frame) far too early (but keeping them on screen so long-term drift didn't get worse).
One of the ways I got to these conclusions was by getting ffmpeg to try to round-trip a PNG sequence to theora ogg and back. Also try the encode with ffmpeg2theora and back with ffmpeg.
A sequence AAAAABBBBBCCCCCDDDDD (where A, B, C, D are identical PNGs) should prove informative.
Humdinger: Does sync recover after a seek? Is this new behaviour after Colin's recent media changes?