Opened 15 months ago

Last modified 15 months ago

#5828 open defect

Duration mismatch on opus to pcm conversion

Reported by: skirhir Owned by:
Priority: minor Component: undetermined
Version: git-master Keywords: opus
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

Summary of the bug:

There is a random non negligible duration mismatch when converting from opus to PCM

How to reproduce:

% ffmpeg -i test.opus out.wav
ffmpeg version N-81528-g39f7564-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.4.1 (Debian 5.4.1-1) 20160803
libopus version 1.1.3

% ffprobe test.opus 
Input #0, ogg, from 'test.opus':
  Duration: 00:00:22.81, start: 1.346000, bitrate: 27 kb/s
    Stream #0:0(eng): Audio: opus, 48000 Hz, mono, fltp, delay 48, padding 0
    Metadata:
      LANGUAGE        : eng
      ENCODER         : Lavf57.48.101

% ffprobe output.wav 
Input #0, wav, from 'output.wav':
  Metadata:
    encoder         : Lavf57.48.101
  Duration: 00:00:21.48, bitrate: 768 kb/s
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, 1 channels, s16, 768 kb/s

Attachments (1)

test.opus (77.1 KB) - added by skirhir 15 months ago.

Download all attachments as: .zip

Change History (5)

Changed 15 months ago by skirhir

comment:1 follow-up: Changed 15 months ago by TD-Linux

The output wav duration matches opusdec, so the bug is not in the conversion but that ffprobe does not take the start or end trimming into account.

comment:2 Changed 15 months ago by cehoyos

  • Keywords libopus removed
  • Priority changed from normal to minor
  • Reproduced by developer set
  • Status changed from new to open
  • Version changed from unspecified to git-master

Please remember to always provide the command line that allows to reproduce together with the complete, uncut console output (and do not use ffplay or ffprobe for issues that are reproducible with ffmpeg).

$ ffmpeg -i test.opus out.wav
ffmpeg version N-81555-g496d97f Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl --enable-gnutls
  libavutil      55. 29.100 / 55. 29.100
  libavcodec     57. 54.102 / 57. 54.102
  libavformat    57. 48.102 / 57. 48.102
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 60.100 /  6. 60.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
Input #0, ogg, from 'test.opus':
  Duration: 00:00:22.81, start: 1.346000, bitrate: 27 kb/s
    Stream #0:0(eng): Audio: opus, 48000 Hz, mono, fltp
    Metadata:
      LANGUAGE        : eng
      ENCODER         : Lavf57.48.101
[wav @ 0x26a2300] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Output #0, wav, to 'out.wav':
  Metadata:
    ISFT            : Lavf57.48.102
    Stream #0:0(eng): Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, mono, s16, 768 kb/s
    Metadata:
      LANGUAGE        : eng
      encoder         : Lavc57.54.102 pcm_s16le
Stream mapping:
  Stream #0:0 -> #0:0 (opus (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
size=    2014kB time=00:00:21.46 bitrate= 768.6kbits/s speed= 374x
video:0kB audio:2014kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.003783%

comment:3 in reply to: ↑ 1 Changed 15 months ago by skirhir

Replying to TD-Linux:

The output wav duration matches opusdec, so the bug is not in the conversion but that ffprobe does not take the start or end trimming into account.

If conversion is correct, is there a way to convert to an untrimmed version by replacing the trimmed section with paddings or at least access the trimming information?

I stumbled upon this when trying to sync audio from multiple webm sources, were the opus trimming seems to be used to sync the video and audio tracks, and I couldn't find a way to keep a time reference.

comment:4 Changed 15 months ago by TD-Linux

You can adjust the fields in the Opus header without reencoding, however I don't know of a tool (other than a hex editor) that supports this right now.

There is basically no trimming at the beginning, which is a bit odd. Maybe the problem lies in the tool you are using to create this opus file, or maybe while writing the final WebM?

opusfile output:

New logical stream (#1, serial: 4846dc03): type opus
WARNING: Implausibly low preskip in Opus stream (1)
Encoded with Lavf57.48.101
User comments section follows...
	language=eng
	encoder=Lavf57.48.101
WARNING: Sample count ahead of granule (336960>336864) in stream 1
WARNING: Sample count ahead of granule (384960>384864) in stream 1
WARNING: Sample count ahead of granule (432960>432864) in stream 1
WARNING: Sample count ahead of granule (480960>480864) in stream 1
WARNING: Sample count ahead of granule (528960>528864) in stream 1
WARNING: Sample count ahead of granule (576960>576864) in stream 1
WARNING: Sample count ahead of granule (624960>624864) in stream 1
WARNING: Sample count ahead of granule (673920>673392) in stream 1
WARNING: Sample count ahead of granule (721920>721392) in stream 1
WARNING: Sample count ahead of granule (770880>770160) in stream 1
WARNING: Sample count ahead of granule (818880>818160) in stream 1
WARNING: Sample count ahead of granule (866880>866160) in stream 1
WARNING: Sample count ahead of granule (914880>914160) in stream 1
WARNING: Sample count ahead of granule (962880>962160) in stream 1
WARNING: Sample count ahead of granule (1010880>1010160) in stream 1
Opus stream 1:
	Pre-skip: 48
	Playback gain: 0 dB
	Channels: 1
	Original sample rate: 48000Hz
	Packet duration:   20.0ms (max),   20.0ms (avg),   20.0ms (min)
	Page duration:   1020.0ms (max),  976.4ms (avg),  420.0ms (min)
	Total data length: 78978 bytes (overhead: 2.3%)
	Playback length: 0m:21.463s
	Average bitrate: 29.44 kb/s, w/o overhead: 28.76 kb/s
Logical stream 1 ended
Note: See TracTickets for help on using tickets.