[vlc-devel] [RFC-PATCH] core/audio_output: do not drop (late) audio blocks if it would cause silence

[Filip Roséen]

When aout_DecPlay notices that a block is more than AOUT_MAX_PTS_DELAY
late, it used to unconditionally drop the block.

This patch makes sure that we do not drop blocks whose duration is
longer than the current drift; meaning that we favor resampling over
blunt silence.

--

This patch effectivelly "fixes" the ticket linked below:

    - https://trac.videolan.org/vlc/ticket/14250

Though the ticket is already flagged as "fixed", I do get silence when
seeking due to the fact that the code in question discards more than
560ms of data (because we are 90ms late).

---
 src/audio_output/dec.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/audio_output/dec.c b/src/audio_output/dec.c
index 84c2f60..846ce22 100644
--- a/src/audio_output/dec.c
+++ b/src/audio_output/dec.c
@@ -360,8 +360,16 @@ void aout_DecPlay (audio_output_t *aout, block_t *block, int input_rate)
          * latency spikes (excessive load, SIGSTOP, etc.) or if buffering is
          * insufficient. We assume the PTS is wrong and play the buffer anyway:
          * Hopefully video has encountered a similar PTS problem as audio. */
-        msg_Warn (aout, "buffer too late (%"PRId64" us): dropped", advance);
-        goto drop;
+
+        /* Even though we are too late, do not drop a block whose duration is
+         * longer then the current drift; instead favor resampling in these
+         * cases. */
+
+        if( block->i_length < -advance )
+        {
+            msg_Warn (aout, "buffer too late (%"PRId64" us): dropped", advance);
+            goto drop;
+        }
     }
     if (advance > AOUT_MAX_ADVANCE_TIME)
     {   /* Early buffers can only be caused by bugs in the decoder. */
-- 
2.8.2