Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Mon, Mar 06, 2017 at 04:31:32PM +0100, wm4 wrote: > On Mon, 6 Mar 2017 16:23:15 +0100 > u-9...@aetey.se wrote: > > > Did the project (who?) ever make a general decision about Cinepak > > or delegate to wm4 to represent the project's stance? > > > > I question her/his tone, not the policy, but

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

Hi, On Mon, Mar 6, 2017 at 9:52 AM, wrote: > I am sorry for misrepresentation of the statements of wm4! > No problem. Now Ronald where were you with your policing > when the person in question (wm4) repeatedly violated CoC? > > I point out that your behaviour of selective

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Mon, 6 Mar 2017 16:23:15 +0100 u-9...@aetey.se wrote: > Did the project (who?) ever make a general decision about Cinepak > or delegate to wm4 to represent the project's stance? > > I question her/his tone, not the policy, but what is the latter > when not refracted through your, wm4's or

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Mon, Mar 06, 2017 at 08:19:06AM -0500, Ronald S. Bultje wrote: > On Mon, Mar 6, 2017 at 7:08 AM, wrote: > > > It is clear that you personally do not want the Cinepak decoder to be able > > to output multiple pixel formats, for unspecified reasons ("by choice"). > > > > You

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Mon, Mar 06, 2017 at 08:19:06AM -0500, Ronald S. Bultje wrote: > Hi, > > On Mon, Mar 6, 2017 at 7:08 AM, wrote: > > > You did not have to pay attention to the patch, given your limited > > understanding of the matter > > > And this is a CoC [1] violation, please don't do

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

Hi, On Mon, Mar 6, 2017 at 7:08 AM, wrote: > It is clear that you personally do not want the Cinepak decoder to be able > to output multiple pixel formats, for unspecified reasons ("by choice"). > > You make it look like it is your discretion who decides whether something > is

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

To everyone: I am really sorry for having to react to this kind of irrational arguments. OTOH keeping silence could be interpreted as accepting them. As far as my common sense goes, I can not count these as "pending comments". TL;DR: trying to reason, given the arbitrary statements and

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Mon, 6 Mar 2017 10:15:44 +0100 u-9...@aetey.se wrote: > On Sun, Mar 05, 2017 at 06:20:34PM -0500, Ronald S. Bultje wrote: > > Hi Rune, > > > > On Sun, Mar 5, 2017 at 4:26 PM, wrote: > > > > > Ronald, > > > > > > On Sun, Mar 05, 2017 at 02:38:31PM -0500, Ronald S. Bultje

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On 3/6/17, u-9...@aetey.se wrote: > On Sun, Mar 05, 2017 at 06:20:34PM -0500, Ronald S. Bultje wrote: >> Hi Rune, >> >> On Sun, Mar 5, 2017 at 4:26 PM, wrote: >> >> > Ronald, >> > >> > On Sun, Mar 05, 2017 at 02:38:31PM -0500, Ronald S. Bultje wrote: >> > > Hi,

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Sun, Mar 05, 2017 at 06:20:34PM -0500, Ronald S. Bultje wrote: > Hi Rune, > > On Sun, Mar 5, 2017 at 4:26 PM, wrote: > > > Ronald, > > > > On Sun, Mar 05, 2017 at 02:38:31PM -0500, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Sun, Mar 5, 2017 at 2:22 PM,

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

Hi Rune, On Sun, Mar 5, 2017 at 4:26 PM, wrote: > Ronald, > > On Sun, Mar 05, 2017 at 02:38:31PM -0500, Ronald S. Bultje wrote: > > Hi, > > > > On Sun, Mar 5, 2017 at 2:22 PM, wrote: > > > > > On Mon, Feb 13, 2017 at 02:41:40PM +0100, u-9...@aetey.se wrote: >

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

Ronald, On Sun, Mar 05, 2017 at 02:38:31PM -0500, Ronald S. Bultje wrote: > Hi, > > On Sun, Mar 5, 2017 at 2:22 PM, wrote: > > > On Mon, Feb 13, 2017 at 02:41:40PM +0100, u-9...@aetey.se wrote: > > > On Mon, Feb 13, 2017 at 02:19:45PM +0100, Michael Niedermayer wrote: > > > >

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

Hi, On Sun, Mar 5, 2017 at 2:22 PM, wrote: > On Mon, Feb 13, 2017 at 02:41:40PM +0100, u-9...@aetey.se wrote: > > On Mon, Feb 13, 2017 at 02:19:45PM +0100, Michael Niedermayer wrote: > > > you may want to add yourself to MAINTAINERs (after talking with > > > roberto, who i

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Mon, Feb 13, 2017 at 02:41:40PM +0100, u-9...@aetey.se wrote: > On Mon, Feb 13, 2017 at 02:19:45PM +0100, Michael Niedermayer wrote: > > you may want to add yourself to MAINTAINERs (after talking with > > roberto, who i belive has less interrest in cinepak than you do > > nowadays) > > Sounds

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

Hi Ronald, On Tue, Feb 14, 2017 at 09:46:55AM -0500, Ronald S. Bultje wrote: > > The huge difference in the amount of the data to be processed; in other > > words the very essence of the vector quantization technology where frame > > data is represented by a codebook, by design meant to be much

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Tue, Feb 14, 2017 at 10:03:41AM +0100, Paul B Mahol wrote: > Correct way in solving this is outputing in cinepak decoder actual > native format that it > uses and not do any conversions of colorspace which is currently done. > Implement correct colorspace conversions of cinepak format to others

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On 2/14/17, wm4 wrote: > On Tue, 14 Feb 2017 09:51:54 +0100 > u-9...@aetey.se wrote: > >> On Tue, Feb 14, 2017 at 06:51:46AM +0100, wm4 wrote: >> > On Mon, 13 Feb 2017 18:51:39 +0100 >> > u-9...@aetey.se wrote: >> > >> > > Then abstracting a "mini-swscale" could become

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Tue, 14 Feb 2017 09:51:54 +0100 u-9...@aetey.se wrote: > On Tue, Feb 14, 2017 at 06:51:46AM +0100, wm4 wrote: > > On Mon, 13 Feb 2017 18:51:39 +0100 > > u-9...@aetey.se wrote: > > > > > Then abstracting a "mini-swscale" could become justifiable. > > > > And this is why we should probably

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Tue, Feb 14, 2017 at 06:51:46AM +0100, wm4 wrote: > On Mon, 13 Feb 2017 18:51:39 +0100 > u-9...@aetey.se wrote: > > > Then abstracting a "mini-swscale" could become justifiable. > > And this is why we should probably reject this patch. > What you wrote paints a horrifying future.

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Mon, 13 Feb 2017 18:51:39 +0100 u-9...@aetey.se wrote: > Then abstracting a "mini-swscale" could become justifiable. And this is why we should probably reject this patch. What you wrote paints a horrifying future. Note that we would have this discussion even if it'd speed up the h264

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

Thanks Michael, Your corrections are appreciated. On Mon, Feb 13, 2017 at 02:19:45PM +0100, Michael Niedermayer wrote: > you may want to add yourself to MAINTAINERs (after talking with > roberto, who i belive has less interrest in cinepak than you do > nowadays) Sounds ok for me. Roberto, what

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On 2/13/17, Michael Niedermayer wrote: > On Sat, Feb 11, 2017 at 10:25:03PM +0100, u-9...@aetey.se wrote: >> Hello, >> >> This is my best effort attempt to make the patch acceptable >> by the upstream's criteria. >> >> Daniel, do you mind that I referred to your message in

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Sat, Feb 11, 2017 at 10:25:03PM +0100, u-9...@aetey.se wrote: > Hello, > > This is my best effort attempt to make the patch acceptable > by the upstream's criteria. > > Daniel, do you mind that I referred to your message in the commit? > I believe is is best to indicate numbers from a third

[FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

Hello, This is my best effort attempt to make the patch acceptable by the upstream's criteria. Daniel, do you mind that I referred to your message in the commit? I believe is is best to indicate numbers from a third party measurement. The code seems to be equvalent to the previous patch, with