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 <psch...@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

+    size = FFMIN(size, RAW_SAMPLES) * par->block_align;
+    size = 1 << ff_log2(size);
+
+    ret = av_get_packet(s->pb, pkt, size);
what if block_align is not a power of 2?

for example with 6 channels there could be a reasonable block size
that is not a multiple of 2.
or am i missing something ?

Good catch. Yes, this is a problem. Should probably round down before multiplying by block_align

/Tomas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to