Regression in duration calculation for ogg files.

[Dale Curtis]

Commit ​http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=5901cd6236d97b34fe59a47ba0fd6da8f647d1f1 introduced a significant regression in the duration calculation for some OGG files:

​http://commondatastorage.googleapis.com/dalecurtis-shared/sync1.ogg
​http://commondatastorage.googleapis.com/dalecurtis-shared/sync2.ogg

Chrome's copy of FFmpeg has had this commit reverted for some time now w/o issue. I couldn't find an upstream issue report for this though, so decided to file this bug.

The issue can be seen by running ffplay on either file above and noting that the duration is nearly 5 secs off (25.36 vs 30.35)

dalecurtis@xorax /d/code/chrome/src $ ffplay -autoexit media/test/data/content/sync1.ogg
ffplay version N-39514-gfde6314 Copyright (c) 2003-2012 the FFmpeg developers

built on Apr 4 2012 11:24:39 with gcc 4.4.3
configuration: --enable-libx264 --enable-libvpx --enable-gpl --enable-ffplay
libavutil 51. 44.100 / 51. 44.100
libavcodec 54. 12.100 / 54. 12.100
libavformat 54. 3.100 / 54. 3.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 66.101 / 2. 66.101
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 10.100 / 0. 10.100
libpostproc 52. 0.100 / 52. 0.100

Input #0, ogg, from 'media/test/data/content/sync1.ogg':

Duration: 00:00:25.36, start: 0.000000, bitrate: 6 kb/s

Stream #0:0: Audio: vorbis, 44100 Hz, mono, s16, 80 kb/s

30.35 A-V: 0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0

Dropping the commit above (and subsequent changes to that commit) fixes this regression, seemingly without issue:

Input #0, ogg, from '/d/code/chrome/src/media/test/data/content/sync1.ogg':

Duration: 00:00:29.99, start: 0.000000, bitrate: 5 kb/s

[reimar]

You might want to improve your communication/documentation :-)
This was already discussed here:
​http://ffmpeg.org/pipermail/ffmpeg-devel/2011-August/114143.html
Discussion includes a sample file for why that code is needed.

[Dale Curtis]

Agreed on documentation! I'm working on cleaning all this up now, so hopefully we can reduce miscommunication in the future :) Thanks for your patience in any case.

Looks like it still an issue today though, so probably worth leaving the bug open.

FWIW, recreating sync1 and sync2 from wav to ogg using a fresh FFmpeg with either libvorbis or vorbis (sync2 only) results in files which still trigger this issue today though. In fact, every file I've tried to convert to a 30 sec ogg ends up being ~5 secs short.

Here's the command line I'm using:
ffmpeg -t 30 -acodec libvorbis -vn -i <...> <out>.ogg

Should I be doing something else?

[Carl Eugen Hoyos]

The regression as such is reproducible.

[Carl Eugen Hoyos]

Replying to reimar:

This was already discussed here:
​http://ffmpeg.org/pipermail/ffmpeg-devel/2011-August/114143.html
Discussion includes a sample file for why that code is needed.

The duration of StreamPiece.ogg is broken since 1f95ad (which fixed mouse seeking for the sample).

[Michael Niedermayer]

locally fixed, will be in my next push

[Dale Curtis]

Thanks again Michael! I've verified the fix with our local set of test files.

[Dale Curtis]

I was testing the next FFmpeg roll for Chrome and realized this fix causes reading of the entire file during avformat_open_input. Which can be gigabytes of data in the case of long videos. If you try with a multi-gigabyte theora/ogv file over http it's immediately noticeable.

[Michael Niedermayer]

Replying to dalecurtis:

I was testing the next FFmpeg roll for Chrome and realized this fix causes reading of the entire file during avformat_open_input. Which can be gigabytes of data in the case of long videos. If you try with a multi-gigabyte theora/ogv file over http it's immediately noticeable.

Locally fixed, ill push it after some more tests