edit lists in audio and OF

[jpiesing]

From the IBC adjacent meeting ..

Many of the audio test streams include edit lists. Is the value of the offset introduced by the edit list is large enough that the OF would detect incorrect implementation of edit lists?

[jpiesing]

@haudiobe

[yanj-github]

Incorrect implementation of edit lists on devices will be detected by missing frames and/or AV sync failures.

[jpiesing]

Incorrect implementation of edit lists on devices will be detected by missing frames and/or AV sync failures.

The example given in the meeting was an edit list that removes 40ms from the start of an audio file.
Would this not happening really be detected given the values of the tolerances we have selected?
Would detecting non-removal of the start of an audio file need a carefully constructed audio file where the edit list removed a longer piece of audio from the start? e.g. 250ms?

[MichaelForsyth634]

Looking at some of the aac media
aac_lc has 2048 samples delay (42.7 ms)
he_aac_v2 has 7106 samples delay of (148.0 ms)

I would therefore expect most incorrect device implementations of edit lists to result in detectable AV sync issues or undetected start delays, but by default you wouldn't be able to tell what the source of the issue is.

Given that there are multiple possible sources of these issues that in theory can cancel out, if you want to explicitly test that the edit list box is being handle then in my view you need to create tests to do so.

Your suggestion of of audio with a extended edit list box would catch cases of the edit list being ignored BUT would missing cases where the edit list is rounded to nearest frame or audio unit

If you wanted to fully check the edit list box functionality you would need something like
3 independent test runs
1: Reference audio with default edit list
2: Reference audio with edit list removed
3: Reference audio with default edit list + 1s (time arbitrary)

Then:
by comparing 1 & 2 you can tell if the if the edit list box is being respected partially or in full.
by comparing 2 & 3 you can catch some edge cases where edit list is being ignored but the device inserts the correct delay based on codec.
by comparing 1,2 & 3 you can tell if it inserting a start delay

Issues with that testing approached is it would require significant new functionality in the OF to be implement to allow comparing tests runs to decide pass or fail

[jpiesing]

Looking at some of the aac media
aac_lc has 2048 samples delay (42.7 ms)

From config.ini, we have the following.

start_segment_num_tolerance = 4
end_segment_num_tolerance = 4

Which corresponds to 80ms. Won't an incorrect implementation of edit lists loose the 42.7ms in this 80ms tolerance?

[yanj-github]

@jpiesing Yes, this is correct.
OF will not flag a failure when the measured value is 42.7 ms, since it is within the 80 ms tolerance. However, the observation message will still indicate number of segments loose.

For other observations such as AV sync, there are defined tolerances:
av_sync_start_tolerance = 1000 ms → The first 1000 ms of sync is ignored.
If synchronization does not catch up after 1000 ms, OF will detect it as a failure when the offset is outside the range of [40, -120] ms.