On Mon, Jan 4, 2016 at 1:29 AM, Clément Bœsch <u...@pkh.me> wrote: > On Sun, Jan 03, 2016 at 09:49:33PM -0800, Ganesh Ajjanagadde wrote: >> On Sun, Jan 3, 2016 at 1:30 PM, Carl Eugen Hoyos <ceho...@ag.or.at> wrote: >> > Carl Eugen Hoyos <cehoyos <at> ag.or.at> writes: >> > >> >> Ganesh Ajjanagadde <gajjanag <at> mit.edu> writes: >> >> >> >> > No one has told me what is interesting >> >> >> >> Did you look at tickets #4441 or #4085? >> > >> > Or ticket #4829 or a j2k issue? >> >> Thanks a lot for taking the time to point these out. They have all >> been noted. Unfortunately, I have too many things on my list now. 4829 >> may be what I tackle first; it may take a while though. >> >> I hope the following is helpful. >> Generally, my strengths are in algorithmic/mathematical/numerical >> improvements. > > but not interested in merging pre-filter and RLB-filter in EBU R128 like I > pointed out? :(
That was a long time back, completely forgotten and never noted down explicitly. Thanks for reminding me :). > > More seriously, maybe try to write a filter? I'm thinking of the Eulerian > magnification filter¹², which I unfortunately haven't time to work on. I recall seeing this at MIT a year back, noted. Thanks. > > You may also enjoy studying motion interpolation for many applications. > > Anyway, the point is, you have a very large range of possibilities to > enjoy yourself on the project wrt image processing. > > [1]: http://people.csail.mit.edu/mrub/vidmag/ > [2]: https://www.youtube.com/watch?v=ONZcjs1Pjmk > >> I have a strong interest in security (both its >> "practical" and "theoretical" variants), but with nowhere near the >> same level of knowledge. >> >> Clarifications: by algorithmic improvements, I do not usually count >> asm code, but make exceptions in some cases. In particular, I have >> minimal knowledge of assembly and minimal motivation in learning it. >> However, I may examine at some point cases where I am convinced that a >> compiler can't do the needful. >> By theoretical aspects of security, I refer to defensive programming, >> some forms of undefined behavior (e.g rint64_clip, many ubsan >> failures), and other such things such as those flagged by Coverity. By >> practical aspects of security, I refer to things like fuzzing crashes, >> other ubsan failures, and other things flagged by Coverity or found by >> audit. > > Well, I have a challenging suggestion then... How about looking at > threading? Look for Helgrind (or DRD) on http://fate.ffmpeg.org. I know > many of the report are false positive... but are they? Do we have real > issues spotted here? You might want to study why we have so much of them, > if ints read/write really are actually atomic on all platforms, ... that > sort of stuff :) Ah, threading - this was always a pain, and I deliberately did not study it as well as I should have during my undergrad years. This will unfortunately go very down in my list, as I need to study it and find the necessary time. @all: thanks very much for suggestions. > > -- > Clément B. > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
