[Bug 752106] flacparse: makes up bogus DTS for audio after seeking

[GStreamer (GNOME Bugzilla)]

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

Tim-Philipp Müller <t.i.m at zen.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|gstreamer (core)            |gst-plugins-good
         Resolution|---                         |FIXED
   Target Milestone|1.6.0                       |1.5.91
            Summary|baseparse: makes up bogus   |flacparse: makes up bogus
                   |DTS for audio after seeking |DTS for audio after seeking

--- Comment #27 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
It affects parsers for framed formats where timestamps are created based on
information in the headers (like sample offset or frame offset). I've only
fixed up audioparsers for now. Will have a look at the other GstBaseParse
sub-classes later. In any case, it's not a regression anyway.commit
fcdb79ef7b7ff55c8a64573cc991fca04dc7e590
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Fri Sep 4 19:45:37 2015 +0100

    wavpackparse: set both pts and dts so baseparse doesn't make up wrong dts
after seeks

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

commit 0d88f271084cce54de38907a618368deed843ee8
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Fri Sep 4 19:34:41 2015 +0100

    flacparse: set both pts and dts so baseparse doesn't make up wrong dts
after a seek

    flac contains the sample offset in the frame header, so after a seek
    without index flacparse will know the exact position we landed on and
    timestamp buffers accordingly. It only set the pts though, which means
    the baseparse-set dts which was set to the seek position prevails, and
    since the seek was based on an estimate, there's likely a discrepancy
    between where we wanted to land and where we did land, so from here on
    that dts/pts difference will be maintained, with dts possibly multiple
    seconds ahead of pts, which is just wrong. The easiest way to fix this
    is to just set both pts and dts based on the sample offset, but perhaps
    parsed audio should just not have dts set at all.

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

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