[gstreamer-bugs] [Bug 612312] typefind: Post AAC profile in caps

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=612312
  GStreamer | gst-plugins-base | git

--- Comment #7 from Arun Raghavan <ford_prefect at gentoo.org> 2010-03-19 16:39:42 UTC ---
Posting a patch updated for comments soon. In the mean time, here's some
documentation on how these profiles are to be used.

For AAC-LC/Main/SSR/LTP, the usage is straightforward - the streams will have
the corresponding profile string in caps, and decoders will (eventually) list
the profiles they support in their caps, and linking will proceed as usual.

The HE-AAC v1/v2 case is slightly more complicated. HE-AAC v1 is AAC-LC with an
additional SBR payload, and HE-AAC v2 is AAC-LC with an SBR and PS payload. The
AudioObjectType in the header can:

1. explicitly signal that this is HE-AAC (MP4 container only, ADTS doesn't have
enough bits)
2. implicitly signal by an AAC-LC object with SBR/PS data just showing up in
the bitstream
3. implicitly signal in backward-compatible mode via an extensionAudioObject
field in the header (again MP4 only) indicating the HE-AAC profile type

The expected behaviour for an AAC-only decoder is that it should not play a
stream which explicitly signals HE-AAC, but for an implicitly signaled HE-AAC
stream, it should play only the AAC bits.

To make this work with the caps-based approach, I propose that streams with
explicitly signaled HE-AAC have profile set as "he-aac-v1" or "he-aac-v2",
while implicitly signaled HE-AAC streams have these as "aac-lc+sbr" and
"aac-lc+sbr+ps" respectively.

Non-HE AAC decoders would register one element for handling aac-lc, and
another, with low rank supporting "aac-lc+sbr" and "aac-lc+sbr+ps". HE-AAC
decoders would register support for the AAC profiles, "aac-lc+sbr", "he-aac-v1"
(and possibly "aac-lc+sbr+ps" and "he-aac-v2" if supported) with higher rank.

In this way, when an implicitly signaled HE-AAC stream needs to be decoded, if
an HE-AAC decoder is available it will be used, but if not, the fallback AAC
decoder will be used.

To make that easier to grok, the table lists the type of decoder and the
supported profiles:

Decoder >       non-HE AAC      HE-AAC v1       HE-AAC v2
Caps
 v
aac-lc, etc.    Y*              Y*              Y*

aac-lc+sbr      Y (degraded)    Y               Y

aac-lc+sbr+ps   Y (degraded)    Y (degraded)    Y

he-aac-v1       N               Y               Y

he-aac-v2       N               N               Y

'*' => decoders would support what profiles they can decode, of course, but I'm
assuming all decoders we're speaking of can decode aac-lc

'degraded' => the decoder _can_ play the profile type, but since it doesn't
support all stream features, it will not be of the maximum possible quality

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.