Hi,
2015-02-05 19:19 GMT+01:00 Michael Niedermayer :
>> +frame->width = FFALIGN(4 * sps->width, FF_INPUT_BUFFER_PADDING_SIZE);
>
> FF_INPUT_BUFFER_PADDING_SIZE is not guranteed to be a power of 2 but
> FFALIGN needs a power of 2
I don't think the padding is actually needed because it's just
On Thu, Feb 05, 2015 at 08:17:25AM +0100, Christophe Gisquet wrote:
> Hi,
>
> 2015-02-05 7:29 GMT+01:00 Christophe Gisquet :
> > We were previously reference-counting the sao-buffer. Should we do
> > that for sao_pixel_buffer_[hv], then?
>
> Something like the attached patch.
>
> Note: I'm proba
On Thu, Feb 05, 2015 at 06:47:08PM +0100, Michael Niedermayer wrote:
> On Thu, Feb 05, 2015 at 01:57:48PM +0100, Mickaël Raulet wrote:
> > PPS_A_qualcomm_7, yes I have sometimes an issue with this sequence.
> >
> > Patch LGTM otherwise, it does not change the behaviour of the previous
> > implemen
On Thu, Feb 05, 2015 at 01:57:48PM +0100, Mickaël Raulet wrote:
> PPS_A_qualcomm_7, yes I have sometimes an issue with this sequence.
>
> Patch LGTM otherwise, it does not change the behaviour of the previous
> implementation.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147E
Hi,
2015-02-05 11:13 GMT+01:00 Christophe Gisquet :
> 2015-02-05 10:13 GMT+01:00 Christophe Gisquet :
>> The patch breaks make fate-hevc THREADS=3, so needs more thought.
>
> Compilation issue, running make clean first passes "fate-hevc
> THREADS=3" and "fate-hevc THREADS=3 THREAD_TYPE=slice"
Ran
PPS_A_qualcomm_7, yes I have sometimes an issue with this sequence.
Patch LGTM otherwise, it does not change the behaviour of the previous
implementation.
Mickaël
2015-02-05 13:36 GMT+01:00 Christophe Gisquet
:
> Hi,
>
> 2015-02-05 13:17 GMT+01:00 Mickaël Raulet :
> > on one sequence? PPS7_xxx
Hi,
2015-02-05 13:17 GMT+01:00 Mickaël Raulet :
> on one sequence? PPS7_xxx ? Right?
I think we're not speaking about the same thing, maybe. I had an
issue, starting right from the first fate-hevc-conformance sequence,
where ffmpeg wouldn't even parse correctly the SPS.
Rebuilding from scratch f
on one sequence? PPS7_xxx ? Right?
Mickaël
2015-02-05 11:13 GMT+01:00 Christophe Gisquet
:
> 2015-02-05 10:13 GMT+01:00 Christophe Gisquet <
> christophe.gisq...@gmail.com>:
> > The patch breaks make fate-hevc THREADS=3, so needs more thought.
>
> Compilation issue, running make clean first pa
2015-02-05 10:13 GMT+01:00 Christophe Gisquet :
> The patch breaks make fate-hevc THREADS=3, so needs more thought.
Compilation issue, running make clean first passes "fate-hevc
THREADS=3" and "fate-hevc THREADS=3 THREAD_TYPE=slice"
--
Christophe
___
f
Hi,
2015-02-05 9:48 GMT+01:00 Mickaël Raulet :
> WPP try it out with thread_type=slice.
Does it mean these buffer should rather be per thread? If having 2 ctb
lines of buffer fixes this, does this mean having 2 instances of a
single line/column, one per ctb line number parity, would equally fix
t
2015-02-05 8:17 GMT+01:00 Christophe Gisquet :
> Hi,
>
> 2015-02-05 7:29 GMT+01:00 Christophe Gisquet >:
> > We were previously reference-counting the sao-buffer. Should we do
> > that for sao_pixel_buffer_[hv], then?
>
> Something like the attached patch.
>
> Note: I'm probably overallocating co
Hi,
2015-02-05 7:29 GMT+01:00 Christophe Gisquet :
> We were previously reference-counting the sao-buffer. Should we do
> that for sao_pixel_buffer_[hv], then?
Something like the attached patch.
Note: I'm probably overallocating compared to previously, but that
doesn't look to be a big deal.
On
Hi,
2015-02-04 2:05 GMT+01:00 Michael Niedermayer :
> applied the cherry picked code and the update
James mentioned this issue:
http://fate.ffmpeg.org/report.cgi?time=20150205015545&slot=x86_64-archlinux-gcc-valgrindundef
This looks like a missing free:
==15442==at 0x4C2C526: memalign (in
/u
On Mon, Feb 02, 2015 at 04:02:41PM +0100, Michael Niedermayer wrote:
> On Mon, Feb 02, 2015 at 03:31:54PM +0100, Michael Niedermayer wrote:
> > On Mon, Feb 02, 2015 at 02:22:36PM +0100, Christophe Gisquet wrote:
> > > Hi,
> > >
> > > 2015-02-02 13:32 GMT+01:00 Michael Niedermayer :
> > > > On Mon,
On Mon, Feb 02, 2015 at 03:31:54PM +0100, Michael Niedermayer wrote:
> On Mon, Feb 02, 2015 at 02:22:36PM +0100, Christophe Gisquet wrote:
> > Hi,
> >
> > 2015-02-02 13:32 GMT+01:00 Michael Niedermayer :
> > > On Mon, Feb 02, 2015 at 07:41:54AM +0100, Christophe Gisquet wrote:
> > > hmm, is there
On Mon, Feb 02, 2015 at 02:22:36PM +0100, Christophe Gisquet wrote:
> Hi,
>
> 2015-02-02 13:32 GMT+01:00 Michael Niedermayer :
> > On Mon, Feb 02, 2015 at 07:41:54AM +0100, Christophe Gisquet wrote:
> > hmm, is there a reason not to take the original commit unchanged ?
> > I was hoping to reduce t
Hi,
2015-02-02 13:32 GMT+01:00 Michael Niedermayer :
> On Mon, Feb 02, 2015 at 07:41:54AM +0100, Christophe Gisquet wrote:
> hmm, is there a reason not to take the original commit unchanged ?
> I was hoping to reduce the difference to openhevc so that we also
> are able to merge future changes fro
On Mon, Feb 02, 2015 at 07:41:54AM +0100, Christophe Gisquet wrote:
> Hi,
>
> the attached patch is somewhat of a hack job, as the commit I used may
> already have been edited from its original version, and I have added
> some stuff on top of it (eg the commit message).
hmm, is there a reason not
Hi,
the attached patch is somewhat of a hack job, as the commit I used may
already have been edited from its original version, and I have added
some stuff on top of it (eg the commit message).
Thus I have signed it off. I haven't tried testing it in the edge
filter case because it was a messier t
19 matches
Mail list logo
