Loading the thumb/medium sizes from the config, saving
things to the db, and loading the image is now all done by
resize_tool. It still calls resize_image for the actual
work.
To get us moving towards a MediaManager class, the first
idea is to create a class that wraps our current dict based
manager and makes all users happy.
Fixes for systems with Pillow, but leaves a "try: except ImportError" to
support anything that doesn't have a PIL top level import.
Signed-off-by: Alon Levy <alon@pobox.com>
The new media type supports pdf and a subset of media recognized by libreoffice via
unoconv.
Every document added goes through:
* conversion to pdf with unoconv if not already a pdf
* creation of thumbnail and medium sized image, and pdfinfo generates
some information (even for unoconv produces docs - should fix this)
Poppler (pdftocairo, pdfinfo) is used. http://poppler.freedesktop.org/
A working but uglified pdf.js integration exists, which is enabled by
setting pdf.pdf_js=true mediagoblin_local.ini (disabled in mediagoblin.ini)
Adds one test to the test_submission test suite, and another separate test_pdf suite.
The tests are only run if media_types.pdf.processing.check_prerequisites passes, so
the test suite will not require any extra package.
TODO: make test suite say 'skipped' in that case instead of just 'ok'
Signed-off-by: Alon Levy <alon@pobox.com>
* cwebber/254_delete_queue_directories:
Removing docstring bit about delete_file possibly deleting directories in the future
Convert media processing backends to delete the queue directory (#254)
Implement delete_dir in the FileStorage
Conflicts:
mediagoblin/media_types/image/processing.py
mediagoblin/media_types/video/processing.py
Conflicts, because those media_types already use the newer
proc_state.delete_queue_file() method (which needs
updating.
Removed the old VideoThumbnailer since it's not used anymore.
VideoThumbnailerMarkII:
Changed the state switching in on_thumbnail_message to only set the
state to "processing thumbnail" if the seek was succesful.
I'm not sure what I'm doing here, but I know at least some of it is
good, and as a whole, it seems to work, so far :)
There were some "serializing to json strings" issues. They should be
fixed now... much more careful whitelist and cleaning of the video
"tags" metadata out of gstreamer.
This commit sponsored by Aimee Sullivan. Thanks!
"vp8 video" is what vp8 is marked as in gstreamer's metadata.
However, the browser expects it just as the name "vp8". So fixing
that.
This commit sponsored by Tyng-Ruey Chuang. Thank you!
The reason for this is to avoid defining this twice as we were
previously (once in the template, once in video/models.py)
This commit sponsored by Roland McIntosh. Thank you!
It's kind of awkward because it relies on there being a entry.media_data,
but that's not guaranteed... (see http://issues.mediagoblin.org/ticket/650)
so we use a dopey fallback in the template in that case (kind of
annoying info duplication).
This commit sponsored by Piotr Wieczorek. Thank you!
Of course, the version that appears here is not really dangerous
because it's for the "call the file individually" form of debugging,
but it isn't allowed anyway.
This commit sponsored by Michael Faryniarz. Thanks!
This comes in several parts:
- Store the metadata from gstreamer during processing
- Add a new JSONEncoded field to the VideoData table
- And, of course, add a migration for that field!
This commit sponsored by Julius Tuomisto. Thank you, Julius!
- Update get_display_media in several ways:
- now uses the media type's own declaration of the order of things
- returns both the media_size and the media_path, as per the docstring
- implicitly uses self.media_files as opposed to forcing you to pass it in
- update videos to use get_display_media
- update images to declare media_fetch_order in the media manager (videos also)
- update stl to use media.media_files['original'] instead of weird
use of get_display_media
- update sidebar to only conditionally show webm_640
TODO still: identify video type information *during* processing, show
that in the <video><source /></video> element.
This commit sponsored by Nathan Yergler. Thanks, nyergler!
There's no reason to copy it over to 'webm_640' in such a case,
clearly.
Added logic so we don't do it twice either.
Haven't tested this yet though ;)
This commit sponsored by Algot Runeman. Thank you!
The idea is to have a class that has the knowledge of the
currently being processed media and also has tools for
that.
The long term idea is to make reprocessing easier by for
example hiding the way the original comes into the
processing code.
For all our media_types, let the backref on the media_entry
be a scalar (there is only one media_data per media_entry)
instead of a list with zero or one entry.
The media_data toolchain on MediaEntry currently handles
both transparently.
We never deleted our queue directory which were created per submission.
With the FileStorage backend being able to delete directories now, we can
request the deletion of the task directory too. It will only be deleted if
it is completely empty.
