After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 765260 - baseparse: regression with aac streams
baseparse: regression with aac streams
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal blocker
: 1.8.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-04-19 14:38 UTC by Edward Hervey
Modified: 2016-04-20 10:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
baseparse: Remember if we interpolated DTS from PTS and refresh it whenever we update the PTS (4.24 KB, patch)
2016-04-20 08:53 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Edward Hervey 2016-04-19 14:38:42 UTC
This was introduced by https://bugzilla.gnome.org/show_bug.cgi?id=765096

The scenario that fails is the following:
* The input to aacparse never has any DTS, only PTS
* The first buffer contains bogus data (i.e. no data starts there), the 2nd buffer will start with valid header/data.
* For simplicity, the first PTS is 0, the second 1, the third 2, ...

When the first buffer arrives, we end up with the following computed values:
* prev_pts : 0 , prev_dts : 0, next_pts : 0, next_dts : 0
Nothing is pushed, quite a bit of data is skipped

when the second buffer arrives, we end up with the following computed values:
* prev_pts : 1 , prev_dts : 0 , next_pts : 1, next_dts : 0
There isn't enough data yet to push out a parsed frame

The 3rd buffer arrives, we have the same computed values (we didn't consume anything from the adapter)
* prev_pts : 1 , prev_dts : 0 , next_pts : 1, next_dts : 0
We end up parsing and pushing a frame with ... PTS:1 and DTS:0
 => This is wrong, the DTS should also be 1

There is more data in the adapter to be parsed, we end up with the following computed values:
* prev_pts : 2 , prev_dts : 0 , next_pts : 2, next_dts : 1
We end up parsing and pushing a frame with PTS:2 DTS:1
  => Same problem
Comment 1 Sebastian Dröge (slomo) 2016-04-20 08:53:02 UTC
Created attachment 326389 [details] [review]
baseparse: Remember if we interpolated DTS from PTS and refresh it whenever we update the PTS

Otherwise PTS and DTS will come out of sync if upstream continues to provide
PTS and not DTS, and we have to skip some data from the stream or PTS are not
exactly increasing with the duration of each packet.
Comment 2 Sebastian Dröge (slomo) 2016-04-20 10:10:03 UTC
Attachment 326389 [details] pushed as 5294065 - baseparse: Remember if we interpolated DTS from PTS and refresh it whenever we update the PTS