[Bug 685730] audiodecoder: Timestamp and buffer tracking not threadsafe and robust

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=685730

Edward Hervey <bilboed at bilboed.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bilboed at bilboed.com
   Target Milestone|git master                  |1.6.0
           Severity|major                       |blocker

--- Comment #3 from Edward Hervey <bilboed at bilboed.com> ---
As far as I can see, the threading issue seems to be solved (the code dealing
with the frame list and other computation is protected by the audio decoder
stream lock in _handle_frame() and _finish_frame()).

That being said, the timestamp handling is completely bust.

What I'm seeing on a amcaudiodecoder instance (omxqcomaudiodecodermultiaac) is
the following:

Stream is 48000 stereo AAC

* Incoming buffers have an average duration of 0:00:00.021333333
* They are provided to the android media codec subsystem with proper timestamps
(increasing by that duration every time)
* In the output loop thread we get decoded buffers with timestamps increasing
by 0:00:00.042541667 (i.e. it seems the implementation provides us one output
buffer for two input buffers)
* The _finish_frame algorithm doesn't care about any potential timestamp we
could have put on the decoded buffer and tries to do some magic ... resulting
in the final output buffers being spaced by 0:00:00.021333333

=> outgoing buffers have wrong ts/duration, the resulting audio is garbled in
many situations on android.

I know there's a tolerance property which could mitigate this issue, but it
seems completely wrong for audiodecoder to not be able to take into account
some hints (such as buffer timestamp) that the implementation could provide.

A solution would be to have the base audio decoder compare the proposed
timestamp *AND* number of samples to the total number of samples outputted
(tracked in priv->base_ts and priv->samples_out)

Marking this as blocker since we should have proper audio playback on android
for 1.6

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.