Page MenuHomePhabricator

add support for firefogg
Closed, ResolvedPublic

Description

Author: mdale

Description:
Initial patch for support for firefogg transcoding and progress uploading.

live demo here:
http://metavid.org/w/index.php/Special:Upload

We are limited here by the upload api and the fact that firefogg only works with browsers firefox 3.1 and above.

Once we add in an upload api this will work a lot better (won't need to resort to ugly hackery to figure out if the upload was successful)


Version: unspecified
Severity: enhancement
URL: http://firefogg.org

Details

Reference
bz16927

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:25 PM
bzimport set Reference to bz16927.

mdale wrote:

firefogg patch

Attached:

Couple minor notes:

  • Needs localization on the 'Select File' button
  • 'Enable video converter' checkbox should use a <label>
  • Destination filename isn't being automatically set when using the converter option
  • Testing w/ a current 3.1 nightly... it seems to be sticking at '100% - Uploaded'

mdale wrote:

right... firefog api changes (need to update the patch) ... Destination file-name was not available until the most resent version :)
other issue is not handling the complex commons upload form property yet.

update arriving shortly...

mdale wrote:

this patch has been folded into the add_media_wizard.js and re factored with jQuery dependency and in the process of adding chunk support. By moving it into add_media_wizard.js space it can be deployed as a user gadget. Hopefully we can do some test deployment with that next week.

Awesome! *runs off to install firefogg on ff 3.1*

mdale wrote:

(you can test it by adding the following to your user script page:
importScriptURI('http://mvbox2.cse.ucsc.edu/w/extensions/MetavidWiki/skins/add_media_wizard.js');
or
importScriptURI('http://localhost/wiki/extensions/MetavidWiki/skins/add_media_wizard.js');

if you check out the trunk of MetavidWiki locally.

mdale wrote:

oky try again ..fixed the multiple select binding bug and I have it force the link to the file on post request completion (that way it does not look like it hangs at 100% if we don't parse the html result properly)

Better. :D

A couple problems I'm still seeing:

  • Smaller files aren't scaled properly? 320x240 QuickTime videos from my mother's digital camera are getting uploaded with large black borders on the right and bottom.
  • Selecting a .wmv file appears to have no affect -- it doesn't fill out the filename and won't upload. (Tested on Mac OS X; note that I have WMV components for QuickTime installed.) If only some file types are acceptable, there needs to be some feedback when selecting an unusable type...

mdale wrote:

  1. small file scale issue is hard to resolve..its likely a bug with the underling quicktime decoder in ffmpeg. I think you would have the same problem with any ffmpeg based transcoder. We are working on a feature that would expose the resolution of the source media file via firefogg so that we could choose a lower resolution encode in those cases. (This would also avoid ugly up-sampling) ...

In general it does not have scaling issues.. I uploaded a 320x240 wmv and it got converted to 400x300 ogg video without large black borders.

  1. r48590 (firefogg usses ffmpeg (not native quicktime for decodes)). Added .wmf file supported (to our file extension check). Also added a error msg with a link to http://commons.wikimedia.org/wiki/Commons:Firefogg#Supported_File_Types ... (To test the file types select some non-video file)

In practice there may be some wmv files that use the latest M$ codecs that may not work well with ffmpeg... but ~most stuff~ should work.

*nod* For reference if needed for debugging, here's my sample files:

http://leuksman.com/misc/100_3989.mov <- original 320x240 QuickTime

http://leuksman.com/misc/100_3989.580.ogv <- Firefogg output

Per Michael: fixed with the new-upload branched merged back in core.