[Bug 757153] New: opus: Handle start/end trimming

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=757153

            Bug ID: 757153
           Summary: opus: Handle start/end trimming
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: slomo at coaxion.net
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

See bug #757049, bug #742643, bug #727305 and bug #729950. We need to handle
for Opus the start/end trimming and seek preroll.
This is also related to bug #746109 and especially bug #740196.

The Opus encoder tells us with OPUS_GET_LOOKAHEAD_REQUEST how many samples have
to be thrown away from the beginning of the stream. At the end of the stream
the last Opus frame will be padded with some more samples if the stream length
is not an integer multiple of the frame size.

This could also be used for lossless cutting of Opus streams, where you might
want to cut in the middle of the frame.


For Ogg the start trimming is in the OpusHead, the end trimming is given on the
last packet. For Matroska/WebM it's in the container too, done exactly the same
just for a different container. In MP4 the start trimming is the same, the end
trimming is given directly in the headers from the duration of the stream. In
MPEG-TS it's given per packet how much of this specific packet has to be
trimmed (note that this means that you never get a value bigger than the
framesize then, you'll get values for each frame!).

We need to a) pass this information from demuxer to decoder, and b) from
encoder to muxer. In a way that we can handle all the variants (complete start
trimming vs. start trimming per frame, complete end trimming by duration vs.
end trimming per frame).

Then c) we also need to handle it in the decoder properly to throw away the
data and make sure to not break A/V sync because of that. The thrown away data
is not part of the segment!


Any ideas how to do this, other than having 1) the start trimming in the
OpusHead to get it from the beginning and 2) additionally having a generic
GstMeta (this affects all audio codecs in the end) to have per frame start/end
trimming?

For GstAudioDecoder we should probably have a generic setting on the base class
and then let the base class handle that. That might be what the "lookahead"
currently is for, but it seems to not do what it should (see bug #754226).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.