[FFmpeg-trac] #4178(avformat:open): Opus audio in MKV container

FFmpeg trac at avcodec.org
Fri Jan 23 09:51:22 CET 2015


#4178: Opus audio in MKV container
-------------------------------------+-------------------------------------
             Reporter:  agressiv     |                    Owner:  vigneshvg
                 Type:  enhancement  |                   Status:  open
             Priority:  wish         |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  mkv opus     |               Blocked By:
  regression                         |  Reproduced by developer:  1
             Blocking:               |
Analyzed by developer:  1            |
-------------------------------------+-------------------------------------

Comment (by mbunkus):

 This sounds like an issue in ffmpeg's Ogg or Opus output code. If I follow
 the steps you've described then I do see several more Ogg packets for
 which the expected granulepos doesn't match the Ogg page's actual
 granulepos.

 What I've done:

 1. Merged a WAV file with mkvmerge, e.g. `mkvmerge -o source.mka
 source.wav`
 2. Encoded that to !Ogg/Opus with ffmpeg, e.g. `ffmpeg -i source.mka
 source.ogg`
 3. Merged that !Ogg/Opus file to an .mka and turned on debugging output
 during this conversion: `mkvmerge --debug opus -o result.mka source.ogg`

 The debug output contains a couple of lines which report a difference
 between the actual granulepos and the expected one. Such lines look like
 this:

 {{{
 Debug> src/input/r_ogm.cpp:1134: Opus discard padding calculated
 00:00:03.020000000 Ogg timestamp 00:00:03.019979166 diff
 00:00:00.000020834 samples 1 (Ogg page's granulepos 144959)
 }}}

 (Note that the latest MKVToolNix release, v7.5.0, doesn't output the Ogg
 granulepos; that's a change I've just pushed to the MKVToolNix repo.)

 Like I said: mkvmerge calculates the //expected// timestamp as the sum of
 the durations of all the Opus packets encountered so far by
 [[http://tools.ietf.org/html/rfc6716#section-3.1|decoding their TOCs]].
 This timestamp is calculated with the //actual// timestamp derived from
 the Ogg page's granulepos according to the [[https://tools.ietf.org/html
 /draft-ietf-codec-oggopus-06#section-4.3|official formula]]:
 `timestamp_in_ns = 1_000_000_000 * granulepos / 48000` (note that pre-skip
 is not used in this calculation as the pre-skip is kept as a separate
 header value in Matroska).

 Having said that this looks like a rounding error in the program (ffmpeg)
 creating the Ogg stream. That granulepos for the Ogg packet shown above is
 most likely supposed to be 144960 instead of 144959 as 144960 would result
 in a time stamp of exactly 3.02s – which would match the timestamp
 calculated by summing all the packet's durations by decoding the packet
 duration in the TOC.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4178#comment:13>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list