On 2018-02-15 10:17, Philipp M. Scholl wrote:
On Wed, Feb 14, 2018 at 03:41:18PM +0100, Tomas Härdin wrote:
[..snip..]
FFMAX(codec->sample_rate/25, 1) would be nicer
agree.
+size = FFMIN(size, RAW_SAMPLES * codec->block_align);
+size = 1 << ff_log2(size);
-size= RAW_SAMPLES*s->st
On Thu, Feb 15, 2018 at 01:54:17AM +0100, Michael Niedermayer wrote:
[..snip..]
> breaks fate
>
I was unsure about the ramifications of a changed blocksize. Maybe you can
comment on that?
>
> [...]
> > --- a/tests/ref/seek/lavf-alaw
> > +++ b/tests/ref/seek/lavf-alaw
> > @@ -1,53 +1,53 @@
> > -r
On Wed, Feb 14, 2018 at 03:41:18PM +0100, Tomas Härdin wrote:
[..snip..]
> FFMAX(codec->sample_rate/25, 1) would be nicer
>
agree.
> > +size = FFMIN(size, RAW_SAMPLES * codec->block_align);
> > +size = 1 << ff_log2(size);
> > -size= RAW_SAMPLES*s->streams[0]->codecpar->block_align;
> >
On Wed, Feb 14, 2018 at 03:11:54PM +0100, 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 a
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 w
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 c
