[MPlayer-dev-eng] [PATCH] [TEST AFILTER] Encode ac3 at runtime using lavc
Ulion
ulion2002 at gmail.com
Sun Nov 25 04:15:52 CET 2007
2007/11/25, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> On Sun, Nov 25, 2007 at 12:08:02AM +0800, Ulion wrote:
> > 2007/11/24, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > > > + static const int default_sample_rate[AC3_MAX_CHANNELS+1] = \
> > > > + {0, 96000, 192000, 256000, 384000, 448000, 448000};
> > >
> > > That '\' is pointless.
> > >
> > > > + s->expect_len = AC3_FRAME_SIZE * data->nch * data->bps;
> > > > + if (s->add_iec61937_header)
> > > > + af->mul = (double)AC3_FRAME_SIZE * 2 * 2 / s->expect_len;
> > > > + else
> > > > + af->mul = (double)AC3_MAX_CODED_FRAME_SIZE / s->expect_len;
> > >
> > > still think it is better to always add the headers and add removal code
> > > to ao_pcm if desired. That is assuming that the padding 0 do not hurt,
> > > but I doubt they will.
> >
> > removal code in ao_pcm is a plan, but indeed you will find it's a
> > little hard to do that, and I'm not ready to do that by now.
>
> Why doesn't reading the bit length from the header, converting it to
> bytes, writing that many bytes (outburst is 65536 so all of it should be
> in one play call) and returning the number of bytes written + header
> len not work?
The bit length in the header, is not the length of the iec package,
it's the valid payload's length, after this length, you normally got
zeroes, instead of next iec header. So I said it's a little hard.
>
> > I'm sorry the second sentence you said 'That is assuming that the
> > pendding 0 do not hurt', what's the 'That' mean? I didn't figure it
> > out.
>
> "That" refers to the sentence before, or maybe more precisely an
> no-header mode being pointless.
in no header mode, there's no padding zeroes, only raw ac3/dts
streams, maybe you mis-understood it.
--
Ulion
More information about the MPlayer-dev-eng
mailing list