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

[Rostislav Pehlivanov]

On 9 March 2018 at 23:33, Michael Niedermayer <michael at niedermayer.cc>
wrote:

> On Fri, Mar 09, 2018 at 07:23:02PM +0100, Hendrik Leppkes wrote:
> > On Fri, Mar 9, 2018 at 7:02 PM, Michael Niedermayer
> > <michael at niedermayer.cc> wrote:
> > > 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
> > >
> >
> > Many common sample rates (ie. 22050, 44100, 88200, etc) don't evenly
> > divide by 16 or 32 - they do however by 25.
> > You would get oddly sized frames, which is not really advantageous.
>
> ok, that is an argument to favor /25
>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> What does censorship reveal? It reveals fear. -- Julian Assange
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Besides, pretty much all compilers will optimize that to a multiply + a
right shift.