sync: correct timestamp discontinuities in sync instead of reader (#192)

* sync: correct timestamp discontinuities in sync instead of reader

This patch passes discontinuity information through the pipeline till it
reaches sync.c.  The timestamps are passed through the pipeline as read
and unmodified to sync.c (instead of attempting to correct
discontinuities in reader).  In sync, when we see a discontinuity,
we know where the next timestamp should be based on the timestamp
and duration of the previous buffer (before the discontinuity). So
we calculate an "SCR" offset based on the timestamp after the
discontinuity and what we calculate it should be.

The old discontinuity handling code was broken due to the following.

The MPEG STD timing model relies heavily on the decoder having an STC
that is phase lock looped to the PCRs in the stream.  When decoding a
broadcast stream, the decoder can count on the time measure between PCRs
using the STC to match to a high degree of accuracy.
I.e. STC - lastSTC  == PCR - lastPCR.  When a discontinuity occurs, the
decoder calculates a new PCR offset = PCR - STC.  I.e. the offset is the
new PCR value minus what it would have been if there had been no
discontinuity.

The above does not work without a reliable STC, which we do not have.
We have been attempting to approximate one by avereraging the duration
of received packets and extrapolating an "STC" based on the last PTS and
the average packet duration.  But this is highly variable and
unreliable.

* decavcodec: fix data type of next_pts

It needs to be double so that partial ticks are not lost

* deccc608sub: clarify comment

* sync: allow queueing more audio

Audio is small, and there is often a significant amount of audio in the
stream before the first video frame.

* sync: improve handling of damaged streams

When data is missing, the audio decoder was extrapolating timestamps
from the last pts before the error caused by the missing data which
caused sync issues.

Also, missing data can cause the video decoder to output a frame out of
order with the wrong scr sequence.  Drop such frames.

1 files changed, 15 insertions, 5 deletions

diff --git a/libhb/declpcm.c b/libhb/declpcm.c
index a75c506d9..e7d009375 100644
--- a/libhb/declpcm.c
+++ b/libhb/declpcm.c
@@ -20,6 +20,7 @@ struct hb_work_private_s
     uint32_t    pos;        /* buffer offset for next input data */
 
     int64_t     next_pts;   /* pts for next output frame */
+    int         scr_sequence;
 
     /* the following is frame info for the frame we're currently accumulating */
     uint64_t    duration;   /* frame duratin (in 90KHz ticks) */
@@ -151,7 +152,11 @@ static void lpcmInfo( hb_work_object_t *w, hb_buffer_t *in )
     pv->nsamples = ( pv->duration * pv->samplerate ) / 90000;
     pv->size = pv->nchunks * chunk_size;
 
-    pv->next_pts = in->s.start;
+    if (in->s.start != AV_NOPTS_VALUE)
+    {
+        pv->next_pts     = in->s.start;
+    }
+    pv->scr_sequence = in->s.scr_sequence;
 }
 
 static int declpcmInit( hb_work_object_t * w, hb_job_t * job )
@@ -160,6 +165,7 @@ static int declpcmInit( hb_work_object_t * w, hb_job_t * job )
     w->private_data = pv;
     pv->job = job;
 
+    pv->next_pts = (int64_t)AV_NOPTS_VALUE;
     pv->resample =
         hb_audio_resample_init(AV_SAMPLE_FMT_FLT,
                                w->audio->config.out.mixdown,
@@ -336,10 +342,14 @@ static hb_buffer_t *Decode( hb_work_object_t *w )
 
     if (out != NULL)
     {
-        out->s.start    = pv->next_pts;
-        out->s.duration = pv->duration;
-        pv->next_pts   += pv->duration;
-        out->s.stop     = pv->next_pts;
+        out->s.start         = pv->next_pts;
+        out->s.duration      = pv->duration;
+        if (pv->next_pts != (int64_t)AV_NOPTS_VALUE)
+        {
+            pv->next_pts        += pv->duration;
+            out->s.stop          = pv->next_pts;
+        }
+        out->s.scr_sequence  = pv->scr_sequence;
     }
     return out;
 }