X264 Summer Of Code 2008 - Revision history

Dark Shikari at 01:13, 18 March 2008

2008-03-18T01:13:45Z

← Older revision		Revision as of 18:13, 17 March 2008
Line 1:		Line 1:
	~~''(Note: page copied with minor modifications from~~ [http://wiki.videolan.org/SoC_x264 ~~the Videolan wiki])~~'~~'<br><br>~~		[http://wiki.videolan.org/SoC_x264 This year's x264 SoC is being handled by VideoLan.]
	[[x264~~]] has loads of possibilities for [[FFmpeg Summer Of Code 2008]] projects. This~~ is ~~part of the FFmpeg Summer of Code 2008.~~

	*Mentor (and author of this page): Jason Garrett-Glaser (Dark Shikari)
	*Possible backup mentor: Loren Merritt (pengvado)

	~~==Introduction to x264==~~
	~~x264 is probably the most efficient, compression-wise, open source video encoder there is. It is quite competitive with commercial encoders, outclassing a large number of them.~~

	While not actually part of ffmpeg (it has its own codebase), it is a major library used by ffmpeg, licensed under the GPL, in addition to being a standalone encoder. As the only major open-source H.264 encoder, x264 has a near-complete monopoly on H.264 encoding in the consumer world, along with being ~~used~~ by ~~many major corporations, including Facebook and Google. Some companies, such as Avail Media, have in the past offered bounties on improvements to the encoder.~~

	~~==x264 project ideas==~~
	This is not at all an exhaustive list; this is just a few I thought up with. I'm willing to mentor any reasonable project on x264 to the best of my ability. I'm being pretty conservative here, so I'm picking projects that are probably not at all too ambitious for a good student. If anything, I might be underestimating the amount of work that can be done, so feel free to propose something else if you're feeling creative.
	~~:-- Dark Shikari~~

	~~===Size key===~~
	Depends heavily on the skill and willingness to work of the student. An extremely dedicated and talented student might be able to implement MBAFF in a summer, but it is certainly not fair to expect such a thing from most students.

	*Very Large: Probably too large to completed in one summer.
	*Large: Probably the right size for a full-summer project.
	*Medium: Probably too small. Could be combined with another project, of course.
	*Small: A small project, but definitely useful, and could be part of a larger project.

	~~===Skills needed===~~
	~~These are required for all listed projects and probably anything not listed, too.~~
	*Basic C programming.
	*Basic understanding of video encoding, or at least willingness to do the appropriate reading up on the topic before the summer begins.
	*Confidence in the ability to learn the following and similar topics:
	~~:*Discrete cosine transform and similar frequency transforms~~
	~~:*Motion estimation and compensation~~
	~~:*Quantization and entropy encoding~~

	~~==Projects==~~
	~~===Fast inter refinement===~~
	~~''Size: Medium to large.''~~

	Description: Improve heuristics and decision-making for inter refinement to improve efficiency on non-insane encoding settings. This would involve various early termination heuristics along with methods of deciding which partition modes need to be searched while performing minimal actual searching on those partition modes. This would be similar to, but a vastly more in-depth analysis of what was proposed in the "Fast-Ref-Search" patch.

	~~Difficulty: Medium~~

	~~===Fast intra refinement===~~
	~~''Size: Small to medium''~~

	Description: Similar to above, but covering intra modes instead. Would probably involve considerable statistical analysis of intra mode data, along with creative solutions for improved RDO refinement. We already have some ideas on this one, but haven't implemented any of them.

	~~Difficulty: Medium~~

	~~===RDO B-frame decision===~~
	~~''Size: Medium to large''~~

	Description: x264's biggest weakness is its B-frame decision algorithm, which can often be extremely subtopimal, with OPSNR losses as high as 1db in some cases. Improving this would drastically increase the effectiveness of the encoder.

	~~Difficulty: Medium-high~~

	~~===Other possible projects===~~
	~~Anything here (and not here) can potentially be picked from at the request of a student.~~

	*Assembly optimizations of any sort
	~~:*Extra skills: Assembly coding~~
	~~:*Difficulty: Medium~~
	~~:*Examples:~~
	~~::*Port cacheline split to the motion compensation code for increased speed (this could further be used to improve ffh264's decoding).~~
	~~::*Assembly-optimize some things that haven't been already.~~
	~~::*Port some MMX assembly to SSE where it seems useful.~~
	~~::*Play around with potential SSE4 optimizations.~~

	*Psychovisual optimizations for mode decision and quantization (e.g. QNS)
	~~:*Extra skills: Creativity and perhaps some understanding of DCT/Fourier math.~~
	~~:*Difficulty: Medium-high~~
	~~:*Examples:~~
	~~::*SSIM-QNS optimization?~~
	~~::*Adaptive deadzone?~~
	~~::*Adaptive lambda?~~

	*Implementing MBAFF or PicAFF (potentially too difficult for a SoC project, however)
	~~:*Difficulty: Very high~~

	*Fast RD optimization using heuristics
	~~:*Extra skills: Reading lots of IEEE papers~~
	~~:*Difficulty: Medium~~

	*Motion search improvements
	~~:*Difficulty: Medium~~

	*Anything else reasonable, honestly. There's all sorts of ideas floating around.

	~~==Contact info==~~
	~~If you are interested, drop by #ffmpeg-devel, #ffmpeg, #x264, or #x264dev on Freenode~~.

Dark Shikari: adding RL names

2008-03-17T20:37:55Z

adding RL names

← Older revision		Revision as of 13:37, 17 March 2008
Line 2:		Line 2:
	[[x264]] has loads of possibilities for [[FFmpeg Summer Of Code 2008]] projects. This is part of the FFmpeg Summer of Code 2008.		[[x264]] has loads of possibilities for [[FFmpeg Summer Of Code 2008]] projects. This is part of the FFmpeg Summer of Code 2008.

	*Mentor (and author of this page): Dark Shikari		*Mentor (and author of this page): Jason Garrett-Glaser (Dark Shikari)
	*Possible backup mentor: pengvado		*Possible backup mentor: Loren Merritt (pengvado)

	==Introduction to x264==		==Introduction to x264==

Dark Shikari at 20:32, 17 March 2008

2008-03-17T20:32:06Z

← Older revision		Revision as of 13:32, 17 March 2008
Line 1:		Line 1:
	''(Note: page copied with minor modifications from [http://wiki.videolan.org/SoC_x264 the Videolan wiki])''		''(Note: page copied with minor modifications from [http://wiki.videolan.org/SoC_x264 the Videolan wiki])''<br><br>
	[[x264]] has loads of possibilities for [[FFmpeg Summer Of Code 2008]] projects. This is part of the FFmpeg Summer of Code 2008.		[[x264]] has loads of possibilities for [[FFmpeg Summer Of Code 2008]] projects. This is part of the FFmpeg Summer of Code 2008.

Dark Shikari: new page

2008-03-17T20:31:15Z

new page

New page

''(Note: page copied with minor modifications from [http://wiki.videolan.org/SoC_x264 the Videolan wiki])''
[[x264]] has loads of possibilities for [[FFmpeg Summer Of Code 2008]] projects. This is part of the FFmpeg Summer of Code 2008.

*Mentor (and author of this page): Dark Shikari
*Possible backup mentor: pengvado

==Introduction to x264==
x264 is probably the most efficient, compression-wise, open source video encoder there is. It is quite competitive with commercial encoders, outclassing a large number of them.

While not actually part of ffmpeg (it has its own codebase), it is a major library used by ffmpeg, licensed under the GPL, in addition to being a standalone encoder. As the only major open-source H.264 encoder, x264 has a near-complete monopoly on H.264 encoding in the consumer world, along with being used by many major corporations, including Facebook and Google. Some companies, such as Avail Media, have in the past offered bounties on improvements to the encoder.

==x264 project ideas==
This is not at all an exhaustive list; this is just a few I thought up with. I'm willing to mentor any reasonable project on x264 to the best of my ability. I'm being pretty conservative here, so I'm picking projects that are probably not at all too ambitious for a good student. If anything, I might be underestimating the amount of work that can be done, so feel free to propose something else if you're feeling creative.
:-- Dark Shikari

===Size key===
Depends heavily on the skill and willingness to work of the student. An extremely dedicated and talented student might be able to implement MBAFF in a summer, but it is certainly not fair to expect such a thing from most students.

*Very Large: Probably too large to completed in one summer.
*Large: Probably the right size for a full-summer project.
*Medium: Probably too small. Could be combined with another project, of course.
*Small: A small project, but definitely useful, and could be part of a larger project.

===Skills needed===
These are required for all listed projects and probably anything not listed, too.
*Basic C programming.
*Basic understanding of video encoding, or at least willingness to do the appropriate reading up on the topic before the summer begins.
*Confidence in the ability to learn the following and similar topics:
:*Discrete cosine transform and similar frequency transforms
:*Motion estimation and compensation
:*Quantization and entropy encoding

==Projects==
===Fast inter refinement===
''Size: Medium to large.''

Description: Improve heuristics and decision-making for inter refinement to improve efficiency on non-insane encoding settings. This would involve various early termination heuristics along with methods of deciding which partition modes need to be searched while performing minimal actual searching on those partition modes. This would be similar to, but a vastly more in-depth analysis of what was proposed in the "Fast-Ref-Search" patch.

Difficulty: Medium

===Fast intra refinement===
''Size: Small to medium''

Description: Similar to above, but covering intra modes instead. Would probably involve considerable statistical analysis of intra mode data, along with creative solutions for improved RDO refinement. We already have some ideas on this one, but haven't implemented any of them.

Difficulty: Medium

===RDO B-frame decision===
''Size: Medium to large''

Description: x264's biggest weakness is its B-frame decision algorithm, which can often be extremely subtopimal, with OPSNR losses as high as 1db in some cases. Improving this would drastically increase the effectiveness of the encoder.

Difficulty: Medium-high

===Other possible projects===
Anything here (and not here) can potentially be picked from at the request of a student.

*Assembly optimizations of any sort
:*Extra skills: Assembly coding
:*Difficulty: Medium
:*Examples:
::*Port cacheline split to the motion compensation code for increased speed (this could further be used to improve ffh264's decoding).
::*Assembly-optimize some things that haven't been already.
::*Port some MMX assembly to SSE where it seems useful.
::*Play around with potential SSE4 optimizations.

*Psychovisual optimizations for mode decision and quantization (e.g. QNS)
:*Extra skills: Creativity and perhaps some understanding of DCT/Fourier math.
:*Difficulty: Medium-high
:*Examples:
::*SSIM-QNS optimization?
::*Adaptive deadzone?
::*Adaptive lambda?

*Implementing MBAFF or PicAFF (potentially too difficult for a SoC project, however)
:*Difficulty: Very high

*Fast RD optimization using heuristics
:*Extra skills: Reading lots of IEEE papers
:*Difficulty: Medium

*Motion search improvements
:*Difficulty: Medium

*Anything else reasonable, honestly. There's all sorts of ideas floating around.

==Contact info==
If you are interested, drop by #ffmpeg-devel, #ffmpeg, #x264, or #x264dev on Freenode.