[FFmpeg-devel] [PATCH v4] avformat/pcm: decrease delay when reading PCM streams.

[Michael Niedermayer]

On Fri, Mar 09, 2018 at 11:18:38AM +0100, Tomas Härdin wrote:
> On 2018-03-09 01:40, Michael Niedermayer wrote:
> >On Wed, Mar 07, 2018 at 03:30:37PM +0100, Philipp M. Scholl wrote:
> >>  Here is the fourth version of the PCM patch with updated testcases.
> >>
> >>  The blocksize of the PCM decoder is hard-coded. This creates
> >>unnecessary delay when reading low-rate (<100Hz) streams. This creates
> >>issues when multiplexing multiple streams, since other inputs are only
> >>opened/read after a low-rate input block was completely read.
> >>
> >>  This patch decreases the blocksize for low-rate inputs, so
> >>approximately a block is read every 40ms. This decreases the startup
> >>delay when multiplexing inputs with different rates.
> >>
> >>Signed-off-by: Philipp M. Scholl <pscholl at bawue.de>
> >>---
> >>  libavformat/pcm.c         | 16 ++++++++++++----
> >>  tests/ref/seek/lavf-alaw  | 42 +++++++++++++++++++++---------------------
> >>  tests/ref/seek/lavf-mulaw | 42 +++++++++++++++++++++---------------------
> >>  3 files changed, 54 insertions(+), 46 deletions(-)
> >>
> >>diff --git a/libavformat/pcm.c b/libavformat/pcm.c
> >>index 806f91b6b..1ea15a9e8 100644
> >>--- a/libavformat/pcm.c
> >>+++ b/libavformat/pcm.c
> >>@@ -28,13 +28,21 @@
> >>  int ff_pcm_read_packet(AVFormatContext *s, AVPacket *pkt)
> >>  {
> >>-    int ret, size;
> >>+    int ret, size = INT_MAX;
> >>+    AVCodecParameters *par = s->streams[0]->codecpar;
> >>-    size= RAW_SAMPLES*s->streams[0]->codecpar->block_align;
> >>-    if (size <= 0)
> >>+    if (par->block_align <= 0)
> >>          return AVERROR(EINVAL);
> >>-    ret= av_get_packet(s->pb, pkt, size);
> >>+    /*
> >>+     * Compute read size to complete a read every 40ms.  Clamp to RAW_SAMPLES if
> >>+     * larger. Use power of two as readsize for I/O efficiency.
> >>+     */
> >>+    size = FFMAX(par->sample_rate/25, 1);
> >division is a bit slowish, and this is done per (small) packet.
> >Maybe a >>4 or >>5 could be used ? (this is a minor issue)
> 
> It's not the 80's any more

i do not think this comment is appropriate in a patch review.

The goal is not to be different from fast code for the sake of
being different from fast code. Or?

If a /25 is better than a >>4 or >>5 then it may make sense to
keep /25. But to me it seemed the value was completely arbitrary
so a /16 or /32 would do equally 

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180309/d7171f0a/attachment.sig>