[Bug 746109] New: qtdemux: Support for gapless playback for .m4a files

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 746109
           Summary: qtdemux: Support for gapless playback for .m4a files
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: dv at pseudoterminal.org
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Hello,

I am currently investigating how to enable gapless playback for .m4a files.
>From what I gathered, the primary way is to read out the information from the
iTunSMPB tag. If it is not present, the Nero method can be used/assumed as
fallback (which is, drop the first frame, usually 1024 samples for AAC LC).

The former has been introduced by Apple for iTunes. The latter is commonly done
by FAAC/FAAD and Nero AAC software.

Looking at the qtdemux code, one approach that seems promising is to modify the
segment in gst_qtdemux_activate_segment() prior to sending the newsegment
event. That is, the data in stream->segment would *not* be modified; instead,
the segment structure would be copied, the copy modified, and passed over to
gst_event_new_segment(). This way, downstream sees a segment with the
base/start/stop/duration values adjusted to exclude the padding samples. (The
reason why this is done in a local copy is to prevent early buffer clipping in
qtdemux itself; clipping needs to be applied on the decoded samples).

I'll come up with a patch that implement it and post it here, but in the
meantime, if somebody knows a good reason why it shouldn't be done like that,
it would be great to hear about it.

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