mirror of
https://gitee.com/openharmony/third_party_ffmpeg
synced 2024-11-27 13:10:37 +00:00
7fad19a63d
* 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>
25 lines
1.2 KiB
Plaintext
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
|