Hello,
Given the practical constraints I can not thoroughly fulfill all the
requirements for submitting a patch. I hope it can make it at least to
the list archive, for possible future perusal by someone.
The patch addresses the missing Kate subtitles support, reflected
in trac as
http
On Mon, Oct 24, 2016 at 10:00:38AM +0200, wm4 wrote:
> > The patch addresses the missing Kate subtitles support, reflected
> > in trac as
> >https://trac.ffmpeg.org/ticket/3039
> I don't quite get it. Doesn't this just demux kate subtitles as text
> without stripping whatever formattin
worth to mention:
On Mon, Oct 24, 2016 at 10:25:44AM +0200, u-9...@aetey.se wrote:
> > >https://trac.ffmpeg.org/ticket/3039
The ticket refers to a sample with graphical subtitles. This is _not_
being solved by the proposed patch.
A sample with text subtitles can be seen e.g. at
http
On Mon, Oct 24, 2016 at 11:09:43AM +0200, wm4 wrote:
> > Text subtitles in ogg kate are a straightforward way to put srt-like data
>
> Note that srt supports simple HTML-like tags.
Yes, you are right, the patch just ignores the possible presence
of Kate markup (does not try to interpret it, nor r
On Mon, Oct 24, 2016 at 11:46:07AM +0200, Clément Bœsch wrote:
> On Mon, Oct 24, 2016 at 11:39:40AM +0200, u-9...@aetey.se wrote:
> > Yes, you are right, the patch just ignores the possible presence
> > of Kate markup (does not try to interpret it, nor removes).
> > This is probably not too bad, fo
On Mon, Oct 24, 2016 at 11:49:25AM +0200, Clément Bœsch wrote:
> > It is bad if you don't strip the markup in the decoder.
> To expand on this: it is extremely worrisome that ffmpeg could be the
> source of yet another wave of insane .srt files with kate markup in it
> because someone decided to r
On Mon, Oct 24, 2016 at 12:18:23PM +0200, Clément Bœsch wrote:
> Today, in practice, we have to support all kind of mix of subtitles markup
> in various formats because of this. It would be great not to make things
> worst :)
Let's see.
Looking at kateenc code I believe that the intention was to
On Mon, Oct 24, 2016 at 08:09:09PM +0200, wm4 wrote:
> B) add a compile time option that runs emms() unconditionally at the end
>of each mmx asm block
> It would be interesting to see what the speed
> impact of B) actually is.
+1
Regards,
Rune
___
On Mon, Oct 24, 2016 at 09:53:22PM +0200, Henrik Gramner wrote:
> The decision to issue emms manually instead of after every MMX
> function was a deliberate decision. I'd hardly call it "misdesigned"
> to make SIMD code twice as fast at the cost of technically abusing the
It would be nice to look
On Tue, Oct 25, 2016 at 05:48:50PM +0200, Henrik Gramner wrote:
> On Tue, Oct 25, 2016 at 2:28 PM, wrote:
> > It would be nice to look at a benchmarking comparison, to be able to
> > see the actual practical performance gain of the decision not to follow
> > the ABI.
>
> Just a quick comparison
On Wed, Oct 26, 2016 at 04:21:14PM +0200, Hendrik Leppkes wrote:
> You can add "not caring about first-gen sse2 CPUs" to the list as
> well, if you want. Those are way old as well.
> There is going to be a performance loss either way, except that emms
> slows it down everywhere, while using sse2 is
On Wed, Oct 26, 2016 at 05:08:56PM +0200, Hendrik Leppkes wrote:
> > One of the highly appreciated virtues of ffmpeg is its efficiency,
> > this makes hardware much more useful. Please do not cut off the low
> > end systems when possible.
> Its not about low-end, its about 15+ years old hardware.
On Wed, Oct 26, 2016 at 06:17:27PM +0200, wm4 wrote:
> > With all respect, I find such an argument hardly appropriate for two
> > reasons:
> > it is formally incorrect (see below),
> > it shifts the attention from the functionality/usability to emotionally
> > charged aspects like age.
>
> It's n
> > http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n114
>
> Urgh. This is even worse than I imagined. FFmpeg is using undefined
> behaviours by calling it without resetting the state, but this is also
> completely undefined behaviour on their side.
I feel a duty to remind, in the mos
On Mon, Oct 03, 2016 at 12:37:29PM +0200, Carl Eugen Hoyos wrote:
> 2016-10-03 12:30 GMT+02:00 Hendrik Leppkes :
>
> > Lets just fix the bugs
>
> Sorry: Which bugs exactly should we just fix?
>
> Carl Eugen
Please fix the UB in the MMX-code.
Rune
__
On Mon, Oct 03, 2016 at 08:01:05AM -0400, Ronald S. Bultje wrote:
> > Ping on the patch:
> The patch is unlikely to assist in fixing the issue and is likely to cause
> further inflammation. Therefore I would prefer you did not apply the patch
> and also please don't send a new version that is diff
On Mon, Oct 03, 2016 at 04:26:50PM +0200, u-9...@aetey.se wrote:
> With all the competence present here, is it really infeasible to improve
> the code structure so that it does not involve the C library in the
> bit-crunching performance critical paths??
Bad wording. Should be: "assembler-implemen
Ronald,
I sincerely appreciate that you are taking the effort to talk to me
and explain your position.
Unfortunately in your messages you consistently ignored a crucial point
and this is the last time I try to retell it:
> On Mon, Oct 3, 2016 at 10:26 AM, wrote:
> > What you are talking about i
On Mon, Oct 03, 2016 at 05:27:19PM +0200, wm4 wrote:
> > Musl merely showed you the problem and now you are suggesting to "document
> > that the messenger with his bad news about our health is no longer welcome".
>
> musl could also choose to abandon its incredibly "clever" hack (that
> makes almo
On Mon, Oct 03, 2016 at 07:28:08PM +0200, Hendrik Leppkes wrote:
> > Again: no offence! Standard libraries are just a quite different area,
> > it postulated other skills and presents other implementation challenges
> > than multimedia programming.
>
> Optimized code is the same everywhere, you ju
On Mon, Oct 03, 2016 at 09:48:47PM +0200, Nicolas George wrote:
> > As bright as the people here are, they land in a foreign area, which
> > accidentally leads to statements like the above.
>
> I am sorry, but an appeal to authority will not cut it in front of real
> arguments.
[Everyone, sorry f
Hello,
On slow hardware a 16-bit framebuffer depth makes a remarkable difference
in performance and still provides a good look.
When videos are to be played on slow terminals there is a single
best speed performer, cinepak (tell me if you know a better codec in this
respect, the only comparable o
Here comes a slightly better version, with rounding to nearest instead
of rounding down at color bits truncation. I was unable to reliably measure
any speed difference compared to the simplistic former version.
The output quality now fully corresponds to the capabilities of rgb565
and the decoding
Comments cleanup:
- change the encoding of the original developer name from ISO-8859-1 to UTF-8
- remove the stale/completed TODO list
- fix a typo
No code changes, only improved consistency in the comments.
I kindly ask to apply this cleanup, which of course was due from the beginning.
Attac
Comments style cleanup:
- make all comments follow the same style (C-style)
No code changes, only improved consistency and clarity in the comments.
No changes in the comments besides whitespace and the syntactic delimiters.
The original file uses a mixture of C and C++ style comments, not for
cl
On Sat, Jan 28, 2017 at 12:31:33PM +0100, wm4 wrote:
> On Sat, 28 Jan 2017 11:50:27 +0100
> u-9...@aetey.se wrote:
>
> > Comments style cleanup:
> > - make all comments follow the same style (C-style)
> >
> > No code changes, only improved consistency and clarity in the comments.
> > No changes
Fix a plainly wrong (inverted) misleading comment in the cinepak decoder.
No code changes.
I kindly ask to apply this fix, which of course was due from the beginning.
Attaching the patch.
Regards,
Rune
--- libavcodec/cinepak.c.orig 2017-01-28 17:00:37.0 +0100
+++ libavcodec/cinepak.c
On Sat, Jan 28, 2017 at 08:30:34PM +0100, Moritz Barsnick wrote:
> On Sat, Jan 28, 2017 at 11:50:27 +0100, u-9...@aetey.se wrote:
> > -// MAX_STRIPS limits the maximum quality you can reach
> > -//when you want high quality on high resolutions,
> > -// MIN_STRIPS limits the minimum effi
On Sat, Jan 28, 2017 at 07:53:06PM +0100, Michael Niedermayer wrote:
> On Sat, Jan 28, 2017 at 11:42:24AM +0100, u-9...@aetey.se wrote:
> > Attaching the patch.
>
> please provide a git compatible patch
> git format-patch / send-email
>
> git is quite flexible and often takes diffs in mails too
>
Attaching the new version.
Regards,
Rune
>From f563e57f7609cd890b655cb9d140849f0917a6d3 Mon Sep 17 00:00:00 2001
From: Rl
Date: Sun, 29 Jan 2017 16:40:27 +0100
Subject: [PATCH 1/3] libavcodec/cinepakenc.c: comments cleanup (contents)
Change the encoding of the original developer name from ISO-88
Attaching the new version.
Regards,
Rune
>From e6719743b78862f897133d3f69a5e88a6a9a803e Mon Sep 17 00:00:00 2001
From: Rl
Date: Sun, 29 Jan 2017 18:14:19 +0100
Subject: [PATCH 2/3] libavcodec/cinepakenc.c: comments style cleanup
Avoid the present mixture of comment styles (C vs C++)
by convertin
Attaching the new version.
Regards,
Rune
>From f2041c0aaa5209e5d52649f741b6ee1dbc7e9021 Mon Sep 17 00:00:00 2001
From: Rl
Date: Sun, 29 Jan 2017 18:28:25 +0100
Subject: [PATCH 3/3] libavcodec/cinepak.c: fix a wrong (inverted) misleading
comment
Make the comment message understandable and correc
Hello,
On Sat, Jan 28, 2017 at 07:53:06PM +0100, Michael Niedermayer wrote:
> please provide a git compatible patch
> git format-patch / send-email
The corresponding patches (concerning comments in cinepak-related files)
have been resent in a git-compatible form 2017-01-29.
This patch applies aft
On Thu, Feb 02, 2017 at 01:31:00PM +0100, Michael Niedermayer wrote:
> > From: Rl
>
> Is it intended that your name is not in the Author field for git ?
This is coherent with my earlier patches (from 2014).
Yes.
Regards,
Rune
___
ffmpeg-devel mailin
On Thu, Feb 02, 2017 at 04:25:05PM +0100, wm4 wrote:
> I can see how conversion in the decoder could speed it up somewhat
> (especially if limited by memory bandwidth, I guess), but it's not
> really how we do things in FFmpeg. Normally, conversion is done by
> libswscale (or whatever the API user
Hello Ronald,
On Thu, Feb 02, 2017 at 11:16:35AM -0500, Ronald S. Bultje wrote:
> On Thu, Feb 2, 2017 at 10:59 AM, wrote:
> > It is the irregular differences between them which are the reason
> > for splitting. I would not call this "duplication". If you feel
> > it is straightforward and importa
On Thu, Feb 02, 2017 at 05:52:29PM +0100, wm4 wrote:
> On Thu, 2 Feb 2017 16:59:51 +0100
> u-9...@aetey.se wrote:
> > On Thu, Feb 02, 2017 at 04:25:05PM +0100, wm4 wrote:
> > > I can see how conversion in the decoder could speed it up somewhat
> > I would not call "twice" for "somewhat" :)
>
> We
On Fri, Feb 03, 2017 at 11:14:28AM +0100, wm4 wrote:
> > On a 16-bit-per-pixel output with a CPU-based decoder you will
> > not find _any_ over 25% of Cinepak speed. Raw video can not compete
> > either when indata delivery bandwidth si limited.
> >
> > It has also an unused improvement margin in
Hello Ronald,
On Fri, Feb 03, 2017 at 08:52:53AM -0500, Ronald S. Bultje wrote:
> > I thought about generating the bodies of the functions from something
> > like a template but it did not feel like this would make the code more
> > understandable aka maintainable. So I wonder if there is any poin
On Fri, Feb 03, 2017 at 05:51:19PM +0100, Hendrik Leppkes wrote:
> On Fri, Feb 3, 2017 at 5:36 PM, wrote:
> > So get_format() is not a solution, mo matter how good or misleading
> > its documentation is.
>
> "The application" can implement the get_format callback anyway it
> wants, ask the user
On Fri, Feb 03, 2017 at 08:21:37PM +0100, wm4 wrote:
> With your special use-case (special as in does not fit into the API
> conventions of libavcodec), you might be better off with creating your
> own standalone cinepak decoder. That's not a bad thing; there's plenty
> of multimedia software that
Hello,
Here comes an amended patch, I think all the relevant points
in the discussion have been addressed:
- maintainability and code duplication:
straightforward code templating to reduce duplication
would hardly improve its quality, robustness and maintainability;
a proper style improveme
Hello Mark,
On Sun, Feb 05, 2017 at 12:12:37PM +, Mark Thompson wrote:
> On 05/02/17 10:02, u-9...@aetey.se wrote:
> > To make it a bit more clear, my use case is
> >
> > - various devices and videobuffers
> > - different applications which are not feasible to patch/teach/replace
> >
> > Rep
On Mon, Feb 06, 2017 at 07:57:25AM +0100, Clément Bœsch wrote:
> On Sun, Feb 05, 2017 at 12:24:30PM +0100, u-9...@aetey.se wrote:
> > Hello,
> >
> > Here comes an amended patch, I think all the relevant points
> > in the discussion have been addressed:
> >
> > - maintainability and code duplicati
On Thu, Feb 02, 2017 at 05:19:16PM +0100, Michael Niedermayer wrote:
> On Thu, Feb 02, 2017 at 04:22:28PM +0100, u-9...@aetey.se wrote:
> > On Thu, Feb 02, 2017 at 01:31:00PM +0100, Michael Niedermayer wrote:
> patch applied
>
> thx
Thanks Michael.
What about the other patches from that series?
Hello Michael,
On Tue, Feb 07, 2017 at 03:09:56AM +0100, Michael Niedermayer wrote:
> > What about the other patches from that series?
>
> > The second one is purely cosmetic (looks useful to me but not much
> > of concern)
>
> I have no oppinion about // vs /**/ comments but in the absence of
>
On Mon, Feb 06, 2017 at 11:05:06PM +0100, Clément Bœsch wrote:
> On Mon, Feb 06, 2017 at 10:05:10AM +0100, u-9...@aetey.se wrote:
> [...]
> > > No, code quality is not outside the scope of your patch.
> >
> > Code quality is a subjective matter.
> >
>
> I'm not going to fight with you
Appreciat
On Fri, Feb 03, 2017 at 11:42:03AM +0100, u-9...@aetey.se wrote:
> On Fri, Feb 03, 2017 at 11:14:28AM +0100, wm4 wrote:
> > > On a 16-bit-per-pixel output with a CPU-based decoder you will
> > > not find _any_ over 25% of Cinepak speed. Raw video can not compete
> > > either when indata delivery ba
On Tue, Feb 07, 2017 at 04:23:50PM +0100, wm4 wrote:
> > Still, given the disapproval of the "code quality" without a tangible
> > criteria to follow, I can hardly take any accomodating steps, barring
> > the omission of the unused code - would this step be enough?
>
> Bad:
> - dead code
Already
On Tue, Feb 07, 2017 at 04:17:30PM +0100, Hendrik Leppkes wrote:
> On Tue, Feb 7, 2017 at 3:57 PM, wrote:
> > Still, given the disapproval of the "code quality" without a tangible
> > criteria to follow, I can hardly take any accomodating steps, barring
> > the omission of the unused code - would
Hello Ronald,
On Tue, Feb 07, 2017 at 10:29:01AM -0500, Ronald S. Bultje wrote:
> So, right now, the decoder outputs pal8 vs. rgb24 depending on the internal
> format of the bitstream, and you're changing it to do conversion so it
> outputs a selectable output format directly, right? (And then the
On Tue, Feb 07, 2017 at 12:54:23PM -0500, Ronald S. Bultje wrote:
> On Tue, Feb 7, 2017 at 12:04 PM, wrote:
>
> > cinepak, rgb2419.7 (via the fast bilinear swscaler)
> > cinepak, internal rgb565 6.0
>
>
> The reason that your decoder-integrated colorspace convertor is so much
Dear Henrik,
On Tue, Feb 07, 2017 at 07:21:39PM +0100, Hendrik Leppkes wrote:
> > Why not, if there will be a data consumer with this hypothetical format
> > and we will need speed? Why not? This _is_ efficient at the decoder,
> > it is just many of the developers ignored this fact until now.
>
>
On Tue, Feb 07, 2017 at 10:50:42PM +0100, Michael Niedermayer wrote:
> There is no "Rl" in there
>
> git removes that when applying with git am
> git am
> ...
> From: Rl
> ...
> git show
> ...
> Author: addr-see-the-webs...@aetey.se
Oh! :-/
> I dont know why git does that but it does, i retest
On Tue, Feb 07, 2017 at 09:07:02PM -0700, Daniel Verkamp wrote:
> There is already a rgb24-to-rgb565 path, but it does not get used by
> default because of the needsDither check in ff_get_unscaled_swscale().
> If the scaling algorithm is set to fast_bilinear, needsDither is
> ignored and the RGB24
On Wed, Feb 08, 2017 at 09:02:44AM -0500, Ronald S. Bultje wrote:
> I encourage you to fork the code and publish the faster decoder so others
> with use cases like yours can use it. It's free software, you're allowed
> and encouraged to do that.
I considered this possibility. My scope of contribut
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 ab
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 d
On Mon, Feb 13, 2017 at 02:23:47PM +0100, Paul B Mahol wrote:
> >> @@ -488,4 +1026,6 @@ AVCodec ff_cinepak_decoder = {
> >> .close = cinepak_decode_end,
> >> .decode = cinepak_decode_frame,
> >> .capabilities = AV_CODEC_CAP_DR1,
> >> +.pix_fmts = pixfmt_l
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.
--^^^
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
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 sm
Support for conditional compilation,
a simple non-intrusive means to avoid binary bloat when this is relevant.
OTOH this change adds some extra lines to the source, which
may be acceptable or not.
Regards,
Rune
>From 11b5906e5161748b77bbad242ac28a49851c8b4f Mon Sep 17 00:00:00 2001
From: Rl
Date
Hello,
Here comes the latest version of the patch, with adjustments
made according to all substantial feedback comments.
Among others the code has been further deduplicated to ease maintenance.
Hopefully the 2-4 times improvement of the decoding speed justifies the
growth of the affected source
On Sat, Feb 25, 2017 at 09:27:05PM +0100, Paul B Mahol wrote:
> On 2/25/17, u-9...@aetey.se wrote:
> > Hello,
> >
> > Here comes the latest version of the patch, with adjustments
> > made according to all substantial feedback comments.
> >
> > Among others the code has been further deduplicated to
This extra patch "beyond the series" is being posted for the benefit
of a casual reader who needs extremely fast/lightweight video decoding
of prearranged videos, with existing or/and mainstream applications
(e.g. like mplayer).
This patch is vital to make the cinepak decoding speedup (the matter
On Sat, Mar 04, 2017 at 09:16:30AM -0800, Philip Langdale wrote:
> On Wed, 1 Mar 2017 11:58:39 +0100
> Timo Rothenpieler wrote:
> > Would like to bring this back up.
> > I'd like to merge this, as specially the scaling is freely done by the
> > video asic, offering a possibility to scale without r
On Sat, Mar 04, 2017 at 08:33:03PM +0100, Timo Rothenpieler wrote:
> >Which criteria would make a decoder (or any tool) a wrong place
> >for something it does much better than anyone else?
>
> It's about having scaling-functionality in libavcodec, while it belongs into
> libavfilter, but the cuvid
For one week there was no substantial feedback on the patches.
I understand that the first patch was very large which makes it hard
to review.
That's why I now have produced a limited, minimalistic change which still
yields most of the improvement.
I kindly ask the reader to note that cinepak is
Whitespace adjustments only.
Regards,
Rune
>From 664e8878aac9dd9fa0393a1d60de81df8bf2f195 Mon Sep 17 00:00:00 2001
From: Rl
Date: Sun, 5 Mar 2017 16:32:58 +0100
Subject: [PATCH 2/2] libavcodec/cinepak.c: small whitespace cleanups
---
libavcodec/cinepak.c | 8
1 file changed, 4 insertio
On Sun, Mar 05, 2017 at 07:32:08PM +0100, Paul B Mahol wrote:
> On 3/5/17, u-9...@aetey.se wrote:
> > I kindly ask the reader to note that cinepak is not ffmpeg's everyday meal
> > i.e. fast shortcut judgements may be not applicable. Please take your time.
> Cinepak is old crappy codec. Get over
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 o
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:
> > > > you may want to ad
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, wrote:
> > >
> > > > On Mon, Feb
On Mon, Mar 06, 2017 at 10:19:33AM +0100, Paul B Mahol wrote:
> On 3/6/17, u-9...@aetey.se wrote:
> > I do have respect for your work and competence.
> > Please do the same to others.
>
> What is your Work and Competence in FFmpeg?
This is offtopic and looks like ad hominem
"a logical fallacy in
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 careles
Karl,
I wish to thank you for the effort to make the "opposite" parties
to better understand each other.
As you say, indeed the patch makes a move which looks in line with
ffmpeg's former traditions but which at least formally collides with
the currently percepted "best practices".
On Mon, Mar 0
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 that again.
Actual
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 make it look like it
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
Hello Karl,
I appreciate your interest and comments.
Keeping on topic, to the patch decision makers:
I actually complied with all real suggestions heard during
the discussion, even with those I find being misdirected,
i.e. virtually everything except dropping the patch as a whole.
Now I am
Now it has been more than a month since the initial submission
of the Cinepak decoder speedup patch (not counting the proof of concept
posted two months ago).
Since then, more and more of the oftentimes ignorant discussion was
dedicated to the perceived design/development policy conformance (still
82 matches
Mail list logo
