On Thu, Jan 14, 2016 at 12:28:32AM +0100, Andreas Cadhalpun wrote:
> On 13.01.2016 19:18, foo86 wrote:
> > Hmm, core sample rate and number of samples are already checked to be
> > compatible with XLL at this point. There must be some bug in upsampling
> > logic if these asserts are triggering,
On Tue, Jan 12, 2016 at 11:58:43PM +0100, Andreas Cadhalpun wrote:
> It's not completely fixed yet, because the check is only done if
> static_fields_present is 1.
You are right, placing the check there doesn't account for case when
static_fields_present becomes 0 later. I moved the check closer
On 13.01.2016 19:18, foo86 wrote:
> On Tue, Jan 12, 2016 at 11:58:43PM +0100, Andreas Cadhalpun wrote:
>> It's not completely fixed yet, because the check is only done if
>> static_fields_present is 1.
>
> You are right, placing the check there doesn't account for case when
>
On 08.01.2016 15:34, foo86 wrote:
> On Thu, Jan 07, 2016 at 08:17:59PM +0100, Andreas Cadhalpun wrote:
>> On 03.01.2016 18:49, foo86 wrote:
>>> +for (i = 0; i < s->nmixoutconfigs; i++) {
>>> +for (j = 0; j < nchannels_dmix; j++) {
>>> +// Mix output mask
>>> +
On Thu, Jan 07, 2016 at 03:32:50PM +0100, Christophe Gisquet wrote:
> One commit implements "sum/diff decoding", introducing sumdiff_X
> functions, with X fixed or float.
>
> I think those are the corresponding butterflies_X functions in the
> AV(Float|Fixed)DSPContext structures. But I haven't
On Thu, Jan 07, 2016 at 08:17:59PM +0100, Andreas Cadhalpun wrote:
> On 03.01.2016 18:49, foo86 wrote:
> > +for (i = 0; i < spkr_remap_nsets; i++) {
> > +// Number of channels to be decoded for speaker remapping
> > +int nch_for_remaps = get_bits(>gb, 5)
On Wed, Jan 06, 2016 at 02:53:32PM -0300, James Almer wrote:
> On 1/6/2016 2:32 PM, foo86 wrote:
> > OK, I'll start changing the patch.
> >
> > Some questions so far:
> >
> > 1. Should I remove old decoder files in separate commit first or should
> > I simply proceed with replacing entire
Hi,
2016-01-07 12:48 GMT+01:00 foo86 :
> bench dca pcm_f32le
> bench dca2 pcm_f32le
> bench libdcadec pcm_s32le
OK, that was mostly out of curiosity, as "dca2" has benefits
surpassing such issues anyway. And the improvement is 10% for where it
matters (raspberry).
On 07.01.2016 20:20, Hendrik Leppkes wrote:
> On Thu, Jan 7, 2016 at 8:17 PM, Andreas Cadhalpun
> wrote:
>>
>> I'd be glad to increase fuzz-testing coverage further, but I'm lacking
>> input examples. It would be great if you could share some (tiny) samples
>>
On 06.01.2016 23:17, Andreas Cadhalpun wrote:
> On 06.01.2016 18:32, foo86 wrote:
>> Otherwise testing coverage will be decreased somewhat. The easiest way to do
>> this is to modify ff_dca2_check_crc() to always return 0.
>
> I tried this (comment out everything in ff_dca2_check_crc except
On Wed, Jan 6, 2016 at 4:01 AM, James Almer wrote:
> On 1/5/2016 11:51 PM, Michael Niedermayer wrote:
>> On Tue, Jan 05, 2016 at 11:44:04PM -0300, James Almer wrote:
>>> On 1/5/2016 11:35 PM, Michael Niedermayer wrote:
On Tue, Jan 05, 2016 at 11:27:25PM -0300, James Almer
On Wed, Jan 06, 2016 at 12:28:00AM +0100, Hendrik Leppkes wrote:
> So that leaves us with a bunch of positive comments, on this side
> anyway, and noone opposed yet.
>
> Arguments for a switch include:
> - Nearly complete coverage of all DTS features, well tested and
> confirmed bit-exact (only
foo86 gmail.com> writes:
> 1. Should I remove old decoder files in separate
> commit first
Please do that, it makes the diff much easier to
read afaict,
> 2. Is it OK to leave arch-specific dca code as
> well as dcadsp.c untouched for now?
Only if you believe that this makes your future
On 1/6/2016 2:32 PM, foo86 wrote:
> On Wed, Jan 06, 2016 at 12:28:00AM +0100, Hendrik Leppkes wrote:
>> So that leaves us with a bunch of positive comments, on this side
>> anyway, and noone opposed yet.
>>
>> Arguments for a switch include:
>> - Nearly complete coverage of all DTS features, well
Hi,
2016-01-06 18:32 GMT+01:00 foo86 :
> dca dca2libdcadec
> System 1: 0:11.90 0:11.16 0:19.73
> System 2: 0:57.00 0:55.23 1:21.33
> System 3: 7:41.31 7:00.84 13:16.70
Just to be sure, because I won't check myself: is
On Tue, Jan 05, 2016 at 10:46:19PM +0100, Andreas Cadhalpun wrote:
> OK. This decoder seems to be quite robust in handling fuzzed samples,
> so from a security point of view it should be fine to replace the
> old dca decoder with this one.
Out of interest, did you disable CRC checks in the
On 06.01.2016 18:32, foo86 wrote:
> On Tue, Jan 05, 2016 at 10:46:19PM +0100, Andreas Cadhalpun wrote:
>> OK. This decoder seems to be quite robust in handling fuzzed samples,
>> so from a security point of view it should be fine to replace the
>> old dca decoder with this one.
>
> Out of
On Tue, Jan 05, 2016 at 08:45:22PM +0100, Andreas Cadhalpun wrote:
> On 03.01.2016 18:49, foo86 wrote:
> > +// 5.3.1 - Bit stream header
> > +static int parse_frame_header(DCA2CoreDecoder *s)
> > +{
> [...]
> > +// Source PCM resolution
> > +s->source_pcm_res =
On Tue, Jan 05, 2016 at 11:27:25PM -0300, James Almer wrote:
> On 1/5/2016 11:21 PM, Michael Niedermayer wrote:
> > On Tue, Jan 05, 2016 at 11:38:00PM +0300, foo86 wrote:
> >> On Tue, Jan 05, 2016 at 08:45:22PM +0100, Andreas Cadhalpun wrote:
> >>> On 03.01.2016 18:49, foo86 wrote:
> +//
On 1/5/2016 11:35 PM, Michael Niedermayer wrote:
> On Tue, Jan 05, 2016 at 11:27:25PM -0300, James Almer wrote:
>> On 1/5/2016 11:21 PM, Michael Niedermayer wrote:
>>> On Tue, Jan 05, 2016 at 11:38:00PM +0300, foo86 wrote:
On Tue, Jan 05, 2016 at 08:45:22PM +0100, Andreas Cadhalpun wrote:
On Tue, Jan 05, 2016 at 11:44:04PM -0300, James Almer wrote:
> On 1/5/2016 11:35 PM, Michael Niedermayer wrote:
> > On Tue, Jan 05, 2016 at 11:27:25PM -0300, James Almer wrote:
> >> On 1/5/2016 11:21 PM, Michael Niedermayer wrote:
[...]
> >
> >
> >>
> >> Ideally, once this decoder is committed
On 1/5/2016 11:51 PM, Michael Niedermayer wrote:
> On Tue, Jan 05, 2016 at 11:44:04PM -0300, James Almer wrote:
>> On 1/5/2016 11:35 PM, Michael Niedermayer wrote:
>>> On Tue, Jan 05, 2016 at 11:27:25PM -0300, James Almer wrote:
On 1/5/2016 11:21 PM, Michael Niedermayer wrote:
> [...]
>>>
>>>
On 03.01.2016 18:49, foo86 wrote:
> +// 5.3.1 - Bit stream header
> +static int parse_frame_header(DCA2CoreDecoder *s)
> +{
[...]
> +// Source PCM resolution
> +s->source_pcm_res = ff_dca_bits_per_sample[pcmr_index = get_bits(>gb,
> 3)];
This can cause an out-of-bounds read if get_bits
On 05.01.2016 21:38, foo86 wrote:
> On Tue, Jan 05, 2016 at 08:45:22PM +0100, Andreas Cadhalpun wrote:
>> On 03.01.2016 18:49, foo86 wrote:
>>> +// 5.3.1 - Bit stream header
>>> +static int parse_frame_header(DCA2CoreDecoder *s)
>>> +{
>> [...]
>>> +// Source PCM resolution
>>> +
On Tue, Jan 5, 2016 at 10:46 PM, Andreas Cadhalpun
wrote:
> On 05.01.2016 21:38, foo86 wrote:
>> On Tue, Jan 05, 2016 at 08:45:22PM +0100, Andreas Cadhalpun wrote:
>>> On 03.01.2016 18:49, foo86 wrote:
+// 5.3.1 - Bit stream header
+static int
On Wed, Jan 6, 2016 at 12:40 AM, Ganesh Ajjanagadde wrote:
> On Tue, Jan 5, 2016 at 3:28 PM, Hendrik Leppkes wrote:
>> On Tue, Jan 5, 2016 at 10:46 PM, Andreas Cadhalpun
>> wrote:
>>> On 05.01.2016 21:38, foo86 wrote:
On Tue, Jan 5, 2016 at 3:42 PM, Hendrik Leppkes wrote:
> On Wed, Jan 6, 2016 at 12:40 AM, Ganesh Ajjanagadde wrote:
[...]
>> For now, I definitely think we should replace our decoder.
>> Just a clarification: in the long run, isn't it a good idea to get
>>
On Tue, Jan 5, 2016 at 3:28 PM, Hendrik Leppkes wrote:
> On Tue, Jan 5, 2016 at 10:46 PM, Andreas Cadhalpun
> wrote:
>> On 05.01.2016 21:38, foo86 wrote:
>>> On Tue, Jan 05, 2016 at 08:45:22PM +0100, Andreas Cadhalpun wrote:
On
On Tue, Jan 05, 2016 at 11:38:00PM +0300, foo86 wrote:
> On Tue, Jan 05, 2016 at 08:45:22PM +0100, Andreas Cadhalpun wrote:
> > On 03.01.2016 18:49, foo86 wrote:
> > > +// 5.3.1 - Bit stream header
> > > +static int parse_frame_header(DCA2CoreDecoder *s)
> > > +{
> > [...]
> > > +// Source PCM
On 1/5/2016 11:21 PM, Michael Niedermayer wrote:
> On Tue, Jan 05, 2016 at 11:38:00PM +0300, foo86 wrote:
>> On Tue, Jan 05, 2016 at 08:45:22PM +0100, Andreas Cadhalpun wrote:
>>> On 03.01.2016 18:49, foo86 wrote:
+// 5.3.1 - Bit stream header
+static int
On Sun, Jan 3, 2016 at 6:49 PM, foo86 wrote:
> This is initial version of libdcadec DCA decoder port I hacked together over
> the last week. This patch is of RFC/inquiry type and not meant for immediate
> inclusion.
>
> Any comments about the code are appreciated, as well as
On 1/3/2016 2:49 PM, foo86 wrote:
> This is initial version of libdcadec DCA decoder port I hacked together over
> the last week. This patch is of RFC/inquiry type and not meant for immediate
> inclusion.
>
> Any comments about the code are appreciated, as well as suggestions concerning
> how
On Sun, 3 Jan 2016 20:49:10 +0300
foo86 wrote:
> This is initial version of libdcadec DCA decoder port I hacked together over
> the last week. This patch is of RFC/inquiry type and not meant for immediate
> inclusion.
>
> Any comments about the code are appreciated, as well
On 1/3/2016 3:44 PM, wm4 wrote:
> On Sun, 3 Jan 2016 20:49:10 +0300
> foo86 wrote:
>
>> This is initial version of libdcadec DCA decoder port I hacked together over
>> the last week. This patch is of RFC/inquiry type and not meant for immediate
>> inclusion.
>>
>> Any
>IMO this should replace the current dca decoder. Based on what i saw from
libdcadec
>yours is cleaner, more feature complete, you're a knowledgeable
maintainer, and
>since the current developer for ffdca over at libav is porting code from
yours to
>get bitexact xll working the code duplication
James Almer gmail.com> writes:
> But by all means lets not have another prores
> or asf/wmv demuxer situation.
The asf situation can be fixed anytime, nobody
is working on the broken demuxer...
Carl Eugen
___
ffmpeg-devel mailing list
On Sun, Jan 03, 2016 at 07:14:28PM +0100, Hendrik Leppkes wrote:
> Having two dca decoders with varying degrees of features is no
> advantages, and considering the native decoder lacks a long list of
> features and fails decoding a bunch of XLL streams, the aim should be
> to replace.
> I'm not
37 matches
Mail list logo