Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#1186 closed defect (fixed)

Regression in duration calculation for ogg files.

Reported by: dalecurtis 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 cehoyos 5 years ago.
StreamPiece.ogg (913.7 KB) - added by cehoyos 5 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 follow-up: Changed 5 years ago by 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.

comment:2 Changed 5 years ago by dalecurtis

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?

Changed 5 years ago by cehoyos

comment:3 Changed 5 years ago by cehoyos

  • Keywords ogg regression added
  • Reproduced by developer set
  • Status changed from new to open

The regression as such is reproducible.c

Version 0, edited 5 years ago by cehoyos (next)

comment:4 in reply to: ↑ 1 Changed 5 years ago by cehoyos

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

Changed 5 years ago by cehoyos

comment:5 Changed 5 years ago by michael

  • Resolution set to fixed
  • Status changed from open to closed

locally fixed, will be in my next push

comment:6 Changed 5 years ago by dalecurtis

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

comment:7 follow-up: Changed 5 years ago by 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.

Last edited 5 years ago by dalecurtis (previous) (diff)

comment:8 in reply to: ↑ 7 Changed 5 years ago by michael

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.