http://giss.tv/wiki/api.php?action=feedcontributions&user=Kurimu&feedformat=atom Giss - User contributions [en] 2024-03-28T08:18:36Z User contributions MediaWiki 1.31.1 http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=602 Dmmdb Braindump 2010-08-19T11:16:44Z <p>Kurimu: /* Refactoring */</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Average Audio Data Rates ===<br /> * LD: 64kb ?<br /> * SD: 128kb ?<br /> * HD: 320kb ?<br /> <br /> === Average Video Data Rates ===<br /> * LD: 500kb ?<br /> * SD: 2000kb ?<br /> * HD: 5000kb ?<br /> <br /> === Codecs and encapsulers ===<br /> * ogg/vorbis-theora<br /> * WebM/VP8 ?<br /> <br /> === Original Material ===<br /> On the server side config there could be an option that would enable or disable the keeping of the original files. If kept they shold be organized by channels (ie, in a folder with the channel name...)<br /> <br /> == Interface ==<br /> <br /> === Player ===<br /> ==== Size ====<br /> Always set to 640px of width regardless of content. Which means that:<br /> * video res is perfect match when it plays SD/480p material (default view)<br /> * video res is stretched when it plays LD/240p material<br /> * video res is reduced when it plays HD/720p content.<br /> <br /> HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.<br /> <br /> ==== Default and Fall-back back-end ====<br /> Only two back-ends are needed to cover almost all situations and simplify maintenance:<br /> * default is HTML5 &lt;video&gt; tag<br /> * fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)<br /> <br /> '''Radical Idea:''' My personal view would be to outsource the issue entirely to a project such as videojs.com so that someone else can take care of all the heavy lifting and compatibility nightmare.<br /> <br /> == Interoperability ==<br /> <br /> === API ===<br /> It would be nice to have a documentation of the API as it would encourage the contribution of client side tools/helpers and plugins. For example a CLI to upload and annotate the material.<br /> <br /> === Share ===<br /> ==== Wordpress ====<br /> As far as I understand wordpress' editor for standalone installations disables any potentially risky tags in a post, making the &lt;iframe&gt;&lt;/iframe&gt; trick useless. To counter this it is required to make a special hack to embed GISS TV using short codes and functions.php in a theme (more on this soon).<br /> <br /> Ideally the support should be provided by a plugin using the video upload interface of Wordpress (used for, a.o, Vimeo) or provide a GISS.tv shortcode plugin (used for, a.o, Vimeo) that does not involved hacking one's theme. It should not be too difficult to go from the functions.php shortcode hack to full plugin.<br /> <br /> ==== What do you embed ====<br /> Behind the wordpress issue, there is a confusion, or at least some doubts:<br /> * It is easy to create such a plugin and embedding could even be simplified by just inserting a &lt;video&gt; tag in the post and some underlying text that points to the GISS channel, but is something else needed?<br /> * What about other CMS and blog engines? Do they also suffer from the forbidden direct usage of &lt;iframe&gt; and &lt;object&gt;?<br /> * What about the FLash player fallback? This should be handled by a js included in the embedded code?<br /> * How do the others do?<br /> <br /> == Development &amp; Community ==<br /> === Workflow ===<br /> Using a DVCS would bring more visibility and simplify the process of contributing/deploying code. There are many options out there, from the popular git to mercurial or the more exotic darcs. By using DVCS, contributors can silently fork the project and commit locally to test different features and keep track of their development, once mature and accepted they can be pushed (repos to repos or as patches) to the official repos. Silent forkers can also keep in sync with the official repos while testing their changes. A central repos (such as gitorious) can be used as backup for official repos or hub if the workflow is classic (central repository).<br /> <br /> === Refactoring ===<br /> The code needs a serious cleaning, at the time of this writing, on the kurimu channel page:<br /> * W3C validator: 254 Errors and 38 warnings<br /> * webkist's inspector audit: nearly 100 of warning and problem on page's resources<br /> <br /> For a future release, I would argue it might be easier to start from scratch if the client side of the project is not much entangled in the PHP code. Using Javascript to do all the interactions and calls to a PHP powered API.<br /> <br /> ==== Javascript ====<br /> * To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib. In-lining CSS or JS should be done if nothing else is possible.<br /> * Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff.<br /> * Variable should be kept enclosed in functions whenever possible to avoid bad surprises when several channels are openned at once.<br /> <br /> ==== Tables and other hardcoded design choices ====<br /> A lot of tables are used at the moment and it's very hard to maintain, scale and read. It should be removed and the layout should only use floating divs to achieve complex layouts. It is also much more flexible as it decouple the markup language - that should kept as minimal as possible - from the design style sheet. It will also simplify the way towards full customization of a dmmdb page.<br /> <br /> === Community ===<br /> Social software is growing fast and there are more and more efforts to provide distributed systems. It would be good to see how dmmdb can interface with, for example, GNU Social, FOAF, etc.</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=601 Dmmdb Braindump 2010-08-19T11:14:50Z <p>Kurimu: /* Refactoring */</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Average Audio Data Rates ===<br /> * LD: 64kb ?<br /> * SD: 128kb ?<br /> * HD: 320kb ?<br /> <br /> === Average Video Data Rates ===<br /> * LD: 500kb ?<br /> * SD: 2000kb ?<br /> * HD: 5000kb ?<br /> <br /> === Codecs and encapsulers ===<br /> * ogg/vorbis-theora<br /> * WebM/VP8 ?<br /> <br /> === Original Material ===<br /> On the server side config there could be an option that would enable or disable the keeping of the original files. If kept they shold be organized by channels (ie, in a folder with the channel name...)<br /> <br /> == Interface ==<br /> <br /> === Player ===<br /> ==== Size ====<br /> Always set to 640px of width regardless of content. Which means that:<br /> * video res is perfect match when it plays SD/480p material (default view)<br /> * video res is stretched when it plays LD/240p material<br /> * video res is reduced when it plays HD/720p content.<br /> <br /> HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.<br /> <br /> ==== Default and Fall-back back-end ====<br /> Only two back-ends are needed to cover almost all situations and simplify maintenance:<br /> * default is HTML5 &lt;video&gt; tag<br /> * fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)<br /> <br /> '''Radical Idea:''' My personal view would be to outsource the issue entirely to a project such as videojs.com so that someone else can take care of all the heavy lifting and compatibility nightmare.<br /> <br /> == Interoperability ==<br /> <br /> === API ===<br /> It would be nice to have a documentation of the API as it would encourage the contribution of client side tools/helpers and plugins. For example a CLI to upload and annotate the material.<br /> <br /> === Share ===<br /> ==== Wordpress ====<br /> As far as I understand wordpress' editor for standalone installations disables any potentially risky tags in a post, making the &lt;iframe&gt;&lt;/iframe&gt; trick useless. To counter this it is required to make a special hack to embed GISS TV using short codes and functions.php in a theme (more on this soon).<br /> <br /> Ideally the support should be provided by a plugin using the video upload interface of Wordpress (used for, a.o, Vimeo) or provide a GISS.tv shortcode plugin (used for, a.o, Vimeo) that does not involved hacking one's theme. It should not be too difficult to go from the functions.php shortcode hack to full plugin.<br /> <br /> ==== What do you embed ====<br /> Behind the wordpress issue, there is a confusion, or at least some doubts:<br /> * It is easy to create such a plugin and embedding could even be simplified by just inserting a &lt;video&gt; tag in the post and some underlying text that points to the GISS channel, but is something else needed?<br /> * What about other CMS and blog engines? Do they also suffer from the forbidden direct usage of &lt;iframe&gt; and &lt;object&gt;?<br /> * What about the FLash player fallback? This should be handled by a js included in the embedded code?<br /> * How do the others do?<br /> <br /> == Development &amp; Community ==<br /> === Workflow ===<br /> Using a DVCS would bring more visibility and simplify the process of contributing/deploying code. There are many options out there, from the popular git to mercurial or the more exotic darcs. By using DVCS, contributors can silently fork the project and commit locally to test different features and keep track of their development, once mature and accepted they can be pushed (repos to repos or as patches) to the official repos. Silent forkers can also keep in sync with the official repos while testing their changes. A central repos (such as gitorious) can be used as backup for official repos or hub if the workflow is classic (central repository).<br /> <br /> === Refactoring ===<br /> The code needs a serious cleaning, at the time of this writing, on the kurimu channel page:<br /> * W3C validator: 254 Errors and 38 warnings<br /> * webkist's inspector audit: nearly 100 of warning and problem on page's resources<br /> <br /> For a future release, I would argue it might be easier to start from scratch if the client side of the project is not much entangled in the PHP code. Using Javascript doing all the interaction and call to a PHP powered API.<br /> <br /> ==== Javascript ====<br /> * To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib. In-lining CSS or JS should be done if nothing else is possible.<br /> * Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff.<br /> * Variable should be kept enclosed in functions whenever possible to avoid bad surprises when several channels are openned at once.<br /> <br /> ==== Tables and other hardcoded design choices ====<br /> A lot of tables are used at the moment and it's very hard to maintain, scale and read. It should be removed and the layout should only use floating divs to achieve complex layouts. It is also much more flexible as it decouple the markup language - that should kept as minimal as possible - from the design style sheet. It will also simplify the way towards full customization of a dmmdb page.<br /> <br /> === Community ===<br /> Social software is growing fast and there are more and more efforts to provide distributed systems. It would be good to see how dmmdb can interface with, for example, GNU Social, FOAF, etc.</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=600 Dmmdb Braindump 2010-08-19T11:07:06Z <p>Kurimu: /* Default and Fall-back back-end */</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Average Audio Data Rates ===<br /> * LD: 64kb ?<br /> * SD: 128kb ?<br /> * HD: 320kb ?<br /> <br /> === Average Video Data Rates ===<br /> * LD: 500kb ?<br /> * SD: 2000kb ?<br /> * HD: 5000kb ?<br /> <br /> === Codecs and encapsulers ===<br /> * ogg/vorbis-theora<br /> * WebM/VP8 ?<br /> <br /> === Original Material ===<br /> On the server side config there could be an option that would enable or disable the keeping of the original files. If kept they shold be organized by channels (ie, in a folder with the channel name...)<br /> <br /> == Interface ==<br /> <br /> === Player ===<br /> ==== Size ====<br /> Always set to 640px of width regardless of content. Which means that:<br /> * video res is perfect match when it plays SD/480p material (default view)<br /> * video res is stretched when it plays LD/240p material<br /> * video res is reduced when it plays HD/720p content.<br /> <br /> HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.<br /> <br /> ==== Default and Fall-back back-end ====<br /> Only two back-ends are needed to cover almost all situations and simplify maintenance:<br /> * default is HTML5 &lt;video&gt; tag<br /> * fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)<br /> <br /> '''Radical Idea:''' My personal view would be to outsource the issue entirely to a project such as videojs.com so that someone else can take care of all the heavy lifting and compatibility nightmare.<br /> <br /> == Interoperability ==<br /> <br /> === API ===<br /> It would be nice to have a documentation of the API as it would encourage the contribution of client side tools/helpers and plugins. For example a CLI to upload and annotate the material.<br /> <br /> === Share ===<br /> ==== Wordpress ====<br /> As far as I understand wordpress' editor for standalone installations disables any potentially risky tags in a post, making the &lt;iframe&gt;&lt;/iframe&gt; trick useless. To counter this it is required to make a special hack to embed GISS TV using short codes and functions.php in a theme (more on this soon).<br /> <br /> Ideally the support should be provided by a plugin using the video upload interface of Wordpress (used for, a.o, Vimeo) or provide a GISS.tv shortcode plugin (used for, a.o, Vimeo) that does not involved hacking one's theme. It should not be too difficult to go from the functions.php shortcode hack to full plugin.<br /> <br /> ==== What do you embed ====<br /> Behind the wordpress issue, there is a confusion, or at least some doubts:<br /> * It is easy to create such a plugin and embedding could even be simplified by just inserting a &lt;video&gt; tag in the post and some underlying text that points to the GISS channel, but is something else needed?<br /> * What about other CMS and blog engines? Do they also suffer from the forbidden direct usage of &lt;iframe&gt; and &lt;object&gt;?<br /> * What about the FLash player fallback? This should be handled by a js included in the embedded code?<br /> * How do the others do?<br /> <br /> == Development &amp; Community ==<br /> === Workflow ===<br /> Using a DVCS would bring more visibility and simplify the process of contributing/deploying code. There are many options out there, from the popular git to mercurial or the more exotic darcs. By using DVCS, contributors can silently fork the project and commit locally to test different features and keep track of their development, once mature and accepted they can be pushed (repos to repos or as patches) to the official repos. Silent forkers can also keep in sync with the official repos while testing their changes. A central repos (such as gitorious) can be used as backup for official repos or hub if the workflow is classic (central repository).<br /> <br /> === Refactoring ===<br /> The code needs a serious cleaning, at the time of this writing, on the kurimu channel page:<br /> * W3C validator: 254 Errors and 38 warnings<br /> * webkist's inspector audit: nearly 100 of warning and problem on page's resources<br /> <br /> ==== Javascript ====<br /> * To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib. In-lining CSS or JS should be done if nothing else is possible.<br /> * Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff.<br /> * Variable should be kept enclosed in functions whenever possible to avoid bad surprises when several channels are openned at once.<br /> <br /> ==== Tables and other hardcoded design choices ====<br /> A lot of tables are used at the moment and it's very hard to maintain, scale and read. It should be removed and the layout should only use floating divs to achieve complex layouts. It is also much more flexible as it decouple the markup language - that should kept as minimal as possible - from the design style sheet. It will also simplify the way towards full customization of a dmmdb page.<br /> <br /> === Community ===<br /> Social software is growing fast and there are more and more efforts to provide distributed systems. It would be good to see how dmmdb can interface with, for example, GNU Social, FOAF, etc.</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=599 Dmmdb Braindump 2010-08-19T11:05:14Z <p>Kurimu: /* Video Support */</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Average Audio Data Rates ===<br /> * LD: 64kb ?<br /> * SD: 128kb ?<br /> * HD: 320kb ?<br /> <br /> === Average Video Data Rates ===<br /> * LD: 500kb ?<br /> * SD: 2000kb ?<br /> * HD: 5000kb ?<br /> <br /> === Codecs and encapsulers ===<br /> * ogg/vorbis-theora<br /> * WebM/VP8 ?<br /> <br /> === Original Material ===<br /> On the server side config there could be an option that would enable or disable the keeping of the original files. If kept they shold be organized by channels (ie, in a folder with the channel name...)<br /> <br /> == Interface ==<br /> <br /> === Player ===<br /> ==== Size ====<br /> Always set to 640px of width regardless of content. Which means that:<br /> * video res is perfect match when it plays SD/480p material (default view)<br /> * video res is stretched when it plays LD/240p material<br /> * video res is reduced when it plays HD/720p content.<br /> <br /> HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.<br /> <br /> ==== Default and Fall-back back-end ====<br /> Only two back-ends are needed to cover almost all situations and simplify maintenance:<br /> * default is HTML5 &lt;video&gt; tag<br /> * fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)<br /> <br /> == Interoperability ==<br /> <br /> === API ===<br /> It would be nice to have a documentation of the API as it would encourage the contribution of client side tools/helpers and plugins. For example a CLI to upload and annotate the material.<br /> <br /> === Share ===<br /> ==== Wordpress ====<br /> As far as I understand wordpress' editor for standalone installations disables any potentially risky tags in a post, making the &lt;iframe&gt;&lt;/iframe&gt; trick useless. To counter this it is required to make a special hack to embed GISS TV using short codes and functions.php in a theme (more on this soon).<br /> <br /> Ideally the support should be provided by a plugin using the video upload interface of Wordpress (used for, a.o, Vimeo) or provide a GISS.tv shortcode plugin (used for, a.o, Vimeo) that does not involved hacking one's theme. It should not be too difficult to go from the functions.php shortcode hack to full plugin.<br /> <br /> ==== What do you embed ====<br /> Behind the wordpress issue, there is a confusion, or at least some doubts:<br /> * It is easy to create such a plugin and embedding could even be simplified by just inserting a &lt;video&gt; tag in the post and some underlying text that points to the GISS channel, but is something else needed?<br /> * What about other CMS and blog engines? Do they also suffer from the forbidden direct usage of &lt;iframe&gt; and &lt;object&gt;?<br /> * What about the FLash player fallback? This should be handled by a js included in the embedded code?<br /> * How do the others do?<br /> <br /> == Development &amp; Community ==<br /> === Workflow ===<br /> Using a DVCS would bring more visibility and simplify the process of contributing/deploying code. There are many options out there, from the popular git to mercurial or the more exotic darcs. By using DVCS, contributors can silently fork the project and commit locally to test different features and keep track of their development, once mature and accepted they can be pushed (repos to repos or as patches) to the official repos. Silent forkers can also keep in sync with the official repos while testing their changes. A central repos (such as gitorious) can be used as backup for official repos or hub if the workflow is classic (central repository).<br /> <br /> === Refactoring ===<br /> The code needs a serious cleaning, at the time of this writing, on the kurimu channel page:<br /> * W3C validator: 254 Errors and 38 warnings<br /> * webkist's inspector audit: nearly 100 of warning and problem on page's resources<br /> <br /> ==== Javascript ====<br /> * To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib. In-lining CSS or JS should be done if nothing else is possible.<br /> * Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff.<br /> * Variable should be kept enclosed in functions whenever possible to avoid bad surprises when several channels are openned at once.<br /> <br /> ==== Tables and other hardcoded design choices ====<br /> A lot of tables are used at the moment and it's very hard to maintain, scale and read. It should be removed and the layout should only use floating divs to achieve complex layouts. It is also much more flexible as it decouple the markup language - that should kept as minimal as possible - from the design style sheet. It will also simplify the way towards full customization of a dmmdb page.<br /> <br /> === Community ===<br /> Social software is growing fast and there are more and more efforts to provide distributed systems. It would be good to see how dmmdb can interface with, for example, GNU Social, FOAF, etc.</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=598 Dmmdb Braindump 2010-08-19T10:55:52Z <p>Kurimu: /* Wordpress */</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Audio Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> === Video Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> == Interface ==<br /> <br /> === Player ===<br /> ==== Size ====<br /> Always set to 640px of width regardless of content. Which means that:<br /> * video res is perfect match when it plays SD/480p material (default view)<br /> * video res is stretched when it plays LD/240p material<br /> * video res is reduced when it plays HD/720p content.<br /> <br /> HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.<br /> <br /> ==== Default and Fall-back back-end ====<br /> Only two back-ends are needed to cover almost all situations and simplify maintenance:<br /> * default is HTML5 &lt;video&gt; tag<br /> * fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)<br /> <br /> == Interoperability ==<br /> <br /> === API ===<br /> It would be nice to have a documentation of the API as it would encourage the contribution of client side tools/helpers and plugins. For example a CLI to upload and annotate the material.<br /> <br /> === Share ===<br /> ==== Wordpress ====<br /> As far as I understand wordpress' editor for standalone installations disables any potentially risky tags in a post, making the &lt;iframe&gt;&lt;/iframe&gt; trick useless. To counter this it is required to make a special hack to embed GISS TV using short codes and functions.php in a theme (more on this soon).<br /> <br /> Ideally the support should be provided by a plugin using the video upload interface of Wordpress (used for, a.o, Vimeo) or provide a GISS.tv shortcode plugin (used for, a.o, Vimeo) that does not involved hacking one's theme. It should not be too difficult to go from the functions.php shortcode hack to full plugin.<br /> <br /> ==== What do you embed ====<br /> Behind the wordpress issue, there is a confusion, or at least some doubts:<br /> * It is easy to create such a plugin and embedding could even be simplified by just inserting a &lt;video&gt; tag in the post and some underlying text that points to the GISS channel, but is something else needed?<br /> * What about other CMS and blog engines? Do they also suffer from the forbidden direct usage of &lt;iframe&gt; and &lt;object&gt;?<br /> * What about the FLash player fallback? This should be handled by a js included in the embedded code?<br /> * How do the others do?<br /> <br /> == Development &amp; Community ==<br /> === Workflow ===<br /> Using a DVCS would bring more visibility and simplify the process of contributing/deploying code. There are many options out there, from the popular git to mercurial or the more exotic darcs. By using DVCS, contributors can silently fork the project and commit locally to test different features and keep track of their development, once mature and accepted they can be pushed (repos to repos or as patches) to the official repos. Silent forkers can also keep in sync with the official repos while testing their changes. A central repos (such as gitorious) can be used as backup for official repos or hub if the workflow is classic (central repository).<br /> <br /> === Refactoring ===<br /> The code needs a serious cleaning, at the time of this writing, on the kurimu channel page:<br /> * W3C validator: 254 Errors and 38 warnings<br /> * webkist's inspector audit: nearly 100 of warning and problem on page's resources<br /> <br /> ==== Javascript ====<br /> * To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib. In-lining CSS or JS should be done if nothing else is possible.<br /> * Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff.<br /> * Variable should be kept enclosed in functions whenever possible to avoid bad surprises when several channels are openned at once.<br /> <br /> ==== Tables and other hardcoded design choices ====<br /> A lot of tables are used at the moment and it's very hard to maintain, scale and read. It should be removed and the layout should only use floating divs to achieve complex layouts. It is also much more flexible as it decouple the markup language - that should kept as minimal as possible - from the design style sheet. It will also simplify the way towards full customization of a dmmdb page.<br /> <br /> === Community ===<br /> Social software is growing fast and there are more and more efforts to provide distributed systems. It would be good to see how dmmdb can interface with, for example, GNU Social, FOAF, etc.</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=597 Dmmdb Braindump 2010-08-19T10:45:37Z <p>Kurimu: /* Interface */</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Audio Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> === Video Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> == Interface ==<br /> <br /> === Player ===<br /> ==== Size ====<br /> Always set to 640px of width regardless of content. Which means that:<br /> * video res is perfect match when it plays SD/480p material (default view)<br /> * video res is stretched when it plays LD/240p material<br /> * video res is reduced when it plays HD/720p content.<br /> <br /> HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.<br /> <br /> ==== Default and Fall-back back-end ====<br /> Only two back-ends are needed to cover almost all situations and simplify maintenance:<br /> * default is HTML5 &lt;video&gt; tag<br /> * fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)<br /> <br /> == Interoperability ==<br /> <br /> === API ===<br /> It would be nice to have a documentation of the API as it would encourage the contribution of client side tools/helpers and plugins. For example a CLI to upload and annotate the material.<br /> <br /> === Share ===<br /> ==== Wordpress ====<br /> As far as I understand wordpress' editor for standalone installations disables any potentially risky tags in a post, making the &lt;iframe&gt;&lt;/iframe&gt; trick useless. To counter this it is require to make a special hack to embed GISS TV using short codes and functions.php in a theme (more on this soon), but ideally the support should be provided by a plugin using the video upload interface of Wordpress or provide a GISS.tv shortcode plugin that does not involved hacking one's theme.<br /> <br /> == Development &amp; Community ==<br /> === Workflow ===<br /> Using a DVCS would bring more visibility and simplify the process of contributing/deploying code. There are many options out there, from the popular git to mercurial or the more exotic darcs. By using DVCS, contributors can silently fork the project and commit locally to test different features and keep track of their development, once mature and accepted they can be pushed (repos to repos or as patches) to the official repos. Silent forkers can also keep in sync with the official repos while testing their changes. A central repos (such as gitorious) can be used as backup for official repos or hub if the workflow is classic (central repository).<br /> <br /> === Refactoring ===<br /> The code needs a serious cleaning, at the time of this writing, on the kurimu channel page:<br /> * W3C validator: 254 Errors and 38 warnings<br /> * webkist's inspector audit: nearly 100 of warning and problem on page's resources<br /> <br /> ==== Javascript ====<br /> * To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib. In-lining CSS or JS should be done if nothing else is possible.<br /> * Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff.<br /> * Variable should be kept enclosed in functions whenever possible to avoid bad surprises when several channels are openned at once.<br /> <br /> ==== Tables and other hardcoded design choices ====<br /> A lot of tables are used at the moment and it's very hard to maintain, scale and read. It should be removed and the layout should only use floating divs to achieve complex layouts. It is also much more flexible as it decouple the markup language - that should kept as minimal as possible - from the design style sheet. It will also simplify the way towards full customization of a dmmdb page.<br /> <br /> === Community ===<br /> Social software is growing fast and there are more and more efforts to provide distributed systems. It would be good to see how dmmdb can interface with, for example, GNU Social, FOAF, etc.</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=596 Dmmdb Braindump 2010-08-19T10:39:24Z <p>Kurimu: /* Tables and other hardcoded design choices */</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Audio Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> === Video Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> == Interface ==<br /> <br /> === Player ===<br /> ==== Size ====<br /> Always set to 640px of width regardless of content. Which means that:<br /> * video res is perfect match when it plays SD/480p material (default view)<br /> * video res is stretched when it plays LD/240p material<br /> * video res is reduced when it plays HD/720p content.<br /> <br /> HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.<br /> <br /> ==== Default and Fall-back back-end ====<br /> Only two back-ends are needed to cover almost all situations and simplify maintenance:<br /> * default is HTML5 &lt;video&gt; tag<br /> * fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)<br /> <br /> == Development &amp; Community ==<br /> === Workflow ===<br /> Using a DVCS would bring more visibility and simplify the process of contributing/deploying code. There are many options out there, from the popular git to mercurial or the more exotic darcs. By using DVCS, contributors can silently fork the project and commit locally to test different features and keep track of their development, once mature and accepted they can be pushed (repos to repos or as patches) to the official repos. Silent forkers can also keep in sync with the official repos while testing their changes. A central repos (such as gitorious) can be used as backup for official repos or hub if the workflow is classic (central repository).<br /> <br /> === Refactoring ===<br /> The code needs a serious cleaning, at the time of this writing, on the kurimu channel page:<br /> * W3C validator: 254 Errors and 38 warnings<br /> * webkist's inspector audit: nearly 100 of warning and problem on page's resources<br /> <br /> ==== Javascript ====<br /> * To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib. In-lining CSS or JS should be done if nothing else is possible.<br /> * Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff.<br /> * Variable should be kept enclosed in functions whenever possible to avoid bad surprises when several channels are openned at once.<br /> <br /> ==== Tables and other hardcoded design choices ====<br /> A lot of tables are used at the moment and it's very hard to maintain, scale and read. It should be removed and the layout should only use floating divs to achieve complex layouts. It is also much more flexible as it decouple the markup language - that should kept as minimal as possible - from the design style sheet. It will also simplify the way towards full customization of a dmmdb page.<br /> <br /> === Community ===<br /> Social software is growing fast and there are more and more efforts to provide distributed systems. It would be good to see how dmmdb can interface with, for example, GNU Social, FOAF, etc.</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=595 Dmmdb Braindump 2010-08-19T10:38:58Z <p>Kurimu: /* Development &amp; Community */</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Audio Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> === Video Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> == Interface ==<br /> <br /> === Player ===<br /> ==== Size ====<br /> Always set to 640px of width regardless of content. Which means that:<br /> * video res is perfect match when it plays SD/480p material (default view)<br /> * video res is stretched when it plays LD/240p material<br /> * video res is reduced when it plays HD/720p content.<br /> <br /> HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.<br /> <br /> ==== Default and Fall-back back-end ====<br /> Only two back-ends are needed to cover almost all situations and simplify maintenance:<br /> * default is HTML5 &lt;video&gt; tag<br /> * fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)<br /> <br /> == Development &amp; Community ==<br /> === Workflow ===<br /> Using a DVCS would bring more visibility and simplify the process of contributing/deploying code. There are many options out there, from the popular git to mercurial or the more exotic darcs. By using DVCS, contributors can silently fork the project and commit locally to test different features and keep track of their development, once mature and accepted they can be pushed (repos to repos or as patches) to the official repos. Silent forkers can also keep in sync with the official repos while testing their changes. A central repos (such as gitorious) can be used as backup for official repos or hub if the workflow is classic (central repository).<br /> <br /> === Refactoring ===<br /> The code needs a serious cleaning, at the time of this writing, on the kurimu channel page:<br /> * W3C validator: 254 Errors and 38 warnings<br /> * webkist's inspector audit: nearly 100 of warning and problem on page's resources<br /> <br /> ==== Javascript ====<br /> * To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib. In-lining CSS or JS should be done if nothing else is possible.<br /> * Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff.<br /> * Variable should be kept enclosed in functions whenever possible to avoid bad surprises when several channels are openned at once.<br /> <br /> ==== Tables and other hardcoded design choices ====<br /> A lot of tables are used at the moment and it's very hard to maintain, scale and read. It should be removed and the layout should only use floating divs to achieve complex layouts. It is also much more flexible as it decouple the markup language - that should kept as minimal as possible - frm the design style sheet. It will also simplify the way towards full customization of a dmmdb page. <br /> <br /> === Community ===<br /> Social software is growing fast and there are more and more efforts to provide distributed systems. It would be good to see how dmmdb can interface with, for example, GNU Social, FOAF, etc.</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=594 Dmmdb Braindump 2010-08-19T10:28:37Z <p>Kurimu: /* About javascript */</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Audio Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> === Video Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> == Interface ==<br /> <br /> === Player ===<br /> ==== Size ====<br /> Always set to 640px of width regardless of content. Which means that:<br /> * video res is perfect match when it plays SD/480p material (default view)<br /> * video res is stretched when it plays LD/240p material<br /> * video res is reduced when it plays HD/720p content.<br /> <br /> HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.<br /> <br /> ==== Default and Fall-back back-end ====<br /> Only two back-ends are needed to cover almost all situations and simplify maintenance:<br /> * default is HTML5 &lt;video&gt; tag<br /> * fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)<br /> <br /> == Development &amp; Community ==<br /> === Code ===<br /> <br /> === Development ===<br /> Using a DVCS would bring more visibility and simplify the process of contributing/deploying code. There are many options out there, from the popular git to mercurial or the more exotic darcs. By using DVCS, contributors can silently fork the project and commit locally to test different features and keep track of their development, once mature and accepted they can be pushed (repos to repos or as patches) to the official repos. Silent forkers can also keep in sync with the official repos while testing their changes. A central repos (such as gitorious) can be used as backup for official repos or hub if the workflow is classic (central repository).<br /> <br /> === Refactoring ===<br /> The code needs a serious cleaning, at the time of this writing, on the kurimu channel page:<br /> * W3C validator: 254 Errors and 38 warnings<br /> * webkist's inspector audit: nearly 100 of warning and problem on page's resources<br /> <br /> ==== About javascript ====<br /> * To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib. In-lining CSS or JS should be done if nothing else is possible.<br /> * Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff.<br /> * Variable should be kept enclosed in functions whenever possible to avoid bad surprises when several channels are openned at once.<br /> <br /> === Community ===<br /> Social software is growing fast and there are more and more efforts to provide distributed systems. It would be good to see how dmmdb can interface with, for example, GNU Social, FOAF, etc.</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=593 Dmmdb Braindump 2010-08-19T10:27:14Z <p>Kurimu: /* About javascrip */</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Audio Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> === Video Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> == Interface ==<br /> <br /> === Player ===<br /> ==== Size ====<br /> Always set to 640px of width regardless of content. Which means that:<br /> * video res is perfect match when it plays SD/480p material (default view)<br /> * video res is stretched when it plays LD/240p material<br /> * video res is reduced when it plays HD/720p content.<br /> <br /> HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.<br /> <br /> ==== Default and Fall-back back-end ====<br /> Only two back-ends are needed to cover almost all situations and simplify maintenance:<br /> * default is HTML5 &lt;video&gt; tag<br /> * fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)<br /> <br /> == Development &amp; Community ==<br /> === Code ===<br /> <br /> === Development ===<br /> Using a DVCS would bring more visibility and simplify the process of contributing/deploying code. There are many options out there, from the popular git to mercurial or the more exotic darcs. By using DVCS, contributors can silently fork the project and commit locally to test different features and keep track of their development, once mature and accepted they can be pushed (repos to repos or as patches) to the official repos. Silent forkers can also keep in sync with the official repos while testing their changes. A central repos (such as gitorious) can be used as backup for official repos or hub if the workflow is classic (central repository).<br /> <br /> === Refactoring ===<br /> The code needs a serious cleaning, at the time of this writing, on the kurimu channel page:<br /> * W3C validator: 254 Errors and 38 warnings<br /> * webkist's inspector audit: nearly 100 of warning and problem on page's resources<br /> <br /> ==== About javascript ====<br /> * To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib.<br /> * Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff.<br /> * Variable should be kept enclosed in functions whenever possible to avoid bad surprises when several channels are openned at once.<br /> <br /> === Community ===<br /> Social software is growing fast and there are more and more efforts to provide distributed systems. It would be good to see how dmmdb can interface with, for example, GNU Social, FOAF, etc.</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=592 Dmmdb Braindump 2010-08-19T10:24:02Z <p>Kurimu: /* Development &amp; Community */</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Audio Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> === Video Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> == Interface ==<br /> <br /> === Player ===<br /> ==== Size ====<br /> Always set to 640px of width regardless of content. Which means that:<br /> * video res is perfect match when it plays SD/480p material (default view)<br /> * video res is stretched when it plays LD/240p material<br /> * video res is reduced when it plays HD/720p content.<br /> <br /> HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.<br /> <br /> ==== Default and Fall-back back-end ====<br /> Only two back-ends are needed to cover almost all situations and simplify maintenance:<br /> * default is HTML5 &lt;video&gt; tag<br /> * fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)<br /> <br /> == Development &amp; Community ==<br /> === Code ===<br /> <br /> === Development ===<br /> Using a DVCS would bring more visibility and simplify the process of contributing/deploying code. There are many options out there, from the popular git to mercurial or the more exotic darcs. By using DVCS, contributors can silently fork the project and commit locally to test different features and keep track of their development, once mature and accepted they can be pushed (repos to repos or as patches) to the official repos. Silent forkers can also keep in sync with the official repos while testing their changes. A central repos (such as gitorious) can be used as backup for official repos or hub if the workflow is classic (central repository).<br /> <br /> === Refactoring ===<br /> The code needs a serious cleaning, at the time of this writing, on the kurimu channel page:<br /> * W3C validator: 254 Errors and 38 warnings<br /> * webkist's inspector audit: nearly 100 of warning and problem on page's resources<br /> <br /> ==== About javascrip ====<br /> * To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib.<br /> * Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff.<br /> * Variable should be kept enclosed in functions whenever possible to avoid bad surprises when several channels are openned at once.<br /> <br /> === Community ===<br /> Social software is growing fast and there are more and more efforts to provide distributed systems. It would be good to see how dmmdb can interface with, for example, GNU Social, FOAF, etc.</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=591 Dmmdb Braindump 2010-08-19T10:04:42Z <p>Kurimu: /* Size */</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Audio Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> === Video Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> == Interface ==<br /> <br /> === Player ===<br /> ==== Size ====<br /> Always set to 640px of width regardless of content. Which means that:<br /> * video res is perfect match when it plays SD/480p material (default view)<br /> * video res is stretched when it plays LD/240p material<br /> * video res is reduced when it plays HD/720p content.<br /> <br /> HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.<br /> <br /> ==== Default and Fall-back back-end ====<br /> Only two back-ends are needed to cover almost all situations and simplify maintenance:<br /> * default is HTML5 &lt;video&gt; tag<br /> * fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)<br /> <br /> == Development &amp; Community ==</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=590 Dmmdb Braindump 2010-08-19T10:04:29Z <p>Kurimu: /* Interface */ player</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Audio Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> === Video Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> == Interface ==<br /> <br /> === Player ===<br /> ==== Size ====<br /> Always set to 640px of width regardless of content. Which means that:<br /> * video res is perfect match when it plays SD/480p material (default view)<br /> * video res is stretched when it plays LD/240p material<br /> * video res is reduced when it plays HD/720p content.<br /> <br /> HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.<br /> <br /> ==== Default and Fall-back back-end ===-<br /> Only two back-ends are needed to cover almost all situations and simplify maintenance:<br /> * default is HTML5 &lt;video&gt; tag<br /> * fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)<br /> <br /> == Development &amp; Community ==</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=589 Dmmdb Braindump 2010-08-19T09:35:11Z <p>Kurimu: res</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> === Supported Resolutions ===<br /> All should be encoded with '''1:1 pixel ratio''' and '''progressive scan'''<br /> * LD: 240p - 320x240 4:3 and 432x240 16:9<br /> * SD: 480p - 640x480 4:3 and 854x480 16:9<br /> * HD basic: 720p - 1280×720 16:9 only<br /> <br /> Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.<br /> <br /> === Audio Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> === Video Data Rates ===<br /> * LD:<br /> * SD:<br /> * HD:<br /> <br /> == Interface ==<br /> <br /> <br /> == Development &amp; Community ==</div> Kurimu http://giss.tv/wiki/index.php?title=Dmmdb_Braindump&diff=588 Dmmdb Braindump 2010-08-18T11:19:16Z <p>Kurimu: skeleton</p> <hr /> <div>'''Note''': This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.<br /> <br /> == Video Support ==<br /> <br /> == Interface ==<br /> <br /> == Development &amp; Community ==</div> Kurimu http://giss.tv/wiki/index.php?title=Main_Page&diff=587 Main Page 2010-08-18T11:15:39Z <p>Kurimu: /* Development */ entry fo dmmdb braindump</p> <hr /> <div>== G.I.S.S GLOBAL INDEPENDENT STREAMING SUPPORT ==<br /> <br /> <br /> '''free streaming services for free media.<br /> free as in cost, free as in software.'''<br /> <br /> [http://giss.tv giss.tv]<br /> <br /> == G.I.S.S. features ==<br /> <br /> * [http://giss.tv/addmount.html Setup your mointpoint and start a channel]<br /> <br /> * [http://giss.tv/interface Setup your channel interface], ''for developers: [[interfaces dev page]]''<br /> <br /> * [http://riereta.net/gisschannel/itheora/index.php View/listen giss channels with itheora]<br /> <br /> == G.I.S.S. components ==<br /> <br /> * [[Sahabuntu giss cd for streaming]]<br /> <br /> * [[Distributed Multi-Media DataBase ( dmmdb )]]<br /> <br /> * [[G.I.S.S. streaming packages for Ubuntu Hardy ]]<br /> <br /> * [[Easy streaming with TSS]]<br /> <br /> == Technical info ==<br /> <br /> * [[Servers Configuration]]<br /> <br /> * [[GISS map v2.0 documentation]]<br /> <br /> * [[Slave Servers Requirements]]<br /> <br /> * [[Icecast URL Auth]]<br /> <br /> * [[Streaming Tools]]<br /> <br /> == Documentation ==<br /> <br /> [[Image:Giss_map.png|thumbnail|right]]<br /> <br /> * [http://stream.hackitectura.net/~vale/OnceUponAGiss/ Once Upon A Giss]<br /> <br /> * [[Text : Motivations Behind The Tools]]<br /> <br /> * [[Videos of presentations]]<br /> <br /> == Events ==<br /> <br /> * [[20th of January : They've got a bomb]]<br /> <br /> == Development ==<br /> <br /> * [[Development G.I.S.S. Phase 3]]<br /> * [[dmmdb Braindump]] - Not a Roadmap yet</div> Kurimu