GNOME Bugzilla – Bug 746109
qtdemux: Support for gapless playback for .m4a files
Last modified: 2018-11-03 14:58:46 UTC
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.
Created attachment 316610 [details] [review] proof-of-concept iTunSMPB support Here is one proof-of-concept patch for handling iTunSMPB data in .m4a files. It basically overwrites segment data with the information from iTunSMPB. The adjustment excludes the decoder delay, which is either 1024 or (very rarely outside of DAB streams) 960 samples. In the patch, 1024 is hardcoded. Note that this is done only if (a) the MP4 container has only one stream and (b) if that single stream is of type AAC. The decoder delay is excluded for two reasons: (1) segment adjustments didn't work properly without the exclusion (2) some decoders automatically exclude the first 960/1024 samples, some don't (FAAD does, avdec_aac doesn't) Also, I do think that the decoder delay always equals the first frame, but I didn't find .m4a files with iTunSMPB data and 960 sample frames to test. Comments welcome.
To add to that, I would not bother with gapless playback of .aac files. These are usually AAC bitstreams with ADTS headers. These do not contain extra information like iTunSMPB. This means that aside from the decoder delay, nothing can be adjusted in these cases. So, just apply the decoder delay then. If AAC decoders are fixed to handle this delay, then this is accomplished anyway.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/169.