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
if
+ * 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
/Tomas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
