Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1186 closed defect (fixed)

Regression in duration calculation for ogg files.

Reported by: Dale Curtis Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: ogg regression
Cc: reimar Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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

Attachments (2)

sync1.ogg (21.5 KB ) - added by Carl Eugen Hoyos 12 years ago.
StreamPiece.ogg (913.7 KB ) - added by Carl Eugen Hoyos 12 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 by reimar, 12 years ago

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.

comment:2 by Dale Curtis, 12 years ago

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?

by Carl Eugen Hoyos, 12 years ago

Attachment: sync1.ogg added

comment:3 by Carl Eugen Hoyos, 12 years ago

Keywords: ogg regression added
Reproduced by developer: set
Status: newopen

The regression as such is reproducible.

Last edited 12 years ago by Carl Eugen Hoyos (previous) (diff)

in reply to:  1 comment:4 by Carl Eugen Hoyos, 12 years ago

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).

by Carl Eugen Hoyos, 12 years ago

Attachment: StreamPiece.ogg added

comment:5 by Michael Niedermayer, 12 years ago

Resolution: fixed
Status: openclosed

locally fixed, will be in my next push

comment:6 by Dale Curtis, 12 years ago

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

comment:7 by Dale Curtis, 12 years ago

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.

Last edited 12 years ago by Dale Curtis (previous) (diff)

in reply to:  7 comment:8 by Michael Niedermayer, 12 years ago

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

Note: See TracTickets for help on using tickets.