SoC x264 2008 - Revision history

DoesItReallyMatter: +:Category:SoC

2019-02-05T08:46:13Z

← Older revision		Revision as of 08:46, 5 February 2019
Line 148:		Line 148:
	You should also contact the admin [[User:J-b\|jb]].		You should also contact the admin [[User:J-b\|jb]].

	{{GSoC}} [[Category:x264]]		{{GSoC}}

			[[Category:SoC]]
			[[Category:x264]]

2013-09-30T14:04:19Z

← Older revision		Revision as of 14:04, 30 September 2013
Line 148:		Line 148:
	You should also contact the admin [[User:J-b\|jb]].		You should also contact the admin [[User:J-b\|jb]].

	{{GSoC}}		{{GSoC}} [[Category:x264]]

2013-09-30T13:45:33Z

← Older revision		Revision as of 13:45, 30 September 2013
Line 147:		Line 147:

	You should also contact the admin [[User:J-b\|jb]].		You should also contact the admin [[User:J-b\|jb]].

			{{GSoC}}

2009-03-13T11:13:51Z

← Older revision	Revision as of 11:13, 13 March 2009
(No difference)

2008-03-29T00:32:21Z

Other possible projects

2008-03-25T15:49:30Z

Updates

← Older revision		Revision as of 15:49, 25 March 2008
Line 138:		Line 138:
	*Your algorithm shouldn't violate the MV range limit as stated previously. If it does it might lead to random crashing, which we obviously don't want.		*Your algorithm shouldn't violate the MV range limit as stated previously. If it does it might lead to random crashing, which we obviously don't want.
	*If there's not a large difference between HEX and UMH, you won't have much room to work! Try to find a high-motion source where the difference is measurable.		*If there's not a large difference between HEX and UMH, you won't have much room to work! Try to find a high-motion source where the difference is measurable.
			:May I strongly recommend the free 1080p source of Elephant's Dream? Low-resolution sources don't have much motion, in terms of pixels-moved-per frame, so they're not good for measuring efficiency of complex motion searches.

	==Contact info==		==Contact info==

2008-03-24T14:18:03Z

Updates

← Older revision		Revision as of 14:18, 24 March 2008
Line 137:		Line 137:
	*Your algorithm should be '''deterministic'''. This means, unlike one algorithm submitted so far (which wasn't half-bad!)... it cannot contain rand().		*Your algorithm should be '''deterministic'''. This means, unlike one algorithm submitted so far (which wasn't half-bad!)... it cannot contain rand().
	*Your algorithm shouldn't violate the MV range limit as stated previously. If it does it might lead to random crashing, which we obviously don't want.		*Your algorithm shouldn't violate the MV range limit as stated previously. If it does it might lead to random crashing, which we obviously don't want.
			*If there's not a large difference between HEX and UMH, you won't have much room to work! Try to find a high-motion source where the difference is measurable.

	==Contact info==		==Contact info==

2008-03-24T00:29:13Z

Qualification tasks

← Older revision		Revision as of 00:29, 24 March 2008
Line 134:		Line 134:
	::When you're done, email me the resulting patch for x264 and any extra information you think would be useful.		::When you're done, email me the resulting patch for x264 and any extra information you think would be useful.
	*This list isn't complete. I may add more if there's time left and we haven't narrowed it down to the right number of students yet.		*This list isn't complete. I may add more if there's time left and we haven't narrowed it down to the right number of students yet.
			===Updates===
			*Your algorithm should be '''deterministic'''. This means, unlike one algorithm submitted so far (which wasn't half-bad!)... it cannot contain rand().
			*Your algorithm shouldn't violate the MV range limit as stated previously. If it does it might lead to random crashing, which we obviously don't want.

	==Contact info==		==Contact info==

2008-03-22T14:11:16Z

Film grain modeling

← Older revision		Revision as of 14:11, 22 March 2008
Line 63:		Line 63:
	''Size: Medium to large''		''Size: Medium to large''

	An integral part of the standard... but supported by basically nothing despite its potential usefulness. This would involve implementing FGM in both x264 '''and''' some sort of decoder, preferably ffmpeg.		An integral part of the standard... but supported by basically nothing despite its potential usefulness. This would involve implementing FGM in both x264 '''and''' some sort of decoder, preferably ffmpeg. Some work has already been done in this category, so you won't be starting from nothing.

	Difficulty: Medium		Difficulty: Medium

2008-03-22T14:10:53Z

Projects

← Older revision		Revision as of 14:10, 22 March 2008
Line 57:		Line 57:

	Description: x264 doesn't support any color spaces other than YV12. This would solve this problem by adding the ability to use YUY2 and YV24 color spaces. This might be useful for some animation footage, or graphics; plus its been requested often.		Description: x264 doesn't support any color spaces other than YV12. This would solve this problem by adding the ability to use YUY2 and YV24 color spaces. This might be useful for some animation footage, or graphics; plus its been requested often.

			Difficulty: Medium

			===Film grain modeling===
			''Size: Medium to large''

			An integral part of the standard... but supported by basically nothing despite its potential usefulness. This would involve implementing FGM in both x264 '''and''' some sort of decoder, preferably ffmpeg.

	Difficulty: Medium		Difficulty: Medium