[FFmpeg-devel] [PATCH] pulse: set default frame_size to 4608

[Michael Niedermayer]

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
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

-- 
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
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140103/798cd385/attachment.asc>