Talk:SoC 2007 - Revision history

Dionoea: Reverted edits by Wx0U64 (Talk); changed back to last version by Compn

2007-05-31T13:03:23Z

Reverted edits by Wx0U64 (Talk); changed back to last version by Compn

← Older revision		Revision as of 13:03, 31 May 2007
Line 14:		Line 14:
	=== DirectX improvements ===		=== DirectX improvements ===

	HD1080 streams (for instance MPEG4-AVC) push the best current machines at their limit. Usage of http://en.wikipedia.org/wiki/DXVA could help to leverage any GPU capabilities and accelerate the rendering (delegation of part of the process to the GPU depending on GPU capabilities		HD1080 streams (for instance MPEG4-AVC) push the best current machines at their limit. Usage of http://en.wikipedia.org/wiki/DXVA could help to leverage any GPU capabilities and accelerate the rendering (delegation of part of the process to the GPU depending on GPU capabilities & driver implementation). Actually, hardware manufacturers such as ATI (h264 DxVA) or NVidia (PureVideo) have already provided such implementation and some other players have already integrated DXVA.

			=== Subtitles ===

			is it possible to play two subtitles at once? or at least, can this be optionally added when the new subtitle code comes in ? :) --[[User:Compn\|Compn]] 18:02, 19 April 2007 (CEST)

Wx0U64 at 12:49, 31 May 2007

2007-05-31T12:49:42Z

← Older revision		Revision as of 12:49, 31 May 2007
Line 14:		Line 14:
	=== DirectX improvements ===		=== DirectX improvements ===

	HD1080 streams (for instance MPEG4-AVC) push the best current machines at their limit. Usage of http://en.wikipedia.org/wiki/DXVA could help to leverage any GPU capabilities and accelerate the rendering (delegation of part of the process to the GPU depending on GPU capabilities ~~& driver implementation). Actually, hardware manufacturers such as ATI (h264 DxVA) or NVidia (PureVideo) have already provided such implementation and some other players have already integrated DXVA.~~		HD1080 streams (for instance MPEG4-AVC) push the best current machines at their limit. Usage of http://en.wikipedia.org/wiki/DXVA could help to leverage any GPU capabilities and accelerate the rendering (delegation of part of the process to the GPU depending on GPU capabilities

	~~=== Subtitles ===~~

	~~is it possible to play two subtitles at once? or at least, can this be optionally added when the new subtitle code comes in ? :) --[[User:Compn\|Compn]] 18:02, 19 April 2007 (CEST)~~

Compn: /* General talk */

2007-04-19T16:02:58Z

General talk

← Older revision		Revision as of 16:02, 19 April 2007
Line 15:		Line 15:

	HD1080 streams (for instance MPEG4-AVC) push the best current machines at their limit. Usage of http://en.wikipedia.org/wiki/DXVA could help to leverage any GPU capabilities and accelerate the rendering (delegation of part of the process to the GPU depending on GPU capabilities & driver implementation). Actually, hardware manufacturers such as ATI (h264 DxVA) or NVidia (PureVideo) have already provided such implementation and some other players have already integrated DXVA.		HD1080 streams (for instance MPEG4-AVC) push the best current machines at their limit. Usage of http://en.wikipedia.org/wiki/DXVA could help to leverage any GPU capabilities and accelerate the rendering (delegation of part of the process to the GPU depending on GPU capabilities & driver implementation). Actually, hardware manufacturers such as ATI (h264 DxVA) or NVidia (PureVideo) have already provided such implementation and some other players have already integrated DXVA.

			=== Subtitles ===

			is it possible to play two subtitles at once? or at least, can this be optionally added when the new subtitle code comes in ? :) --[[User:Compn\|Compn]] 18:02, 19 April 2007 (CEST)

Bjb: /* DirectX improvements */

2007-04-02T09:16:19Z

DirectX improvements

← Older revision		Revision as of 09:16, 2 April 2007
Line 13:		Line 13:

	=== DirectX improvements ===		=== DirectX improvements ===

			HD1080 streams (for instance MPEG4-AVC) push the best current machines at their limit. Usage of http://en.wikipedia.org/wiki/DXVA could help to leverage any GPU capabilities and accelerate the rendering (delegation of part of the process to the GPU depending on GPU capabilities & driver implementation). Actually, hardware manufacturers such as ATI (h264 DxVA) or NVidia (PureVideo) have already provided such implementation and some other players have already integrated DXVA.

Bjb: /* General talk */ Add DirectX improvements section

2007-04-02T09:07:35Z

General talk: Add DirectX improvements section

← Older revision		Revision as of 09:07, 2 April 2007
Line 10:		Line 10:
	From the VLC point of view i don't agree. It would be easier to integrate the muxer directly into VLC than put it in libavformat and then change the libavformat <-> VLC interface to use it. I'm not sure how the chapter / menu / subs system works in MKV but it sure will add complexitiy to or libavformat interface (and some lagg time between the time the mkv muxer makes it into ffmpeg and the time we make it work in VLC). -- [[User:Dionoea\|Dionoea]] 16:25, 8 March 2007 (CET)		From the VLC point of view i don't agree. It would be easier to integrate the muxer directly into VLC than put it in libavformat and then change the libavformat <-> VLC interface to use it. I'm not sure how the chapter / menu / subs system works in MKV but it sure will add complexitiy to or libavformat interface (and some lagg time between the time the mkv muxer makes it into ffmpeg and the time we make it work in VLC). -- [[User:Dionoea\|Dionoea]] 16:25, 8 March 2007 (CET)
	:Note that the ffmpeg project already has this listed on their [http://wiki.multimedia.cx/index.php?title=Summer_Of_Code_2007 SOC page.]		:Note that the ffmpeg project already has this listed on their [http://wiki.multimedia.cx/index.php?title=Summer_Of_Code_2007 SOC page.]


			=== DirectX improvements ===

Username: /* MKV muxer */

2007-03-15T16:28:03Z

MKV muxer

← Older revision		Revision as of 16:28, 15 March 2007
Line 9:		Line 9:
	=== MKV muxer ===		=== MKV muxer ===
	From the VLC point of view i don't agree. It would be easier to integrate the muxer directly into VLC than put it in libavformat and then change the libavformat <-> VLC interface to use it. I'm not sure how the chapter / menu / subs system works in MKV but it sure will add complexitiy to or libavformat interface (and some lagg time between the time the mkv muxer makes it into ffmpeg and the time we make it work in VLC). -- [[User:Dionoea\|Dionoea]] 16:25, 8 March 2007 (CET)		From the VLC point of view i don't agree. It would be easier to integrate the muxer directly into VLC than put it in libavformat and then change the libavformat <-> VLC interface to use it. I'm not sure how the chapter / menu / subs system works in MKV but it sure will add complexitiy to or libavformat interface (and some lagg time between the time the mkv muxer makes it into ffmpeg and the time we make it work in VLC). -- [[User:Dionoea\|Dionoea]] 16:25, 8 March 2007 (CET)
			:Note that the ffmpeg project already has this listed on their [http://wiki.multimedia.cx/index.php?title=Summer_Of_Code_2007 SOC page.]

J-b: /* General talk */ Keep the page CLEAN

2007-03-08T17:27:22Z

General talk: Keep the page CLEAN

← Older revision		Revision as of 17:27, 8 March 2007
Line 2:		Line 2:

	== General talk ==		== General talk ==

			=== Cache and GUI interface ===
	This project may need to redesign a bit the cache handling module access. (How is this "Interface" related ? I agree that we might need to change the caching algorithms for web-content, but it's definitively not interface (nor web plugin) related. [[User:Dionoea\|Dionoea]] 16:17, 8 March 2007 (CET))		This project may need to redesign a bit the cache handling module access. (How is this "Interface" related ? I agree that we might need to change the caching algorithms for web-content, but it's definitively not interface (nor web plugin) related. [[User:Dionoea\|Dionoea]] 16:17, 8 March 2007 (CET))
	% Because VLC caches in seconds and Youtube are just caching the most they can to have the whole file local.		: Because VLC caches in seconds and Youtube are just caching the most they can to have the whole file local.

			=== MKV muxer ===
			From the VLC point of view i don't agree. It would be easier to integrate the muxer directly into VLC than put it in libavformat and then change the libavformat <-> VLC interface to use it. I'm not sure how the chapter / menu / subs system works in MKV but it sure will add complexitiy to or libavformat interface (and some lagg time between the time the mkv muxer makes it into ffmpeg and the time we make it work in VLC). -- [[User:Dionoea\|Dionoea]] 16:25, 8 March 2007 (CET)

J-b at 17:25, 8 March 2007

2007-03-08T17:25:15Z

← Older revision		Revision as of 17:25, 8 March 2007
Line 2:		Line 2:

	== General talk ==		== General talk ==
			This project may need to redesign a bit the cache handling module access. (How is this "Interface" related ? I agree that we might need to change the caching algorithms for web-content, but it's definitively not interface (nor web plugin) related. [[User:Dionoea\|Dionoea]] 16:17, 8 March 2007 (CET))
			% Because VLC caches in seconds and Youtube are just caching the most they can to have the whole file local.

J-b at 14:44, 8 March 2007

2007-03-08T14:44:28Z

New page

== Questions ==

== General talk ==