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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel