Once we ship the firefogg extension support for the uploading videos; commons should request that users select the highest quality source video footage available ie the HD video their camera captured or DV original edited footage from their local computer and then commons will supply the transcode settings.
I think it would be good if we wrote up some documentation to explain this to uploaders... any volunteers to help on that front?
Presently for the firefogg upload support I have arbitrarily chosen 400 pixels wide with keep-aspect ratio and 500kbs bitrate.
Firefogg could let us request multiple encodes or profiles from the user.
Should we plan on supporting multiple "profiles" ie multiple quality settings? Ie one version at around 320 wide 300kbs for low bandwidth / resolution environments, cell phones etc (300kbs should be "acceptable quality" once the new Thusnelda theora encoder lands).
We could additionally read the source file resolution that users provide and choose a "maximum quality preservation version" we could probably even ship the Dirac codec with firefogg (Dirac is a high quality at high resolution wavelate codec for more on dirac see your favorite info source ;)
If we want to support multiple quality settings for a single "stream" this will require a bit more infrastructure. Specifically I propose we add another namespace for temporal media called Stream: and have it directly map to ROE xml something like: http://tinyurl.com/72x57r more info on ROE http://wiki.xiph.org/index.php/ROE
File:my_movie_low_quality.ogg and File:my_movie_high_quality.ogg would soft redirect to Stream:my_movie and all the meta info would be stored there. The Stream namespace also allows us to group other media tracks that share a temporal meaning such as multiple language audio dubbing and multilingual transcripts/ subtitles. The javascript player can then dynamically select audio language and or subtitles based on the user language.
Stream namespace could also store "mirrors" or point to "torrents" improving syndication and bandwith cost distribution for high traffic HD content ie (Miro could read the ROE file and grab the torrent rather than hit our servers) and or a Firefox torrent extension could be detected by our javascript player and choose the torrent over hitting our servers for the HD content.
Not to say all these things will happen at once ... just pointing out the need for a new namespace to group idential temporal meaning files.
--michael
Michael Dale wrote:
If we want to support multiple quality settings for a single "stream" this will require a bit more infrastructure. Specifically I propose we add another namespace for temporal media called Stream: and have it directly map to ROE xml something like: http://tinyurl.com/72x57r more info on ROE http://wiki.xiph.org/index.php/ROE
File:my_movie_low_quality.ogg and File:my_movie_high_quality.ogg would soft redirect to Stream:my_movie and all the meta info would be stored there. The Stream namespace also allows us to group other media tracks that share a temporal meaning such as multiple language audio dubbing and multilingual transcripts/ subtitles. The javascript player can then dynamically select audio language and or subtitles based on the user language.
No need. Users would use [[File:my_movie.ogg|high]] or [[File:my_movie.ogg|low]] The actual ROE file would be at upload/thumb/f/fa/my_movie.ogg/my_movie-ROE.ogg (or Special:MvExportStream as metavidwiki does) as other types do. Same for the other temporary files.
You would not want to hard code the |high quality or |low quality version to the article / wiki syntax. The idea is that you just put something like [[Stream:my_movie]] or [[File:my_movie.ogg]] (in your example) and then based on the client bandwidth, client supported codecs, local language, and client player preference and the available streams on the server the javascript player choses the appropriate set of video, audio, and text streams to playback.
Its not quite the same problem as existing File namespace transformations system. Same temporal meaning files are not _only_ files programmability transcoded from a single my_video.ogg source. Its different from the thumbnails or flattened SVGs derivatives. Aside from the issue of associating dubbed audio tracks, Users will never upload their original HD footage because of bandwidth constraints and for maximum quality on the low-end version we want to create the low bandwidth derivatives from the original footage so the derivatives will not really be a "temporary file" that can easily be regenerated.
We can certainly overload the File namespace as you suggest to enable such associations but the minimal hierarchy of a Stream namespace to associate specific identical temporal meaning files seems cleaner/worthwhile to me. It will mean that a single File: page will be associated with many actual "files" that may have different licenses etc.
The stream namespace also contains interfaces for associated layers of timed text putting all those associations into the File namespace may complicate things but we can go that way if its the consensus.
peace, --michael
Platonides wrote:
Michael Dale wrote:
If we want to support multiple quality settings for a single "stream" this will require a bit more infrastructure. Specifically I propose we add another namespace for temporal media called Stream: and have it directly map to ROE xml something like: http://tinyurl.com/72x57r more info on ROE http://wiki.xiph.org/index.php/ROE
File:my_movie_low_quality.ogg and File:my_movie_high_quality.ogg would soft redirect to Stream:my_movie and all the meta info would be stored there. The Stream namespace also allows us to group other media tracks that share a temporal meaning such as multiple language audio dubbing and multilingual transcripts/ subtitles. The javascript player can then dynamically select audio language and or subtitles based on the user language.
No need. Users would use [[File:my_movie.ogg|high]] or [[File:my_movie.ogg|low]] The actual ROE file would be at upload/thumb/f/fa/my_movie.ogg/my_movie-ROE.ogg (or Special:MvExportStream as metavidwiki does) as other types do. Same for the other temporary files.
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Users' views on the need for subject-consent for photographs of identifiable people vary hugely, from "why should we need consent anyway?" to "any photo that has no subject consent is obviously illegal and msut be deleted". This divergence of views is causing uncertainty and inconsistent keep/delete decisions on Deletion Requests. The uncertainty is harming not also Commons but also its Wiki "customers".
I have made a proposal with a view to obtaining consensus for a middle ground, at
http://commons.wikimedia.org/wiki/Commons:Photographs_of_identifiable_people...
More comments are needed on the talk page, especially - if I may be permitted to canvass mildy - from users who have views that are not at one end or the other of the spectrum. Please don't just leave the discussion to those with very strong views.
Michael
ps. Michael deserves big thanks for his great work on this :-)
On Fri, Feb 6, 2009 at 6:55 PM, Michael Maggs Michael@maggs.name wrote:
Users' views on the need for subject-consent for photographs of identifiable people vary hugely, from "why should we need consent anyway?" to "any photo that has no subject consent is obviously illegal and msut be deleted". This divergence of views is causing uncertainty and inconsistent keep/delete decisions on Deletion Requests. The uncertainty is harming not also Commons but also its Wiki "customers".
I have made a proposal with a view to obtaining consensus for a middle ground, at
http://commons.wikimedia.org/wiki/Commons:Photographs_of_identifiable_people...
More comments are needed on the talk page, especially - if I may be permitted to canvass mildy - from users who have views that are not at one end or the other of the spectrum. Please don't just leave the discussion to those with very strong views.
Michael
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l