[FFmpeg-devel] [RFC] AAC nonmeaningful window sequences
Thu Jul 1 08:26:19 CEST 2010
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, 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
>> 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
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
More information about the ffmpeg-devel