Hi folks,
Here are our notes from yesterday’s multimedia team meeting, when we planned our next development cycles.
We discussed our goals for the next 6-week cycle, as well as for subsequent cycles. We agreed to focus on wrapping up feature development and gradually releasing Media Viewer v0.2 in April/May, so we can move on to other important tasks on our roadmap.
To stay focused on this goal, we decided to devote the next 6-week cycle to completing final features for the first pilot release of Media Viewer v0.2 in the next cycle.
We will then switch our focus to Upload Wizard and Structured Data in the subsequent cycle, only fixing Media Viewer bugs as needed. We expect this new work to continue to be our main focus through the summer.
To make rapid progress on these important multimedia priorities, we may need to push back the next version of Media Viewer 0.3 to later in the year — or only do incremental work on it in the next quarters.
Our current goals for the next few cycles are outlined below — and you can read more on our meeting notepad: http://etherpad.wikimedia.org/p/multimedia-planning-meeting-2014-03-12
We welcome your comments, questions and suggestions about these proposed goals. We expect to adjust them periodically, based on this feedback and other factors.
Please respond by email for now. You can also post comments about Media Viewer on this discussion page: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
Thanks as always for your constructive feedback, which is invaluable to us!
Best regards,
Fabrice on behalf of the Multimedia team
____________________________________________
MULTIMEDIA TEAM GOALS - NEXT CYCLES
Here are our proposed goals for the multimedia team’s next development cycles. (We define a cycle as a 6-week iteration, which includes 6 weekly sprints; it can also include one or more product releases).
We will be discussing these goals with community and team members in coming days. We expect to adjust them periodically, based on this feedback and other factors.
1. Goals for Current Cycle * Current Cycle started February 6, ends March 19 (second half of fiscal Q3). * Media Viewer v0.2 - Develop key features for pilot release in April * Analyze image load metrics, define acceptance criteria * Bugs & Technical Debt - Ongoing * See Mingle wall of tasks completed this cycle: http://ur1.ca/gtyvh
2. Goals for Next Cycle * Starts March 20, ends April 30 (first half of fiscal Q4). * Media Viewer v0.2 - Complete key features and launch tasks for April release * Release Media Viewer v0.2 in April/May (MW.org > small wikis > large wikis > all wikis) * Fix Media Viewer v0.2 Bugs (address most urgent community concerns) * Upload Wizard - Fix large bugs, collect metrics, unit tests, plan next steps * Bugs & Technical Debt - Ongoing * See Mingle wall: http://ur1.ca/gtvvr
3. Goals for Subsequent Cycle * Starts May 1, ends June 11 (second half of fiscal Q4) * Upload Wizard - improve UI design, incremental code refactoring, new features * Fix Media Viewer v0.2 Bugs (focus on most important community concerns) * Structured Data - start planning and first prototypes, with Wikidata and community * File Notifications - Your file was used * See Mingle wall: http://ur1.ca/gtyt3
4. Goals for 'Next-Subsequent' Cycle * Starts June 12, ends July 23 (first half of fiscal Q1) * Upload Wizard continued improvements and bug fixes, as needed * Structured Data - start implementation on Commons, with Wikidata and community * Fix Media Viewer v0.2 Bugs (focus on most important issues)
As time allows, we will consider incremental work on these goals throughout next year: * Media Viewer v0.3 - Develop new features (zoom, A/V support, plugins) * File Feedback - Develop positive feedback tool (Thanks, Watch or Favorite)
Useful links
* Multimedia Project Hub https://www.mediawiki.org/wiki/Multimedia
* About Media Viewer https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer
* Media Viewer Release Plan https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan
_______________________________
Fabrice Florin Product Manager, Multimedia Wikimedia Foundation
Thank you, Fabrice. Is any followup to the earlier RfC planned, regarding converting mp4-to-ogg on upload?
That seemed like the main unresolved aspect of the discussion. SJ
On Thu, Mar 13, 2014 at 3:03 PM, Fabrice Florin fflorin@wikimedia.org wrote:
Hi folks,
Here are our notes from yesterday's multimedia team meeting, when we planned our next development cycles.
We discussed our goals for the next 6-week cycle, as well as for subsequent cycles. We agreed to focus on wrapping up feature development and gradually releasing Media Viewer v0.2 in April/May, so we can move on to other important tasks on our roadmap.
To stay focused on this goal, we decided to devote the next 6-week cycle to completing final features for the first pilot release of Media Viewer v0.2 in the next cycle.
We will then switch our focus to Upload Wizard and Structured Data in the subsequent cycle, only fixing Media Viewer bugs as needed. We expect this new work to continue to be our main focus through the summer.
To make rapid progress on these important multimedia priorities, we may need to push back the next version of Media Viewer 0.3 to later in the year -- or only do incremental work on it in the next quarters.
Our current goals for the next few cycles are outlined below -- and you can read more on our meeting notepad: http://etherpad.wikimedia.org/p/multimedia-planning-meeting-2014-03-12
We welcome your comments, questions and suggestions about these proposed goals. We expect to adjust them periodically, based on this feedback and other factors.
Please respond by email for now. You can also post comments about Media Viewer on this discussion page: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
Thanks as always for your constructive feedback, which is invaluable to us!
Best regards,
Fabrice on behalf of the Multimedia team
MULTIMEDIA TEAM GOALS - NEXT CYCLES
Here are our proposed goals for the multimedia team's next development cycles. (We define a cycle as a 6-week iteration, which includes 6 weekly sprints; it can also include one or more product releases).
We will be discussing these goals with community and team members in coming days. We expect to adjust them periodically, based on this feedback and other factors.
- Goals for Current Cycle
- Current Cycle started February 6, ends March 19 (second half of fiscal
Q3).
- Media Viewer v0.2 - Develop key features for pilot release in April
- Analyze image load metrics, define acceptance criteria
- Bugs & Technical Debt - Ongoing
- See Mingle wall of tasks completed this cycle: http://ur1.ca/gtyvh
- Goals for Next Cycle
- Starts March 20, ends April 30 (first half of fiscal Q4).
- Media Viewer v0.2 - Complete key features and launch tasks for April
release
- Release Media Viewer v0.2 in April/May (MW.org > small wikis > large wikis
all wikis)
- Fix Media Viewer v0.2 Bugs (address most urgent community concerns)
- Upload Wizard - Fix large bugs, collect metrics, unit tests, plan next
steps
- Bugs & Technical Debt - Ongoing
- See Mingle wall: http://ur1.ca/gtvvr
- Goals for Subsequent Cycle
- Starts May 1, ends June 11 (second half of fiscal Q4)
- Upload Wizard - improve UI design, incremental code refactoring, new
features
- Fix Media Viewer v0.2 Bugs (focus on most important community concerns)
- Structured Data - start planning and first prototypes, with Wikidata and
community
- File Notifications - Your file was used
- See Mingle wall: http://ur1.ca/gtyt3
- Goals for 'Next-Subsequent' Cycle
- Starts June 12, ends July 23 (first half of fiscal Q1)
- Upload Wizard continued improvements and bug fixes, as needed
- Structured Data - start implementation on Commons, with Wikidata and
community
- Fix Media Viewer v0.2 Bugs (focus on most important issues)
As time allows, we will consider incremental work on these goals throughout next year:
- Media Viewer v0.3 - Develop new features (zoom, A/V support, plugins)
- File Feedback - Develop positive feedback tool (Thanks, Watch or Favorite)
Useful links
- Multimedia Project Hub
https://www.mediawiki.org/wiki/Multimedia
- About Media Viewer
https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer
- Media Viewer Release Plan
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan
Fabrice Florin Product Manager, Multimedia Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Is any followup to the earlier RfC planned, regarding converting mp4-to-ogg on upload?
My understanding is that as a result of the RfC discussion, we're currently not considering any use of mp4 on wikimedia sites. That means transcoding mp4 files on upload is also out of the question. Wikimedia servers just won't support mp4 in any way. That was a direct result of the RfC discussion.
Which is why we're looking into importing open formats from other sites at the moment. It can be considered somewhat of a workaround from an end-user perspective, as some of these websites allow uploads in closed formats, mp4 included.
We might bring up more hybrid solutions that were not proposed in the RfC later for the community to consider (eg. letting a 3rd-party such as the internet archive do the transcoding on our behalf at upload time). But these ideas would definitely be controversial and require another round of community feedback. They're not being actively explored at the moment, besides asking these 3rd parties if they would be willing to do it.
For now we're quite confident that a Flickr-like import of videos in open formats is a safe bet which is compatible with the community's values.
On Fri, Mar 14, 2014 at 8:29 AM, Samuel Klein meta.sj@gmail.com wrote:
Thank you, Fabrice. Is any followup to the earlier RfC planned, regarding converting mp4-to-ogg on upload?
That seemed like the main unresolved aspect of the discussion. SJ
On Thu, Mar 13, 2014 at 3:03 PM, Fabrice Florin fflorin@wikimedia.org wrote:
Hi folks,
Here are our notes from yesterday's multimedia team meeting, when we
planned
our next development cycles.
We discussed our goals for the next 6-week cycle, as well as for
subsequent
cycles. We agreed to focus on wrapping up feature development and
gradually
releasing Media Viewer v0.2 in April/May, so we can move on to other important tasks on our roadmap.
To stay focused on this goal, we decided to devote the next 6-week cycle
to
completing final features for the first pilot release of Media Viewer
v0.2
in the next cycle.
We will then switch our focus to Upload Wizard and Structured Data in the subsequent cycle, only fixing Media Viewer bugs as needed. We expect this new work to continue to be our main focus through the summer.
To make rapid progress on these important multimedia priorities, we may
need
to push back the next version of Media Viewer 0.3 to later in the year
-- or
only do incremental work on it in the next quarters.
Our current goals for the next few cycles are outlined below -- and you
can
read more on our meeting notepad: http://etherpad.wikimedia.org/p/multimedia-planning-meeting-2014-03-12
We welcome your comments, questions and suggestions about these proposed goals. We expect to adjust them periodically, based on this feedback and other factors.
Please respond by email for now. You can also post comments about Media Viewer on this discussion page: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
Thanks as always for your constructive feedback, which is invaluable to
us!
Best regards,
Fabrice on behalf of the Multimedia team
MULTIMEDIA TEAM GOALS - NEXT CYCLES
Here are our proposed goals for the multimedia team's next development cycles. (We define a cycle as a 6-week iteration, which includes 6 weekly sprints; it can also include one or more product releases).
We will be discussing these goals with community and team members in
coming
days. We expect to adjust them periodically, based on this feedback and other factors.
- Goals for Current Cycle
- Current Cycle started February 6, ends March 19 (second half of fiscal
Q3).
- Media Viewer v0.2 - Develop key features for pilot release in April
- Analyze image load metrics, define acceptance criteria
- Bugs & Technical Debt - Ongoing
- See Mingle wall of tasks completed this cycle: http://ur1.ca/gtyvh
- Goals for Next Cycle
- Starts March 20, ends April 30 (first half of fiscal Q4).
- Media Viewer v0.2 - Complete key features and launch tasks for April
release
- Release Media Viewer v0.2 in April/May (MW.org > small wikis > large
wikis
all wikis)
- Fix Media Viewer v0.2 Bugs (address most urgent community concerns)
- Upload Wizard - Fix large bugs, collect metrics, unit tests, plan next
steps
- Bugs & Technical Debt - Ongoing
- See Mingle wall: http://ur1.ca/gtvvr
- Goals for Subsequent Cycle
- Starts May 1, ends June 11 (second half of fiscal Q4)
- Upload Wizard - improve UI design, incremental code refactoring, new
features
- Fix Media Viewer v0.2 Bugs (focus on most important community concerns)
- Structured Data - start planning and first prototypes, with Wikidata
and
community
- File Notifications - Your file was used
- See Mingle wall: http://ur1.ca/gtyt3
- Goals for 'Next-Subsequent' Cycle
- Starts June 12, ends July 23 (first half of fiscal Q1)
- Upload Wizard continued improvements and bug fixes, as needed
- Structured Data - start implementation on Commons, with Wikidata and
community
- Fix Media Viewer v0.2 Bugs (focus on most important issues)
As time allows, we will consider incremental work on these goals
throughout
next year:
- Media Viewer v0.3 - Develop new features (zoom, A/V support, plugins)
- File Feedback - Develop positive feedback tool (Thanks, Watch or
Favorite)
Useful links
- Multimedia Project Hub
https://www.mediawiki.org/wiki/Multimedia
- About Media Viewer
https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer
- Media Viewer Release Plan
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan
Fabrice Florin Product Manager, Multimedia Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
-- Samuel Klein @metasj w:user:sj +1 617 529 4266
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Dear Gilles, Brion, and Michael,
Thank you for the fast replies. And thanks again to Fabrice for sharing the roadmap for the next months.
Making it easy for people to convert from encumbered to unencumbered formats, and to share media under a free license even if they cannot understand encodings, are unambiguously part of our mission. That part does not seem controversial, though how best to make this happen is debated. The framing of the RFC made it hard to discuss transcoding in any detail.
Brion writes:
As Gilles mentioned, based on the RfC results we don't currently have a server-side solution on the table.
A strict reading of that discussion might mean that we shouldn't store and process encumbered codecs ourselves. Nevertheless, as suggested a few times there, we can at the very least channel uploaders through a server-side solution that isn't hosted on our servers.
Michael Dale writes:
[ snip many insightful things ]
The user should upload the source asset, the server should do the encoding.
Agreed.
Internet archive would be a good partner.
Yes, and I believe they are willing. What might a transparent hand-off to them look like on our side? If we sketch out what this might look like in practice, community members who care about transcoding could organize a related, low-drama discussion about it on Commons. It should be possible to get such a process accepted by IArchivists, Wikimedians, and even Linksvayers.
Sam
( One possibility: Detecting that the format can't be uploaded directly, passing the upload to IA, conversion to an unencumbered format, and upload-to-Commons with metadata mapping. Depending on the size of the file, the uploader could "complete" the upload before the file is available for use, and be asked to come back in a few minutes. But the summary page, a link to the partner archive page, and the filename for use in other WM projects, could be available right away. )
Thanks, SJ!
I’m happy to say that we’ve started a productive collaboration with the Internet Archive and Wikimedia community members, to address your recommendations below about video uploads for unsupported formats.
As a first step, we want to make it easy for people to upload videos from the Internet Archive to Wikimedia Commons, which seems like a very realistic project. The Archive already has all the tools needed to upload videos in a wide range of formats (1), then transcode them to Ogg format and transfer them to Commons through their Upload Wizard. Their developer page provides very helpful information on how to use these tools. (2)
Our current goal is to start with a very simple implementation, which would add an ‘Upload from Internet Archive’ tool on Commons, that would work just like the tool we use now to import images from Flickr. This button would invite users to copy and paste the URL of the Internet Archive file they wish to upload, then take it from there. Our proposed specifications for this first feature are posted on our Mingle card #306 (3), which we hope to take on in collaboration with community developers next quarter.
To get the ball started, it should be pretty easy for a community developer to create a simple tool powered by the Wikimedia Toolserver. This could be done by adapting the Flickr upload bot (4), to perform some of its verification and file transfer functions, such as: retrieving the metadata from the IA Metadata API, confirming that it has the appropriate license, checking a blacklist of contributors, then uploading the file.
In a second step, we could look into a tighter integration with the Internet Archive’s upload process, so that it could be initiated from Commons, if someone tries to upload an MP4 video file from our sites. They could be redirected to IA in ways that make the whole process much smoother. But this would require more development resources, and would need more community discussions, given the controversial nature of this proprietary format.
Speaking personally on behalf of long-time video creators like myself, I hope we can get to that stage sooner rather than later, to make it more inviting for us to donate our video footage to the free knowledge movement. :)
Andrew Lih and Kevin Gorman have been spearheading this community-led initiative. They would welcome the participation of a few more community members to help with this project, particularly for the technical development aspects. Our multimedia team is also prepared to support this project, but we like the idea of doing this as a collaboration with other community members who share our commitment to make it happen. :)
We’ll keep you posted on this initiative as it develops.
Enjoy your weekend,
Fabrice
(1) https://archive.org/help/derivatives.php
(2) http://blog.archive.org/developers/
(3) https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/306
(4) https://commons.wikimedia.org/wiki/User:Flickr_upload_bot
On Mar 14, 2014, at 7:30 PM, Samuel Klein meta.sj@gmail.com wrote:
Dear Gilles, Brion, and Michael,
Thank you for the fast replies. And thanks again to Fabrice for sharing the roadmap for the next months.
Making it easy for people to convert from encumbered to unencumbered formats, and to share media under a free license even if they cannot understand encodings, are unambiguously part of our mission. That part does not seem controversial, though how best to make this happen is debated. The framing of the RFC made it hard to discuss transcoding in any detail.
Yes, in hindsight, we probably should have started a series of discussions, rather than one big RfC.
The next time we bring up video with our community, we might want to start with a general discussion on the role of video on our sites, then have separate discussions about contributing different file formats, as well as viewing them.
We didn’t have the resources to do this full community engagement at the time, but have learned an important lesson that complex issues like these can’t be solved effectively in a single RfC.
Onward!
Brion writes:
As Gilles mentioned, based on the RfC results we don't currently have a server-side solution on the table.
A strict reading of that discussion might mean that we shouldn't store and process encumbered codecs ourselves. Nevertheless, as suggested a few times there, we can at the very least channel uploaders through a server-side solution that isn't hosted on our servers.
Yes, we agree on that point.
In collaboration with community members, we have initiated discussions with third parties like the Internet Archive, and are getting positive responses from them.
Our current plan is to start with small, incremental steps, as described below.
Michael Dale writes:
[ snip many insightful things ]
The user should upload the source asset, the server should do the encoding.
Agreed.
Internet archive would be a good partner.
Yes, and I believe they are willing. What might a transparent hand-off to them look like on our side?
We’re proposing to start with a simple ‘Upload from Internet Archive’ button, as outlined on this Mingle card:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/306
This would be similar to what we are doing now with ‘Upload from Flickr’ tools already in use on our sites.
So in this first step, contributors would be invited to post MP4 videos on the Internet Archive site, then import those videos in Ogg format on Commons.
Once this first step is in place, we would consider improving this workflow by integrating the upload process more closely between Commons and Internet Archive.
If we sketch out what this might look like in practice, community members who care about transcoding could organize a related, low-drama discussion about it on Commons. It should be possible to get such a process accepted by IArchivists, Wikimedians, and even Linksvayers.
Yes, that is our general plan.
Sam
( One possibility: Detecting that the format can't be uploaded directly, passing the upload to IA, conversion to an unencumbered format, and upload-to-Commons with metadata mapping. Depending on the size of the file, the uploader could "complete" the upload before the file is available for use, and be asked to come back in a few minutes. But the summary page, a link to the partner archive page, and the filename for use in other WM projects, could be available right away. )
Yes, that is part of the second step we would consider, once we have completed the first step (a simple ‘Upload from Internet Archive’ button).
Keep in mind that our resources are going to be pretty limited for this
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
_______________________________
Fabrice Florin Product Manager Wikimedia Foundation
Hi all,
To get the ball started, it should be pretty easy for a community developer
to create a simple tool powered by the Wikimedia Toolserver. This could be done by adapting the Flickr upload bot (4), to perform some of its verification and file transfer functions, such as: retrieving the metadata from the IA Metadata API, confirming that it has the appropriate license, checking a blacklist of contributors, then uploading the file.
Related: Thomas Tanon (User:Tpt) has written a tool to transfer books from the Internet Archive to Wikimedia Commons (and using OAuth \o/)
It lives on Tool Labs http://tools.wmflabs.org/ia-upload
And the code is available on GitHub: https://github.com/Tpt/ia-upload
This is fantastic!
On Sat, Mar 15, 2014 at 2:45 PM, Jean-Frédéric jeanfrederic.wiki@gmail.comwrote:
Hi all,
To get the ball started, it should be pretty easy for a community
developer to create a simple tool powered by the Wikimedia Toolserver. This could be done by adapting the Flickr upload bot (4), to perform some of its verification and file transfer functions, such as: retrieving the metadata from the IA Metadata API, confirming that it has the appropriate license, checking a blacklist of contributors, then uploading the file.
Related: Thomas Tanon (User:Tpt) has written a tool to transfer books from the Internet Archive to Wikimedia Commons (and using OAuth \o/)
It lives on Tool Labs http://tools.wmflabs.org/ia-upload
And the code is available on GitHub: https://github.com/Tpt/ia-upload
-- Jean-Frédéric
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
On Fri, Mar 14, 2014 at 12:29 AM, Samuel Klein meta.sj@gmail.com wrote:
Thank you, Fabrice. Is any followup to the earlier RfC planned, regarding converting mp4-to-ogg on upload?
As Gilles mentioned, based on the RfC results we don't currently have a server-side solution on the table.
I plan to do some research on client-side conversion combined with upload once I've gotten a little farther on the JavaScript Ogg player (which is now working pretty well on Safari 6.1/7 and IE 10/11, and I'm experimenting with Flash-based support for older browsers).
Going client-side means we can use the existing MP4 decoding built into the operating system or browser, combined with shipping a software Ogg or WebM encoder. In my preliminary research there's going to be some ugly tradeoffs, though...
Possibilities are basically:
1) in-browser JavaScript and/or Flash: no installation required, but likely slow. Probably would only work on desktop (assuming my prelim research is correct and it's doable at all!)
2) OS & browser-specifc extension or plugin (similar to Firefogg): requires one-time installation. Not possible for mobile, and historically it's not been easy to get people to install Firefogg. I don't really want to go down this road as there's a potential combinatorial explosion of things to support.
3) OS-specific native helper app: requires one-time installation. Desktop is doable; should be workable but slow on mobile. Requiring installation may be a stopping point for many users.
Of course performance is a big question both on mobile and for a potential JS/Flash in-browser encoder... hence it remains experimental research on my time for now. :)
-- brion
On Mar 14, 2014, at 12:02 PM, Brion Vibber brion@pobox.com wrote:
On Fri, Mar 14, 2014 at 12:29 AM, Samuel Klein meta.sj@gmail.com wrote: Thank you, Fabrice. Is any followup to the earlier RfC planned, regarding converting mp4-to-ogg on upload?
As Gilles mentioned, based on the RfC results we don't currently have a server-side solution on the table.
I plan to do some research on client-side conversion combined with upload once I've gotten a little farther on the JavaScript Ogg player (which is now working pretty well on Safari 6.1/7 and IE 10/11, and I'm experimenting with Flash-based support for older browsers).
Going client-side means we can use the existing MP4 decoding built into the operating system or browser, combined with shipping a software Ogg or WebM encoder. In my preliminary research there's going to be some ugly tradeoffs, though...
Possibilities are basically:
in-browser JavaScript and/or Flash: no installation required, but likely slow. Probably would only work on desktop (assuming my prelim research is correct and it's doable at all!)
OS & browser-specifc extension or plugin (similar to Firefogg): requires one-time installation. Not possible for mobile, and historically it's not been easy to get people to install Firefogg. I don't really want to go down this road as there's a potential combinatorial explosion of things to support.
OS-specific native helper app: requires one-time installation. Desktop is doable; should be workable but slow on mobile. Requiring installation may be a stopping point for many users.
I don’t like the idea of an extra encoding pass of all content that becomes part of the wikimedia archive, I would strongly recommend we work with a partner to upload the original asset into an archive, and have the service re-encode an ingest, with a metadata mapping.
Maybe its less exciting then cross-compling an encoder into javascript ;) but we should think long term and work to preserve the original quality encodes, and in theory patents will expire, and or we will want to re-encod into whatever is free and popular at that point in time.
ffmpeg has been compiled to JS with a nice little library package, but I don’t think its a good idea archive wise. Not to mention this is has much more patent exposure for the users. Instead of legally hosting two or three decoders on WMF, or using decoders that are already on users systems, we would be pushing out patented separate software runtimes for decoders to thousands of users ? Firefogg was already hosted on a seperate domain for this reason.
Thinking ahead, Imagine ORBX.js gains acceptance or Apple buys into Daala, as it delivers on the improvements they are targeting. We would then have 3 passes on all content, getting pretty distant from the H.264 captured by the device.
We are not dealing with mezzanine files, devices already have relatively aggressive low bitrates on consumer captured video assets.
The user should upload the source asset, the server should do the encoding.
Internet archive would be a good partner.
—michael
On Fri, Mar 14, 2014 at 11:39 AM, Michael Dale mdale@wikimedia.org wrote:
On Mar 14, 2014, at 12:02 PM, Brion Vibber brion@pobox.com wrote:
I plan to do some research on client-side conversion combined with upload once I've gotten a little farther on the JavaScript Ogg player (which is now working pretty well on Safari 6.1/7 and IE 10/11, and I'm experimenting with Flash-based support for older browsers).
Going client-side means we can use the existing MP4 decoding built into the operating system or browser, combined with shipping a software Ogg or WebM encoder. In my preliminary research there's going to be some ugly tradeoffs, though...
[snip] I don’t like the idea of an extra encoding pass of all content that becomes part of the wikimedia archive, I would strongly recommend we work with a partner to upload the original asset into an archive, and have the service re-encode an ingest, with a metadata mapping.
*nod* If we end up with a good transcoding partner, that'll obviate the need for this line of research for basic video uploads. (I might still experiment with pure Ogg/WebM encoding for generating animations in-browser, though. I've got all kinds of crazy ideas!)
For the meantime though, client-side transcoding *is* our existing situation, just with less convenient tools -- anything that gets uploaded into our system is likely to have gotten re-encoded from MP4 or something else to Ogg or WebM, and we make all our playback derivatives from that.
Maybe its less exciting then cross-compling an encoder into javascript ;)
That's for sure! ;)
but we should think long term and work to preserve the original quality encodes, and in theory patents will expire, and or we will want to re-encod into whatever is free and popular at that point in time.
*strongly agree*
For the same reason I'm excited about doing on-wiki editing like the stuff you prototyped a while ago; that can save a level of transcoding and makes things more reusable...
ffmpeg has been compiled to JS with a nice little libraryhttp://bgrins.github.io/videoconverter.js/ package, but I don’t think its a good idea archive wise. Not to mention this is has much more patent exposure for the users. Instead of legally hosting two or three decoders on WMF, or using decoders that are already on users systems, we would be pushing out patented separate software runtimes for decoders to thousands of users ? Firefogg was already hosted on a seperate domain for this reason.
Yes, tools like ffmpeg and VLC are tough for us to use directly for patent reasons; if we end up shipping anything ourselves for client-side transcoding it'll have to make use of the system or browser or Flash's existing video decoding facilities or it's a total no-go. For JS that means piggybacking on the <video> element and Web Audio API.
-- brion
multimedia@lists.wikimedia.org