[FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Ganesh Ajjanagadde]

On Mon, Jan 4, 2016 at 1:29 AM, Clément Bœsch <u at 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 <cehoyos at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>