On 2018-02-14 15:11, Philipp M. Scholl wrote:
Hi there,

  thanks for the feedback. I made the following changes to the patch:

  - hard-code to 40ms delay. Wasn't really sure what a good value is. But given
    that the is mainly for encoding low-rate sensor data in audio streams,
    together with a video recording, 40ms should be fine in most cases.

  - fix issue when sample rate is smaller (<100, now 25).

  - use ff_log2 for calculating a power of two read size. A power of two to make
    efficient use of I/O buffers.

  - remove the superfluous check for multiple input streams. PCM decoders are
    always single-streams, right?!

There are certainly formats which support multiple audio streams. MOV and MXF comes to mind. Anywhere you need multiple languages.. But I see the patch doesn't change anything having to do with stream count anyway

diff --git a/libavformat/pcm.c b/libavformat/pcm.c
index 806f91b6b1..48c3c09bb4 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 *codec = s->streams[0]->codecpar;
+    /*
+     * Compute read size to complete a read every 40ms.  Clamp to RAW_SAMPLES 
+     * larger. Use power of two as readsize for I/O efficiency.
+     */
+    size = (codec->sample_rate/25 | 1) * codec->block_align;

FFMAX(codec->sample_rate/25, 1) would be nicer

+    size = FFMIN(size, RAW_SAMPLES * codec->block_align);
+    size = 1 << ff_log2(size);
- size= RAW_SAMPLES*s->streams[0]->codecpar->block_align;
      if (size <= 0)
          return AVERROR(EINVAL);

This will never be true since ff_log() always returns >= 0 which makes size >= 1. I suggest putting it before the 1 << ff_log2.

- ret= av_get_packet(s->pb, pkt, size);
+    ret = av_get_packet(s->pb, pkt, size);

Doesn't looks like it belongs, but it makes all the assignments align so whatever

ffmpeg-devel mailing list

Reply via email to