[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