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
2009/1/29 Walter Siegmund <siegmund(a)astro.washington.edu>:
> Hi,
>
> I tried the instructions in part 1 but was not able to see the
> "Ubuntu icon/a film reel with a plus symbol". That is with OS X
> 10.4.11/Safari 3.2.1. I did empty my browser cache. I tried Camino
> 1.5 with the same result.
Hi Walter,
I see you copied a few things from my monobook.js, so you should have
other things installed. Do you see the "category tree" icon at the
right end of the icons above the edit box?
Here is a screenshot:
<http://commons.wikimedia.org/wiki/User_talk:Tgr/catinsert.js>
If you can see that, but not that film reel one, then it is a problem
with the Metavid script. If you can't see either, then I suspect your
cache is still not emptied.
Or, hmm, maybe there is something Firefox specific about these
scripts... but just for the add-media wizard, I think it is only
Javascript stuff...
Brianna
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
2009/1/31 Peter Jacobi <pjacobi.de(a)googlemail.com>:
> David Gerard <dgerard(a)gmail.com> wrote:
>> I didn't add "(or are supposed to be)". Now I'm wondering if I was
>> thinking of the personality rights tag.
> Can you please give an example link to the tag you are talking about?
This is the personality rights tag:
http://commons.wikimedia.org/wiki/Template:Personality_rights
This is the category of restrictions templates:
http://commons.wikimedia.org/wiki/Category:Restriction_tags
Possibly I was thinking of the note about model rights in the reuse page:
http://commons.wikimedia.org/wiki/COM:REUSE
So if there isn't a tag warning in general about model rights
(assuming reusers aren't reading all of Commons, they're just looking
at an image page, seeing the licence and going "ooh I can use that" as
Virgin did with the CC-by-sa pic they reused) - is a tag warning that,
duh, you have to take care with pictures of people worthwhile?
(cc to commons-l)
- d.
2009/1/30 Johannes Beigel <johannes.beigel(a)pediapress.com>:
> On 29.01.2009, at 13:48, Brianna Laugher wrote:
> > On Wikimedia Commons a little bit of work has been done to this end:
> > <http://commons.wikimedia.org/wiki/Commons:Commons_API>
>
> We've been aware of this page and Magnus' implementation, and we think
> it looks really good!
>
> The information is (AFAIK) scraped from the rendered XHTML of
> articles. This could be done in a less error-prone way (and more
> efficiently) if the data would be stored and accessed via database in
> some way. Of course this would require some discussion, formal
> decisions and code changes. But as I stated in an earlier post: I
> think MediaWiki is so widely used by people who want to share and
> collaborate on free content, that it's not too farfetched to build
> some "license infrastracture" into the software itself.
I agree that it makes a lot of sense. But because it would be a big
change, I fear that unless the lead developers show great enthusiasm
for the idea, it will take a very long time to be accepted and
completed. Whereas building an "add-on" tool can be faster to get to
point of functionality.
It may be a good idea to try and build the Commons API to mimic the
MediaWiki API, imagining that in the future such information will be
available via that. So then hopefully for now people could use the
Commons API, and in the future switch to the MediaWiki API by just
changing the API URL, and all their queries could stay the same.
How does that sound? Other ideas about how to approach it are welcome...
cheers
Brianna
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
2008/10/14 Johannes Beigel <johannes.beigel(a)pediapress.com>:
>>> Secondly, current version of the tool does a plagiarism - beacause
>>> it does not mention
>>> image authors and does not provide any mean (like by making images
>>> clickable) to check
>>> these authors.
>>
>> Ouch, thanks for pointing that out. Tricky to do this automatically
>> since it's all wiki-text with templates, but we'll investigate a
>> solution here.
>
> We'd highly appreciate input from the community regarding this topic!
>
> The printed books from PediaPress contain a list of figures where the
> license of each image is listed, together with the URL to the image
> description page. As some kind of "hotfix" this solution could be
> implemented in the PDF export of the Collection extension, too. But
> this doesn't really solve the problem.
>
> We think it's more of a technical/software thing, so I cross-posted
> (and set Reply-To) to Wikitech-l.
>
> In our opinion, license management/handling must be a core feature of
> MediaWiki, because the software is explicitely developed for the
> collaborative distribution of free content. Licenses of the containing
> articles and images should not be represented via some agreed-upon
> convention but via structured (and machine-readable) information,
> available for each relevant object in the wiki.
>
> Some information that would be desired:
>
> - Full (official) name of the license(s).
> - Whether the full text of the license has to be included or a
> reference sufficient.
> - Reference to the full text of the license(s) (in some rigidly
> defined format like wikitext).
> - Whether attribution is required. If so: The list of required
> attributions.
>
> So, basically all the information that's required to check if it's
> possible to take some part of the MediaWiki and use it somewhere else
> and all the information that has to be included in that other place.
> This information could be made accessible via MediaWiki API, but
> ideally it's contained in the wikitext and/or XHTML, too.
Because different wikis implement licenses in different ways (ie there
are no naming conventions for license templates), I am not sure this
license information would belong in MediaWiki core. But I think that
definitely Wikimedia Commons, and perhaps other Wikimedia wikis that
accept freely licensed uploads, should work on providing a "community
API" layer. My thinking behind this is that the communities build a
lot of structure into their content via templates or categories or
whatever. It makes sense to provide an API to stop every third party
user having to reinvent the wheel.
On Wikimedia Commons a little bit of work has been done to this end:
<http://commons.wikimedia.org/wiki/Commons:Commons_API>
In particular this contains some of the license info you mentioned.
e.g. below is the info for the GFDL.
GFDL
full_name
GNU Free Documentation License
attach_full_license_text
1
attribute_author
1
keep_under_same_license
1
keep_under_similar_license
0
license_logo_url
http://upload.wikimedia.org/wikipedia/commons/thumb/2/22/Heckert_GNU_white.…
license_info_url
http://www.gnu.org/copyleft/fdl.html
license_text_url
http://www.gnu.org/licenses/fdl.txt
The "Commons API" also has an author field.
<http://toolserver.org/~magnus/commonsapi.php?image=Sa-warthog.jpg&meta>
I think at the moment this is being taken from the {{information}}
template. You can see in this example it includes a wiki link; it
should have already been resolved to a full URL, so there is
definitely still work to be done.
I would be interested to know if further development of the Commons
API would be "heading in the right direction" for PediaPress.
cheers,
Brianna
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
Dear members,
I am a newbie of wiki and I want to do research on a wiki page. I want
to know how to get the visit log of the page, i.e., hourly/ daily hit
counts, and if possible, visitor IP address, user agent, etc.
If you happen know the way, please finger it for me.
Thanks in advance for your kind help!
With best regards,
Grain
Hi all,
This is a bit of a 'cross post' from here;
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(miscellaneous)#Copyrig…
(and http://wikipediareview.com/index.php?showtopic=22495 )
where I was raising the question of how Wikimedia deals with deletions,
which of course aren't really full 'deletions' in that they're available to
admin.s - my previous post follows;
.....it's illegal to break copyright, right? - and if an article, or image
on a wikimedia foundation project breaks copyright then it gets deleted. I
just wonder how the copyright owner feels about the article / image still
being available to over a thousand (and growing) number of unidentified
people - that's illegal, right?
I've had this in the 'don't really care' bucket for ages - but as part of my
forays into sexual content on wiki, came across this
image<http://commons.wikimedia.org/wiki/File:Brip.jpg>(now deleted)
which I believe was very (very) close to being an illegal
image, because it sexualised a child.
Anyone reading this who's an admin at commons can view the image - isn't
that a bit wrong?
The fact is that wikimedia's administrators have unfettered (and apparently
un-monitorable) access to a huge, and ever growing body of copyright
infringing work. Doesn't seem sustainable to me.
thoughts most welcome,
cheers,
Peter,
PM.
While the upload API is under development / stabilization ... I hacked
in basic firefogg upload support to the add_media_wizard ... Since
firefogg works over post you can use it with the existing upload
interface (without good error handling).... If you first download the
browser extension from firefogg.org you can do client side transcoding
by adding in:
importScriptURI('http://mvbox2.cse.ucsc.edu/wiki/extensions/MetavidWiki/skins/add_media_wiza…');
to your User:Name/monobook.js page on commons... once added visit the
upload page and hopefully it gives you the option to transcode ;)
This is just a proof of concept demo.. we should soon have real
integration ;)
peace,
--michael