FFmpeg/doc/soc.txt
Michael Niedermayer 7fad19a63d Merge remote-tracking branch 'qatar/master'
* qatar/master:
  x86: cabac: replace explicit memory references with "m" operands
  avplay: don't request a stereo downmix
  wmapro: use av_float2int()
  lavc: avoid invalid memcpy() in avcodec_default_release_buffer()
  lavu: replace int/float punning functions
  lavfi: install libavfilter/vsrc_buffer.h
  Remove extraneous semicolons
  sdp: Restore the original mp4 format h264 extradata if converted
  rtpenc: Add support for mp4 format h264
  rtpenc: Simplify code by introducing a separate end pointer
  movenc: Use the actual converted sample for RTP hinting
  Fix a bunch of common typos.

Conflicts:
	doc/developer.texi
	doc/eval.texi
	doc/filters.texi
	doc/protocols.texi
	ffmpeg.c
	ffplay.c
	libavcodec/mpegvideo.h
	libavcodec/x86/cabac.h
	libavfilter/Makefile
	libavformat/avformat.h
	libavformat/cafdec.c
	libavformat/flvdec.c
	libavformat/flvenc.c
	libavformat/gxfenc.c
	libavformat/img2.c
	libavformat/movenc.c
	libavformat/mpegts.c
	libavformat/rtpenc_h264.c
	libavformat/utils.c
	libavformat/wtv.c

Merged-by: Michael Niedermayer <michaelni@gmx.at>
2011-12-12 01:25:37 +01:00

25 lines
1.2 KiB
Plaintext

Google Summer of Code and similar project guidelines
Summer of Code is a project by Google in which students are paid to implement
some nice new features for various participating open source projects ...
This text is a collection of things to take care of for the next soc as
it's a little late for this year's soc (2006).
The Goal:
Our goal in respect to soc is and must be of course exactly one thing and
that is to improve FFmpeg, to reach this goal, code must
* conform to the development policy and patch submission guidelines
* must improve FFmpeg somehow (faster, smaller, "better",
more codecs supported, fewer bugs, cleaner, ...)
for mentors and other developers to help students to reach that goal it is
essential that changes to their codebase are publicly visible, clean and
easy reviewable that again leads us to:
* use of a revision control system like git
* separation of cosmetic from non-cosmetic changes (this is almost entirely
ignored by mentors and students in soc 2006 which might lead to a surprise
when the code will be reviewed at the end before a possible inclusion in
FFmpeg, individual changes were generally not reviewable due to cosmetics).
* frequent commits, so that comments can be provided early