[FFmpeg-devel] [RFC] AAC nonmeaningful window sequences

[Alex Converse]

On Thu, Jul 1, 2010 at 2:20 AM, Rob <robert.swain at gmail.com> wrote:
> On 1 July 2010 06:29, Alex Converse <alex.converse at gmail.com> wrote:
>> For a long time we've spammed a warning and ignored the spec when an
>> AAC non-meaningful window transition is encountered (e.g. ONLY_LONG ->
>> SHORT[1], oddly we don't warn about the reverse) The authors have made
>> it clear that non-meaningful window transitions should be handled
>> naively. They even included some non-meaningful transition test
>> vectors (al03*). When asked to clarify they have stuck to this
>> position[2].
>>
>> We do a fancier fixup where we force windows to match. (e.g. ONLY_LONG
>> -> SHORT becomes START ->SHORT). Still I get bug-reports about this.
>> Most people see the warning and hear an artifact but not and artifact
>> in comparison to the spec's method and report a bug. I'm wondering if
>> we should remove the warning, make the warning consistent, or
>> implement the transitions as the spec requires.
>
> Hmm. If you can find some efficient way to handle these cases (maybe
> via special-casing) then by all means implement it. It was avoided
> because it complicated the code a lot to do overlapping in their way
> to be able to handle these very strange and seemingly nonsensical
> overlaps.
>

I have something coded up. Unfortunately it doesn't align nicely with
out SIMD routines.

> Are you saying that the spec's method of overlapping doesn't reduce
> artifacting significantly for such overlaps?
>

Out method *should* reduce artifacting more than the spec's especially
because we can generate a fifth window type that doesn't even exist in
the spec (a LONG_STOP_START window).

It kind of makes me wonder why they bothered to even let the bitstream
even specify window shape when it can be fully inferred from the
length.

--Alex