Replying here just for the record. Keiji Costantini wrote: > I took a look at sequent files in libswscale directory: > > Makefile > swscale.h > swscale.c > swscale_internal.h > swscale-example.c > > During the project I am told to *not* read the file "yuv2rgb.c". If > there are other files not to read, it would be nice to know that. For > now, I'm checking that every file I open contains an LGPL header or the > permission of utilization under LGPL (as swscale.c).
I'm not sure, Michael I guess that this is the only one taboo (I'll try to split out the stuff he could read to ease the work) > regarding "swscale-example.c" and "swscale_internal.h" > swscale-example.c includes swscale_internal.h which, according to > Makefile, is not public. Could test function inside "swscale-example.c" > be split from the file to have a clean "example" about using swscale > (Just took about 1/2 hour to understand why it is there)? I'd like to have the test routine split and have a test target as well. That could be one of the first commit. > regarding "swscale.c" > Should asm code be split in different files - for example to let > Makefile manage arch / cpu features (such mmx,3dnow etc)? Basically: - make an header out of the constants and macros that aren't that related (e.g. the avoption and avclass stuff) - try to get swscale-template.c built from some Makefile targets, check the libavcodec - move the remaining unrelated cruft in separate arch specific headers. - remove the hack to avoid warnings about unused vars (there is a macro already in place for it in libavutils/mem.h) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero _______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
