[FFmpeg-devel] [PATCH] pulse: set default frame_size to 4608
michaelni at gmx.at
Fri Jan 3 03:29:38 CET 2014
On Fri, Jan 03, 2014 at 12:18:37AM +0100, Lukasz M wrote:
> On 2 January 2014 23:26, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Thu, Jan 02, 2014 at 04:36:45PM +0100, Federico Simoncelli wrote:
> > > Given the current defaults (channels = 2, sample_rate = 48000) the
> > > frame_size is changed to 4608 in order to obtain whole numbers for
> > > frame_duration (both 16 and 24 bits_per_sample).
> > >
> > > frame_duration = (frame_size * 1000000 * 8) /
> > > (sample_rate * channels * bits_per_sample)
> > >
> > > A message has been added to warn the user when the frame duration
> > > is not an integer.
> > the timebase should be changed to a multiple of the sample rate
> > see the avpriv_set_pts_info() call
> > that avoids the problem of the durations being not exactly
> > representable
> > and the frame_size either should be "redefined" to mean samples
> > across all channels so that 8bit samples with 3 channels and a
> > frame size of 1024 means 3072 bytes
> > cutting frames between channels is quiet bad so a frame size
> > in bytes is problematic but if its kept in bytes then a default of
> > 3360 should avoid the fractional durations with the changed timebase
> Another solution is not to hardcode value as option default, but calculate
> it in pulse_read_header to value around 1024 (near current value) that has
> no issue with dividing if it is not provided explicitly.
that does sort of, not work
consider 7 channels and 44101 samplerate
to get that to fit in a 1/1000000 timebase you need a frame size thats
quite a bit larger than 1024
why 44101, well that might be the true sample rate the hardware uses
> This is more backward compatible than changing default to other or
> redefining meaning of the param.
> In any case don't forget to update documentation.
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel