On Fri, Mar 9, 2018 at 7:02 PM, Michael Niedermayer
<mich...@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 <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
>
> 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.
40ms sounds like a nice round number.
- Hendrik
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
